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

0 引言

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

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

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

（2）服務松耦合；

（3）服務的可重用性；

（4）服務自治[6]。

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

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

1 模塊化層級框架搭建

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

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

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

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

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

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

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

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

圖1 車身控制域系統(tǒng)設計框架

2 車身控制域子系統(tǒng)設計

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

2.1 功能需求文檔內(nèi)容設計

功能需求文檔的內(nèi)容包括功能描述和功能用例流程。

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

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

2.1.2 繪制功能用例流程圖

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

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

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

2.2 邏輯實現(xiàn)文檔內(nèi)容設計與銜接

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

2.2.1 建立軟件組件并繼承產(chǎn)品能力

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

2.2.2 打包并部署軟件組件

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

2.2.3 設計軟件組件接口

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

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

2.2.4 繪制信號流程圖

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

2.3 其它需求文檔建立與關聯(lián)

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

3 基于EA的功能拓展

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

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

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

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

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

4 設計方法實踐

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

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

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

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

4.1 氛圍燈功能設計

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

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

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

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

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

4.2 氛圍燈接口模塊設計

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

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

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

圖5 部分信號流程

4.3 氛圍燈系統(tǒng)框圖搭建與文檔輸出

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

圖6 氛圍燈系統(tǒng)

5 結論

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

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

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

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