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

0 引言

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

在當(dāng)下軟件定義汽車的時(shí)代[4]，汽車生產(chǎn)廠商依托架構(gòu)方案進(jìn)行造車，以控制成本，提高產(chǎn)品競爭力[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)前國際上先進(jìn)的面向服務(wù)化的汽車架構(gòu)（Service-Oriented Architecture，SOA）。這些汽車構(gòu)架具有粗粒度、松耦合的特征，服務(wù)之間通過定義簡單、精確的接口進(jìn)行通訊，其設(shè)計(jì)的基本原則主要有：

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

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

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

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

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

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

1 模塊化層級框架搭建

利用EA開展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)對功能進(jìn)行標(biāo)識(shí)，新增的功能需求按新的順序進(jìn)行編號(hào)，固化的功能需求不再改變編號(hào)，把此車型平臺(tái)上所有功能需求匯集在一個(gè)服務(wù)器上，當(dāng)開發(fā)不同車型時(shí)，根據(jù)功能需求進(jìn)行拆分重組，完成車身域子系統(tǒng)的功能設(shè)計(jì)，輸出功能規(guī)范和開發(fā)交付物。

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

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

使用EA 搭建模塊化層級的框架，首先需建立功能需求文檔，這是開展車身控制域子系統(tǒng)設(shè)計(jì)的基礎(chǔ)，主要用于存放設(shè)計(jì)中的功能描述和功能用例流程圖。在功能需求文檔的子文檔中，需要對功能進(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)軟件開發(fā)；系統(tǒng)工程師根據(jù)性能需求，提出可量化、可實(shí)現(xiàn)的性能指標(biāo)，比如系統(tǒng)的資源占用情況、響應(yīng)時(shí)間要求。

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

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

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

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

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

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

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

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

在獲得車身控制域的系統(tǒng)功能需求后，應(yīng)對其進(jìn)行分解。把一項(xiàng)功能拆解成多條功能用例，在EA 中用案例（Use Case）元素進(jìn)行表示，考慮支持實(shí)現(xiàn)這些功能用例的需求，每一條功能用例的前置條件、觸發(fā)條件、執(zhí)行方法或步驟，在執(zhí)行動(dòng)作過程中，有其他異常情況發(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í)就可繪制功能流程的傳遞過程，在此基礎(chǔ)上加入功能定義中的判斷條件，可完成功能用例流程圖設(shè)計(jì)。

功能用例流程圖的主要作用是梳理功能邏輯，分配功能任務(wù)。通過功能用例流程圖，系統(tǒng)設(shè)計(jì)人員可以明確系統(tǒng)的依賴關(guān)系以及系統(tǒng)的邏輯、時(shí)序和步驟，各軟件組件也能明確自身需要完成的工作內(nèi)容。狀態(tài)機(jī)和活動(dòng)圖在EA中均有對應(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ì)。在搭建模塊化層級框架時(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]，該組件可通過EA 中的關(guān)系圖，對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元素，再通過部署圖實(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對基礎(chǔ)元素的封裝能力，把EA的基礎(chǔ)接口封裝出不同類型的接口。以SOC為基礎(chǔ)單元，根據(jù)架構(gòu)的層級關(guān)系，每個(gè)層級之間建立的標(biāo)準(zhǔn)接口為內(nèi)部接口，與其他SOC 之間的交互稱為外部接口；若以SWC 為基礎(chǔ)單元，其外部接口和需求接口，分別代表著SWC能提供的服務(wù)和消費(fèi)依賴；每個(gè)外部接口元素可以在“操作”（Operation）選項(xiàng)卡里添加具體的接口名稱，并將添加的外部接口名稱提供給其他SWC進(jìn)行消費(fèi)；需求接口則是其余SWC 的外部接口，不能自行建立，需依賴方的SWC 建立外部接口，通過消費(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ù)類型與程序開發(fā)高級語言中的數(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)與功能用例流程圖對應(yīng)，是以每個(gè)SWC 為單元，接口消費(fèi)關(guān)系為鏈路的示意圖，能更詳細(xì)表達(dá)出數(shù)據(jù)在軟件組件之間的流轉(zhuǎn)關(guān)系，對后期系統(tǒng)問題故障診斷起到非常有用的幫助。

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

在進(jìn)行一些涉及行車安全的系統(tǒng)設(shè)計(jì)時(shí)，如雨刮系統(tǒng)、大燈系統(tǒng)[13]，功能安全專業(yè)會(huì)對某些場景提出需求，通過ASIL等級進(jìn)行約束和規(guī)范，這些特殊的需求可以使用需求（Requirement）元素進(jìn)行描述，并在圖中與Use Case進(jìn)行關(guān)聯(lián)，形成對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]后，可以通過共享服務(wù)器的方式，為有需求的使用人員開辟賬號(hào)查看或編輯內(nèi)容。但在實(shí)際開發(fā)過程中，為了追求更好的設(shè)計(jì)質(zhì)量，不同的系統(tǒng)大多是分配給不同的軟件供應(yīng)商完成，為了項(xiàng)目全盤設(shè)計(jì)內(nèi)容的安全性、保密性，往往是單獨(dú)提供供應(yīng)商承接的開發(fā)內(nèi)容部分，所以設(shè)計(jì)的產(chǎn)出只保留在系統(tǒng)或者服務(wù)器中是遠(yuǎn)遠(yuǎn)不夠的，還需要把系統(tǒng)中設(shè)計(jì)的內(nèi)容導(dǎo)出來使用。

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

系統(tǒng)開發(fā)過程中常用到的開發(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)入功能對應(yīng)的需求內(nèi)容、前置條件、觸發(fā)條件、執(zhí)行方法或步驟，形成文檔后進(jìn)行導(dǎo)出保存。此方法的好處在于文檔是一個(gè)動(dòng)態(tài)鏈接的狀態(tài)，如果元素中有更新，刷新文檔后，對應(yīng)的內(nèi)容也會(huì)更新，保證了設(shè)計(jì)與文檔同步。另一種方法則是利用第三方的腳本進(jìn)行導(dǎo)出，此方法的缺點(diǎn)是若文檔有更新，則需要重新導(dǎo)出，無法像在線設(shè)計(jì)一樣同步更新。

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

基于EA 提供的API，可以直接進(jìn)行數(shù)據(jù)庫訪問，具有強(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ì)工作。

需要說明的是圖2～圖6所涉及的內(nèi)容僅作為示例展示，相對于實(shí)際開發(fā)做了處理，實(shí)際開發(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 中對氛圍燈功能進(jìn)行拆分，氛圍燈首先具有中控屏與語音打開和關(guān)閉的Use Case。往下層級拆分，有通過中控屏與語音選擇的靜態(tài)、動(dòng)態(tài)氛圍燈控制的Use Case。再往下一個(gè)層級，靜態(tài)氛圍燈具有中控屏與語音調(diào)節(jié)顏色、亮度的Use Case，動(dòng)態(tài)氛圍燈具有音樂律動(dòng)模式與隨駕駛模式兩種選擇的Use Case，其中音樂律動(dòng)模式下面又拆分有3 種色域（冷色、暖色、中色）的選擇Use Case，讓音樂律動(dòng)的值在色域中進(jìn)行律動(dòng)。

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

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

根據(jù)架構(gòu)拓?fù)淝闆r，梳理出關(guān)聯(lián)單元，在EA中建立相應(yīng)的ECU單元元素，開展功能分配工作。功能的分配同樣可以應(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)方討論后，由對方承接并建立相應(yīng)的PC。PC 建立完整后就可以針對每個(gè)Use Case 繪制相應(yīng)的流程圖，見圖3。

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

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

根據(jù)PC能力進(jìn)行整合與分配，建立對應(yīng)的SWC，氛圍燈系統(tǒng)主要分音樂律動(dòng)算法部分SWC、邏輯控制部分SWC、燈頭驅(qū)動(dòng)SWC 以及中間件信號(hào)路由能力。建立SWC后需對其進(jìn)行部署，其中音樂律動(dòng)算法的SWC 部署在安卓系統(tǒng)內(nèi)部，這樣可以直接獲得到PCM源碼音頻數(shù)據(jù)，利用算法提取到用于控制氛圍燈的音頻、振幅等音樂特征；邏輯控制部分的SWC（圖4）針對氛圍燈的控制邏輯進(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）方式通過路由傳給燈頭，按照同樣的方式建立服務(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)流程圖的繪制，見圖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）。利用第三方腳本插件，可以對元素中的信息進(jìn)行選擇性導(dǎo)出生成Word 文檔，利用此腳本可以按照模板生成氛圍燈的功能規(guī)范。如果軟件開發(fā)方需要ARXML 作為軟件開發(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 開展車身域系統(tǒng)設(shè)計(jì)工作，通過圖表的方式能很好地理清系統(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)已在國內(nèi)汽車行業(yè)逐漸流行，傳統(tǒng)手寫功能規(guī)范的方式在車身域場景化的開發(fā)中效率低下，需要一些信息化的工具輔助完成系統(tǒng)設(shè)計(jì)工作，經(jīng)實(shí)踐EA 符合目前汽車行業(yè)車身域系統(tǒng)設(shè)計(jì)需求。

應(yīng)用EA 開展系統(tǒng)設(shè)計(jì)，有利于設(shè)計(jì)協(xié)同性和信息查詢的便利性。應(yīng)用EA 進(jìn)行設(shè)計(jì)的人員，可以分模塊化同步開展工作，相互之間不干擾，有依賴需求時(shí)通過圖表元素建立關(guān)系，各個(gè)系統(tǒng)的設(shè)計(jì)人員之間從圖表元素中獲得對方的需求，進(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ì)量。

編輯：黃飛

?