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

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

1 汽車架構的設計差異

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

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

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

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

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

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

2 功能定義

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

3 系統(tǒng)框圖

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

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

4 服務API設計

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

圖4 服務的軟件架構

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

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

5 測試搭建

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

6 原子服務技術思考

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

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

7 結論

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

編輯：黃飛

?