SOA架構(gòu)下基于EA的車身控制域系統(tǒng)設(shè)計(jì)

譚仁福

（嵐圖汽車科技有限公司智能電子電器部，武漢 430000）

縮略語(yǔ)

SOAService-Oriented Architecture

EAEnterprise Architect

MEBModular Electrification Toolkit

TGNA Toyota New Global Architecture

SEASustainable Experience Architecture

PCProduct Capability

SOCSystem on Chip

SWCSoftware Component

ECUElectronic Control Unit

APIApplication Program Interface

PCMPulse Code Modulation

LINLocal Interconnect Network

ASILAutomotive Safety Integrity Level

CANController Area Network

CANFDCAN Flexible Data-rate

AUTOSARAutomotive Open System Architecture

XMLXtensible Markup Language

0 引言

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

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

（1）標(biāo)準(zhǔn)化的服務(wù)契約；

（2）服務(wù)松耦合；

（3）服務(wù)的可重用性；

（4）服務(wù)自治[6]。

由此可以看出，在設(shè)計(jì)、輸出車身控制系統(tǒng)或子系統(tǒng)對(duì)應(yīng)的功能規(guī)范時(shí)，在新的架構(gòu)方案下，系統(tǒng)設(shè)計(jì)人員還需要對(duì)服務(wù)接口進(jìn)行標(biāo)準(zhǔn)化定義。

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

1 模塊化層級(jí)框架搭建

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2 繪制功能用例流程圖

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

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

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

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

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

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

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

2.2.2 打包并部署軟件組件

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

2.2.3 設(shè)計(jì)軟件組件接口

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

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

2.2.4 繪制信號(hào)流程圖

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

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

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

3 基于EA的功能拓展

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

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

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

另外用到的開(kāi)發(fā)文檔是在AUTOSAR[15]標(biāo)準(zhǔn)下，采用可擴(kuò)展標(biāo)記語(yǔ)言（Automotive Open System Architecture Extensible Markup Language，ARXML）來(lái)傳遞具有層次結(jié)構(gòu)的接口數(shù)據(jù)。主要就是導(dǎo)出EA里的SWC及其接口部分信息、消費(fèi)的依賴關(guān)系內(nèi)容。因?yàn)榈谌焦ぞ呖梢酝ㄟ^(guò)API 直接訪問(wèn)數(shù)據(jù)庫(kù)，導(dǎo)出的數(shù)據(jù)比使用系統(tǒng)工具更快，通常利用第三方工具導(dǎo)出，然后利用MATLAB生成ARXML文檔。

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

4 設(shè)計(jì)方法實(shí)踐

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

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

圖2 部分氛圍燈功能需求用例設(shè)計(jì)

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

4.1 氛圍燈功能設(shè)計(jì)

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

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

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

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

4.2 氛圍燈接口模塊設(shè)計(jì)

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

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

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

圖5 部分信號(hào)流程

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

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

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

5 結(jié)論

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

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

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

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