2023年5月9日—10日由捷途汽車主辦，蓋世汽車承辦的2023捷途汽車電子架構與智能駕駛論壇上，華為智能車控解決方案架構設計部長何朗表示，通過SDV分層解耦+服務化，實現(xiàn)樂高式開發(fā)和車型快速適配。同時，SOA與分層設計，能夠最大化實現(xiàn)軟硬件解耦，降低開發(fā)復雜度。
(資料圖片)
同時他還總結了華為在實踐過程中總結出三條經驗：在人機交互類應用中引入真事件機制，替代周期機制；在SoAd層將多個上層報文進行聚包，聚包到達觸發(fā)條件后再添加ETH報文頭發(fā)送；異步調用降低多任務時CPU占用和時延。
何朗 | 華為智能車控解決方案架構設計部長
以下為演講內容整理：
SOA架構的思考與設計
近些年SOA服務化落地過程中，架構隨著業(yè)務的發(fā)展不斷進行調整，在這個過程中一些思考與解決措施與大家分享一下。首先回到軟件定義的主題，面對日趨復雜的場景，智能化零部件的增多會帶來相關的網(wǎng)絡安全及隱私方面的需求。并且在軟件開發(fā)過程中的落地流程也日趨復雜，所以都需要進行調整和變革。
我們在很多車型上做了實踐，以及工程化的落地方案，包括和行業(yè)的生態(tài)伙伴們共同做了很多有益的探索。總體來看，軟件適應汽車迭代過程中的周期性壓力和要求、生態(tài)伙伴的增多以及生態(tài)運營的不斷豐富等，需要將軟件分為三層，并且在應用層要解決多種復雜問題。
在物理層，隨著智能化部件的引入，對通信和電子信息架構的調整具有巨大的變化，但為了整體軟件架構能保持穩(wěn)定，所以引入了服務層，目前處于建設過程中。對軟件架構的設計，有以下幾個應對措施，在分層設計方面，設計了三層，這樣可以把中間傳統(tǒng)的跨ECU的開發(fā)，通過軟件架構解耦到中間平臺，這一層包含了設備抽象。簡而言之把軟件中通過經驗固化形成標準庫直接調用，讓開發(fā)者有更多的精力進行面向消費者的差異化創(chuàng)新。
在解耦的過程中，發(fā)現(xiàn)物理層到應用層是隨著車的電子信號而變化，并且對應的電子器件的差異化會導致需要進行適配工作。在軟件架構中引入設備抽象和原子服務兩層進行軟硬件充分解耦，設備抽象的使命是屏蔽統(tǒng)一類型硬件不同硬件供應商或統(tǒng)一供應商不同型號的接口差異，原子服務將基本的原子能力抽象成標準化的接口，這些能力也會隨著車型的變化固定下來，通過經驗累積，形成可快速重用的資產。
在實踐過程中，因為新的傳感器引入，也會對智能化提出更高的要求，比如傳感攝像頭、雷達信號的引入等，如何向上提供更多的能力，也是消費者感興趣的業(yè)務創(chuàng)新范圍。通過一些實踐，把新型的傳感器對外的能力做原子化的封裝，也可以利用已經封裝好的能力形成一些新的業(yè)務。
在軟件定義汽車SOA的架構中，我認為比較有價值的設計原理，是通過軟件的差異去屏蔽不同硬件的能力，解決不同原子服務之間的耦合性，形成避免雙向依賴，減少信號之間交互的復雜度。以及對服務接口的前向兼容，避免上層軟件針對下層硬件的變化，產生新的架構變化。
SOA開發(fā)落地的性能挑戰(zhàn)與實踐
在SOA落地過程中遇到的主要挑戰(zhàn)，是如何做到軟件Onetrack，因軟件規(guī)模日益龐大與復雜，分工也越來越精細。這種情況下，大量的軟件工程如何做到跨車型和平臺，甚至是引入一個新的供應商能快速融入當前的架構，成為一個大的課題。
比如在實際落地過程中，服務層、抽象層以及對應APP間的部署和調用間的關系非常復雜，必然會導致不僅要兼容很多功能，還要兼顧性能的考驗。在保證服務層穩(wěn)定和靈活部署的前提下，有利于新功能的快速移植和同步。
在這個過程中，會發(fā)現(xiàn)服務的靈活性不可避免帶來通信的壓力，具體表現(xiàn)在一是通過原有信息架構到服務化架構，為了保持靈活性所以會引入大量報文，各個服務器的接口間的獨立會帶來通信消息壓力的巨幅增加；二是在傳統(tǒng)的MCU去處理這些消息的時候，因為要應對不確定性的報文，最開始第一次SOA時，對消息的處罰機制都沒有做約束，所以短時間會引入大量的報文，這種情況下對CPU的負載也是非常大的考驗。
針對這兩個表現(xiàn)，我們在很多車型上做了嘗試，總結了服務部署的六條經驗，比如功能安全高的(ASIL-B以上), 部署在MCU上，多個CP間，若存在資源分布不均，優(yōu)先部署在CP資源最富余的節(jié)點上等。同時，還要兼顧開發(fā)者能力的聚合，以及對消費者體驗的實時性要求，把人機交互的應用或者相關的服務，就近部署到對應的VIU或座艙控制器上。比如以手動開啟尾門特性為例，開門的應用是部署在尾門最近的VIU上，同時為了響應更快，對應的應用部署在座艙上，與物理按鍵原子服務就近共部署。
圖源：演講嘉賓材料
滿足靈活部署的性能要求后，我們發(fā)現(xiàn)同樣一個功能會分散在不同的區(qū)域控制器和中央控制器系統(tǒng)中，多種交互以及對應的通信開銷會產生大量的報文沖擊。在這樣的情況下，為了保持車身域通信的靈活性，其消息粒度會變小，從而產生大量的報文，帶來了通信傳輸?shù)膲毫Α?/p>
我們借鑒ICT中的通信經驗，比如在2G時解決信息風暴或短信的擁塞的方法，，引入真事件機制，替代默認的周期機制，對周期性的報文通過操作系統(tǒng)及工具鏈的配置，允許這些報文形成聚合，在沒有發(fā)生變化時默認延長周期，但發(fā)生變化時，就會立刻觸發(fā)上報。采用周期性Event機制，每秒要產生20000+報文，而采用update on change機制，每秒產生的報文低于1000個，處理報文數(shù)減少了20倍以上，極大的降低了CPU處理開銷。
對以太代替CAN的通信的方式，最大的變化是會引入大量的消息負載，通過引入NPDU的方式，把消息分成不同類型，區(qū)分輕重緩急，兼顧實時性和通信效率需求。如果不是很緊急的報文，可以累積到一定時間上報，這樣的方式可以將負載大幅降低。
異步調用打破傳統(tǒng)通信機制
傳統(tǒng)的通信方式，對Autosar標準協(xié)議非常成熟，消息機制比較穩(wěn)定，并且它的負載是通過底層統(tǒng)一處理。而SOA的形式下，會面臨著大量阻塞的問題，具體原因是類似于RPC的服務方式，因為它的原理是要等到反饋結果之后，才能處理后面的動作。而服務化的方式后，會發(fā)現(xiàn)是多任務高頻同時發(fā)送的場景，如果每個處理的任務都需要等待后續(xù)的任務才能往下走，不可避免的會導致隊列會變得冗長。
針對這種情況引用異步調用機制，把一個閉環(huán)的消息變成了兩次閉環(huán)消息。第一次把任務發(fā)到被調用方之后，不需要等待回調結果并行處理其他任務，這樣可以把很多串行的任務變成并行。比如位置燈可能會部署在車不同區(qū)域的控制器中，可能會因為其他同時并發(fā)的任務而阻塞等待，但通過異步調用的方式，應用本身能在60毫秒之內處理完，也能夠解決服務化所帶來的問題。
服務化本身因為以太在面向于車載和功能安全應用，會面臨著很多的挑戰(zhàn)。對車燈或者車門要去協(xié)調各個地方的應用，所以針對延時以及同步等問題的處理，還需要后續(xù)考慮一些對策。總體來看，通過架構的標準化對齊產業(yè)鏈的各種語言，能夠通過不同原子服務組合體現(xiàn)車型差異，并配置化適配，使能上層應用跨車型復用，同時通過設備抽象，屏蔽硬件的差異化，軟硬件解耦，能夠使軟件在不同車型中更加靈活的移植，甚至做到不感知。
我們要想辦法做到整車的靈活部署，以及對應的接口的標準化，使OTA新功能上線將變更和OTA范圍控制在某一個控制器內，同時對其他應用來說，能夠盡量做到不感知。以性能來看，以太通信打破了傳統(tǒng)CAN周期處理思路，優(yōu)化其處理性能，可以提高可靠性和加速轉型。目前來看，最大的就是通信擁塞、調用問題和隊列問題，通過異步調用以及消息觸發(fā)的靈活性，對應聚合等方式可以逐步完善性能。
（以上內容來自于華為智能車控解決方案架構設計部長何朗于2023年5月9-10日在捷途汽車主辦，蓋世汽車承辦的2023捷途汽車電子架構與智能駕駛論壇上發(fā)表的《軟件定義汽車的性能挑戰(zhàn)》主題演講。）
