【摘 要】隨著車輛功能逐漸增多，用戶需求不停更新，車輛軟件需要快速迭代才能給用戶更好的服務(wù)體驗(yàn)，更快的功能體驗(yàn)，真正滿足千人千面的需求，從分布式EE架構(gòu)轉(zhuǎn)變?yōu)楝F(xiàn)在的中央計(jì)算加區(qū)域控制的架構(gòu)，以SOA的形式實(shí)現(xiàn)軟硬解耦，將更多的功能以原子服務(wù)的封裝集中到車身控制器（BCM），根據(jù)動(dòng)態(tài)配置進(jìn)行不同服務(wù)的調(diào)用。本文從整車架構(gòu)、BCM的功能定義、原子服務(wù)劃分講述BCM的原子服務(wù)設(shè)計(jì)。

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

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

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

傳統(tǒng)EE架構(gòu)的開發(fā)流程如圖1所示，由市場(chǎng)首先對(duì)車型定位，針對(duì)定位尋找相應(yīng)的或更高配置的主流車型進(jìn)行對(duì)標(biāo)，主要對(duì)標(biāo)其外形、內(nèi)飾、靜態(tài)功能和動(dòng)態(tài)功能并牽頭全員填寫競品分析表，將分析結(jié)果整合并調(diào)研用戶需求后整理輸出配置表、技術(shù)梳理配置表，找到各自的相關(guān)項(xiàng)，轉(zhuǎn)換為技術(shù)方案，將配置表分解為多個(gè)功能邏輯，再將功能邏輯分配給多系統(tǒng)，輸出網(wǎng)絡(luò)通信需求表，根據(jù)需求表，輸出子系統(tǒng)的需求文檔，文檔中寫明I/O、人機(jī)交互界面、性能要求、應(yīng)用場(chǎ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òng)駕駛等級(jí)越來越高，導(dǎo)致功能安全等級(jí)相應(yīng)提高，因此針對(duì)不同功能所需求的功能安全等級(jí)不一致，需要安全工程師梳理后，再根據(jù)所分配的功能安全等級(jí)、原子服務(wù)設(shè)計(jì)以及軟件模塊，進(jìn)行軟件架構(gòu)和硬件架構(gòu)設(shè)計(jì)。

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

2 功能定義

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

3 系統(tǒng)框圖

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

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

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

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

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

原子服務(wù)設(shè)計(jì)，首先根據(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ù)、低速報(bào)警服務(wù)、外后視鏡服務(wù)、座椅服務(wù)、座椅通風(fēng)加熱服務(wù)、方向盤調(diào)節(jié)服務(wù)、迎賓服務(wù)、雨刮洗滌服務(wù)、制動(dòng)燈服務(wù)、轉(zhuǎn)向燈服務(wù)、報(bào)警燈服務(wù)、日行燈服務(wù)、霧燈服務(wù)、近光燈服務(wù)、遠(yuǎn)光燈服務(wù)、位置燈服務(wù)、倒車燈服務(wù)、激光燈服務(wù)、后牌照燈服務(wù)、logo燈服務(wù)、前照燈調(diào)節(jié)服務(wù)、空氣凈化服務(wù)、頂燈服務(wù)、手套箱服務(wù)、除霜除霧服務(wù)等。對(duì)于設(shè)備服務(wù)，定義如下：門開關(guān)、門鎖、尾門開關(guān)、尾門鎖、尾門電機(jī)、車窗開關(guān)、車窗電機(jī)等，根據(jù)輸入條件和輸出控制，隔離相應(yīng)的設(shè)備。

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

5 測(cè)試搭建

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

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

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

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

7 結(jié)論

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

編輯：黃飛

?