【摘 要】隨著車輛功能逐漸增多，用戶需求不停更新，車輛軟件需要快速迭代才能給用戶更好的服務體驗，更快的功能體驗，真正滿足千人千面的需求，從分布式EE架構轉變為現在的中央計算加區域控制的架構，以SOA的形式實現軟硬解耦，將更多的功能以原子服務的封裝集中到車身控制器（BCM），根據動態配置進行不同服務的調用。本文從整車架構、BCM的功能定義、原子服務劃分講述BCM的原子服務設計。
當下汽車行業正面臨轉型的革命，隨著新四化的提出，軟件定義汽車已成為必然趨勢，軟硬件的解耦程度決定了企業產品的差異性，對硬件來說，需要可兼容、可擴展，對軟件來說，需要升級快、可移植性好，因此從架構層面需要基于SOA來進行開發，將傳統的分布式架構轉為中央集中式架構，由中央計算單元與區域控制組成，將功能按顆粒度大小封裝成不同的原子服務，以標準的服務接口進行調用，在功能交互過程中，交互雙方無需考慮對方的協議，原子服務設計是決定軟硬件耦合深度的重要因素，好的原子服務設計可以降低整車成本、屏蔽異構性且服務組合可以實現不同的功能，做到動態配置車輛功能。
1 汽車架構的設計差異
1.1 傳統EE架構開發
傳統EE架構的開發流程如圖1所示，由市場首先對車型定位，針對定位尋找相應的或更高配置的主流車型進行對標，主要對標其外形、內飾、靜態功能和動態功能并牽頭全員填寫競品分析表，將分析結果整合并調研用戶需求后整理輸出配置表、技術梳理配置表，找到各自的相關項，轉換為技術方案，將配置表分解為多個功能邏輯，再將功能邏輯分配給多系統，輸出網絡通信需求表，根據需求表，輸出子系統的需求文檔，文檔中寫明I/O、人機交互界面、性能要求、應用場景等，子系統根據功能分配自己的網絡接口和硬件接口，最后完成系統的原理圖和網絡開發。
圖1 傳統EE架構的開發流程
1.2 在SOA下的EE架構開發
基于SOA的EE架構開發流程如圖2所示，與傳統相比，在輸出配置表和轉換功能邏輯是一致的，區別在于：功能邏輯轉換后，沒有直接分配系統而是將功能邏輯轉換為原子服務，根據顆粒度大小，定義出硬件抽象服務并定義原子服務的接口，根據架構，將服務接口部署在不同的模塊內，由于現汽車的自動駕駛等級越來越高，導致功能安全等級相應提高，因此針對不同功能所需求的功能安全等級不一致，需要安全工程師梳理后，再根據所分配的功能安全等級、原子服務設計以及軟件模塊，進行軟件架構和硬件架構設計。
圖2 基于SOA的EE架構開發流程
2 功能定義
以中央計算單元加區域控制的形式BCM集成了車身功能、空調功能、路由等功能，還具有網絡管理、信號檢測等功能，車身功能包括后除霜、外部燈光、內部燈光、前照燈調節功能、防盜、背門控制、中控功能、雨刮洗滌、后視鏡功能、喇叭、天窗功能、RKE、PKE、玻璃升降、座椅調節等；空調功能主要是對泵、空調箱等電機或電磁閥的驅動，包括空調水泵驅動、電機水泵驅動、冷凝器風扇驅動、空調板驅動、冷卻泵驅動、制冷機功能、空調箱功能、鼓風機驅動等；路由功能分為信號路由和線束路由，信號路由是因為BCM還承擔網關的角色，BCM與中央計算單元采用百兆或千兆以太網連接，與其他ECU采用CAN或十兆以太網連接，需要將其他ECU的信號轉發至中央計算單元，實現信號路由，而線束路由則是將需要轉接的硬線信號，通過BCM控制器進行轉接；因為整車在下電后既要保證車輛在一定時間內蓄電池不虧電又要保證車輛功能能夠喚醒，因此網絡管理尤為重要，網絡管理包括定義喚醒模式、睡眠模式，需要根據不同的通信方式進行睡眠管理；信號檢測包括碰撞信號、門開關檢測、門狀態檢測、溫度檢測、陽光檢測、擋位開關檢測、燈光開關檢測等。
3 系統框圖
根據架構和功能定義，得到BCM的系統框圖（圖3），電源管理模塊將外部KL30常電轉換為系統芯片所需的系統電壓并保持穩定，MCU芯片支持數字信號和模擬信號的輸入。一般開關類的信號為數字信號，如門開關；傳感器一般為模擬信號，如溫度傳感器、位置傳感器等，或部分開關是PWM形式也屬于模擬信號，如燈光亮度調節、碰撞信號等。BCM內部有CAN收發器，支持CAN或CANFD的信號，將LIN信號作為硬件預留，有實時性要求不高且非安全類的產品可使用LIN通信，MCU有主MCU和輔MCU，輔MCU主要是對功能作冗余備份，對于外部燈光驅動有兩種形式，分別為高邊驅動HSD和低邊驅動LSD，在大部分場景下，使用HSD較多，將LSD作為硬件預留，但HSD的驅動電流一般小于15A，如洗滌泵、電機水泵常采用半橋芯片和MOS管來驅動，不同的MOS管驅動電流不同，可以支持近400A的電流驅動，BCM內置以太網交換機和PHY芯片，支持十兆/百兆/千兆以太網的ECU通信。
圖3 BCM的系統框圖
4 服務API設計
服務的軟件架構如圖4所示，分為硬件層、基礎軟件層、功能軟件、硬件/設備抽象層、原子服務層、RTE運行環境和應用層，因為BCM不存在音視頻接收和圖片接收，因此沒有SOC、GPU或DSP等異構芯片。在軟件層，對于硬實時信號，使用classical autosar，針對軟實時使用adaptive autosar，adaptive autosar也是實現原子服務的關鍵，硬件/設備抽象層，是對輸入接口、傳感器/執行器等硬件進行抽象，目的是屏蔽硬件差異對軟件的影響，原子服務則是通過排列組合為應用層提供統一接口，提高開發效率，RTE為應用層的APP提供運行環境，應用層是將功能體驗直接面向用戶，形成產品競爭力。
圖4 服務的軟件架構
原子服務設計，首先根據function list，列出BCM的所有功能，然后按照顆粒度大小，將功能轉換為合適的API描述，在服務API描述中定義服務類型，可以是最小服務API，也可以是組合后的API，最小服務API如左前門開關服務，組合后API可以是左前門服務，此服務包括門鎖狀態、車把手狀態、車門狀態、車門開度、兒童鎖狀態等。一般BCM的原子服務定義為如下：車門服務、尾門服務、車窗服務、天窗服務、遮陽服務、車鑰匙服務、車外鳴笛服務、低速報警服務、外后視鏡服務、座椅服務、座椅通風加熱服務、方向盤調節服務、迎賓服務、雨刮洗滌服務、制動燈服務、轉向燈服務、報警燈服務、日行燈服務、霧燈服務、近光燈服務、遠光燈服務、位置燈服務、倒車燈服務、激光燈服務、后牌照燈服務、logo燈服務、前照燈調節服務、空氣凈化服務、頂燈服務、手套箱服務、除霜除霧服務等。對于設備服務，定義如下：門開關、門鎖、尾門開關、尾門鎖、尾門電機、車窗開關、車窗電機等，根據輸入條件和輸出控制，隔離相應的設備。
以溫度檢測服務為例，依據SOME/IP的報文格式，需要定 義service ID/method ID、client ID、session ID、RPC type、返回值、報文周期、調用描述等，服務的調用方法有method、filed、fire and forget、event，其中method又分為RR和FF類型，filed分為setter/getter和notifier，那么該服務里的provider是BCM，consumer是中央計算單元。服務接口可以定義為幾種形式，當使用RR-method時，對溫度傳感器狀態檢測，使用FF-method時，通知中央計算單元溫度過高，當使用field，溫度值檢測，當使用event時，檢測到超過某一閾值后再上報。以field溫度值調用為例，服務的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字段數據類型為float ntfT（），RPC Specific Type為getter，Method Name為OutSIdeTemp，以上ID和port僅作為示例，具體由車企根據實際情況確認。
5 測試搭建
傳統的測試無論是軟件測試、硬件測試、集成測試都無法滿足當下基于SOA的控制器設計，傳統軟件并未深入使用AUTOSAR架構和引入功能安全概念，更多使用的是供應商自身的軟件架構平臺，導致測試無法統一且無法滿足現設計，功能集成測試更多是針對信號相關方的發送與接收，驗證發送時間的正確性和接收方接收的正確性以及發送的間隔時間等，但新型架構下的功能集成測試需要重新搭建，在軟件測試中，需要搭建新的測試平臺，如軟件單元測試中，需增加服務接口測試、服務調度測試等，在軟件集成測試中，各個組件拼接后，在PCBA上需要調度CPU資源測試、內存隔離測試等，由于車身控制器與車輛數字鑰匙相關，在硬件中需要增加安全芯片，以HSM對系統內部監測，以SE對外部通信監測，因此軟件安全測試中，需增加主被動攻擊測試、芯片時序、密鑰安全測試以及數字鑰匙證書測試，要求滿足國密等級。
6 原子服務技術思考
SOA的實現不僅是一個獨立事件，涉及到EE架構以及整個生態的搭建，已有的軟件平臺已成熟且可靠，新的軟件投入給車企及供應商都帶來成本大幅增加且對工程師的技能更為嚴苛，需要掌握復合型的知識體系，SOA基于SOME/IP實現，SOME/IP在數據傳輸時有延遲且是軟實時。
各個軟件層與通信層需要協同調度，多者的一致性會影響服務響應的實時性，調度時間長產生較差的體驗感；用戶不同的車輛需求，要求服務有更高的部署靈活性，然后如何部署既能兼容定制化又能靈活配置；傳統對網絡測試基本是基于CAN或LIN，引入SOA概念后，需要搭建一套新的針對以太網的測試平臺；原子服務設計有評價指標，好的評價指標會指導后續設計的可行性，統一設計理念，降低差異化；傳統的一個功能會拆分為多個服務，且服務可能存在于不同的ECU，增加了軟件的復雜度且影響性能；每個服務都需要有獨立的配置、部署、監控和收集，增加了成本；硬件的冗余和對于功能安全ASIL認證和AUTOSAR的使用，產生的費用也會增加成本。
7 結論
針對以上概述，合適顆粒度的服務原型不僅可以從組織層面、架構層面、運維層面、設計層面等多方面降低成本且做到產品的差異化，真正滿足用戶千人千面的需求且適應當前電子電氣架構開發，在車身控制器上不存在異構芯片設計和多操作系統共存的情況，但關于智能座艙或自動駕駛模塊，會比車身控制器面臨更大的挑戰，但車身控制器也需提前考慮。隨著架構和開發能力的提高，未來車身控制器與自動駕駛或智能座艙融合也逐漸變為可能。
參考文獻
[1]中國汽車工業協會軟件定義汽車工作組.軟件定義汽車服務API API Version 2第一部分：原子服務API參考[S].
[2]中國汽車工業協會軟件定義汽車工作組.軟件定義汽車服務API API Version 2第二部分：設備抽象API參考[S].
[3]中國汽車工業協會軟件定義汽車工作組.軟件定義汽車服務API 第二部分：設備抽象API參考變更說明[S].
[4]中國汽車工業協會軟件定義汽車工作組.軟件定義汽車服務API 第一部分：原子服務API參考變更說明[S].
[5]中國汽車基礎軟件生態委員會（AUTOSEMO）.車載SOA軟件架構技術規范1.0[S].
[6]馬建輝，王知學，侯冬冬，等.一種集成式汽車BCM的設計與實現[J].汽車電器，2019（2）：25-27.
[7]湯自寧，吳瑾，王冠達，等.集成于車身控制器的胎壓接收模塊硬件設計[J].汽車電器，2019（6）：37-39.
[8]張文杰，洪宇，孫宗姚，等.基于新架構的汽車遠程診斷系統的應用[J].汽車文摘，2021（5）：24-27.
[9]莊夏.API網關架構設計實例[J].汽車文摘，2018（5）：99-100.
[10]向勁松，蔣豪，鄧晨輝，等.集成胎壓監測的車身控制器設計[J].汽車文摘，2017（3）：49-53.
轉自智能汽車設計
