國內主機廠車身控制器功能開發通常使用文字來描述系統設計，各個功能之間的依賴關系不清晰，功能復用率不高。隨著功能需求數量的增多，為提高各個功能的復用率，行業內提出面向服務的汽車架構（SOA）解決方案。挖掘SOA 架構設計方法論，總結嵐圖汽車SOA 平臺車身控制域中氛圍燈子系統設計開發實踐經驗，闡述使用企業構架（EA）軟件完成汽車車身控制域系統設計，交付開發需求文檔以及系統功能規范的方法，以達到提升設計效率，改善設計質量的目的。

0 引言

在國內主流整車企業完成車身控制系統或其相關子系統的設計工作時，通常采用Micro soft Visio 軟件完成流程圖的繪制并開展設計工作，使用Microsoft Word 進行人工編寫功能規范或者子系統規范的文字說明，使用Auto CAD 工具輔助完成系統框圖的設計。隨著“域”概念的引入，相較于早期的汽車車身控制器產品功能的開發，車身域控制器不僅新的功能層出不窮[1]，而且功能與功能之間還存在交叉復用的情況。例如2010 年生產的一臺豪華轎車具備800 個整車功能[2]，而在2007年整車功能只有270個[3]。例如中控屏控制車窗、語音控制車窗2個功能需求中，執行端（控制器驅動玻璃升降電機的部分）處理邏輯是一樣的，這部分的邏輯就可以在不同車窗控制方式中復用。隨著各個功能之間交叉復用的情況增多，在進行系統設計時，使用文字進行描述和輔助一些插圖的方式，越來越難以梳理功能的鏈路以及功能之間的交互關系。

在當下軟件定義汽車的時代[4]，汽車生產廠商依托架構方案進行造車，以控制成本，提高產品競爭力[5]，加快軟件產品的迭代。例如大眾汽車集團的電動車模塊化平臺（Modular Electrification Toolkit，MEB）構架，豐田汽車新全球架構平臺（Toyota New Global Architecture，TGNA）和吉利汽車的浩瀚智能體驗（Sustainable Experience Architecture，SEA）架構，都是當前國際上先進的面向服務化的汽車架構（Service-Oriented Architecture，SOA）。這些汽車構架具有粗粒度、松耦合的特征，服務之間通過定義簡單、精確的接口進行通訊，其設計的基本原則主要有：

（1）標準化的服務契約；

（2）服務松耦合；

（3）服務的可重用性；

（4）服務自治[6]。

由此可以看出，在設計、輸出車身控制系統或子系統對應的功能規范時，在新的架構方案下，系統設計人員還需要對服務接口進行標準化定義。

在新架構下，汽車車身域系統開發人員利用企業構架（Enterprise Architect，EA）軟件完成車身域[7]的子系統設計、完成功能規范的編寫和開發交付物，同時根據EA提供的應用程序接口（Application Program Interface，API）進行拓展功能開發的研究。EA是一款企業架構軟件[8]，覆蓋了系統開發的整個周期，除了開發類模型之外，還包括事務進程分析、使用案例需求、動態模型、組件和布局、系統管理、非功能需求、用戶界面設計、測試和維護。EA使用者還可以利用EA中的基礎元素，封裝出一套滿足使用需求的元素插件，所以選擇使用EA進行車身控制域子系統的設計與開發研究，具有很高的靈活度和契合度。

1 模塊化層級框架搭建

利用EA開展SOA架構下車身控制域子系統的設計工作，首先需使用EA 搭建子系統框架。為了避免相關的元素依賴關系不清晰，框架的搭建通常有2種方案。

（1）方案1 以某一車型平臺為單位搭建服務器。服務器內使用唯一編號對功能進行標識，新增的功能需求按新的順序進行編號，固化的功能需求不再改變編號，把此車型平臺上所有功能需求匯集在一個服務器上，當開發不同車型時，根據功能需求進行拆分重組，完成車身域子系統的功能設計，輸出功能規范和開發交付物。

（2）方案2 以項目為單位搭建服務器。每個服務器單獨開發維護，此方案更適合有相同功能的不同車型，按不同用例需求進行定制開發。EA 架構開發環境的搭建可根據公司戰略需求進行工程方案選擇。

在工程內部需要對文檔進行分層搭建，軟件層級的劃分是SOA架構中松耦合的實現方式，所以在搭建文檔時，不僅要橫向考慮開發流程的先后順序，還需要縱向考慮軟件的分層實現[9]。

使用EA 搭建模塊化層級的框架，首先需建立功能需求文檔，這是開展車身控制域子系統設計的基礎，主要用于存放設計中的功能描述和功能用例流程圖。在功能需求文檔的子文檔中，需要對功能進行模塊化的劃分，車身控制域就屬于其中一個模塊，整車的其他控制系統均可根據功能類別劃分成不同的模塊，功能需求文檔建立后，將此文檔派發給系統工程師進行處理和維護。

其次是建立其他需求文檔。比如功能安全需求文檔、系統性能需求文檔，這部分內容可以派發給功能安全工程師和系統工程師進行搭建和維護。由功能安全工程師根據功能安全目標，指導軟件開發；系統工程師根據性能需求，提出可量化、可實現的性能指標，比如系統的資源占用情況、響應時間要求。

最后，建立邏輯實現文檔。邏輯實現文檔包括縱向軟件分層，每個域模塊的層級分類會有不同，車身控制域從軟件控制層、協調層、信號轉換層、傳感器與執行層以及物理層進行劃分，此項可以先由系統工程師設計出相應的外部通信接口，再由軟件開發人員根據開發需求定義內部接口。

基于上述描述，使用EA 搭建出了車身控制域系統設計框架，如圖1所示。

圖1 車身控制域系統設計框架

2 車身控制域子系統設計

在EA中按照以下流程開展車身控制域子系統的設計工作，系統的功能邏輯思路就能非常清晰地呈現出來，進行功能設計時就不會造成邏輯混亂和接口依賴不清晰、不明確的問題，客觀上保證了設計開發的質量。

2.1 功能需求文檔內容設計

功能需求文檔的內容包括功能描述和功能用例流程。

2.1.1 分解功能需求完成功能描述

在獲得車身控制域的系統功能需求后，應對其進行分解。把一項功能拆解成多條功能用例，在EA 中用案例（Use Case）元素進行表示，考慮支持實現這些功能用例的需求，每一條功能用例的前置條件、觸發條件、執行方法或步驟，在執行動作過程中，有其他異常情況發生時所期望的執行結果，以及信息沖突的仲裁情況。這些設計中的信息均可用文字描述的形式放入Use Case 屬性的不同條目下，以完成功能需求分解和定義。

2.1.2 繪制功能用例流程圖

在此階段，首先應根據整車的電子電器架構了解系統中各個單元的分布情況。以物理單元為基礎，軟件組件為載體，抽象出軟件組件的產品能力（Product Capability，PC）。

在每一條功能用例流程圖中拽入功能實現所需要的PC，并在其“特征”選項卡的“操作”（Operation）中建立具體的關聯方法，此時就可繪制功能流程的傳遞過程，在此基礎上加入功能定義中的判斷條件，可完成功能用例流程圖設計。

功能用例流程圖的主要作用是梳理功能邏輯，分配功能任務。通過功能用例流程圖，系統設計人員可以明確系統的依賴關系以及系統的邏輯、時序和步驟，各軟件組件也能明確自身需要完成的工作內容。狀態機和活動圖在EA中均有對應的元素可以直接使用，相比于流程圖更加方便。

2.2 邏輯實現文檔內容設計與銜接

邏輯實現文檔的設計分為縱向設計和橫向設計。縱向設計是把一個系統功能從需求到最終實現的流程設計，橫向設計則是把每個系統的縱向設計內容進行組合設計。在搭建模塊化層級框架時，需要根據實際分層情況把縱向設計內容進行分類管理。下文重點闡述利用EA完成縱向設計內容。

2.2.1 建立軟件組件并繼承產品能力

前文主要描述的是功能層面的設計，下文的設計屬于軟件設計范疇。根據PC需求能力進行分類組合，建立EA 中的軟件組件（Software Component,SWC）[10]，該組件可通過EA 中的關系圖，對PC 操作進行繼承，防止設計人員在需求編制時出現漏項。

2.2.2 打包并部署軟件組件

每個SWC 都需要部署在系統芯片（System on Chip，SOC）里，部署時可把一類或一個系統的SWC一起打包部署。在部署之前，應先根據整車電氣架構圖，建立所有的ECU元素，再通過部署圖實現SWC與ECU的部署關系。

2.2.3 設計軟件組件接口

在SOA 的架構中，主要原則是定義標準化的接口。車身控制域系統的設計，不僅有基于單一（Single）信號的接收與發送，還有基于以太服務的消費接口[11]。利用EA對基礎元素的封裝能力，把EA的基礎接口封裝出不同類型的接口。以SOC為基礎單元，根據架構的層級關系，每個層級之間建立的標準接口為內部接口，與其他SOC 之間的交互稱為外部接口；若以SWC 為基礎單元，其外部接口和需求接口，分別代表著SWC能提供的服務和消費依賴；每個外部接口元素可以在“操作”（Operation）選項卡里添加具體的接口名稱，并將添加的外部接口名稱提供給其他SWC進行消費；需求接口則是其余SWC 的外部接口，不能自行建立，需依賴方的SWC 建立外部接口，通過消費依賴方的外部接口建立關系。

在接口中，如果是Single 類型（汽車CAN、CANFD通信協議數據類型）接口，會描繪出信號的收發情況和數據值。如果是以太服務類型的消費接口，則根據設計需要定義服務接口所傳的參數信息。數據類型與程序開發高級語言中的數據類型相似，有結構體、枚舉、數組和價值（Value）數據類型，如在結構體數據類型中添加成員，可以選擇特征（Feature）[12]里的屬性（Attribute）以區別接口使用的操作內容。

2.2.4 繪制信號流程圖

當有了服務接口和信號接口后，為了更清晰的表達出數據的流向鏈路，可以繪制信號流程圖。信號流程圖應與功能用例流程圖對應，是以每個SWC 為單元，接口消費關系為鏈路的示意圖，能更詳細表達出數據在軟件組件之間的流轉關系，對后期系統問題故障診斷起到非常有用的幫助。

2.3 其它需求文檔建立與關聯

在進行一些涉及行車安全的系統設計時，如雨刮系統、大燈系統[13]，功能安全專業會對某些場景提出需求，通過ASIL等級進行約束和規范，這些特殊的需求可以使用需求（Requirement）元素進行描述，并在圖中與Use Case進行關聯，形成對Use Case約束和要求。還有某些響應時效、性能需求，在與Use Case關聯后把這些特殊的需求橫向分類到功能安全需求、系統性能需求文檔中。這樣不僅把這些特殊需求進行了歸類管理，還清晰地表示出了哪個Use Case承接了需求。

3 基于EA的功能拓展

在完成EA 的系統設計和接口設計[14]后，可以通過共享服務器的方式，為有需求的使用人員開辟賬號查看或編輯內容。但在實際開發過程中，為了追求更好的設計質量，不同的系統大多是分配給不同的軟件供應商完成，為了項目全盤設計內容的安全性、保密性，往往是單獨提供供應商承接的開發內容部分，所以設計的產出只保留在系統或者服務器中是遠遠不夠的，還需要把系統中設計的內容導出來使用。

EA具有強大的拓展功能，不僅在發布（Publish）中可以進行設計導出和導入，還提供相應的API接口，可以供第三方開發人員訪問數據庫。因此，在系統設計人員完成相應設計后，可依托第三方提供的工具，把設計數據按需求格式進行導出，供開發者使用。

系統開發過程中常用到的開發文檔就是功能規范。功能規范的導出通常有2種方法：一種方法是在EA“資源”（Resource）選項卡中創建元素的引用方法，再創建一份具有統一模板的文件（Document），把設計中用到的元素拖入模板文檔中，在LINK 時選擇引用方法。此時拖入的元素則會按照設計方法導入功能對應的需求內容、前置條件、觸發條件、執行方法或步驟，形成文檔后進行導出保存。此方法的好處在于文檔是一個動態鏈接的狀態，如果元素中有更新，刷新文檔后，對應的內容也會更新，保證了設計與文檔同步。另一種方法則是利用第三方的腳本進行導出，此方法的缺點是若文檔有更新，則需要重新導出，無法像在線設計一樣同步更新。

另外用到的開發文檔是在AUTOSAR[15]標準下，采用可擴展標記語言（Automotive Open System Architecture Extensible Markup Language，ARXML）來傳遞具有層次結構的接口數據。主要就是導出EA里的SWC及其接口部分信息、消費的依賴關系內容。因為第三方工具可以通過API 直接訪問數據庫，導出的數據比使用系統工具更快，通常利用第三方工具導出，然后利用MATLAB生成ARXML文檔。

基于EA 提供的API，可以直接進行數據庫訪問，具有強大的拓展功能，可以滿足設計內容的輸出需求。

4 設計方法實踐

在嵐圖汽車SOA平臺項目上利用EA進行了系統設計實踐，本文以車身控制域氛圍燈子系統為設計實例，闡述利用EA完成系統設計工作。

需要說明的是圖2～圖6所涉及的內容僅作為示例展示，相對于實際開發做了處理，實際開發時接口命名規則應滿足集成編譯環境所需的命名規則。

圖2 部分氛圍燈功能需求用例設計

嵐圖汽車公司將氛圍燈系統規劃在車身控制域的功能中，但部署在座艙域的SOC中，利用EA完成氛圍燈系統設計，就打破了傳統產品責任方法，車身控制域系統工程師可以在其他人負責的ECU 上進行系統設計，這也體現了SOA松耦合的優點。

4.1 氛圍燈功能設計

在EA 中對氛圍燈功能進行拆分，氛圍燈首先具有中控屏與語音打開和關閉的Use Case。往下層級拆分，有通過中控屏與語音選擇的靜態、動態氛圍燈控制的Use Case。再往下一個層級，靜態氛圍燈具有中控屏與語音調節顏色、亮度的Use Case，動態氛圍燈具有音樂律動模式與隨駕駛模式兩種選擇的Use Case，其中音樂律動模式下面又拆分有3 種色域（冷色、暖色、中色）的選擇Use Case，讓音樂律動的值在色域中進行律動。

在Use Case 設計時，有許多需求不能通過Use Case 表述出來，比如氛圍燈的初始化狀態、顏色的色譜、亮度等級分配和仲裁關系，以及一些非功能性需求，無法直接放入Use Case 中，可以使用Requirement元素進行描述，并與Use Case建立需求關系，見圖2中的需求關系。

功能定義的詳細描述，需要在Use Case 元素的“性能”（Property）選項卡中的“約束”（Constraint）欄目添加用例前置條件，在“場景”（Scenario）欄目中填寫具體的方案，包括觸發方式、基本執行方式、異常執行方式和備選執行方式。

根據架構拓撲情況，梳理出關聯單元，在EA中建立相應的ECU單元元素，開展功能分配工作。功能的分配同樣可以應用Requirement 元素進行描述，根據功能描述提煉每個ECU 單元能給氛圍燈系統貢獻的能力PC，然后建立氛圍燈系統內的PC，而關聯方的PC 需要和關聯方討論后，由對方承接并建立相應的PC。PC 建立完整后就可以針對每個Use Case 繪制相應的流程圖，見圖3。

圖3 部分氛圍燈功能用例流程

4.2 氛圍燈接口模塊設計

根據PC能力進行整合與分配，建立對應的SWC，氛圍燈系統主要分音樂律動算法部分SWC、邏輯控制部分SWC、燈頭驅動SWC 以及中間件信號路由能力。建立SWC后需對其進行部署，其中音樂律動算法的SWC 部署在安卓系統內部，這樣可以直接獲得到PCM源碼音頻數據，利用算法提取到用于控制氛圍燈的音頻、振幅等音樂特征；邏輯控制部分的SWC（圖4）針對氛圍燈的控制邏輯進行處理，并把處理結果轉換成信號進行輸出；燈頭SWC則根據信號協議內容驅動氛圍燈點亮。

圖4 氛圍燈邏輯控制部分SWC

每個SWC之間根據通信方式建立通信接口，比如算法部分SWC 與邏輯控制的SWC 采用信息中心（Message Center）的方式通信，建立服務接口及數據類型。邏輯控制SWC到燈頭SWC是先采用以太網的方式與網關通信，再由網關采用串行通信總線（Local Interconnect Network，LIN）方式通過路由傳給燈頭，按照同樣的方式建立服務接口、數據類型與信號。按照SOA架構方案，氛圍燈應暴露出服務能力給其他系統使用，所以邏輯控制部分SWC還需承接在以太網提供服務的接口工作。標準化的接口建立以后，需要使用圖表元素進行消費關系的建立，同時也可以進行氛圍燈信號流程圖的繪制，見圖5。

圖5 部分信號流程

4.3 氛圍燈系統框圖搭建與文檔輸出

氛圍燈設計完成后，搭建系統框圖時只需要在圖表元素中拖入關聯的ECU，在ECU 中放入軟件的SWC，這樣SWC 的依賴關系就自動建立，很輕松地完成了系統框圖的繪制（圖6）。利用第三方腳本插件，可以對元素中的信息進行選擇性導出生成Word 文檔，利用此腳本可以按照模板生成氛圍燈的功能規范。如果軟件開發方需要ARXML 作為軟件開發輸入[15]文檔時，可以把EA 中氛圍燈接口模塊設計的內容導出生成Word 文檔，利用文檔轉換腳本把Word 文檔轉換成Excel 表格，再使用MATLAB 工具生成ARXML 文檔[16]。

圖6 氛圍燈系統

5 結論

利用EA 開展車身域系統設計工作，通過圖表的方式能很好地理清系統設計人員的邏輯思路，梳理數據流向，完成需要的系統設計輸出物和交付物，比如系統框圖、系統流程圖、系統規范以及標準化的接口。EA 還具有解耦性，設計工作不與特定的硬件信息耦合，適用于一種系統方案匹配多種產品方案。

目前SOA架構已在國內汽車行業逐漸流行，傳統手寫功能規范的方式在車身域場景化的開發中效率低下，需要一些信息化的工具輔助完成系統設計工作，經實踐EA 符合目前汽車行業車身域系統設計需求。

應用EA 開展系統設計，有利于設計協同性和信息查詢的便利性。應用EA 進行設計的人員，可以分模塊化同步開展工作，相互之間不干擾，有依賴需求時通過圖表元素建立關系，各個系統的設計人員之間從圖表元素中獲得對方的需求，進行協同設計。在設計中及設計完成后，有信息需要查詢和確認時，利用關鍵字符可以在EA 中檢索出元素的所有依賴關系，方便查詢。

EA 不僅適用于企業架構設計，EA 也可以成一款汽車車身控制域系統設計的輔助軟件，提升設計效率，改善設計質量。

編輯：黃飛

?