一、架構(gòu)升級
1.1 軟件架構(gòu)：分層解耦、服務化、API 接口標準化
隨著企業(yè)向軟件定義汽車開發(fā)方法的轉(zhuǎn)變，軟件架構(gòu)也需要同步進行升級，引入面向服務的架構(gòu)（Service-Oriented Architecture，簡稱 SOA）方法論。汽車 SOA 是對整車智能化的底層能力進行組織。將車端的硬件能力和各種功能服務化，這些服務根據(jù) SOA 標準進行接口設計，基于 SOA 標準協(xié)議進行通信。這樣，各服務組件之間就可以相互訪問，從而擴展了服務的組合形式。
圖 4-1 SOA 服務化架構(gòu)示意圖
SOA 的引入使汽車傳統(tǒng)封閉、固化的軟件系統(tǒng)逐漸成為具備開放性、重用性的軟件生態(tài)。在新一輪的軟件架構(gòu)升級中，基于分層解耦的 SOA 服務化架構(gòu)，利用設備抽象和原子服務實現(xiàn)硬件能力的充分服務化，具體對象包括控制器周邊的傳感器、執(zhí)行器、傳統(tǒng)總線通信，以及控制器自身的診斷、存儲設備。同時，基于“邏輯語義轉(zhuǎn)換”的設計思想，完成接口標準化，實現(xiàn)不同平臺、不同車型的接口重用性目標。
圖 4-2 SOA 架構(gòu)下的基礎服務舉例
隨著基礎架構(gòu)及開發(fā)方式的變化，“軟件定義汽車”會顛覆整個汽車開發(fā)流程，基于SOA 的軟件架構(gòu)方案為智能汽車系統(tǒng)提供了重要的服務抽象。嚴謹?shù)姆庋b和分層結(jié)構(gòu)支持使用敏捷開發(fā)方法和針對接口進行測試，并降低了系統(tǒng)的復雜性，將大大簡化軟件組件在車輛更新?lián)Q代時的重用。
圖 4-3 軟件分層架構(gòu)示意圖
架構(gòu)標準化：
分層架構(gòu)，在原有的整車架構(gòu)中，引入原子服務層和設備抽象層。
-
設備抽象層負責封裝底層的硬件差異，并把硬件層的特性以服務的方式提供接口，供原子服務層進行調(diào)用，硬件的調(diào)整不應導致系統(tǒng)軟件對外提供的接口發(fā)生變化，使得應用邏輯擺脫底層硬件平臺的束縛；
-
原子服務層作為中間層，與平臺解耦，對上承接應用服務的調(diào)用，對下進行設備抽象的訪問，體現(xiàn)車型差異，并配置化適配，使能上層應用跨車型復用；
-
應用/組合層服務主要負責用戶需求邏輯的實現(xiàn)，通過調(diào)用原子服務層提供的接口，組合出千變?nèi)f化的場景化應用。
接口標準化：
跨車型、跨零部件供應商，最大化復用，降低軟件定義汽車軟硬件開發(fā)復雜度。
在架構(gòu)標準化的基礎上，如何能實現(xiàn)軟件的跨車企使用？就需要對層與層之間的接口進行標準化，不同整車廠、Tier1、平臺供應商定義同一套服務接口，使得不同整車廠之間，不同 Tier1 之間的軟件可以相互調(diào)用，大大增加軟件的復用性，縮短車輛開發(fā)周期。
在接口標準化推動方面，中國汽車工業(yè)協(xié)會已經(jīng)發(fā)布了第三版《軟件定義汽車原子服務 API 接口與設備抽象 API 接口參考規(guī)范》，包含 700 多個 API，涵蓋車身控制、熱管理、能量管理、運動控制、智駕域、動力域、底盤域等多個功能域，參與接口標準化定義的成員包含整車廠、零部件、基礎平臺供應商、軟件供應商等 100 多家公司。
1.2 通信架構(gòu)：基于車載以太網(wǎng)的技術應用
隨著車輛功能的不斷增加，特別是自動駕駛、智能座艙的不斷發(fā)展，需要傳遞的信號已呈爆炸式增長，車輛功能不斷升級更新，用戶對于 OTA 升級體驗提出更高的要求，傳統(tǒng)的 CAN 總線通信的方式已不能滿足車輛功能的增長速度，采用基于以太網(wǎng)服務的通訊方式，可實現(xiàn)功能的靈活重組，有效解決傳統(tǒng)面向信號的通信架構(gòu)中因個別信號增減/變更，而導致功能相關的所有系統(tǒng)均產(chǎn)生變更的問題。
車載以太網(wǎng)及其支持的上層協(xié)議架構(gòu)如下圖所示，車載以太網(wǎng)主要涉及 OSI 的 1、2層技術，車載以太網(wǎng)同時支持 AVB、TCP/IP、DoIP、SOME/IP、DDS 等多種協(xié)議或應用形式。
圖4-4車載以太網(wǎng)及其支持的上層協(xié)議架構(gòu)
SOME/IP 的全稱為：Scalable service-Oriented MiddlewarE over IP，基于 IP 的可擴展的面向服務的中間件，已于 2013 年納入 AUTOSAR 4.1 規(guī)范。
圖 4-5 支持面向服務的 SOME/IP中間件
通信架構(gòu)升級之后帶來的變化：
-
更靈活的溝通機制：CAN 總線為廣播式通信，多主方式的工作使得每個節(jié)點發(fā)送的信息都可能占據(jù)所有的通信媒介，只是接收節(jié)點可以選擇是否接收該信息。而以太網(wǎng)以一對一或一對多兩種方式進行通信，一對一的方式發(fā)送節(jié)點的報文中涵蓋自己和一個接收節(jié)點的地址；一對多的方式中發(fā)送節(jié)點的報文中涵蓋自己和多個接收節(jié)點的地址。二者都不影響其他節(jié)點的通信。
-
更高的帶寬，更低的時延：車內(nèi)數(shù)據(jù)傳輸總量及對傳輸速度的要求持續(xù)提升，以及在跨行業(yè)的標準協(xié)議需求的驅(qū)動下，支撐更多應用場景、更高速的以太網(wǎng)取代CAN/LIN 等傳統(tǒng)汽車車內(nèi)通信網(wǎng)絡已經(jīng)成為必然。
-
更多的應用場景，易互聯(lián)易擴展：車載以太網(wǎng)與車外網(wǎng)絡基于相同協(xié)議，在與車外網(wǎng)絡進行通信時，接口過渡更加平滑。傳統(tǒng)車內(nèi)通信網(wǎng)絡基于獨有的網(wǎng)絡協(xié)議，且接口標準化差；與車外網(wǎng)絡進行交互時，需要對不同系統(tǒng)的協(xié)議進行轉(zhuǎn)換。在網(wǎng)聯(lián)化趨勢下，車載以太網(wǎng)的協(xié)議轉(zhuǎn)換成本更小。
-
更快的 OTA 升級速度，更易用的體驗：采用以太網(wǎng)進行 OTA 升級，通訊速度相對傳統(tǒng)的 CAN 升級，提升了 10 倍以上，大大降低了用戶等待的時間。采用基于服務的通訊 SOME/IP，可實現(xiàn)功能的靈活重組，有效解決傳統(tǒng)以功能需求為核心的架構(gòu)中因個別功能增減/變更，而導致功能相關系統(tǒng)均需變更的問題，降低系統(tǒng)OTA 升級的復雜度。
1.3 硬件架構(gòu)：區(qū)域接入+算力集中化
整車電子電氣架構(gòu)是實現(xiàn)軟件定義汽車的基石，目前市場上銷售的傳統(tǒng)汽車大部分是分布式電子電氣架構(gòu)，如下圖所示。
圖 4-6 傳統(tǒng)分布式電子電氣架構(gòu)示意圖
在分布式電子電氣架構(gòu)中，首先將汽車功能劃分為不同的模塊，如動力控制、底盤控制、主動安全、被動安全、智能駕駛、信息娛樂和車身等。然后再將每個模塊的功能再進一步細分，例如車身功能又細分為車燈控制、車門控制、座椅控制等功能。不同的電控功能采用獨立電控單元（ECU）實現(xiàn)，不同 ECU 之間通過 CAN/CAN FD 進行通信。
因為每個 ECU 由不同的供應商開發(fā)，有著不同的嵌入式軟件和底層代碼，所以分布式電子電氣架構(gòu)在整車層面造成大量的冗余和 BOM 成本。另外，因為車內(nèi)軟件都分布于各 ECU 上，且 ECU 都由各供應商獨立完成，其軟硬件是緊密耦合的，整車廠并沒有權限去維護和更新 ECU 上的軟件。
快速滿足用戶需求是整車廠搶占市場份額的關鍵，而分布式電子電氣架構(gòu)嚴重制約整車廠響應市場需求的速度。假設某車型中設計完成后，用戶提出增加駕駛員位置記憶功能，即駕駛員將車輛的座椅、方向盤、外后視鏡等相關系統(tǒng)調(diào)整到舒適的位置后，可以將其設置為記憶位置，方便后續(xù)快速調(diào)整。需要對車門控制器、座椅控制器、方向盤控制器、網(wǎng)關等多個部件進行軟件變更，只有當各個零部件供應商完成變更，并且整車廠完成集成測試和整車測試后，才能夠?qū)⑿鹿δ芡斗攀袌?，這將造成開發(fā)和變更周期長、成本高等問題。
為此，各整車廠早已開始儲備新型電子電氣架構(gòu)方案，以促進軟件定義汽車的快速實現(xiàn)。新型電子電氣架構(gòu)的顯著特征是功能（軟件）集中化、硬件標準化。通過中央計算平臺/域控制器對控制功能進行統(tǒng)一管理，從而降低硬件冗余和 BOM 成本，減少整車廠對眾多供應商的依賴。根據(jù)功能集中程度不同，新型電子電氣架構(gòu)主要分為三種類型。
第一種：域集中式電子電氣架構(gòu)
在域集中式電子電氣架構(gòu)中，將整車電子電氣控制功能劃分為 N 個功能域，每個功能域設計一個域控制器，其余控制器均為域內(nèi)控制器，各域內(nèi)控制器一般為智能傳感器、執(zhí)行器和傳統(tǒng)控制器。
域集中式電子電氣架構(gòu)示意圖如下圖所示，示例中將整車電子電氣控制功能劃分為五大功能域：動力域、底盤安全域、智能駕駛域、信息娛樂域和車身舒適域。
圖 4-7 域集中式電子電氣架構(gòu)示意圖
第二種：跨域集中式電子電氣架構(gòu)
在域集中式電子電氣架構(gòu)中，域控制器只負責一個域的功能集中控制；而在跨域集中式電子電氣架構(gòu)中，有些域控制器負責兩個或兩個以上域的功能集中控制，進一步提升了系統(tǒng)功能集成度。比較常見的跨域集中式電子電氣架構(gòu)是三域架構(gòu)，跨域集中式電子電氣架構(gòu)的示意圖如下圖所示。
圖 4-8 跨域集中式電子電氣架構(gòu)示意圖
三域架構(gòu)分別為車輛控制域、智能駕駛域和智能座艙域，將原來的動力域、底盤安全域和車身舒適域整合為車輛控制域，智能駕駛域和智能座艙域?qū)Ｗ崿F(xiàn)汽車智能化和網(wǎng)聯(lián)化。
三域架構(gòu)有 3 個域控制器：
車輛域控制器負責整車控制，對實時性和安全性要求高；
智能駕駛域控制器負責自動駕駛相關感知、規(guī)劃、決策相關功能實現(xiàn)；
智能座艙域控制器負責 HMI 交互和座艙相關功能實現(xiàn)。
第三種：區(qū)域接入+中央集中式電子電氣架構(gòu)
中央集中式電子電氣架構(gòu)不再按照功能去部署車內(nèi)的電子電氣系統(tǒng)，而將整車所有功能域的控制邏輯均集中于中央計算平臺，進一步提升了系統(tǒng)功能集成度。原有分布式和域集中式架構(gòu)中的 ECU 的控制/計算功能被中央計算平臺收編，轉(zhuǎn)變?yōu)楦雍唵蔚膫鞲衅骰驁?zhí)行器。
為了減少線束長度，簡化通信，就近接入和供電，在中央集中式架構(gòu)下可以按照物理位置劃分區(qū)域并在區(qū)域內(nèi)部署區(qū)域控制器，形成中央計算平臺和多個區(qū)域控制器的架構(gòu)，中央集中式電子電氣架構(gòu)的示意圖如下圖所示。
圖 4-9 中央集中式電子電氣架構(gòu)示意圖
硬件架構(gòu)的升級，同時需要考慮跨域功能的融合、SOA 架構(gòu)下的軟件功能分層、服務化后的控制實時性、功能安全設計、復雜的硬件設計與集成等等。
二、安全升級：構(gòu)建多層次的整車縱深防御體系
2.1 功能安全
隨著電子電氣架構(gòu)技術的不斷升級，整車越來越多的系統(tǒng)和組件對功能安全產(chǎn)生影響，為此，功能安全也從部分關鍵系統(tǒng)開發(fā)，向整車各系統(tǒng)全面開發(fā)拓展。
同時，由于域控制器、中央計算平臺等新架構(gòu)技術的出現(xiàn)，對功能安全提出了新的技術挑戰(zhàn)，功能安全必須建立針對這些復雜系統(tǒng)及軟件的開發(fā)和測評手段。
功能安全技術也影響著電子電氣架構(gòu)技術的發(fā)展，從傳統(tǒng)的失效安全（Fail-Safe）向失效運行（Fail-Operational）演變，電子電氣架構(gòu)設計中引入了更多的冗余（如通信冗余、冗余控制器等）及安全保障措施。
未來，車輛智能化生態(tài)的形成，將促進功能安全技術走出單車，向全鏈路延伸，實現(xiàn)整體智能生態(tài)的整體安全。
2.2 預期功能安全
電子電氣架構(gòu)相關的預期功能安全指的是規(guī)避由于功能不足、或可合理預見的人員誤用所導致的人身危害。預期功能安全技術屬于汽車技術的一部分，對應的標準為 ISO 21448。根據(jù)自動駕駛功能及其運行設計域，分析滿足預期功能安全要求的系統(tǒng)配置方案，基于系統(tǒng)配置方案確定或選擇合適的電子電氣架構(gòu)方案。預期功能安全關鍵技術點：
（1）自動駕駛安全準則制定技術：針對自動駕駛已知場景和未知場景下的安全表現(xiàn)，制定客觀量化準則，科學判定自動駕駛的安全水平；
（2）安全分析技術：通過 STPA 等安全分析手段，識別自動駕駛安全相關功能的不足性能局限及危害觸發(fā)條件，制定針對性措施，開展功能更新；
（3）多支柱法測試技術：由仿真測試、定場景測試和真實道路測試組成的自動駕駛預期功能安全測試體系；
（4）安全論證技術：基于安全開發(fā)、分析、測試等結(jié)果，制定預期功能安全檔案策略，通過 GSN 等論證手段，評估自動駕駛安全風險，完成預期功能安全發(fā)布；
（5）安全監(jiān)控技術：通過車載和遠程手段，監(jiān)測自動駕駛運行過程中的安全表現(xiàn)，識別安全風險并開展必要的風險控制措施，以確保自動駕駛運行安全。
2.3 網(wǎng)絡安全
智能汽車車輛端、通信管道、云平臺以及移動應用均面臨一系列的信息安全威脅。從汽車網(wǎng)絡空間維度出發(fā)，通過多重技術協(xié)同、不同手段互補、從外到內(nèi)多層次部署安全防線，滿足車輛信息安全防護的縱深性、均衡性、完整性的要求。需要依據(jù)新一代車輛電子電氣架構(gòu)，從網(wǎng)聯(lián)安全、內(nèi)網(wǎng)安全、ECU 安全角度實施部署相應防護措施。
圖 4-10 智能汽車全方位網(wǎng)絡安全防御
-
網(wǎng)聯(lián)安全
網(wǎng)聯(lián)接入層主要抵御針對以太網(wǎng)的 DOS、PING 類型、畸形報文、掃描爆破、欺騙、木馬等網(wǎng)絡攻擊。需要具備車云聯(lián)動機制的主動安全防護能力，可通過云端系統(tǒng)實時配置防護策略，主要包括接入認證機制、通信保護機制、以太網(wǎng)防火墻機制和入侵檢測與防御（IDPS）機制。
-
車內(nèi)網(wǎng)安全
車輛內(nèi)網(wǎng)安全主要抵御針對車載 CAN/CAN FD、車載以太網(wǎng)的攻擊入侵，包括報文監(jiān)聽、錯誤注入、報文重放等攻擊。防護的策略包括：總線入侵檢測機制、內(nèi)網(wǎng)防火墻機制、功能域隔離機制、總線通信保護機制和診斷安全保護機制。
-
關鍵 ECU 安全
為確保車輛系統(tǒng)或關鍵數(shù)據(jù)不被破壞，在車輛關鍵 ECU 層面需具備安全啟動、關鍵數(shù)據(jù)安全存儲、系統(tǒng)安全運行的安全能力，并可為應用運行提供權限管理能力。
-
服務安全
SOA 安全框架需要遵循五個基本原則：機密性、完整性、真實性、授權性和可用性，通過信息加密、數(shù)字簽名、密碼認證、設計訪問控制列表 ACL、DOS 攻擊監(jiān)控等多種方案及產(chǎn)品實現(xiàn)網(wǎng)絡安全，同時保證這些網(wǎng)絡信息可被發(fā)現(xiàn)、被訪問、被通信以及被監(jiān)測。
圖 4-11 車載 SOA 服務網(wǎng)絡安全原則
-
在服務發(fā)現(xiàn)上，設定信息安全分組隔離機制，使得服務廣播消息只發(fā)給有需要的的服務使用者；
-
在服務訪問上，為服務提供方設置信息安全訪問控制機制，認證并授權服務使用方發(fā)起的服務請求；
-
在服務通信上，根據(jù) SOA 服務實際的業(yè)務應用場景決定 SOA 消息應采用的信息安全傳輸機制；
-
在服務監(jiān)測上，設置服務安全監(jiān)控機制，發(fā)現(xiàn) SOA 服務相關的異常事件及安全響應處理機制。
三、流程變革：敏捷開發(fā)，迭代發(fā)布
汽車上的功能日新月異，軟件代碼量日益增加，傳統(tǒng) V 模型下的瀑布式開發(fā)已經(jīng)不堪重負，為了快速交付給客戶最迫切需要的功能，軟件開發(fā)流程的轉(zhuǎn)變至關重要。目前，越來越多的汽車零部件供應商轉(zhuǎn)向了敏捷開發(fā)。在系統(tǒng)架構(gòu)實現(xiàn)軟硬件解耦，層次化架構(gòu)系統(tǒng)軟件、中間件和應用軟件的基礎上，實現(xiàn)軟件功能的快速迭代、發(fā)布，使得整車廠可以快速占領市場。
敏捷開發(fā)流程的核心是培養(yǎng)研發(fā)人員的協(xié)作意識、責任意識、質(zhì)量意識、學習意識、創(chuàng)新意識，進而提升整個軟件研發(fā)團隊的研發(fā)能力，高效地開發(fā)高質(zhì)量的軟件產(chǎn)品。特性開發(fā)采用以月為研發(fā)周期的迭代開發(fā)模式，進一步分為詳細設計與評審、特性開發(fā)與代碼走讀、代碼質(zhì)量檢視與評估、測試用例設計與編寫、特性功能聯(lián)調(diào)、特性合入評審等多個子流程。每個子流程有具體的輸出件（設計文檔、源代碼、評審報告、測試用例、測試報告等）和量化評判體系（設計文檔章節(jié)完整性、增量代碼度量報告、評審意見密度、測試用例覆蓋率、缺陷密度等），確保每一個子流程均按照軟件研發(fā)質(zhì)量要求達成，并對所有文檔歸檔以支持軟件質(zhì)量回溯。
版本發(fā)布采用以周為發(fā)布周期的軟件版本快速迭代模式，每周從穩(wěn)定分支發(fā)布版本，對軟件基本功能、新增特性進行充分驗證，對已解決的問題進行回歸測試，均通過之后再發(fā)布版本。敏捷開發(fā)的業(yè)務價值：
-
用戶體驗能以月為單位發(fā)布。
-
漏洞和補丁按周進行快速發(fā)布。
-
軟件版本按小時迭代，部件與整車同步集成、自動化驗證（7*24h 無人值守）。
四、工具鏈升級：基于 SOA 的整車服務化開發(fā)
SOA 的總體思路是設計服務模型，將不同的基礎服務進行抽取，分層解耦定義恰當?shù)腁PI 接口，應用調(diào)用服務 API 接口實現(xiàn)業(yè)務邏輯。API 接口定義獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言，確保構(gòu)建在不同系統(tǒng)中的服務可以以一種統(tǒng)一通用的方式進行交互。
對于汽車行業(yè)而言，SOA 是一套新引入的技術，需要一套有效的流程、方法和工具鏈，三者相輔相成，當前業(yè)界還沒有一套非常成熟的方法論和工具鏈，大部分整車廠和 Tier1/Tier2 都處于探索階段，下圖展示了一種基于服務的功能開發(fā)流程方法。
圖 4-12 基于服務的功能開發(fā)流程方法
首先對功能進行需求分析，輸出場景定義和特性設計，以及對應的物理拓撲和模塊功能定義接著繼續(xù)進行系統(tǒng)設計，包括服務架構(gòu)設計、服務設計和通信設計，服務定義需依據(jù)中國汽車工業(yè)協(xié)會軟件定義汽車工作組發(fā)布的 API 接口參考規(guī)范。
轉(zhuǎn)自汽車電子與軟件
