面向SOA的E/E架構(gòu)設(shè)計數(shù)智化轉(zhuǎn)型實踐

金劭南 高仕寧 李超 吳振舉 陳泓宇 柳菁

【歡迎引用】 金劭南，高仕寧，李超，等. 面向SOA的E/E架構(gòu)設(shè)計數(shù)智化轉(zhuǎn)型實踐[J].汽車文摘， 2024（3）： 31-38.

【Cite this paper】 JIN S N， GAO S N， LI C， et al. Digitalization & Intelligence Transformation Practice of SOA E/E Architecture Design [J]. Automotive Digest （Chinese）， 2024（3）： 31-38.

【摘要】隨著數(shù)智化潮流的推進，使用工具鏈進行整車架構(gòu)開發(fā)已成為傳統(tǒng)車企數(shù)智化轉(zhuǎn)型的關(guān)鍵。通過文獻研究、實操探索等方式，結(jié)合集中式面向服務(wù)的架構(gòu)（SOA）項目開發(fā)實例，研究使用EA、PREEvision工具鏈進行架構(gòu)設(shè)計數(shù)智化轉(zhuǎn)型實踐，闡述相關(guān)工具在整車功能架構(gòu)、軟件架構(gòu)設(shè)計中的應(yīng)用。同時根據(jù)工具在應(yīng)用過程中存在的問題，進行二次插件開發(fā)，解決架構(gòu)設(shè)計過程中存在的瓶頸。通過案例實踐表明，使用上述兩款工具可有效應(yīng)對整車E/E架構(gòu)設(shè)計數(shù)智化轉(zhuǎn)型，提高研發(fā)效率。

主題詞：整車架構(gòu) 數(shù)智化轉(zhuǎn)型 工具鏈 架構(gòu)設(shè)計 功能設(shè)計

中圖分類號：U463.61? ?文獻標(biāo)志碼：A? ?DOI： 10.19822/j.cnki.1671-6329.20220288

Digitalization & Intelligence Transformation Practice of SOA E/E Architecture Design

Jin Shaonan， Gao Shining， Li Chao， Wu Zhenju， Chen Hongyu， Liu Jing

（Global R&D Center， China FAW CorporationLimited， Changchun 130013）

【Abstract】 As the trend of digital intelligence advances， using tool chain to develop vehicle architecture has become the key to the intelligent transformation of traditional automobile enterprises，through literature research， practical exploration and other ways，develop examples in conjunction with centralized SOA architecture projects，This paper studies the use of EA and PREEvision tool chain to carry out intelligent transformation practice of architecture design， describes the application of relevant tools in the design of vehicle functional architecture and software architecture. At the same time， according to the problems existing in the application process of the tool， the secondary plug-in development is carried out to solve the bottleneck in the architecture design process. The case practice shows that the above two tools can effectively cope with the intelligent transformation of vehicle E/E architecture design and improve the research and development efficiency.

Key words： Complete Vehicles Architecture， Digitalization & Intelligence Transformation， Tool Chain， Architecture Design，F(xiàn)unction Design

0 引言

隨著汽車“新四化”（智能化、網(wǎng)聯(lián)化、電動化和共享化）的快速發(fā)展，汽車上的功能需求越來越豐富，車輛ECU控制器數(shù)量大幅度增長，汽車電子通信網(wǎng)絡(luò)越來越復(fù)雜，對整車E/E架構(gòu)的要求也越來越高[1]。傳統(tǒng)分布式汽車電子電氣架構(gòu)存在算力不足、布線復(fù)雜和高耦合性的缺陷，已然不能夠支撐當(dāng)前的技術(shù)挑戰(zhàn)及市場需求。因此在軟件定義汽車的背景下，各大主機廠紛紛提出了面向服務(wù)的架構(gòu)（Service-Oriented Architecture，SOA）。如Volvo-SPA2.0架構(gòu)，其設(shè)計主要原則為標(biāo)準(zhǔn)化服務(wù)，服務(wù)松耦合，構(gòu)建可重復(fù)利用的服務(wù)來實現(xiàn)粗粒度、松耦合、靈活性強的集中式汽車E/E架構(gòu)[2]。

數(shù)字化時代，傳統(tǒng)企業(yè)“數(shù)智化轉(zhuǎn)型”已成為提升效率的必由之路[3]。企業(yè)數(shù)智化轉(zhuǎn)型是利用現(xiàn)代信息技術(shù)對企業(yè)業(yè)務(wù)進行重塑，運用主流、前沿的智能化技術(shù)對業(yè)務(wù)流程及機制進行優(yōu)化和管理，實現(xiàn)業(yè)務(wù)效率的提升和創(chuàng)新，保持企業(yè)的競爭力。在軟件定義汽車的時代背景下，數(shù)智化轉(zhuǎn)型已在汽車行業(yè)內(nèi)逐步應(yīng)用，成為重塑產(chǎn)業(yè)結(jié)構(gòu)的重要動力。很多主機廠都提出了數(shù)智化轉(zhuǎn)型之道。豐田作為數(shù)智化轉(zhuǎn)型的標(biāo)桿，獨創(chuàng)“一頁紙極簡思考法” [4]；大眾也提出了相應(yīng)的數(shù)智化轉(zhuǎn)型計劃，成立汽車軟件組織Car.Software，力爭2030年成為軟件驅(qū)動型的移動出行服務(wù)提供商。

智能網(wǎng)聯(lián)汽車數(shù)智化，學(xué)習(xí)互聯(lián)網(wǎng)思維，實現(xiàn)產(chǎn)品敏捷開發(fā)，即數(shù)字汽車開發(fā)[5]。針對面向SOA的電子電氣（Electrical&Electronic，E/E）架構(gòu)設(shè)計數(shù)智化轉(zhuǎn)型，各傳統(tǒng)車企均處于探索實踐的階段，在這其中使用合適有效的工具鏈可以有效提升研發(fā)效率[6]。本文在SOA架構(gòu)思維下，探究整車E/E架構(gòu)設(shè)計中功能架構(gòu)設(shè)計和軟件架構(gòu)設(shè)計數(shù)智化轉(zhuǎn)型的解決方案并實踐，同時根據(jù)工具鏈間存在的痛點問題，對工具鏈進行二次開發(fā)，滿足業(yè)務(wù)靈活度及契合度。

1 面向SOA的E/E架構(gòu)設(shè)計

1.1 傳統(tǒng)E/E架構(gòu)設(shè)計

以傳統(tǒng)基于域控制架構(gòu)開發(fā)的實際流程為例，基于域控制器的傳統(tǒng)分布式架構(gòu)開發(fā)是以車型裝備定義作為輸入，在各階段輸出相應(yīng)的功能設(shè)計規(guī)范傳遞給下游，指導(dǎo)其系統(tǒng)開發(fā)，傳統(tǒng)E/E架構(gòu)設(shè)計如圖1所示。

基于域控制架構(gòu)開發(fā)的核心是以控制器為主線進行的架構(gòu)設(shè)計。首先通過裝備定義明確車型定位，在架構(gòu)設(shè)計階段，依據(jù)裝備定義明確車型需要的所有功能，輸出功能特性列表。再對功能進行功能域劃分，結(jié)合ECU控制器按照功能域輸出架構(gòu)設(shè)計方案。在此基礎(chǔ)上輸出每個功能的詳細功能描述方案。然而在“軟件定義汽車”的時代下，功能需求呈爆發(fā)式增長，該設(shè)計模式不能夠完美適應(yīng)新架構(gòu)思想下的開發(fā)設(shè)計，且傳統(tǒng)開發(fā)流程中各環(huán)節(jié)的輸出物為文檔，并未合理使用相關(guān)工具鏈，難以順應(yīng)當(dāng)前傳統(tǒng)車企數(shù)智化發(fā)展趨勢[7]。

1.2 面向SOA的E/E功能架構(gòu)設(shè)計

相較于傳統(tǒng)的E/E架構(gòu)開發(fā)，面向SOA的架構(gòu)開發(fā)更側(cè)重于降低軟件的耦合度，抽象并暴露出更多的服務(wù)。本文參考AUTOSAR[8]標(biāo)準(zhǔn)中關(guān)于方法論的描述，以集中式SOA架構(gòu)項目為例，提出一種基于集中式SOA架構(gòu)的功能開發(fā)方案，如圖2所示。

基于圖2的功能架構(gòu)設(shè)計，SOA的功能架構(gòu)開發(fā)過程中，同樣以裝備定義作為輸入，用于描述整車產(chǎn)品的定位。不同于傳統(tǒng)架構(gòu)開發(fā)以電子控制單元（Electronic Control Unit，ECU）控制器作為主線，SOA的功能架構(gòu)開發(fā)過程中更側(cè)重于功能和服務(wù)[9]。輸出功能特性列表后進行功能定義、功能設(shè)計和服務(wù)抽象。借鑒互聯(lián)網(wǎng)開發(fā)的思維，在此過程中輸出用例圖和時序圖給下游專業(yè)。其中用例圖用來描述功能的定義內(nèi)容，功能設(shè)計則是對車輛平臺軟件和硬件的能力分析，提取出產(chǎn)品能力（Product Capability， PC），并描述各能力之間的交互，最終形成時序圖。

1.3 面向SOA的E/E軟件架構(gòu)設(shè)計

集中式SOA架構(gòu)定義了整車級SOA軟件架構(gòu)，通過分層部署，提取出全局變量的服務(wù)（如車速、時間、車輛狀態(tài)等），并將其作為通用的軟件模塊服務(wù)，以實現(xiàn)基礎(chǔ)功能軟件接口統(tǒng)一，并可靈活部署（圖3）。

上述工作需要在項目開發(fā)一開始便設(shè)計好，之后的軟件架構(gòu)工作均需圍繞其開展。結(jié)合集中式SOA架構(gòu)項目下整車E/E架構(gòu)開發(fā)流程，其軟件架構(gòu)設(shè)計方案如圖4所示。

在軟件架構(gòu)設(shè)計之初，便需要對整車SOA架構(gòu)進行合理分層以及模塊劃分，搭建整個軟件架構(gòu)的框架，用于承接功能架構(gòu)所輸出的平臺能力（PC）。

當(dāng)接收到功能架構(gòu)設(shè)計所輸出的平臺能力（PC）后，由軟件架構(gòu)進行承接，對PC進行模塊部署，落到對應(yīng)的模塊中，之后需要對模塊進行設(shè)計（Module Design）。軟件架構(gòu)設(shè)計即根據(jù)平臺能力PC在Module上進行軟件組件（Software Component，SWC）劃分，并以輸入的平臺能力（PC）為參考，對SWC進行接口設(shè)計。將上一節(jié)內(nèi)容產(chǎn)出的PC對功能的描述轉(zhuǎn)化為軟件描述。

2 面向SOA的E/E架構(gòu)數(shù)智化轉(zhuǎn)型工具鏈

在數(shù)智化大背景下，使用合理的工具鏈進行開發(fā)設(shè)計可有效地提升研發(fā)效率[10-11]，高效對產(chǎn)出物進行管理，實現(xiàn)多人協(xié)同辦公。結(jié)合集中式SOA架構(gòu)項目實際開發(fā)過程，闡述相應(yīng)工具鏈的使用情況。

2.1 軟件生命周期設(shè)計工具——Enterprise Architect

Enterprise Architect（EA）是SparxSystems公司開發(fā)的旗艦產(chǎn)品，是一款基于統(tǒng)一建模語言（UnifiedModelingLanguage，UML）的可視化建模與設(shè)計工具[12-13]。Enterprise Architect是一個對于軟件系統(tǒng)開發(fā)有著極好支持的計算機輔助工程軟件（Computer Aided Software Engineering，CASE）。不同于VISIO等其他UML建模工具，CASE能夠支撐系統(tǒng)開發(fā)全過程，且支持多人協(xié)同操作，滿足團隊開發(fā)設(shè)計，同時能根據(jù)項目實際需求進行二次開發(fā)，有效提高建模設(shè)計效率及管理能力（圖5）。

結(jié)合面向SOA架構(gòu)開發(fā)過程中功能架構(gòu)開發(fā)流程的相關(guān)活動，EA主要用于功能定義設(shè)計及模塊、SWC定義等相關(guān)環(huán)節(jié)。主要建模內(nèi)容如下：

（1）用例（Use Case，UC）：系統(tǒng)功能基本描述，結(jié)合項目實際情況。

（2）用例圖：描述參與者與系統(tǒng)功能間的交互形式。

（3）狀態(tài)機圖：描述了一個對象在其生命周期內(nèi)所經(jīng)歷的各種狀態(tài)，以及狀態(tài)之間的轉(zhuǎn)移、發(fā)生轉(zhuǎn)移的原因、條件和轉(zhuǎn)移中所執(zhí)行的活動。

（4）產(chǎn)品能力PC：描述整車產(chǎn)品所需提供的車輛能力。

（5）時序圖：描述平臺能力PC之間發(fā)送消息的時間順序顯示多個對象之間的動態(tài)協(xié)作。

（6）SWC：AUTOSAR標(biāo)準(zhǔn)制定目標(biāo)之一，將PC的功能描述轉(zhuǎn)化為軟件描述。

2.2 軟件架構(gòu)設(shè)計工具——PREEvision

PREEvision提供給開發(fā)人員完整的協(xié)同開發(fā)平臺，可用于基于AUTOSAR的軟件架構(gòu)設(shè)計，支持SWC的創(chuàng)建劃分以及接口的定義設(shè)計，為軟件架構(gòu)的定義和端口連接提供圖形支持，同時PREEvision還支持不同版本AUTOSAR軟件技術(shù)規(guī)范的導(dǎo)入和導(dǎo)出[14-15]。

使用PREEvision進行軟件建模的優(yōu)勢主要有2點：

（1）PREEvision支持AUTOSAR標(biāo)準(zhǔn)，滿足集中式SOA架構(gòu)項目的建設(shè)需求。

（2）PREEvision能夠很好的進行全鏈條的追溯，當(dāng)其中某一環(huán)節(jié)發(fā)生改動時，PREEvision能夠展示出所有與之關(guān)聯(lián)的變動，供開發(fā)人員進行參考。

3 面向SOA的E/E架構(gòu)數(shù)智化轉(zhuǎn)型實踐

在集中式SOA架構(gòu)項目開發(fā)過程中嘗試使用EA、PREEvision相關(guān)工具鏈進行架構(gòu)模型的構(gòu)建。其中，使用EA實現(xiàn)功能架構(gòu)設(shè)計相關(guān)內(nèi)容，包括上述多種UML繪制、SWC和接口定義；使用PREEvision實現(xiàn)軟件架構(gòu)設(shè)計內(nèi)容，包括服務(wù)定義、SWC、接口的定義和設(shè)計，以及自適應(yīng)應(yīng)用（Adaptive Application）設(shè)計。本章以信息娛樂域中“車外模擬人工聲音”功能為例，闡述當(dāng)前面向SOA的E/E架構(gòu)開發(fā)數(shù)智化轉(zhuǎn)型實踐情況。

3.1 基于EA的電子電氣功能架構(gòu)設(shè)計

在功能架構(gòu)開發(fā)階段，主要使用EA進行UML模型的繪制。完成功能定義、功能設(shè)計及平臺能力PC部署建模。

3.1.1 功能定義

功能定義階段主要是將用戶需求轉(zhuǎn)化為工程需求，并運用行業(yè)標(biāo)準(zhǔn)UML語言進行建模規(guī)范。在功能定義階段主要工作是使用EA來定義功能用例（UC），并繪制UC圖。在設(shè)計每個功能的用例時，要明確以下屬性：

（1）描述：包括UC名稱及UC的詳細描述，對本UC進行簡單描述。

（2）前置條件/后置條件：描述該UC生效的前提條件和觸發(fā)UC后的狀態(tài)。

（3）場景：描述UC在觸發(fā)期間整個事件流，包括基本事件、異常事件和備選事件。

（4）非功能需求：為滿足功能而必須具有的功能需求以外的特性，包括安全性、可靠性、法規(guī)要求和時效性。

本文以“車外模擬人工聲音”為例將整個大功能的使用場景通過需求分析拆分成多個UC。

當(dāng)定義好UC后，還需定義“參與者”，即描述觸發(fā)用例的角色，如駕駛員和乘客。還需要繪制時序圖，建立“參與者”、“用例”和非功能需求之間的聯(lián)系，如圖6所示。

在功能設(shè)計階段使用EA工具可以很好地使用工程描述語言表示出用戶與功能之間地交互關(guān)系，供相關(guān)專業(yè)開發(fā)人員進行開發(fā)。

3.1.2 功能設(shè)計

完成用例設(shè)計后，需要對每個用例進行功能設(shè)計，即為實現(xiàn)功能所需要的時序設(shè)計。該階段同樣在EA工具上使用UML建模語言進行動態(tài)交互圖設(shè)計。將UC涉及到的信息，功能實現(xiàn)過程和場景進行細化，參考功能定義中的前置條件、后置條件、功能場景進行設(shè)計，在設(shè)計過程中可以不斷發(fā)現(xiàn)功能設(shè)計階段所存在的遺漏點和不合理之處，不斷優(yōu)化迭代。

功能設(shè)計首先根據(jù)功能定義中的信息提出平臺能力（PC），明確為實現(xiàn)全部功能整車需要提供什么樣的能力，以“車外模擬人工聲音”為例，為實現(xiàn)這個功能需要車輛具備模擬發(fā)動機聲音的能力，同時根據(jù)不同車速發(fā)出不同音效，還需要車輛具備獲取車速的能力。在設(shè)計PC時，需要考慮如下因素：

（1）PC名稱及描述：描述PC所提供的能力

（2）PC相關(guān)操作：描述PC之間交互的操作，如獲取車速信息，獲取車輛狀態(tài)；

（3）PC相關(guān)操作返回數(shù)據(jù)類型：PC間交互后返回數(shù)據(jù)的類型，為基本數(shù)據(jù)類型或結(jié)構(gòu)體。

本文以“車外模擬人工聲音”功能為例，給出EA工具鏈PC設(shè)計過程。PC設(shè)計過程見表1及圖7所示。

在初步提出PC后，需要使用這些提出的PC進行功能時序設(shè)計，其目的是通過同臺交互設(shè)計使用這些PC，共同協(xié)同工作實現(xiàn)整個用例UC。該過程使用UML時序圖進行工程描述。在繪制時序圖時，主要有考慮到如下因素。

（1）對象：實現(xiàn)功能的主要對象，即消息實體。在此主要包括參與者與上一步驟中所提到的PC。

（2）生命線：即功能實現(xiàn)的參與生命線。

（3）消息：各對象間交互的內(nèi)容，實現(xiàn)功能事件的動態(tài)交互，主要用到了同步消息與異步消息，依據(jù)實現(xiàn)的內(nèi)容不同來進行選擇。

（4）組合片段：包括一些條件判斷框，如選項片段（Opt）、備選條件進入框（Alt）、并行執(zhí)行框（Par）等。用于處理用例（UC）中場景信息涉及到的不同情況。

本文以“車外模擬人工聲音”功能中的功能設(shè)計為例，給出功能設(shè)計示例，如圖8所示。

在繪制時序圖過程中可以檢驗上一步設(shè)計PC的合理性，保證每個PC的顆粒度是合理的，能夠覆蓋整個功能的完整生命周期，因此在功能設(shè)計階段PC的設(shè)計以及時序圖設(shè)計是一個相互迭代的過程，保證最終功能設(shè)計結(jié)果是合理的。

3.1.3 SWC及其接口定義

為了能夠建立PC上下游間的追溯關(guān)系，功能架構(gòu)設(shè)計階段還需要在EA中完成PC的部署錄入工作，建立SWC及其接口，需要說明的是在EA中并不進行Module及SWC的設(shè)計工作，僅完成定義工作。其目的有2點：（1）方便對PC進行管理，后續(xù)PC可以對其他功能進行復(fù)用，方便PC的快速查找、迭代更新及管理。（2）在EA進行建模后可以提供良好的全鏈條關(guān)系追溯能力，后續(xù)可對每個功能的UC—PC—Module—SWC—接口進行全鏈條追溯，提升開發(fā)效率（圖9）。

3.2 基于PREEvision的電子電氣軟件架構(gòu)設(shè)計

3.2.1 基于PREEvision的分層與模塊設(shè)計

在進行軟件架構(gòu)開發(fā)之初便需制定好整個E/E架構(gòu)分層設(shè)計與模塊設(shè)計，通常情況下該結(jié)構(gòu)后期不會更改，用于支撐整個功能架構(gòu)及軟件架構(gòu)的開發(fā)，依據(jù)1.3節(jié)中圖3的劃分思想，本文按照功能域給出服務(wù)接口層級設(shè)計，如圖10所示。

本項目依照圖10的服務(wù)層級設(shè)計對整車進行接口層級劃分，保證后期的維護和管理，并在PREEvision里進行結(jié)構(gòu)創(chuàng)建，如圖11所示。

在PREEvision中創(chuàng)建好結(jié)構(gòu)后，后續(xù)的服務(wù)及SWC建模均在此結(jié)構(gòu)上進行，因此在架構(gòu)設(shè)計之初分層與模塊設(shè)計非常重要，決定后續(xù)軟件架構(gòu)開發(fā)的合理性。

3.2.2 基于PREEvision的服務(wù)設(shè)計

在接收到功能架構(gòu)的PC輸入后，在軟件架構(gòu)開發(fā)階段需要先進行服務(wù)抽象，將PC轉(zhuǎn)化為服務(wù)。在AUTOSAR標(biāo)準(zhǔn)的指導(dǎo)下[8]，PREEvision支持開發(fā)二次插件腳本實現(xiàn)自動建模，導(dǎo)入標(biāo)準(zhǔn)格式的Excel并自動完成服務(wù)功能的搭建。為了保證準(zhǔn)確導(dǎo)入，在服務(wù)設(shè)計階段，需要按照規(guī)范格式編寫軟件服務(wù)Excel表格，二次開發(fā)腳本對輸入表格進行解析，執(zhí)行插件腳本即可導(dǎo)入服務(wù)模型到PREEvision，以車外模擬人工聲音功能為例，設(shè)計車速相關(guān)的功能服務(wù)，其解析前的Excel如表2所示。

PREEvision導(dǎo)入上述excel表并進行解析，在工具中自動創(chuàng)建相關(guān)服務(wù)接口，創(chuàng)建結(jié)果如圖12所示。

3.2.3 基于PREEvision的SWC設(shè)計

在AUTOSAR中，軟件架構(gòu)由SWC組成，通過服務(wù)接口的軟件實現(xiàn)。軟件架構(gòu)開發(fā)過程中依據(jù)傳遞過來的PC進行SWC設(shè)計，并在PREEvision中進行實現(xiàn)。本文以AP建模規(guī)范為例，依據(jù)所實現(xiàn)的服務(wù)來創(chuàng)建SWC，在Root Composition中新建用于AP的組成（Composition），并在該Composition中新建對應(yīng)的自適應(yīng)應(yīng)用軟件組件（Adaptive Application SW Component），如圖13所示。

3.2.4 基于PREEvision的SWC接口設(shè)計

定義好SWC后，還需添加對應(yīng)的 Adaptive Required/Provided Port，建立服務(wù)于SWC之間的關(guān)系，在此步驟中需要重新命名并將Required Port和Provided Port建立連接。將需要進行AP設(shè)計的Service Interface直接拖拽至AP Required/Provided接口。以獲取車速信息的SWC為例，在PREEvision中SWC接口設(shè)計如圖14所示。

3.2.5 基于PREEvision的Adaptive Application設(shè)計

在AUTOSAR方法論中，AP是可執(zhí)行文件（Executables）的集合，一個Executable源于一個AP SWC，在PREEvision中設(shè)計方法如下。

（1）在System Software Architecture下新建 SW Package， 在此Package下新建兩個名稱為 Application和Executable的SW Package，在兩個SW Package下分別創(chuàng)建Adaptive Application以及Executable。

（2）在Adaptive Application的General屬性窗口，選擇Adaptive Application Kind為Application Level或者Platform Level。

（3）在Adaptive Application 欄 Adaptive Application Editor中將APP與Executable關(guān)聯(lián)，并填寫Adaptive Application Version信息，Executable Build Type及Version信息，將AP SWC與對應(yīng)Adaptive Application建立關(guān)聯(lián)。

Adaptive Application設(shè)計完成后，最終以Application為單位，導(dǎo)出ARXML供下游專業(yè)進行軟件開發(fā)。

3.3 關(guān)鍵工具鏈二次開發(fā)設(shè)計

使用工具鏈進行面向SOA的E/E架構(gòu)開發(fā)可以提升研發(fā)效率，提升了模型管理及維護能力，減少容錯率，一定程度上保證了模型的嚴(yán)謹(jǐn)性。但工具并非萬能，一方面開發(fā)過程中使用工具可有效提升工作效率，實現(xiàn)一定程度上的數(shù)智化轉(zhuǎn)型，另一方面工具的局限性可能會帶來一些重復(fù)冗余的工作，給開發(fā)設(shè)計增添了工作量。無論是EA還是PREEvision，都并非能按照實際開發(fā)需求進行完美適配，在開發(fā)過程中難免會存在一定的局限。本文結(jié)合項目實踐過程中發(fā)現(xiàn)的問題進行總結(jié)并給出解決方案：

（1）對建模內(nèi)容管理困難

在開發(fā)過程中，EA上維護了超過300個功能、3 000個UC、6 000個平臺能力PC。EA工具缺乏對這些功能的導(dǎo)出，只能在工具上進行查看，對于不使用EA的開發(fā)人員來說，不方便查看建模內(nèi)容。

（2）無法高效產(chǎn)出功能需求文檔

在面向SOA架構(gòu)開發(fā)需要產(chǎn)出功能需求文檔（Product Requirement Document，PRD）傳遞給下游專業(yè)進行實現(xiàn)，目前在EA上實現(xiàn)的建模內(nèi)容只能通過手動粘貼的方式來編寫PRD，在此過程中產(chǎn)生了一些不必要的工作，且容易出現(xiàn)人為失誤。

（3）EA工具缺乏對全鏈條追溯的能力

UC、PC等模型元素雖然可通過建模的方式進行關(guān)聯(lián)追溯，但EA工具鏈中缺少相關(guān)功能能夠直觀展現(xiàn)這些關(guān)系，且不支持全鏈條關(guān)系導(dǎo)出供開發(fā)人員參考，在實際工作中會產(chǎn)生一定的麻煩。

（4）EA工具與PREEvision工具間未實現(xiàn)打通

從前兩節(jié)的實踐操作中可以看出，在架構(gòu)開發(fā)中主要使用的工具鏈為EA和PREEvision，2個工具相互獨立，且在各自的工作范圍內(nèi)有重復(fù)的工作，增添了冗余的操作，一定程度上降低了工作效率，且不能實現(xiàn)聯(lián)動更新，為后期維護增添了困難。

針對上述存在的問題，考慮到EA以及PREEvision均可支持二次插件開發(fā)來提高生產(chǎn)效率，如圖15所示。

本文結(jié)合工作實際情況中存在的問題瓶頸，在插件開發(fā)過程中給出解決問題的思路及辦法。

（1）針對EA上模型管理困難的問題，可以考慮通過EA二次開發(fā)插件程序，抓取UC、PC元素并獲取到模型元素中的信息，通過Excel表的形式導(dǎo)出，供架構(gòu)開發(fā)人員進行管理?？紤]到功能數(shù)量繁多、模型信息需要人為錄入缺乏規(guī)范性管理，可以制定相應(yīng)的規(guī)范標(biāo)準(zhǔn)，制定屬性信息描述范式與命名規(guī)則。同時可以按功能域進行劃分，對用例進行管理。

（2）針對EA模型無法導(dǎo)出功能需求文檔PRD的問題，同樣可以使用二次插件開發(fā)的方法進行解決。首先需要規(guī)定好PRD文檔的模板，通過抓取EA中用例圖、時序圖及相關(guān)模型元素的信息，導(dǎo)出PRD初版文檔，該文檔中包含在EA中建模所有內(nèi)容，PRD中其它與模型無關(guān)的（如用戶故事、法規(guī)項等）內(nèi)容在導(dǎo)出后的文檔中補充即可，避免重復(fù)操作，減少開發(fā)人員的工作量（圖16）。

（3）針對功能全鏈條難以追溯的問題，主要原因是EA工具的局限性，不能完美適配面向SOA的整車E/E架構(gòu)開發(fā)，同樣可以通過開發(fā)插件的方式進行彌補，將EA上的模型元素建立關(guān)聯(lián)關(guān)系后，選擇相應(yīng)的功能或某個特定的UC，實現(xiàn)從Function -UC-PC-Module-SWC的全鏈條導(dǎo)出，如圖17所示。

（4）由于在開發(fā)過程中使用到了EA以及PREEvision兩套工具，其相互獨立，未形成聯(lián)動，導(dǎo)致創(chuàng)建SWC和SWC的接口等工作在兩套工具上都進行了一遍，重復(fù)工作在開發(fā)過程中費時費力，且容易出現(xiàn)差錯，一旦其中一種工具上進行了修改，很難同步到另一種工具上，導(dǎo)致后期圍護工作量加大。為解決此問題，可以對EA上的SWC模型進行導(dǎo)出標(biāo)準(zhǔn)格式的Excel文件，同時在PREEvision上也進行二次開發(fā)，將Excel文件導(dǎo)入到PREEvision上進行自動建模，保證工具鏈之間建模內(nèi)容的一致性，避免重復(fù)的操作，提升工作效率。通過EA二次開發(fā)插件所導(dǎo)出Excel格式文件如圖18所示。

4 結(jié)束語

在面向SOA架構(gòu)開發(fā)的過程中，EA和PREEvision是2款可以提高開發(fā)及管理效率的數(shù)智化轉(zhuǎn)型工具。利用EA工具可以有效開展功能架構(gòu)設(shè)計工作，通過UML語言可很好的闡述功能定義和功能實現(xiàn)邏輯。PREEvision可以很好的對SWC進行設(shè)計并導(dǎo)出ARXML供下游進行軟件開發(fā)，并提供優(yōu)秀的追溯性。同時結(jié)合兩款軟件的不足之處和局限性，有針對性的進行二次開發(fā)，解決了開發(fā)流程中所存在的問題，打通了工具之間的瓶頸，使其更加適配于項目本身，提升設(shè)計效率，改善設(shè)計質(zhì)量。

參 考 文 獻

[1] 李丹， 呂穎， 李駿， 等. 面向服務(wù)的體系架構(gòu)[J]. 汽車文摘， 2021（10）： 52-57.

[2] 王東， 李井波， 張晨暉， 等. 一種基于SOA架構(gòu)的總線系統(tǒng)：CN112822080B[P]. 2022-09-16.

[3] 編輯部. 德國大眾旗下CARIAD攜手意法半導(dǎo)體面向軟件定義汽車[J]. 單片機與嵌入式系統(tǒng)應(yīng)用， 2022， 22（10）：2-2.

[4] 金華旺， 張桂新. 工業(yè)企業(yè)數(shù)智化轉(zhuǎn)型關(guān)鍵問題及推進路徑研究[J]. 信息系統(tǒng)工程， 2022， 346（10）： 14-17.

[5] KUGELE S， HETTLER D， PETER J.Data-centric communication and containerization for future automotive software architectures[C]. IEEE International Conference on Software Architecture （ICSA）， 2018.

[6] 李升凱， 吳長水. 智能駕駛硬件計算平臺及CAN通信軟件設(shè)計[J]. 軟件工程， 2022， 25（7）： 51-54.

[7] 唱佳韻， 孫明陽. 汽車文化APP界面設(shè)計研究——以紅旗汽車文化APP界面設(shè)計為例[J].工業(yè)設(shè)計， 2022， 195（10）： 64-66.

[8] 詹克旭. 基于AUTOSAR架構(gòu)的汽車電子軟件產(chǎn)品的開發(fā)方法[J]. 汽車電器， 2021（11）： 73-76.

[9] 王飛飛， 劉夢夢， 翟曉蘭. 智能網(wǎng)聯(lián)汽車測試示范區(qū)發(fā)展模式探究[J]. 汽車實用技術(shù)， 2022（13）： 26-30.

[10] 李震， 劉敏. 基于AUTOSAR的整車電子電氣架構(gòu)設(shè)計方法[J]. 機電一體化， 2012（11）： 73-76.

[11] 伏軍鋒. 汽車電氣系統(tǒng)設(shè)計[J]. 汽車電器， 2010（1）： 1-5.

[12] 陳敏. 基于EA的電子電氣架構(gòu)功能設(shè)計探討[J]. 汽車電器， 2022（6）： 38-41+45.

[13] FENG J T. UML-Based Radar Software Design[C]//Proceedings of 5th International Conference on Electrical & Electronics Engineering and Computer Science（ICEEECS 2018）， 2018： 426-429.

[14] 王永輝. 基于PREEvision的汽車電子電氣架構(gòu)設(shè)計介紹[J]. 汽車實用技術(shù)， 2019， 294（15）： 111-112.

[15] 匡小軍， 唐香蕉， 周濤， 等. 基于PREEvision的汽車電子電氣架構(gòu)工具鏈研究[J]. 汽車電器， 2019， 372（8）： 62-64.

（責(zé)任編輯 明慧）

【作者簡介】

金劭南（1995-），男，中國第一汽車股份有限公司研發(fā)總院，碩士，研究方向為整車電子電氣架構(gòu)設(shè)計。

高仕寧（1984-），男，中國第一汽車股份有限公司研發(fā)總院，碩士，研究方向為整車電子電氣架構(gòu)設(shè)計。

李超（1986-），男，中國第一汽車股份有限公司研發(fā)總院，碩士，研究方向為整車電子電氣架構(gòu)設(shè)計。

吳振舉（1982-），男，中國第一汽車股份有限公司研發(fā)總院，學(xué)士，研究方向為整車電子電氣架構(gòu)設(shè)計。

陳泓宇（1990-），男，中國第一汽車股份有限公司研發(fā)總院，碩士，研究方向為整車電子電氣架構(gòu)設(shè)計。

柳菁（1989-），女，中國第一汽車股份有限公司研發(fā)總院，學(xué)士，研究方向為整車電子電氣架構(gòu)設(shè)計。