面向服務(wù)的電子電氣架構(gòu)研究與應(yīng)用

劉 聰，陳 敏Liu Cong，Chen Min

面向服務(wù)的電子電氣架構(gòu)研究與應(yīng)用

劉 聰，陳 敏
Liu Cong，Chen Min

（上海禾騁科技有限公司，上海 201805）

汽車行業(yè)技術(shù)升級對電子電氣架構(gòu)提出了更高兼容性、靈活性、迭代能力等要求，介紹了面向服務(wù)的電子電氣架構(gòu)設(shè)計(jì)，提出面向服務(wù)架構(gòu)的開發(fā)流程、關(guān)鍵步驟及設(shè)計(jì)原則，并結(jié)合項(xiàng)目開發(fā)實(shí)例進(jìn)行分析。

面向服務(wù)；汽車電子電氣架構(gòu)；軟件架構(gòu)

0 引 言

汽車行業(yè)正在向更高算力、更高平臺化、更高靈活性方向發(fā)展，促進(jìn)了電子電氣架構(gòu)的重大變革。物理架構(gòu)將向域集中及區(qū)域控制方向演進(jìn)[1]，軟件架構(gòu)需要解決軟件復(fù)雜度提升、功能迭代頻繁的問題。SOA（Service Oriented Architecture，面向服務(wù)架構(gòu)設(shè)計(jì)）解決了汽車電子電氣架構(gòu)面臨的各種挑戰(zhàn)，在國內(nèi)外各大整車企業(yè)得到逐步應(yīng)用。

1 SOA架構(gòu)開發(fā)背景

1.1 傳統(tǒng)開發(fā)方式面臨的問題

汽車電子電氣架構(gòu)已從傳統(tǒng)的分布式演進(jìn)到集中式，在功能部署上從基于功能切換到基于物理區(qū)域劃分；但傳統(tǒng)的架構(gòu)開發(fā)方式以功能實(shí)現(xiàn)鏈路為核心、以信號為依托，在需要實(shí)現(xiàn)新增功能時(shí)，面臨著功能定義及功能開發(fā)效率低下、功能迭代開發(fā)周期長的問題，較難實(shí)現(xiàn)功能快速迭代，無法實(shí)現(xiàn)最優(yōu)的用車體驗(yàn)。

1.2 SOA應(yīng)用優(yōu)勢

基于SOA的電子電氣架構(gòu)以靈活性、可拓展性為傳統(tǒng)開發(fā)方式所面臨的問題提供了可行解決方案，其功能可分解為各個(gè)獨(dú)立的服務(wù)，服務(wù)之間通過服務(wù)接口交互，并通過服務(wù)的組合及部署實(shí)現(xiàn)功能應(yīng)用。這種基于服務(wù)的架構(gòu)設(shè)計(jì)可實(shí)現(xiàn)軟硬件解耦、功能靈活組合與快速實(shí)施，這些特性解決了汽車架構(gòu)設(shè)計(jì)面臨的挑戰(zhàn)，使得SOA架構(gòu)得到逐步應(yīng)用。

廣義上講，SOA平臺系統(tǒng)由3大系統(tǒng)組成：開發(fā)者平臺、云后臺和車輛。授權(quán)認(rèn)證的開發(fā)者登錄專屬的開發(fā)者平臺后，可以通過場景編輯等方式開發(fā)新的應(yīng)用程序。開發(fā)者平臺通過云平臺與車輛建立連接，通過服務(wù)通道發(fā)送服務(wù)指令，通過OTA（Over The Air，遠(yuǎn)程升級）通道向車輛推送個(gè)性化的應(yīng)用程序，實(shí)現(xiàn)了功能的快速組合、應(yīng)用的快速迭代。

結(jié)合項(xiàng)目實(shí)踐提出基于SOA架構(gòu)的功能開發(fā)及服務(wù)設(shè)計(jì)方法。

2 基于SOA的電子電氣架構(gòu)設(shè)計(jì)方法

對基于SOA的電子電氣架構(gòu)設(shè)計(jì)從功能場景分析，得出服務(wù)清單，并對服務(wù)進(jìn)行詳細(xì)設(shè)計(jì)、分層和映射，進(jìn)而得到軟件模塊的定義；同時(shí)結(jié)合車輛已有的傳感器、執(zhí)行器等硬件基礎(chǔ)，將硬件能力抽象為服務(wù)，通過服務(wù)組合得到應(yīng)用功能[2]。關(guān)鍵步驟包括功能設(shè)計(jì)、服務(wù)設(shè)計(jì)、模塊設(shè)計(jì)、通信設(shè)計(jì)等[3]。

2.1 功能設(shè)計(jì)

在功能設(shè)計(jì)階段，首先完成功能用例庫，輸入產(chǎn)品經(jīng)理提供的功能需求清單，輸出針對特定功能的用例。當(dāng)完成多個(gè)功能定義后，也就形成了基于整體功能的用例庫。功能用例庫的開發(fā)流程如圖1所示。

圖1 功能用例庫開發(fā)流程

針對功能用例進(jìn)行詳細(xì)設(shè)計(jì)，輸入為功能用例庫和當(dāng)前車輛的硬件配置，輸出為實(shí)現(xiàn)這些功能用例的服務(wù)，此階段中服務(wù)庫基于當(dāng)前功能用例分析和硬件配置分析建立，整體流程如圖2所示。

圖2 功能詳細(xì)設(shè)計(jì)開發(fā)流程

2.2 服務(wù)設(shè)計(jì)

在服務(wù)設(shè)計(jì)階段，基于功能設(shè)計(jì)階段生成的服務(wù)庫進(jìn)行服務(wù)接口詳細(xì)設(shè)計(jì)，定義服務(wù)接口的類型和設(shè)計(jì)規(guī)則。

2.2.1 服務(wù)接口類型

服務(wù)接口分為數(shù)據(jù)類、指令類和事件類。數(shù)據(jù)類型接口可以被get、set、notify調(diào)用，指令類接口可以直接被RR（Request/Response）、FF（Fire&Forget）調(diào)用，事件類接口可以被notify調(diào)用。各服務(wù)接口均遵循請求/響應(yīng)或訂閱/發(fā)布的交互機(jī)制。

2.2.2 服務(wù)接口設(shè)計(jì)規(guī)則

1）RR控制類指令

RR控制類指令應(yīng)用于需要執(zhí)行一段時(shí)間才會有效執(zhí)行反饋的控制類指令，其Response（響應(yīng)）中需要攜帶控制狀態(tài)，此時(shí)RR的Response僅表示接收到Request，并做了必要的前提判斷，并非真正的執(zhí)行結(jié)果。

對于可以對控制指令的Request做出及時(shí)反饋的控制類指令，其Response可直接攜帶是否執(zhí)行成功的信息。

2）通知類指令

通知類指令必須涵蓋該控制類指令所涉及的所有狀態(tài)，例如控制任一車窗全部開度的RR控制指令，必須有獲取/通知車窗當(dāng)前位置的狀態(tài)類指令與之對應(yīng)。

所有通知類指令攜帶的狀態(tài)數(shù)據(jù)必須包含指示數(shù)據(jù)有效性的信息，有如下幾種情況：（1）狀態(tài)數(shù)據(jù)對應(yīng)的CAN（Controller Area Network，控制器局域網(wǎng)）信號本身已有invalid枚舉項(xiàng)或信息，沿用并無需添加內(nèi)容；（2）狀態(tài)數(shù)據(jù)對應(yīng)的CAN信號為連續(xù)量，例如單電池電壓（0～4 095 mV），不在此范圍內(nèi)的數(shù)值即為無效值，不再額外定義invalid指示信息。

2.2.3 服務(wù)分類

對服務(wù)進(jìn)行分類及整合，將服務(wù)劃分為基礎(chǔ)服務(wù)、拓展服務(wù)、協(xié)調(diào)服務(wù)，其分層結(jié)構(gòu)如圖3所示，具體分類原則為：（1）基礎(chǔ)服務(wù)層為實(shí)現(xiàn)過程無任何依賴的需求，多指傳感器、執(zhí)行器；（2）拓展服務(wù)層依賴基礎(chǔ)層和域內(nèi)同層，一般指算法包；（3）有跨域交互需求的服務(wù)均在協(xié)調(diào)服務(wù)層。

圖3 服務(wù)分層結(jié)構(gòu)

2.3 模塊設(shè)計(jì)

模塊設(shè)計(jì)階段，依據(jù)服務(wù)定義創(chuàng)建相應(yīng)的SWC（Software Component，軟件組件），定義對應(yīng)SWC的接口信息及接口數(shù)據(jù)類型，描述SWC的靜態(tài)依賴關(guān)系及動(dòng)態(tài)依賴關(guān)系，將最終得到的SWC進(jìn)行打包部署，得出最終的輸出給到軟件開發(fā)團(tuán)隊(duì)。

從服務(wù)到SWC映射的設(shè)計(jì)方法包括：（1）根據(jù)SWC之間的調(diào)用關(guān)系明確SWC之間的詳細(xì)設(shè)計(jì)，包括實(shí)現(xiàn)某個(gè)需求所需的SWC之間的時(shí)序圖、活動(dòng)圖、狀態(tài)機(jī)；（2）明確SWC之間的信息傳遞，即服務(wù)接口；（3）在SWC部署階段，考慮各成熟ECU的功能實(shí)施方案，如底盤安全均在ESC（Electronic Stability Control System，電子穩(wěn)定控制系統(tǒng)）中，同時(shí)結(jié)合整車最終的域控制器方案定義每個(gè)SWC的歸屬。

2.4 通信設(shè)計(jì)

通信設(shè)計(jì)階段，完成數(shù)據(jù)類型定義、通信行為定義、SD（Service Discovery，服務(wù)發(fā)現(xiàn)）全局定義、SD ECU定義等。此階段屬于網(wǎng)絡(luò)設(shè)計(jì)，數(shù)據(jù)命名、數(shù)據(jù)類型定義等參照AUTOSAR（Automotive Open System Architecture，汽車開放系統(tǒng)架構(gòu)）標(biāo)準(zhǔn)，不再進(jìn)行詳細(xì)說明。

3 基于SOA的電子電氣架構(gòu)應(yīng)用

在某項(xiàng)目開發(fā)中，采用以太骨干網(wǎng)通信方式，并引入SOA架構(gòu)設(shè)計(jì)理念，通過開發(fā)實(shí)例對SOA架構(gòu)開發(fā)流程進(jìn)行說明。

3.1 功能設(shè)計(jì)及服務(wù)設(shè)計(jì)

在車身域和娛樂域中，選出功能用例和對應(yīng)的服務(wù)，具體見表1。功能列為功能清單輸入，包含迎賓功能、燈光功能、智能空調(diào)和賬戶管理4個(gè)功能；用例列由各功能定義；服務(wù)列為實(shí)現(xiàn)該特定用例所需要的服務(wù)。表1中功能用例和服務(wù)定義為部分示例。

表1 功能用例和服務(wù)定義示例

續(xù)表1

3.2 功能拓展實(shí)施

在已有功能和服務(wù)基礎(chǔ)上，添加一個(gè)新的智能迎賓場景，該場景定義為用戶攜帶智能鑰匙靠近車輛后，車輛自動(dòng)解鎖，外燈能夠自動(dòng)開關(guān)遠(yuǎn)光燈一次（迎賓效果），同時(shí)用戶打開門進(jìn)入車內(nèi)，空調(diào)可以自動(dòng)打開并調(diào)整到該用戶定制的溫度、風(fēng)速和風(fēng)向。原有的迎賓功能不具備此功能，如果采用傳統(tǒng)的電子電氣架構(gòu)開發(fā)方法，需要重新定義功能用例和功能實(shí)現(xiàn)方案、功能分配方案，會影響開發(fā)效率。

基于SOA的架構(gòu)系統(tǒng)，可以根據(jù)現(xiàn)有功能用例庫、服務(wù)庫進(jìn)行快速的功能定義和功能開發(fā)，節(jié)省開發(fā)效率。在現(xiàn)有的功能用例庫中，可以快速拆解出智能迎賓是由功能用例庫中的UC-001、UC-003、UC-004、UC-005和UC-006組成；再根據(jù)各用例和服務(wù)的關(guān)聯(lián)關(guān)系，得出實(shí)現(xiàn)該功能場景所必須的服務(wù)包括S0001、S0002、S0003、S0006、S0007、S0008、S0009、S0010、S0011、S0012、S0013和S0014。以上可實(shí)現(xiàn)復(fù)用原有設(shè)計(jì)，達(dá)到快速完成功能定義和功能開發(fā)的目的，如圖4所示。

圖4 智能迎賓功能設(shè)計(jì)

4 總 結(jié)

在總結(jié)傳統(tǒng)電子電氣架構(gòu)開發(fā)所面臨的問題和挑戰(zhàn)的基礎(chǔ)上，提出SOA架構(gòu)開發(fā)流程，說明開發(fā)流程的具體要求及設(shè)計(jì)原則，結(jié)合項(xiàng)目實(shí)例進(jìn)行展示。未來，基于SOA的設(shè)計(jì)能力會是整車廠重點(diǎn)發(fā)展的能力，其設(shè)計(jì)理念會得到更廣泛的應(yīng)用。

[1]劉佳熙,丁鋒.面向未來汽車電子電氣架構(gòu)的域控制器平臺[J].中國集成電路， 2019, 28(9):6.

[2]VETTER A，OBERGFELL P，GUISSOUMA H，et al，Development Processes in Automotive Service-oriented Architectures[C]//2020 9th Mediterranean Conference on Embedded Computing(MECO),2020.

[3]華一丁，龔進(jìn)峰，戎輝，等.基于模型的智能汽車電子電氣架構(gòu)發(fā)展綜述[J].汽車零部件，2019（2）：4.

2021-07-14

1002-4581（2021）06-0034-04

U463.6.02

A

10.14175/j.issn.1002-4581.2021.06.010