基于SOA的車身控制器設(shè)計

周 芹

（的盧技術(shù)有限公司，江蘇 南京 210000）

當(dāng)下汽車行業(yè)正面臨轉(zhuǎn)型的革命，隨著新四化的提出，軟件定義汽車已成為必然趨勢，軟硬件的解耦程度決定了企業(yè)產(chǎn)品的差異性，對硬件來說，需要可兼容、可擴展，對軟件來說，需要升級快、可移植性好，因此從架構(gòu)層面需要基于SOA來進行開發(fā)，將傳統(tǒng)的分布式架構(gòu)轉(zhuǎn)為中央集中式架構(gòu)，由中央計算單元與區(qū)域控制組成，將功能按顆粒度大小封裝成不同的原子服務(wù)，以標準的服務(wù)接口進行調(diào)用，在功能交互過程中，交互雙方無需考慮對方的協(xié)議，原子服務(wù)設(shè)計是決定軟硬件耦合深度的重要因素，好的原子服務(wù)設(shè)計可以降低整車成本、屏蔽異構(gòu)性且服務(wù)組合可以實現(xiàn)不同的功能，做到動態(tài)配置車輛功能。

1 汽車架構(gòu)的設(shè)計差異

1.1 傳統(tǒng)EE架構(gòu)開發(fā)

傳統(tǒng)EE架構(gòu)的開發(fā)流程如圖1所示，由市場首先對車型定位，針對定位尋找相應(yīng)的或更高配置的主流車型進行對標，主要對標其外形、內(nèi)飾、靜態(tài)功能和動態(tài)功能并牽頭全員填寫競品分析表，將分析結(jié)果整合并調(diào)研用戶需求后整理輸出配置表、技術(shù)梳理配置表，找到各自的相關(guān)項，轉(zhuǎn)換為技術(shù)方案，將配置表分解為多個功能邏輯，再將功能邏輯分配給多系統(tǒng)，輸出網(wǎng)絡(luò)通信需求表，根據(jù)需求表，輸出子系統(tǒng)的需求文檔，文檔中寫明I/O、人機交互界面、性能要求、應(yīng)用場景等，子系統(tǒng)根據(jù)功能分配自己的網(wǎng)絡(luò)接口和硬件接口，最后完成系統(tǒng)的原理圖和網(wǎng)絡(luò)開發(fā)。

圖1 傳統(tǒng)EE架構(gòu)的開發(fā)流程

1.2 在SOA下的EE架構(gòu)開發(fā)

基于SOA的EE架構(gòu)開發(fā)流程如圖2所示，與傳統(tǒng)相比，在輸出配置表和轉(zhuǎn)換功能邏輯是一致的，區(qū)別在于：功能邏輯轉(zhuǎn)換后，沒有直接分配系統(tǒng)而是將功能邏輯轉(zhuǎn)換為原子服務(wù)，根據(jù)顆粒度大小，定義出硬件抽象服務(wù)并定義原子服務(wù)的接口，根據(jù)架構(gòu)，將服務(wù)接口部署在不同的模塊內(nèi)，由于現(xiàn)汽車的自動駕駛等級越來越高，導(dǎo)致功能安全等級相應(yīng)提高，因此針對不同功能所需求的功能安全等級不一致，需要安全工程師梳理后，再根據(jù)所分配的功能安全等級、原子服務(wù)設(shè)計以及軟件模塊，進行軟件架構(gòu)和硬件架構(gòu)設(shè)計。

圖2 基于SOA的EE架構(gòu)開發(fā)流程

2 功能定義

以中央計算單元加區(qū)域控制的形式BCM集成了車身功能、空調(diào)功能、路由等功能，還具有網(wǎng)絡(luò)管理、信號檢測等功能，車身功能包括后除霜、外部燈光、內(nèi)部燈光、前照燈調(diào)節(jié)功能、防盜、背門控制、中控功能、雨刮洗滌、后視鏡功能、喇叭、天窗功能、RKE、PKE、玻璃升降、座椅調(diào)節(jié)等；空調(diào)功能主要是對泵、空調(diào)箱等電機或電磁閥的驅(qū)動，包括空調(diào)水泵驅(qū)動、電機水泵驅(qū)動、冷凝器風(fēng)扇驅(qū)動、空調(diào)板驅(qū)動、冷卻泵驅(qū)動、制冷機功能、空調(diào)箱功能、鼓風(fēng)機驅(qū)動等；路由功能分為信號路由和線束路由，信號路由是因為BCM還承擔(dān)網(wǎng)關(guān)的角色，BCM與中央計算單元采用百兆或千兆以太網(wǎng)連接，與其他ECU采用CAN或十兆以太網(wǎng)連接，需要將其他ECU的信號轉(zhuǎn)發(fā)至中央計算單元，實現(xiàn)信號路由，而線束路由則是將需要轉(zhuǎn)接的硬線信號，通過BCM控制器進行轉(zhuǎn)接；因為整車在下電后既要保證車輛在一定時間內(nèi)蓄電池不虧電又要保證車輛功能能夠喚醒，因此網(wǎng)絡(luò)管理尤為重要，網(wǎng)絡(luò)管理包括定義喚醒模式、睡眠模式，需要根據(jù)不同的通信方式進行睡眠管理；信號檢測包括碰撞信號、門開關(guān)檢測、門狀態(tài)檢測、溫度檢測、陽光檢測、擋位開關(guān)檢測、燈光開關(guān)檢測等。

3 系統(tǒng)框圖

根據(jù)架構(gòu)和功能定義，得到BCM的系統(tǒng)框圖（圖3），電源管理模塊將外部KL30常電轉(zhuǎn)換為系統(tǒng)芯片所需的系統(tǒng)電壓并保持穩(wěn)定，MCU芯片支持數(shù)字信號和模擬信號的輸入。一般開關(guān)類的信號為數(shù)字信號，如門開關(guān)；傳感器一般為模擬信號，如溫度傳感器、位置傳感器等，或部分開關(guān)是PWM形式也屬于模擬信號，如燈光亮度調(diào)節(jié)、碰撞信號等。BCM內(nèi)部有CAN收發(fā)器，支持CAN或CANFD的信號，將LIN信號作為硬件預(yù)留，有實時性要求不高且非安全類的產(chǎn)品可使用LIN通信，MCU有主MCU和輔MCU，輔MCU主要是對功能作冗余備份，對于外部燈光驅(qū)動有兩種形式，分別為高邊驅(qū)動HSD和低邊驅(qū)動LSD，在大部分場景下，使用HSD較多，將LSD作為硬件預(yù)留，但HSD的驅(qū)動電流一般小于15A，如洗滌泵、電機水泵常采用半橋芯片和MOS管來驅(qū)動，不同的MOS管驅(qū)動電流不同，可以支持近400A的電流驅(qū)動，BCM內(nèi)置以太網(wǎng)交換機和PHY芯片，支持十兆/百兆/千兆以太網(wǎng)的ECU通信。

圖3 BCM的系統(tǒng)框圖

4 服務(wù)API設(shè)計

服務(wù)的軟件架構(gòu)如圖4所示，分為硬件層、基礎(chǔ)軟件層、功能軟件、硬件/設(shè)備抽象層、原子服務(wù)層、RTE運行環(huán)境和應(yīng)用層，因為BCM不存在音視頻接收和圖片接收，因此沒有SOC、GPU或DSP等異構(gòu)芯片。在軟件層，對于硬實時信號，使用classical autosar，針對軟實時使用adaptive autosar，adaptive autosar也是實現(xiàn)原子服務(wù)的關(guān)鍵，硬件/設(shè)備抽象層，是對輸入接口、傳感器/執(zhí)行器等硬件進行抽象，目的是屏蔽硬件差異對軟件的影響，原子服務(wù)則是通過排列組合為應(yīng)用層提供統(tǒng)一接口，提高開發(fā)效率，RTE為應(yīng)用層的APP提供運行環(huán)境，應(yīng)用層是將功能體驗直接面向用戶，形成產(chǎn)品競爭力。

圖4 服務(wù)的軟件架構(gòu)

原子服務(wù)設(shè)計，首先根據(jù)function list，列出BCM的所有功能，然后按照顆粒度大小，將功能轉(zhuǎn)換為合適的API描述，在服務(wù)API描述中定義服務(wù)類型，可以是最小服務(wù)API，也可以是組合后的API，最小服務(wù)API如左前門開關(guān)服務(wù)，組合后API可以是左前門服務(wù)，此服務(wù)包括門鎖狀態(tài)、車把手狀態(tài)、車門狀態(tài)、車門開度、兒童鎖狀態(tài)等。一般BCM的原子服務(wù)定義為如下：車門服務(wù)、尾門服務(wù)、車窗服務(wù)、天窗服務(wù)、遮陽服務(wù)、車鑰匙服務(wù)、車外鳴笛服務(wù)、低速報警服務(wù)、外后視鏡服務(wù)、座椅服務(wù)、座椅通風(fēng)加熱服務(wù)、方向盤調(diào)節(jié)服務(wù)、迎賓服務(wù)、雨刮洗滌服務(wù)、制動燈服務(wù)、轉(zhuǎn)向燈服務(wù)、報警燈服務(wù)、日行燈服務(wù)、霧燈服務(wù)、近光燈服務(wù)、遠光燈服務(wù)、位置燈服務(wù)、倒車燈服務(wù)、激光燈服務(wù)、后牌照燈服務(wù)、logo燈服務(wù)、前照燈調(diào)節(jié)服務(wù)、空氣凈化服務(wù)、頂燈服務(wù)、手套箱服務(wù)、除霜除霧服務(wù)等。對于設(shè)備服務(wù)，定義如下：門開關(guān)、門鎖、尾門開關(guān)、尾門鎖、尾門電機、車窗開關(guān)、車窗電機等，根據(jù)輸入條件和輸出控制，隔離相應(yīng)的設(shè)備。

以溫度檢測服務(wù)為例，依據(jù)SOME/IP的報文格式，需要定 義service ID/method ID、client ID、session ID、RPC type、返回值、報文周期、調(diào)用描述等，服務(wù)的調(diào)用方法有method、filed、fire and forget、event，其中method又分為RR和FF類型，filed分為setter/getter和notifier，那么該服務(wù)里的provider是BCM，consumer是中央計算單元。服務(wù)接口可以定義為幾種形式，當(dāng)使用RR-method時，對溫度傳感器狀態(tài)檢測，使用FF-method時，通知中央計算單元溫度過高，當(dāng)使用field，溫度值檢測，當(dāng)使用event時，檢測到超過某一閾值后再上報。以field溫度值調(diào)用為例，服務(wù)的server為BCM，服務(wù)的client為中央計算單元，service ID為0x4003，Instance ID為0x0001，server port為30500，client ID為0X0003，client port為30500，服務(wù)描述為：該服務(wù)主要識別室外溫度值，RPC type是field，field屬性字段名為Snsr_TemperOut，field字段數(shù)據(jù)類型為float ntfT（），RPC Specific Type為getter，Method Name為OutSIdeTemp，以上ID和port僅作為示例，具體由車企根據(jù)實際情況確認。

5 測試搭建

傳統(tǒng)的測試無論是軟件測試、硬件測試、集成測試都無法滿足當(dāng)下基于SOA的控制器設(shè)計，傳統(tǒng)軟件并未深入使用AUTOSAR架構(gòu)和引入功能安全概念，更多使用的是供應(yīng)商自身的軟件架構(gòu)平臺，導(dǎo)致測試無法統(tǒng)一且無法滿足現(xiàn)設(shè)計，功能集成測試更多是針對信號相關(guān)方的發(fā)送與接收，驗證發(fā)送時間的正確性和接收方接收的正確性以及發(fā)送的間隔時間等，但新型架構(gòu)下的功能集成測試需要重新搭建，在軟件測試中，需要搭建新的測試平臺，如軟件單元測試中，需增加服務(wù)接口測試、服務(wù)調(diào)度測試等，在軟件集成測試中，各個組件拼接后，在PCBA上需要調(diào)度CPU資源測試、內(nèi)存隔離測試等，由于車身控制器與車輛數(shù)字鑰匙相關(guān)，在硬件中需要增加安全芯片，以HSM對系統(tǒng)內(nèi)部監(jiān)測，以SE對外部通信監(jiān)測，因此軟件安全測試中，需增加主被動攻擊測試、芯片時序、密鑰安全測試以及數(shù)字鑰匙證書測試，要求滿足國密等級。

6 原子服務(wù)技術(shù)思考

SOA的實現(xiàn)不僅是一個獨立事件，涉及到EE架構(gòu)以及整個生態(tài)的搭建，已有的軟件平臺已成熟且可靠，新的軟件投入給車企及供應(yīng)商都帶來成本大幅增加且對工程師的技能更為嚴苛，需要掌握復(fù)合型的知識體系，SOA基于SOME/IP實現(xiàn)，SOME/IP在數(shù)據(jù)傳輸時有延遲且是軟實時。

各個軟件層與通信層需要協(xié)同調(diào)度，多者的一致性會影響服務(wù)響應(yīng)的實時性，調(diào)度時間長產(chǎn)生較差的體驗感；用戶不同的車輛需求，要求服務(wù)有更高的部署靈活性，然后如何部署既能兼容定制化又能靈活配置；傳統(tǒng)對網(wǎng)絡(luò)測試基本是基于CAN或LIN，引入SOA概念后，需要搭建一套新的針對以太網(wǎng)的測試平臺；原子服務(wù)設(shè)計有評價指標，好的評價指標會指導(dǎo)后續(xù)設(shè)計的可行性，統(tǒng)一設(shè)計理念，降低差異化；傳統(tǒng)的一個功能會拆分為多個服務(wù)，且服務(wù)可能存在于不同的ECU，增加了軟件的復(fù)雜度且影響性能；每個服務(wù)都需要有獨立的配置、部署、監(jiān)控和收集，增加了成本；硬件的冗余和對于功能安全ASIL認證和AUTOSAR的使用，產(chǎn)生的費用也會增加成本。

7 結(jié)論

針對以上概述，合適顆粒度的服務(wù)原型不僅可以從組織層面、架構(gòu)層面、運維層面、設(shè)計層面等多方面降低成本且做到產(chǎn)品的差異化，真正滿足用戶千人千面的需求且適應(yīng)當(dāng)前電子電氣架構(gòu)開發(fā)，在車身控制器上不存在異構(gòu)芯片設(shè)計和多操作系統(tǒng)共存的情況，但關(guān)于智能座艙或自動駕駛模塊，會比車身控制器面臨更大的挑戰(zhàn)，但車身控制器也需提前考慮。隨著架構(gòu)和開發(fā)能力的提高，未來車身控制器與自動駕駛或智能座艙融合也逐漸變?yōu)榭赡堋?/p>