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

來源：智能汽車設(shè)計(jì) 陳敏

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

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

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

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

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

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

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

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

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

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

E/E架構(gòu)功能開發(fā)過程層級說明如圖1所示。

圖1 EE架構(gòu)功能開發(fā)層級說明

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

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

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

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

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

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

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

3） 功能設(shè)計(jì)盡量做到可以復(fù)用。 SOA理念的核心思想是追求解耦和復(fù)用， 以便達(dá)到快速應(yīng)對需求變化， 快速迭代產(chǎn)品的目的。 這種思想或理念理應(yīng)貫穿整個(gè)架構(gòu)開發(fā)流程。 目前在基于SOA的E/E架構(gòu)開發(fā)過程中， 系統(tǒng)層級和子系統(tǒng)層級的設(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è)開發(fā)流程的效率。

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

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

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

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

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

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

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

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

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

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

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

對于虛擬功能層所包含的功能設(shè)計(jì)環(huán)節(jié)， 其實(shí)際內(nèi)容也發(fā)生了較大改變。 功能定義部分， 從用戶體驗(yàn)角度， 將功能拆分為一個(gè)個(gè)獨(dú)立的功能用例 （Use Case， 以下簡稱UC）， 對每個(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é)合活動圖和狀態(tài)機(jī)， 對功能的實(shí)現(xiàn)過程進(jìn)一步驗(yàn)證， 以保證此環(huán)節(jié)輸出的功能實(shí)體的必要性和整體性。 這里的功能實(shí)體定義為一個(gè)虛擬的需求描述， 一般結(jié)構(gòu)形式為過程+對象， 如提供車速， 是銜接功能與服務(wù)的重要概念。 其創(chuàng)建原則一般包括高內(nèi)聚， 低耦合， 具備完整單一責(zé)任。

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

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

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

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

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

2） 前置條件：激活該UC所必須滿足的前提條件。

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

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

圖4 Use Case場景描述中不同事件流示意說明

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

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

3.1.1 拆分UC

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

圖5 FCW功能的UseCaseDiagram

3.1.2 定義UC

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

圖6 UC屬性定義界面示意

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

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

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

圖7 UC：activate FCW function活動圖示意

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

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

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

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

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

3.3 小結(jié)

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

4 總結(jié)

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

審核編輯：湯梓紅