來源：智能汽車設計 陳敏

【摘 要】 在軟件定義汽車時代背景下，新一代的汽車電子電氣架構（以下簡稱E/E 架構） 不斷進化。物理拓撲上，控制器ECU 數量大幅減少，集中度提高，拓撲方式從分布式到域集中式，再到中央集成大腦逐步演進；功能開發思路上，從傳統的以明確各ECU 之間交互為主體任務，實現功能為主線，切換到現在的以服務定義和ECU的軟件接口設計為主體，窮盡硬件平臺能力為主線，覆蓋面更廣，功能開發深度更深。傳統的基于文檔的功能設計方式，已不足以滿足現階段功能開發需求。本文結合項目實踐案例，基于Enterprise Architect（以下簡稱：EA） 工具對SOA（Service Oriented Architecture，面向服務架構） 架構功能設計方法進行應用和探索。

隨著汽車行業向智能化、 數字化和電動化發展， 現存大部分汽車的E/E架構由于ECU數量眾多、 線束繁瑣復雜、算力低和功能耦合度高等問題， 無法實現高級別自動駕駛和快速OTA （Over The Air， 空中下載技術） 升級， 從而無法滿足人們對汽車的多樣化需求。主要的挑戰有高級別自動駕駛所要求的實時性和安全性高， 人工智能機器學習所需要的大數據量和高帶寬需求， 還有滿足未來多節點連接（比如車路協同、 云代駕等） 所帶來的信息安全問題[1]。為更好地解決上述汽車行業挑戰， E/E架構拓撲形式在不斷演進， 新的通信方式和開發方法也從工業或IT領域引入， 給汽車行業提供了豐富的技術參考。

針對E/E架構功能開發方法， 其內容和開發思路也發生了變化。本文通過對比傳統架構功能開發流程和SOA架構功能開發流程， 指出傳統架構功能設計環節可能存在的不足， 結合具體項目實例， 提出一種基于EA的功能設計方法， 以滿足架構功能開發過程中對功能設計的需求。

1 E/E架構功能開發介紹

1.1 E/E架構功能開發流程

參考AUTOSAR標準中關于方法論的文檔描述， 圍繞E/E架構功能開發主線， 可以將開發流程從上到下， 從虛到實， 分為4個層級的步驟：產品層、 虛擬功能層、 系統層、子系統層。

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

2） 虛擬功能層：主要定義整車層級的功能交互關系，也就是本論文涉及的內容， 一般包含功能定義和功能實現設計兩個部分。

3） 系統層：主要承接虛擬功能層的輸出， 對功能實現涉及的邏輯模塊進行分配， 定義ECU層級的交互關系， 包括ECU之間的連接拓撲關系、 功能交互時序、 ECU接口定義、 服務定義、 通信定義等。

4） 子系統層級：聚焦具體ECU， 對承接的功能邏輯模塊進一步詳細設計， 定義應用層軟件架構， 軟件組件SWC之間的接口交互、 服務接口設計、 SWC運行設計等。

E/E架構功能開發過程層級說明如圖1所示。

圖1 EE架構功能開發層級說明

圖1中， 產品層級的整車功能分析主要任務為結合市場情況、 競爭對手分析、 公司戰略、 終端用戶需求和自身產品定位等信息， 對整車項目所需要實現的功能進行對標分析， 提煉出所需要實現的功能清單和配置信息， 輸出給到E/E架構進行功能實現。

對于虛擬功能層的整車功能設計環節， 承接產品層級輸出的功能清單， 對清單上的每一個功能進行定義， 拆分功能用例； 功能實現層面， 對某一具體功能用例， 進行功能實現設計， 包括功能邏輯模塊設計、 模塊交互設計、 狀態機等。

而系統層級和子系統層級設計， 則是依據上述功能設計環節的輸出結果， 對其中的功能邏輯模塊進行具體ECU或SWC的映射， 映射關系可以是一對一或多對一； 對交互接口進行進一步詳細細化， 區分ECU間或ECU內部接口，定義內外部接口的類型、 協議和數據類型。 這一步做完后，即可提煉出對具體ECU的功能邏輯需求和接口需求， 用以指導Tier1的開發。

1.2 功能設計流程需求分析

由上述分析可知， 虛擬功能層所包含的功能設計位于產品分析和系統層設計之間， 是從整車層級過渡到ECU級的重要環節， 是功能實現過程中從虛到實的關鍵映射步驟，其需求一般包括以下內容。

1） 需要高效全面地轉化需求。 產品分析重在需求開發， 是以用戶為中心， 服務于用戶體驗， 借用非工程化的語言描述其功能需求； 系統設計重在工程實現， 考慮有限的成本和周期， 用工程化的方式導出Tier1的相應需求， 這就要求處于中間環節的功能設計過程具備簡潔高效地將用戶語言轉化為工程語言的能力， 同時保證產品需求的實現完整性和可追溯性。

2） 功能設計廣度和深度要求高。 傳統的E/E架構功能開發過程中， 功能設計到系統層即結束， 考慮不同ECU之間的交互設計即可； SOA理念下的E/E架構功能開發過程包括功能設計、 服務設計、 模塊設計、 通信設計等[2]步驟， 功能設計需滿足后續服務設計和模塊設計的不同需求， 由于已經深入到子系統層級， 需要考慮的設計廣度和深度大大提高。

3） 功能設計盡量做到可以復用。 SOA理念的核心思想是追求解耦和復用， 以便達到快速應對需求變化， 快速迭代產品的目的。 這種思想或理念理應貫穿整個架構開發流程。 目前在基于SOA的E/E架構開發過程中， 系統層級和子系統層級的設計已經引入了面向服務的設計思想， 將每個服務設計為具體業務邏輯的封裝， 具有明確定義的接口，并可被獨立地實現[3]， 每個服務都是獨立的單元， 具備自洽和重用的特性； 功能設計環節亦是需要考慮， 利用已有的成熟功能設計， 快速迭代， 快速轉化日益變化的產品需求，進而提高整個開發流程的效率。

2 傳統E/E架構功能開發流程分析

傳統E/E架構功能開發以已有的固定的功能清單作為輸入， 基于ECU控制器， 以功能實現為主線， 最終輸出相應的DBC/LIN文件和具體的ECU開發需求給到Tier1供應商， 用以指導Tier1供應商開發。 其大致流程可見圖2。

圖2 傳統E/E架構功能開發流程示意

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

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

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

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

3 基于EA的SOA架構功能設計

不同于傳統E/E架構功能開發， SOA架構功能開發的目的是窮盡硬件能力， 盡可能暴露更多服務， 同時降低軟件耦合度。 本文結合項目實踐， 提出一種面向SOA架構的功能開發流程， 見圖3。

圖3 SOA架構功能開發流程示意

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

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

下文結合項目實例對上述功能設計環節進行具體說明。

3.1 功能定義環節

本環節的主要任務是將用戶需求轉化為工程需求， 同時考慮功能安全、 性能要求等， 輸出該功能所包含的UC集合， 一方面輸入到功能UC庫進行匯總， 以便后續新功能的定義進行復用； 另一方面輸入到下一環節， 進行后續的功能實現設計。

功能定義主要采用EA工具里的Use Case Diagram來進行功能UC的設計， EA是一款基于UML （Unified Modeling Language， 統一建模語言） 的可視化模型與設計工具， 提供了對軟件系統的設計和構建、 業務流程建模和基于領域建模的支持。 功能UC主要定義以下屬性。

1） 描述：對本UC進行簡單描述。

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

3） 后置條件：描述UC執行后功能的狀態。

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

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

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

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

3.1.1 拆分UC

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

圖5 FCW功能的UseCaseDiagram

3.1.2 定義UC

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

圖6 UC屬性定義界面示意

3.2 功能實現設計環節

上述功能定義環節結束后， 可以得到針對某個具體功能的UC集合。 功能實現設計環節則承接每個UC， 對其實現環節所需要的功能實體進行分析。 該過程一般分為以下3個步驟。

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

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

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

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

圖8為UC：activate FCW function所對應的時序圖， 圖中定義了7個功能實體， 定義了FCW功能激活時的實體間的信息交互關系， 采用Alt組合片段定義可能存在的兩級激活報警。

圖8 UC：activate FCW function時序圖示意

3） 功能狀態機設計。狀態機是針對復雜功能存在多個穩定狀態， 定義每個狀態的進入動作、 執行動作和退出動作， 定義狀態跳轉條件和優先級明確各狀態之間的切換關系， 達到說明該功能隨著不同條件的變化改變狀態的目的。本項目主要采用EA中的狀態機圖來定義FCW功能的狀態機切換， 由于狀態機在傳統E/E架構功能開發中已得到廣泛使用， 這里不做過多展開。

3.3 小結

通過以上4種形式的圖形建模， 可以完成FCW功能從功能定義到功能實現的詳細設計。將功能拆解為一個個獨立的UC， 對每個UC進行獨立的活動圖和時序圖設計， 導出實現該UC需要的功能實體和接口需求， 同時輔助以功能狀態機， 對設計過程進行校驗。一般來說， 一個功能對應多個UC和最多一個狀態機圖， 而一個UC對應一個時序圖和一個活動圖 （可選）。

4 總結

本文介紹了E/E架構功能開發流程， 提出SOA架構開發中功能設計環節的需求。通過對傳統E/E架構功能開發中的功能設計環節分析， 指出存在的不足：不能滿足開發的深度和廣度， 同時靈活性和復用性差。基于項目經驗提出一種基于EA的功能設計方法， 通過4個形式的圖形建模， 深入到子系統層級， 為后續服務設計提供設計依據；同時設計2個庫：UC庫和功能實體庫， 為之后的新功能設計提供復用基礎。另外， 從使用工具角度來說， EA建模工具具備良好的可視化界面， 支持各類插件的二次開發和模型的Word形式導出， 結合后續環節的Word轉Excel工具和Excel生成ARXML工具， 可以打通E/E架構開發全流程工具鏈。

審核編輯：湯梓紅