【摘 要】隨著車輛功能逐漸增多，用戶需求不停更新，車輛軟件需要快速迭代才能給用戶更好的服務(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ù)動態(tài)配置進(jìn)行不同服務(wù)的調(diào)用。本文從整車架構(gòu)、BCM的功能定義、原子服務(wù)劃分講述BCM的原子服務(wù)設(shè)計(jì)。
當(dāng)下汽車行業(yè)正面臨轉(zhuǎn)型的革命，隨著新四化的提出，軟件定義汽車已成為必然趨勢，軟硬件的解耦程度決定了企業(yè)產(chǎn)品的差異性，對硬件來說，需要可兼容、可擴(kuò)展，對軟件來說，需要升級快、可移植性好，因此從架構(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)用，在功能交互過程中，交互雙方無需考慮對方的協(xié)議，原子服務(wù)設(shè)計(jì)是決定軟硬件耦合深度的重要因素，好的原子服務(wù)設(shè)計(jì)可以降低整車成本、屏蔽異構(gòu)性且服務(wù)組合可以實(shí)現(xiàn)不同的功能，做到動態(tài)配置車輛功能。
1 汽車架構(gòu)的設(shè)計(jì)差異
1.1 傳統(tǒng)EE架構(gòu)開發(fā)
傳統(tǒng)EE架構(gòu)的開發(fā)流程如圖1所示，由市場首先對車型定位，針對定位尋找相應(yīng)的或更高配置的主流車型進(jìn)行對標(biāo)，主要對標(biāo)其外形、內(nèi)飾、靜態(tài)功能和動態(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)用場景等，子系統(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è)計(jì)以及軟件模塊，進(jìn)行軟件架構(gòu)和硬件架構(gòu)設(shè)計(jì)。
圖2 基于SOA的EE架構(gòu)開發(fā)流程
2 功能定義
以中央計(jì)算單元加區(qū)域控制的形式BCM集成了車身功能、空調(diào)功能、路由等功能，還具有網(wǎng)絡(luò)管理、信號檢測等功能，車身功能包括后除霜、外部燈光、內(nèi)部燈光、前照燈調(diào)節(jié)功能、防盜、背門控制、中控功能、雨刮洗滌、后視鏡功能、喇叭、天窗功能、RKE、PKE、玻璃升降、座椅調(diào)節(jié)等；空調(diào)功能主要是對泵、空調(diào)箱等電機(jī)或電磁閥的驅(qū)動，包括空調(diào)水泵驅(qū)動、電機(jī)水泵驅(qū)動、冷凝器風(fēng)扇驅(qū)動、空調(diào)板驅(qū)動、冷卻泵驅(qū)動、制冷機(jī)功能、空調(diào)箱功能、鼓風(fēng)機(jī)驅(qū)動等；路由功能分為信號路由和線束路由，信號路由是因?yàn)锽CM還承擔(dān)網(wǎng)關(guān)的角色，BCM與中央計(jì)算單元采用百兆或千兆以太網(wǎng)連接，與其他ECU采用CAN或十兆以太網(wǎng)連接，需要將其他ECU的信號轉(zhuǎn)發(fā)至中央計(jì)算單元，實(shí)現(xiàn)信號路由，而線束路由則是將需要轉(zhuǎn)接的硬線信號，通過BCM控制器進(jìn)行轉(zhuǎn)接；因?yàn)檎囋谙码姾蠹纫ＷC車輛在一定時(shí)間內(nèi)蓄電池不虧電又要保證車輛功能能夠喚醒，因此網(wǎng)絡(luò)管理尤為重要，網(wǎng)絡(luò)管理包括定義喚醒模式、睡眠模式，需要根據(jù)不同的通信方式進(jìn)行睡眠管理；信號檢測包括碰撞信號、門開關(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芯片支持?jǐn)?shù)字信號和模擬信號的輸入。一般開關(guān)類的信號為數(shù)字信號，如門開關(guān)；傳感器一般為模擬信號，如溫度傳感器、位置傳感器等，或部分開關(guān)是PWM形式也屬于模擬信號，如燈光亮度調(diào)節(jié)、碰撞信號等。BCM內(nèi)部有CAN收發(fā)器，支持CAN或CANFD的信號，將LIN信號作為硬件預(yù)留，有實(shí)時(shí)性要求不高且非安全類的產(chǎn)品可使用LIN通信，MCU有主MCU和輔MCU，輔MCU主要是對功能作冗余備份，對于外部燈光驅(qū)動有兩種形式，分別為高邊驅(qū)動HSD和低邊驅(qū)動LSD，在大部分場景下，使用HSD較多，將LSD作為硬件預(yù)留，但HSD的驅(qū)動電流一般小于15A，如洗滌泵、電機(jī)水泵常采用半橋芯片和MOS管來驅(qū)動，不同的MOS管驅(qū)動電流不同，可以支持近400A的電流驅(qū)動，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)芯片。在軟件層，對于硬實(shí)時(shí)信號，使用classical autosar，針對軟實(shí)時(shí)使用adaptive autosar，adaptive autosar也是實(shí)現(xiàn)原子服務(wù)的關(guān)鍵，硬件/設(shè)備抽象層，是對輸入接口、傳感器/執(zhí)行器等硬件進(jìn)行抽象，目的是屏蔽硬件差異對軟件的影響，原子服務(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ù)、制動燈服務(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ù)等。對于設(shè)備服務(wù)，定義如下：門開關(guān)、門鎖、尾門開關(guān)、尾門鎖、尾門電機(jī)、車窗開關(guān)、車窗電機(jī)等，根據(jù)輸入條件和輸出控制，隔離相應(yīng)的設(shè)備。
以溫度檢測服務(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í)，對溫度傳感器狀態(tài)檢測，使用FF-method時(shí)，通知中央計(jì)算單元溫度過高，當(dāng)使用field，溫度值檢測，當(dāng)使用event時(shí)，檢測到超過某一閾值后再上報(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ù)主要識別室外溫度值，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 測試搭建
傳統(tǒng)的測試無論是軟件測試、硬件測試、集成測試都無法滿足當(dāng)下基于SOA的控制器設(shè)計(jì)，傳統(tǒng)軟件并未深入使用AUTOSAR架構(gòu)和引入功能安全概念，更多使用的是供應(yīng)商自身的軟件架構(gòu)平臺，導(dǎo)致測試無法統(tǒng)一且無法滿足現(xiàn)設(shè)計(jì)，功能集成測試更多是針對信號相關(guān)方的發(fā)送與接收，驗(yàn)證發(fā)送時(shí)間的正確性和接收方接收的正確性以及發(fā)送的間隔時(shí)間等，但新型架構(gòu)下的功能集成測試需要重新搭建，在軟件測試中，需要搭建新的測試平臺，如軟件單元測試中，需增加服務(wù)接口測試、服務(wù)調(diào)度測試等，在軟件集成測試中，各個(gè)組件拼接后，在PCBA上需要調(diào)度CPU資源測試、內(nèi)存隔離測試等，由于車身控制器與車輛數(shù)字鑰匙相關(guān)，在硬件中需要增加安全芯片，以HSM對系統(tǒng)內(nèi)部監(jiān)測，以SE對外部通信監(jiān)測，因此軟件安全測試中，需增加主被動攻擊測試、芯片時(shí)序、密鑰安全測試以及數(shù)字鑰匙證書測試，要求滿足國密等級。
6 原子服務(wù)技術(shù)思考
SOA的實(shí)現(xiàn)不僅是一個(gè)獨(dú)立事件，涉及到EE架構(gòu)以及整個(gè)生態(tài)的搭建，已有的軟件平臺已成熟且可靠，新的軟件投入給車企及供應(yīng)商都帶來成本大幅增加且對工程師的技能更為嚴(yán)苛，需要掌握復(fù)合型的知識體系，SOA基于SOME/IP實(shí)現(xiàn)，SOME/IP在數(shù)據(jù)傳輸時(shí)有延遲且是軟實(shí)時(shí)。
各個(gè)軟件層與通信層需要協(xié)同調(diào)度，多者的一致性會影響服務(wù)響應(yīng)的實(shí)時(shí)性，調(diào)度時(shí)間長產(chǎn)生較差的體驗(yàn)感；用戶不同的車輛需求，要求服務(wù)有更高的部署靈活性，然后如何部署既能兼容定制化又能靈活配置；傳統(tǒng)對網(wǎng)絡(luò)測試基本是基于CAN或LIN，引入SOA概念后，需要搭建一套新的針對以太網(wǎng)的測試平臺；原子服務(wù)設(shè)計(jì)有評價(jià)指標(biāo)，好的評價(jià)指標(biāo)會指導(dǎo)后續(xù)設(shè)計(jì)的可行性，統(tǒng)一設(shè)計(jì)理念，降低差異化；傳統(tǒng)的一個(gè)功能會拆分為多個(gè)服務(wù)，且服務(wù)可能存在于不同的ECU，增加了軟件的復(fù)雜度且影響性能；每個(gè)服務(wù)都需要有獨(dú)立的配置、部署、監(jiān)控和收集，增加了成本；硬件的冗余和對于功能安全ASIL認(rèn)證和AUTOSAR的使用，產(chǎn)生的費(fèi)用也會增加成本。
7 結(jié)論
針對以上概述，合適顆粒度的服務(wù)原型不僅可以從組織層面、架構(gòu)層面、運(yùn)維層面、設(shè)計(jì)層面等多方面降低成本且做到產(chǎn)品的差異化，真正滿足用戶千人千面的需求且適應(yīng)當(dāng)前電子電氣架構(gòu)開發(fā)，在車身控制器上不存在異構(gòu)芯片設(shè)計(jì)和多操作系統(tǒng)共存的情況，但關(guān)于智能座艙或自動駕駛模塊，會比車身控制器面臨更大的挑戰(zhàn)，但車身控制器也需提前考慮。隨著架構(gòu)和開發(fā)能力的提高，未來車身控制器與自動駕駛或智能座艙融合也逐漸變?yōu)榭赡堋?
參考文獻(xiàn)
[1]中國汽車工業(yè)協(xié)會軟件定義汽車工作組.軟件定義汽車服務(wù)API API Version 2第一部分：原子服務(wù)API參考[S].
[2]中國汽車工業(yè)協(xié)會軟件定義汽車工作組.軟件定義汽車服務(wù)API API Version 2第二部分：設(shè)備抽象API參考[S].
[3]中國汽車工業(yè)協(xié)會軟件定義汽車工作組.軟件定義汽車服務(wù)API 第二部分：設(shè)備抽象API參考變更說明[S].
[4]中國汽車工業(yè)協(xié)會軟件定義汽車工作組.軟件定義汽車服務(wù)API 第一部分：原子服務(wù)API參考變更說明[S].
[5]中國汽車基礎(chǔ)軟件生態(tài)委員會（AUTOSEMO）.車載SOA軟件架構(gòu)技術(shù)規(guī)范1.0[S].
[6]馬建輝，王知學(xué)，侯冬冬，等.一種集成式汽車BCM的設(shè)計(jì)與實(shí)現(xiàn)[J].汽車電器，2019（2）：25-27.
[7]湯自寧，吳瑾，王冠達(dá)，等.集成于車身控制器的胎壓接收模塊硬件設(shè)計(jì)[J].汽車電器，2019（6）：37-39.
[8]張文杰，洪宇，孫宗姚，等.基于新架構(gòu)的汽車遠(yuǎn)程診斷系統(tǒng)的應(yīng)用[J].汽車文摘，2021（5）：24-27.
[9]莊夏.API網(wǎng)關(guān)架構(gòu)設(shè)計(jì)實(shí)例[J].汽車文摘，2018（5）：99-100.
[10]向勁松，蔣豪，鄧晨輝，等.集成胎壓監(jiān)測的車身控制器設(shè)計(jì)[J].汽車文摘，2017（3）：49-53.
轉(zhuǎn)自智能汽車設(shè)計(jì)
