【摘 要】 在軟件定義汽車(chē)時(shí)代背景下，新一代的汽車(chē)電子電氣架構(gòu)（以下簡(jiǎn)稱(chēng)E/E 架構(gòu)） 不斷進(jìn)化。物理拓?fù)渖希刂破鱁CU 數(shù)量大幅減少，集中度提高，拓?fù)浞绞綇姆植际降接蚣惺?，再到中央集成大腦逐步演進(jìn)；功能開(kāi)發(fā)思路上，從傳統(tǒng)的以明確各ECU 之間交互為主體任務(wù)，實(shí)現(xiàn)功能為主線，切換到現(xiàn)在的以服務(wù)定義和ECU的軟件接口設(shè)計(jì)為主體，窮盡硬件平臺(tái)能力為主線，覆蓋面更廣，功能開(kāi)發(fā)深度更深。傳統(tǒng)的基于文檔的功能設(shè)計(jì)方式，已不足以滿(mǎn)足現(xiàn)階段功能開(kāi)發(fā)需求。本文結(jié)合項(xiàng)目實(shí)踐案例，基于Enterprise Architect（以下簡(jiǎn)稱(chēng)：EA） 工具對(duì)SOA（Service Oriented Architecture，面向服務(wù)架構(gòu)） 架構(gòu)功能設(shè)計(jì)方法進(jìn)行應(yīng)用和探索。

隨著汽車(chē)行業(yè)向智能化、 數(shù)字化和電動(dòng)化發(fā)展， 現(xiàn)存大部分汽車(chē)的E/E架構(gòu)由于ECU數(shù)量眾多、 線束繁瑣復(fù)雜、算力低和功能耦合度高等問(wèn)題， 無(wú)法實(shí)現(xiàn)高級(jí)別自動(dòng)駕駛和快速OTA （Over The Air， 空中下載技術(shù)） 升級(jí)， 從而無(wú)法滿(mǎn)足人們對(duì)汽車(chē)的多樣化需求。主要的挑戰(zhàn)有高級(jí)別自動(dòng)駕駛所要求的實(shí)時(shí)性和安全性高， 人工智能機(jī)器學(xué)習(xí)所需要的大數(shù)據(jù)量和高帶寬需求， 還有滿(mǎn)足未來(lái)多節(jié)點(diǎn)連接（比如車(chē)路協(xié)同、 云代駕等） 所帶來(lái)的信息安全問(wèn)題[1]。為更好地解決上述汽車(chē)行業(yè)挑戰(zhàn)， E/E架構(gòu)拓?fù)湫问皆诓粩嘌葸M(jìn)， 新的通信方式和開(kāi)發(fā)方法也從工業(yè)或IT領(lǐng)域引入， 給汽車(chē)行業(yè)提供了豐富的技術(shù)參考。

針對(duì)E/E架構(gòu)功能開(kāi)發(fā)方法， 其內(nèi)容和開(kāi)發(fā)思路也發(fā)生了變化。本文通過(guò)對(duì)比傳統(tǒng)架構(gòu)功能開(kāi)發(fā)流程和SOA架構(gòu)功能開(kāi)發(fā)流程， 指出傳統(tǒng)架構(gòu)功能設(shè)計(jì)環(huán)節(jié)可能存在的不足， 結(jié)合具體項(xiàng)目實(shí)例， 提出一種基于EA的功能設(shè)計(jì)方法， 以滿(mǎn)足架構(gòu)功能開(kāi)發(fā)過(guò)程中對(duì)功能設(shè)計(jì)的需求。

1 E/E架構(gòu)功能開(kāi)發(fā)介紹

1.1 E/E架構(gòu)功能開(kāi)發(fā)流程

參考AUTOSAR標(biāo)準(zhǔn)中關(guān)于方法論的文檔描述， 圍繞E/E架構(gòu)功能開(kāi)發(fā)主線， 可以將開(kāi)發(fā)流程從上到下， 從虛到實(shí)， 分為4個(gè)層級(jí)的步驟：產(chǎn)品層、 虛擬功能層、 系統(tǒng)層、子系統(tǒng)層。

1） 產(chǎn)品層：主要定義整車(chē)層級(jí)的功能需求， 屬于整車(chē)產(chǎn)品定義的范疇， 包含整車(chē)功能對(duì)標(biāo)分析、 功能清單梳理、功能配置管理等。此部分內(nèi)容不在本文討論范疇。

2） 虛擬功能層：主要定義整車(chē)層級(jí)的功能交互關(guān)系，也就是本論文涉及的內(nèi)容， 一般包含功能定義和功能實(shí)現(xiàn)設(shè)計(jì)兩個(gè)部分。

3） 系統(tǒng)層：主要承接虛擬功能層的輸出， 對(duì)功能實(shí)現(xiàn)涉及的邏輯模塊進(jìn)行分配， 定義ECU層級(jí)的交互關(guān)系， 包括ECU之間的連接拓?fù)潢P(guān)系、 功能交互時(shí)序、 ECU接口定義、 服務(wù)定義、 通信定義等。

4） 子系統(tǒng)層級(jí)：聚焦具體ECU， 對(duì)承接的功能邏輯模塊進(jìn)一步詳細(xì)設(shè)計(jì)， 定義應(yīng)用層軟件架構(gòu)， 軟件組件SWC之間的接口交互、 服務(wù)接口設(shè)計(jì)、 SWC運(yùn)行設(shè)計(jì)等。

E/E架構(gòu)功能開(kāi)發(fā)過(guò)程層級(jí)說(shuō)明如圖1所示。

圖1 EE架構(gòu)功能開(kāi)發(fā)層級(jí)說(shuō)明

圖1中， 產(chǎn)品層級(jí)的整車(chē)功能分析主要任務(wù)為結(jié)合市場(chǎng)情況、 競(jìng)爭(zhēng)對(duì)手分析、 公司戰(zhàn)略、 終端用戶(hù)需求和自身產(chǎn)品定位等信息， 對(duì)整車(chē)項(xiàng)目所需要實(shí)現(xiàn)的功能進(jìn)行對(duì)標(biāo)分析， 提煉出所需要實(shí)現(xiàn)的功能清單和配置信息， 輸出給到E/E架構(gòu)進(jìn)行功能實(shí)現(xiàn)。

對(duì)于虛擬功能層的整車(chē)功能設(shè)計(jì)環(huán)節(jié)， 承接產(chǎn)品層級(jí)輸出的功能清單， 對(duì)清單上的每一個(gè)功能進(jìn)行定義， 拆分功能用例；功能實(shí)現(xiàn)層面， 對(duì)某一具體功能用例， 進(jìn)行功能實(shí)現(xiàn)設(shè)計(jì)， 包括功能邏輯模塊設(shè)計(jì)、 模塊交互設(shè)計(jì)、 狀態(tài)機(jī)等。

而系統(tǒng)層級(jí)和子系統(tǒng)層級(jí)設(shè)計(jì)， 則是依據(jù)上述功能設(shè)計(jì)環(huán)節(jié)的輸出結(jié)果， 對(duì)其中的功能邏輯模塊進(jìn)行具體ECU或SWC的映射， 映射關(guān)系可以是一對(duì)一或多對(duì)一；對(duì)交互接口進(jìn)行進(jìn)一步詳細(xì)細(xì)化， 區(qū)分ECU間或ECU內(nèi)部接口，定義內(nèi)外部接口的類(lèi)型、 協(xié)議和數(shù)據(jù)類(lèi)型。這一步做完后，即可提煉出對(duì)具體ECU的功能邏輯需求和接口需求， 用以指導(dǎo)Tier1的開(kāi)發(fā)。

1.2 功能設(shè)計(jì)流程需求分析

由上述分析可知， 虛擬功能層所包含的功能設(shè)計(jì)位于產(chǎn)品分析和系統(tǒng)層設(shè)計(jì)之間， 是從整車(chē)層級(jí)過(guò)渡到ECU級(jí)的重要環(huán)節(jié)， 是功能實(shí)現(xiàn)過(guò)程中從虛到實(shí)的關(guān)鍵映射步驟，其需求一般包括以下內(nèi)容。

1） 需要高效全面地轉(zhuǎn)化需求。產(chǎn)品分析重在需求開(kāi)發(fā)， 是以用戶(hù)為中心， 服務(wù)于用戶(hù)體驗(yàn)， 借用非工程化的語(yǔ)言描述其功能需求；系統(tǒng)設(shè)計(jì)重在工程實(shí)現(xiàn)， 考慮有限的成本和周期， 用工程化的方式導(dǎo)出Tier1的相應(yīng)需求， 這就要求處于中間環(huán)節(jié)的功能設(shè)計(jì)過(guò)程具備簡(jiǎn)潔高效地將用戶(hù)語(yǔ)言轉(zhuǎn)化為工程語(yǔ)言的能力， 同時(shí)保證產(chǎn)品需求的實(shí)現(xiàn)完整性和可追溯性。

2） 功能設(shè)計(jì)廣度和深度要求高。傳統(tǒng)的E/E架構(gòu)功能開(kāi)發(fā)過(guò)程中， 功能設(shè)計(jì)到系統(tǒng)層即結(jié)束， 考慮不同ECU之間的交互設(shè)計(jì)即可；SOA理念下的E/E架構(gòu)功能開(kāi)發(fā)過(guò)程包括功能設(shè)計(jì)、 服務(wù)設(shè)計(jì)、 模塊設(shè)計(jì)、 通信設(shè)計(jì)等[2]步驟， 功能設(shè)計(jì)需滿(mǎn)足后續(xù)服務(wù)設(shè)計(jì)和模塊設(shè)計(jì)的不同需求， 由于已經(jīng)深入到子系統(tǒng)層級(jí)， 需要考慮的設(shè)計(jì)廣度和深度大大提高。

3） 功能設(shè)計(jì)盡量做到可以復(fù)用。SOA理念的核心思想是追求解耦和復(fù)用， 以便達(dá)到快速應(yīng)對(duì)需求變化， 快速迭代產(chǎn)品的目的。這種思想或理念理應(yīng)貫穿整個(gè)架構(gòu)開(kāi)發(fā)流程。目前在基于SOA的E/E架構(gòu)開(kāi)發(fā)過(guò)程中， 系統(tǒng)層級(jí)和子系統(tǒng)層級(jí)的設(shè)計(jì)已經(jīng)引入了面向服務(wù)的設(shè)計(jì)思想， 將每個(gè)服務(wù)設(shè)計(jì)為具體業(yè)務(wù)邏輯的封裝， 具有明確定義的接口，并可被獨(dú)立地實(shí)現(xiàn)[3]， 每個(gè)服務(wù)都是獨(dú)立的單元， 具備自洽和重用的特性；功能設(shè)計(jì)環(huán)節(jié)亦是需要考慮， 利用已有的成熟功能設(shè)計(jì)， 快速迭代， 快速轉(zhuǎn)化日益變化的產(chǎn)品需求，進(jìn)而提高整個(gè)開(kāi)發(fā)流程的效率。

2 傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)流程分析

傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)以已有的固定的功能清單作為輸入， 基于ECU控制器， 以功能實(shí)現(xiàn)為主線， 最終輸出相應(yīng)的DBC/LIN文件和具體的ECU開(kāi)發(fā)需求給到Tier1供應(yīng)商， 用以指導(dǎo)Tier1供應(yīng)商開(kāi)發(fā)。其大致流程可見(jiàn)圖2。

圖2 傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)流程示意

由圖2可以看出， 傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)流程主要涉及虛擬功能層和系統(tǒng)層的設(shè)計(jì)， 輸入為固有的功能清單， 結(jié)合具體的功能， 對(duì)功能進(jìn)行定義和實(shí)現(xiàn)設(shè)計(jì)， 考慮故障處理、 功能安全和HMI需求等， 最終輸出針對(duì)每個(gè)ECU的開(kāi)發(fā)需求和接口文件 （如DBC/LIN文件）。以上過(guò)程， 大多借用Excel和Word等工具來(lái)描述和傳遞過(guò)程中產(chǎn)生的需求， 包括不限于功能需求規(guī)范、 系統(tǒng)規(guī)范和ECU開(kāi)發(fā)需求等文件。

而隨著基于SOA的理念引入， 傳統(tǒng)功能開(kāi)發(fā)流程已不足以滿(mǎn)足SOA追求的靈活性、 可拓展性和可復(fù)用性， 主要表現(xiàn)在以下幾方面。

1） 深度和廣度不夠。深度方面， 傳統(tǒng)功能開(kāi)發(fā)流程僅定義到系統(tǒng)層級(jí)， 明確ECU與ECU之間的交互接口和要求即可， 不滿(mǎn)足需要深入到子系統(tǒng)層級(jí)的要求；廣度方面，僅對(duì)現(xiàn)階段定義的功能輸入進(jìn)行了功能設(shè)計(jì)， 未考慮未來(lái)產(chǎn)品迭代中可能出現(xiàn)的場(chǎng)景和需求。

2） 靈活性不夠， 可復(fù)用性差。上述功能開(kāi)發(fā)流程中，一般采用多級(jí)文檔的形式來(lái)拆解功能， 不同級(jí)別文檔或同級(jí)別文檔之間存在耦合關(guān)系。往往一個(gè)功能點(diǎn)的更新會(huì)同時(shí)帶來(lái)多份文檔的維護(hù)， 并且不同級(jí)別文檔的更新責(zé)任歸屬于不同部門(mén)或組織， 這樣就極大地增加了應(yīng)對(duì)需求變化時(shí)的維護(hù)成本和溝通成本， 進(jìn)而影響快速迭代效率。另外，橫向來(lái)說(shuō)， 這些文檔主要根據(jù)當(dāng)前項(xiàng)目、 當(dāng)前功能清單和當(dāng)前ECU拓?fù)湫问竭M(jìn)行功能設(shè)計(jì)， 針對(duì)性較強(qiáng)， 無(wú)法做到跨項(xiàng)目跨平臺(tái)使用， 可復(fù)用性較差。

3 基于EA的SOA架構(gòu)功能設(shè)計(jì)

不同于傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)， SOA架構(gòu)功能開(kāi)發(fā)的目的是窮盡硬件能力， 盡可能暴露更多服務(wù)， 同時(shí)降低軟件耦合度。本文結(jié)合項(xiàng)目實(shí)踐， 提出一種面向SOA架構(gòu)的功能開(kāi)發(fā)流程， 見(jiàn)圖3。

圖3 SOA架構(gòu)功能開(kāi)發(fā)流程示意

對(duì)比圖2和圖3可知， SOA架構(gòu)功能開(kāi)發(fā)思路和目標(biāo)發(fā)生了重大變化， 不再是以實(shí)現(xiàn)具體功能為主要目標(biāo)， 而是構(gòu)建面向服務(wù)的軟硬件平臺(tái)， 通過(guò)當(dāng)前已有的功能實(shí)現(xiàn)分析和硬件能力分析， 提取出該平臺(tái)所能暴露出的最大能力，同時(shí)應(yīng)用層軟件盡量解耦， 固化SWC之間的接口， 再結(jié)合SOME/IP的通信方式， 可以實(shí)現(xiàn)功能的快速迭代和升級(jí)。

對(duì)于虛擬功能層所包含的功能設(shè)計(jì)環(huán)節(jié)， 其實(shí)際內(nèi)容也發(fā)生了較大改變。功能定義部分， 從用戶(hù)體驗(yàn)角度， 將功能拆分為一個(gè)個(gè)獨(dú)立的功能用例 （Use Case， 以下簡(jiǎn)稱(chēng)UC）， 對(duì)每個(gè)UC進(jìn)行屬性分析， 定義其前置條件、 后置條件、 基本事件流、 可選事件流、 異常事件流等， 同時(shí)加上功能安全需求、 非功能需求、 HMI需求等內(nèi)容。功能實(shí)現(xiàn)設(shè)計(jì)部分， 不再基于ECU進(jìn)行實(shí)現(xiàn)分析， 而是定義實(shí)現(xiàn)某UC所需要的功能實(shí)體， 設(shè)計(jì)功能實(shí)體之間的交互時(shí)序關(guān)系， 同時(shí)結(jié)合活動(dòng)圖和狀態(tài)機(jī)， 對(duì)功能的實(shí)現(xiàn)過(guò)程進(jìn)一步驗(yàn)證， 以保證此環(huán)節(jié)輸出的功能實(shí)體的必要性和整體性。這里的功能實(shí)體定義為一個(gè)虛擬的需求描述， 一般結(jié)構(gòu)形式為過(guò)程 對(duì)象， 如提供車(chē)速， 是銜接功能與服務(wù)的重要概念。其創(chuàng)建原則一般包括高內(nèi)聚， 低耦合， 具備完整單一責(zé)任。

下文結(jié)合項(xiàng)目實(shí)例對(duì)上述功能設(shè)計(jì)環(huán)節(jié)進(jìn)行具體說(shuō)明。

3.1 功能定義環(huán)節(jié)

本環(huán)節(jié)的主要任務(wù)是將用戶(hù)需求轉(zhuǎn)化為工程需求， 同時(shí)考慮功能安全、 性能要求等， 輸出該功能所包含的UC集合， 一方面輸入到功能UC庫(kù)進(jìn)行匯總， 以便后續(xù)新功能的定義進(jìn)行復(fù)用；另一方面輸入到下一環(huán)節(jié)， 進(jìn)行后續(xù)的功能實(shí)現(xiàn)設(shè)計(jì)。

功能定義主要采用EA工具里的Use Case Diagram來(lái)進(jìn)行功能UC的設(shè)計(jì)， EA是一款基于UML （Unified Modeling Language， 統(tǒng)一建模語(yǔ)言） 的可視化模型與設(shè)計(jì)工具， 提供了對(duì)軟件系統(tǒng)的設(shè)計(jì)和構(gòu)建、 業(yè)務(wù)流程建模和基于領(lǐng)域建模的支持。功能UC主要定義以下屬性。

1） 描述：對(duì)本UC進(jìn)行簡(jiǎn)單描述。

2） 前置條件：激活該UC所必須滿(mǎn)足的前提條件。

3） 后置條件：描述UC執(zhí)行后功能的狀態(tài)。

4） 場(chǎng)景：是對(duì)UC激活期間一系列事件流的描述， 主要包含3種：①基本事件流——描述UC正常激活時(shí)的事件流；②可選事件流——描述與基本事件流不同的步驟， 但同樣實(shí)現(xiàn)UC目標(biāo)的事件流；③異常事件流——描述未能實(shí)現(xiàn)UC目標(biāo)的異常事件流。圖4為Use Case場(chǎng)景描述中不同事件流示意說(shuō)明。

圖4 Use Case場(chǎng)景描述中不同事件流示意說(shuō)明

5） 需求描述：描述該UC涉及的需求， 包括功能安全需求、 非功能需求、 HMI需求等。

下面以FCW （Forward CollisionWarning， 前碰撞報(bào)警）功能為例， 說(shuō)明功能定義的過(guò)程。

3.1.1 拆分UC

拆分UC是基于功能的使用場(chǎng)景分析， 將功能拆分為若干個(gè)用戶(hù)可感知的、 獨(dú)立的UC。按照此原則， 可將FCW功能拆分為以下7 個(gè)UC，如圖5所示。

圖5 FCW功能的UseCaseDiagram

3.1.2 定義UC

針對(duì)拆解的每個(gè)UC進(jìn)行上文提到的屬性定義， 包括描述、 前置條件、 后置條件、 場(chǎng)景和需求描述。下面以UC-02-006-07 activate FCW function 為例進(jìn)行展示，圖6中展示的是場(chǎng)景定義中涉及事件流的定義界面， 可以定義基本事件流、 可 選 事 件 流 （如有）、 異 常 事 件 流。另外， 在Requirements選項(xiàng)框中定義需求描述， 在Constraints選項(xiàng)框中定義前置條件和后置條件。

圖6 UC屬性定義界面示意

3.2 功能實(shí)現(xiàn)設(shè)計(jì)環(huán)節(jié)

上述功能定義環(huán)節(jié)結(jié)束后， 可以得到針對(duì)某個(gè)具體功能的UC集合。功能實(shí)現(xiàn)設(shè)計(jì)環(huán)節(jié)則承接每個(gè)UC， 對(duì)其實(shí)現(xiàn)環(huán)節(jié)所需要的功能實(shí)體進(jìn)行分析。該過(guò)程一般分為以下3個(gè)步驟。

1） UC實(shí)現(xiàn)過(guò)程分析。此步驟主要針對(duì)每個(gè)獨(dú)立的UC，進(jìn)行粗略的實(shí)現(xiàn)過(guò)程分析。包括時(shí)間維度的工作流程、 仲裁環(huán)節(jié)和可能并發(fā)存在的行為描述， 并確定上述過(guò)程中涉及的信息。該步驟主要采用EA中的活動(dòng)圖來(lái)實(shí)現(xiàn)， 活動(dòng)圖是一種基于UML語(yǔ)言的動(dòng)態(tài)行為圖， 主要包括活動(dòng)、 動(dòng)作、仲裁節(jié)點(diǎn)、 分支與合并等元素。上述UC：UC-02-006-07 activateFCWfunction的活動(dòng)圖如圖7所示。

圖7 UC：activate FCW function活動(dòng)圖示意

2） UC實(shí)現(xiàn)時(shí)序設(shè)計(jì)。此步驟主要是對(duì)上述實(shí)現(xiàn)過(guò)程的詳細(xì)展開(kāi)， 將其中涉及到的信息、 流程和動(dòng)作進(jìn)行細(xì)化。首先明確該UC的觸發(fā)或啟動(dòng)條件， 進(jìn)而按照活動(dòng)圖定義的粗略時(shí)序， 分析實(shí)現(xiàn)每一步過(guò)程需要的功能實(shí)體， 創(chuàng)建新的或從功能實(shí)體庫(kù)中選擇已有的功能實(shí)體；其次， 根據(jù)實(shí)現(xiàn)過(guò)程， 定義功能實(shí)體之間的交互接口內(nèi)容；最后根據(jù)時(shí)間順序， 將整個(gè)過(guò)程表述完整， 同時(shí)考慮使用組合片段來(lái)定義特殊條件和并列過(guò)程。

該步驟主要采用EA中的時(shí)序圖來(lái)實(shí)現(xiàn)， 時(shí)序圖是一種基于UML語(yǔ)言的動(dòng)態(tài)交互圖， 它通過(guò)描述對(duì)象之間發(fā)送消息的時(shí)間順序顯示多個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作關(guān)系， 主要包含對(duì)象、 生命線、 消息、 組合片段等元素。本項(xiàng)目中， 對(duì)象即功能實(shí)體， 生命線即功能實(shí)體的參與時(shí)間線， 消息主要用到了同步消息和異步消息兩種， 組合片段則采用Opt（選項(xiàng)）、 Alt （抉擇） 和Par （并行） 來(lái)處理UC中可能存在的不同情況， 其中Opt表示一個(gè)可能發(fā)生或可能不發(fā)生的選項(xiàng)過(guò)程， Alt則類(lèi)似于If-Else語(yǔ)句， 定義多個(gè)備選過(guò)程， Par表示并行發(fā)生過(guò)程。

圖8為UC：activate FCW function所對(duì)應(yīng)的時(shí)序圖， 圖中定義了7個(gè)功能實(shí)體， 定義了FCW功能激活時(shí)的實(shí)體間的信息交互關(guān)系， 采用Alt組合片段定義可能存在的兩級(jí)激活報(bào)警。

圖8 UC：activate FCW function時(shí)序圖示意

3） 功能狀態(tài)機(jī)設(shè)計(jì)。狀態(tài)機(jī)是針對(duì)復(fù)雜功能存在多個(gè)穩(wěn)定狀態(tài)， 定義每個(gè)狀態(tài)的進(jìn)入動(dòng)作、 執(zhí)行動(dòng)作和退出動(dòng)作， 定義狀態(tài)跳轉(zhuǎn)條件和優(yōu)先級(jí)明確各狀態(tài)之間的切換關(guān)系， 達(dá)到說(shuō)明該功能隨著不同條件的變化改變狀態(tài)的目的。本項(xiàng)目主要采用EA中的狀態(tài)機(jī)圖來(lái)定義FCW功能的狀態(tài)機(jī)切換， 由于狀態(tài)機(jī)在傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)中已得到廣泛使用， 這里不做過(guò)多展開(kāi)。

3.3 小結(jié)

通過(guò)以上4種形式的圖形建模， 可以完成FCW功能從功能定義到功能實(shí)現(xiàn)的詳細(xì)設(shè)計(jì)。將功能拆解為一個(gè)個(gè)獨(dú)立的UC， 對(duì)每個(gè)UC進(jìn)行獨(dú)立的活動(dòng)圖和時(shí)序圖設(shè)計(jì)， 導(dǎo)出實(shí)現(xiàn)該UC需要的功能實(shí)體和接口需求， 同時(shí)輔助以功能狀態(tài)機(jī)， 對(duì)設(shè)計(jì)過(guò)程進(jìn)行校驗(yàn)。一般來(lái)說(shuō)， 一個(gè)功能對(duì)應(yīng)多個(gè)UC和最多一個(gè)狀態(tài)機(jī)圖， 而一個(gè)UC對(duì)應(yīng)一個(gè)時(shí)序圖和一個(gè)活動(dòng)圖 （可選）。

4 總結(jié)

本文介紹了E/E架構(gòu)功能開(kāi)發(fā)流程， 提出SOA架構(gòu)開(kāi)發(fā)中功能設(shè)計(jì)環(huán)節(jié)的需求。通過(guò)對(duì)傳統(tǒng)E/E架構(gòu)功能開(kāi)發(fā)中的功能設(shè)計(jì)環(huán)節(jié)分析， 指出存在的不足：不能滿(mǎn)足開(kāi)發(fā)的深度和廣度， 同時(shí)靈活性和復(fù)用性差?；陧?xiàng)目經(jīng)驗(yàn)提出一種基于EA的功能設(shè)計(jì)方法， 通過(guò)4個(gè)形式的圖形建模， 深入到子系統(tǒng)層級(jí)， 為后續(xù)服務(wù)設(shè)計(jì)提供設(shè)計(jì)依據(jù)；同時(shí)設(shè)計(jì)2個(gè)庫(kù)：UC庫(kù)和功能實(shí)體庫(kù)， 為之后的新功能設(shè)計(jì)提供復(fù)用基礎(chǔ)。另外， 從使用工具角度來(lái)說(shuō)， EA建模工具具備良好的可視化界面， 支持各類(lèi)插件的二次開(kāi)發(fā)和模型的Word形式導(dǎo)出， 結(jié)合后續(xù)環(huán)節(jié)的Word轉(zhuǎn)Excel工具和Excel生成ARXML工具， 可以打通E/E架構(gòu)開(kāi)發(fā)全流程工具鏈。

參考文獻(xiàn)：

[1] Philipp Obergfell，Stefan Kugele，Eric Sax. Model-Based Resource Analysis and Synthesis of Service-Oriented AutomotiveSoftware Architectures [C]//IEEE/ACM 22nd International Conference on Model Driven EngineeringLanguages and Systems（MODELS）2019.

[2] 華一丁，龔進(jìn)峰，戎輝，等. 基于模型的智能汽車(chē)電子電氣架構(gòu)發(fā)展綜述[J]. 汽車(chē)零部件，2019（2）：63-66.

[3] 劉佳熙，施思明，徐振敏，等. 面向服務(wù)架構(gòu)汽車(chē)軟件開(kāi)發(fā)方法和實(shí)踐[J]. 中國(guó)集成電路，2021，1（16）：83-84.

END