更準確地理解車輛控制系統中的實時性

引言

在最近一起有公開報道的輔助駕駛相關事故中，由于AEB（自動緊急制動系統）功能被懷疑沒有起作用，又有一家車企的高級輔助駕駛功能遭到質疑。其實，目前大多數車輛中AEB功能的生效車速區間在70km/h以下，美國公路安全保險協會IIHS對新車AEB的最高測試速度僅為40km/h。

AEB功能之所以跟車輛速度強相關，主要是由于車輛從檢測到障礙物到采取剎車動作需要一定的時間，而車速越快，留給系統反應的時間就越少。在傳感器探測能力確定的情況下，系統從評估傳入的傳感器數據到啟動剎車必須在毫秒級（如300ms）的時間內完成，否者就可能為時已晚，失去了意義。這正是行業對于 “高實時性”要求的具體體現。

然而，行業內很多人對于“實時性”這一概念實際上卻存在著很大的誤解，在智能駕駛相關開發中也沒有給予足夠的重視，對于提升系統的“實時性”也缺乏系統性思路。比如：

汽車電子領域的“實時性”就是指系統跑得快么？

把MCU換成MPU，系統的實時性就提升了么？

為什么說AUTOSAR CP的實時性要優于AUTOSAR AP？

采用實時操作系統，系統是不是就滿足實時性要求了？

以太網、5G為什么也強調要支持確定性通信？

什么是端到端的系統級實時性？

系統實時性的影響因素有哪些？如何優化？

希望本文能有助于大家更準確地理解車輛控制系統中的實時性，并能夠對實時性問題進行系統、全面的分析，從而使得開發出的智能駕駛產品功能更可靠，性能表現更優，真正降低交通事故的概率和產生的危害。

什么是實時系統？

如果我們問一個軟件開發人員，尤其是IT行業的軟件工程師，“實時”是什么意思，得到的回答大概率是：“實時”就是非常快、或者幾乎感覺不到延遲。對于常人而言，這么理解倒是也可以；但對于嵌入式領域，尤其是涉及人身安全的自動駕駛、整車控制等系統而言，這個回答完全沒Get到“實時”二字的真諦。

其實，對于嵌入式領域而言，“實時”應理解為“及時”，英文用“in time”表達，即強調系統應在一個確定的時間內完成特定的任務，追求“確定性”和“可預期”。

假設有一個任務交給兩個系統分別處理，A系統處理平均需要10ms，且每次都能確保在12ms內處理完畢，而B系統平均處理只需要5ms，但某些情況下可能要花費20ms、50ms甚至更久才能完成。由此，我們可以認為A系統的實時性更好。

可見，在本質上，實時性跟系統運行的“快慢”其實沒有必然關系。

實際應用中，不同系統對于實時性的滿足程度并不相同。為此，人們根據系統對規定時間內完成任務的敏感性不同，將實時系統分為“硬實時系統”和“軟實時系統”。

圖：不同系統對于實時性的要求程度不同（來源：網絡）

?硬實時系統（Hard Real-time）嚴格限定在規定的時間內完成任務，否則就可能導致系統功能的失效。例如對于線控轉向，如果駕駛員發出轉向操作后100ms內車輪沒有執行轉向，則可能導致碰撞事故，嚴重的甚至造成車毀人亡。

軟實時系統（Soft Real-time）則要求沒有這么嚴格，允許出現一定的時間偏差。軟實時只能提供統計意義上的實時性，例如有的應用要求系統在95%的情況下能夠確保在規定時間內完成任務即可。車輛信息娛樂域的系統大多都屬于軟實時系統。

總之，實時性是一個相對的概念，如同功能安全，也分不同等級，需要根據系統的功能要求，綜合平衡系統升級的靈活性、成本等不同因素，設計“夠用”的實時性即可。

車內的各種系統對實時性有不同的要求。以AUTOSAR標準為例，CP通常用于硬實時系統中，而AP多用于對實時性要求較低、但又比用于車機的Android實時性要求高的系統，如下圖所示。

圖：AUTOSAR CP系統、AP系統及信息娛樂系統對于實時性、安全性和計算能力有著不同的要求（參考文獻7）

如何理解三者在實時性方面的差異呢？我們以操作系統理論中經常提及的“優先級反轉”為例來簡單解釋下。

“優先級反轉”是指一個正在訪問臨界區資源的低優先級任務或進程，導致其它高優先級任務或進程反而必須等待而被延遲響應的情況。在實時應用中，這是一個十分嚴重的問題。在基于最大吞吐量原則進行調度的常規Linux系統中，如Android系統，這個問題甚至被認為是影響系統實時性的最重要原因。而Linux的另一個版本——RT-Linux，則在常規Linux的基礎上，通過對“優先級反轉”等問題的優化，提升了系統的實時性。

AUTOSAR AP運行所基于的操作系統盡管與Linux一樣都是符合POSIX標準的操作系統，如QNX操作系統，但可以認為是類似于經過實時性優化的RT-Linux，因而其實時性是要優于車機中應用的Android系統的。

AUTOSAR CP中所定義的OS由于是一個完全靜態（任務數量、優先級都是確定的，運行過程中不會變）的操作系統，因而針對“優先級反轉”問題可以進一步優化，通過“優先級天花板協議（Priority Ceiling Protocol）”的方法，從而實現比RT-Linux更高的實時性。因此，AUTOSAR CP的實時性定位要高于AUTOSAR AP的實時性定位，尤其是能夠滿足硬實時系統的要求。

那是不是只要系統使用了AUTOSAR CP，或者某個宣稱是硬實時操作系統的OS，就算是一個硬實時系統了呢？實際情況遠遠沒有這么簡單，影響系統實時性的因素非常多。

AUTOSAR標準從R4.x版本開始，專門引入了Timing Analysis這一新方法。在這里，Timing一詞，中文多習慣譯為“時序”，可以認為等效于“實時性”。

什么是系統級實時性

為了說清楚這個問題，我們首先來看一個AUTOSAR標準中所舉的主動轉向的例子。如下圖所示：

圖：主動轉向系統中的端到端時序要求（參考文獻1）

整個系統包含傳感器、兩個ECU、CAN和Flexray總線以及執行器。功能大意是通過對車輛側傾角度的持續監測，及時主動調整轉向，避免車輛側翻。功能開發人員根據車輛動態模型和主動轉向功能的定義，提出了整個事件鏈（Event chain）的最大響應時間不能超過30ms的要求。顯然，這是一個典型的硬實時要求。

這一實時性要求或時序（Timing）要求可根據事件鏈上所涉及的事件，分解為T1~T5五個部分，其中T1、T3、T5為通信傳輸用時，而T2和T4為ECU內部處理用時。

從這個例子中不難看出，系統的實時性分析需要首先明確“系統”一詞所指的范圍。在車輛控制中，尤其是自動駕駛，實時性應該更多指端到端的時序（End-to-End Timing），而不能只是孤立地看某個控制器或某條通信總線的實時性。因此，要想優化系統的實時性，則不僅需要從ECU內部功能入手，還需要考慮信息傳遞所涉及的各種通信過程。

影響系統實時性的三大層面、九個層級

總體而言，影響系統實時性的因素可以分為通信層面、調度層面和代碼層面三個層面，而每個層面中又有多個層級，總計可劃分成九個主要層級。

通信層面

通信層面的時間主要指信號在網絡總線上的傳輸所消耗的時間。其中，報文響應時間、帶寬、利用率（Payload）以及數據緩沖區大小對該層面的時間影響重大。

在這一層面上，開發過程中關注的重點往往是端到端時間（如從傳感器到執行器）或者軟件中一個本地事件到服務器上的另一個事件的時間差。具體而言，又可分細為三個層級：

（1）V2X層級：即車輛與外界進行數據通信時所需的時間。如V2V場景中，前車在檢測到危險時向跟隨在后方的車輛發出警示。顯然，警示信息的傳遞不應太久。

典型解決方案：

優化車輛與外部世界通信實時性的一個典型實例就是5G確定性網絡。手機偶爾有一兩秒沒信號或許不是什么大問題，但對于汽車而言，未來要想實現基于云端的車輛控制，實時性是必須解決的問題。

傳統的4G網絡由于IP網絡“分組交換”帶來的傳輸路徑不確定，無法提供延遲、丟包和抖動的最壞情況界限，就無法提供確定的延遲，難以保證信號“及時”地傳送到目的地，而5G確定性網絡則有可能解決這些問題，從而提高這一層級的實時性。

2019年5月，華為在第三屆未來網絡大會上，提出了5G確定性網絡。對于這一概念，華為聯合信通院、三大運營商在2020年共同發布的《5G確定性網絡產業白皮書》中做了如下定義：

5G確定性網絡（5GDN：5G Deterministic Networking），是指利用5G網絡資源打造可預期、可規劃、可驗證，有確定性能力的移動專網，提供差異化的業務體驗。

（2）車內網絡：車內不同ECU之間通過網絡進行數據交互所需的時間。如系統通常要求剎車踏板踩下200ms之內亮起剎車燈，而剎車信號檢測和剎車燈的控制往往不是在同一個ECU內完成，有時甚至要經過一個網關。這中間可能涉及同一個信號在不同總線上的多次傳輸。這些傳輸過程的實時性同樣不容忽視，應盡量避免延遲、丟幀等問題。

典型解決方案：

TSN(Time-sensitiveNetworking，時間敏感網絡)可以說是這一層級當前最熱的話題。針對車內日益增多的以太網通信，由TSN工作組制定的相關標準的核心目標就是提升這一層級的實時性。

傳統的以太網是一種“盡力而為”（Best effort）的傳輸方式。而TSN以太網是一種以時鐘同步為基礎實現對不同流量（時間敏感流量/非時間敏感流量，可搶占幀/不可搶占幀）的調度，兼顧幀的過濾和冗余設計，從而實現確定性通信。

順帶說一下，5G確定性網絡中其實也包含對TSN技術的應用。也就是說，某些提高系統實時性的技術解決方案可能應用于多個不同層級，而不一定僅局限于某一個層級。

（3）ECU內部：在ECU內部，多個通過SPI或I2C等方式連接在一起的芯片之間或異構SoC內核之間進行數據交互所需的時間。如中央域控制器中MCU與MPU之間數據的傳輸，異構多核SoC內部實時核與計算核之間的通信，還有電池管理控制器中MCU和電芯采樣芯片之間的通信，這些通信耗時對于系統實時性的影響也不容忽視。 ? ?

典型解決方案：

TDA4中的IPC驅動包是這方面的一個好例子。TI開發的Jacinto 7 SoC在一個SoC上有多個不同的CPU，包括Cortex-R5F、Cortex-A72等。在這些CPU上運行的軟件需要相互協作，也就必然需要相互通信。因此協作方式通常被稱為處理器間通信或IPC（Intra Processor Communication）。每個CPU和操作系統上都提供了IPC驅動包，以支持更上層的應用程序之間相互通信。

圖：TDA4 IPC消息收發過程（參考文獻8）

為了提高通信效率，IPC驅動包利用了芯片中提供的硬件郵箱資源，同時還采用了基于共享內存的消息隊列，從而可以有效減少通信擁堵情況的發生，為實現核間通信的確定性提供了良好的基礎，有助于提升系統的實時性。

調度層面

調度層面也就是常說的操作系統層面，該層面對于任務的響應時間（Response Time）影響重大，而響應時間是調度理論中最重要的時間參數，它表征了從需要執行任務到任務執行完畢所經過的時間，是衡量操作系統是否為硬實時操作系統的核心因素。考慮到日益普遍的多核處理器，這一層面也可進一步細分為兩個層級：

（1）SoC層級：對于多核處理器，任務在各個CPU之間的分配與調度策略會影響系統所有與時間有關的行為。例如，在訪問核間共享的數據時，為確保數據一致性，不同CPU上運行的軟件之間需要同步，進而產生額外時間開銷，延遲響應時間。

典型解決方案：

Amdahl定律給出的啟示。針對多核引入后的并行計算，計算機專家Gene Amdahl早在半個世紀前就發現，系統性能的提升潛力在很大程度上取決于這些軟件中必須按順序處理（沒辦法并行處理）的部分所占的比例。

因此，即使CPU數量持續增加也將不再帶來任何實際計算能力的提升。即隨著CPU內核的增加，處理速度的提升將逐漸接近水平線。打個通俗點兒的比喻：請兩個人裝修房子需要花10天完成的話，請十個人并不能保證2天內完成，而極可能是至少需要5天，且增加再多的人也沒用。

圖：Amdahl定律（來源：網絡）

對于車輛上控制相關功能而言，通常包含很多難以并行化的因素，要么功能在邏輯上不允許，要么項目需要重用之前基于單核MCU開發的大部分軟件。

有人可能說，英偉達的高端GPU不是都已集成數千個CUDA內核了么？對此，有必要澄清一點：控制類算法、復雜狀態機以及不同通信總線之間傳輸報文的網關，它們與可以輕松分布在成百上千個圖形計算核心上的渲染引擎不具有可比性，即后者可以輕松支持并行處理，而前者則很難。

但是，這也給了我們一個重要啟示：要想在車輛控制中利用好多核處理器，就必須盡可能地將各種功能進行解耦，形成一系列相對獨立的Function Cluster(功能簇)，以便可以同時跑在多個內核上。

（2）CPU層級：對于單核MCU或多核SoC中的單個CPU，一次只能處理一個任務，要執行另一個任務（如中斷）就必須先暫停當前的任務。所以，CPU層級調度就是指執行單核調度的層級。

典型解決方案：

這里我們以支持搶占式調度的AUTOSAR OS為例。為了保證系統滿足硬實時的要求，AUTOSAR標準提出了Timing Protection的概念，通過確保影響任務響應時間因素的上限或者下限來優化系統的實時性。具體而言就是：

保證任務或中斷的執行不超出預設的最長執行時間；

保證共享資源被鎖的時間不超出預設的最長時間；

保證中斷被禁止的時間不超過預設的最長時間；

保證任務的激活間隔不低于預設的時間；

保證中斷的發生間隔不低于預設的時間；

其實，這五條可以概括為兩種時序保護機制：

A. 執行時間預算保護，即防止任務或中斷超出允許執行的最長時間；

B. 執行頻次保護，即防止任務或中斷的產生頻率超出允許的范圍；

需要說明的是，實際開發中，準確計算最長執行執行時間非常困難，對于多核MCU，這更加不可能。有關這部分的討論超出了本文的范圍，感興趣的讀者可以查閱靜態代碼分析相關技術，其中德國AbsInt公司開發的aiT分析軟件是這方面的代表性工具。

代碼層面

代碼層面的分析重點是代碼執行所需的時間，即凈運行時間（Core Execution Time），不包括因中斷等原因造成的打斷所增加的時間（這部分時間在調度層面進行考慮）。在代碼層面進行分析活動的最有價值輸出就是前面提到的任務或中斷的最長執行時間（Worst Case Execution Time）這一時間參數。根據不同的顆粒度，代碼層面可進一步細分為四個層級：

（1）函數層級：這里的“函數”指所有與函數（C/C++中function的概念）類似的結構，包括AUTOSAR OS任務和中斷服務例程，POSIX系統中的Thread等。

以AUTOSAR OS為例，任務（Task）會調用一系列Runnable，而Runnable內含有若干子函數。因此，根據函數的不同層次，可進一步分為任務/中斷層級、Runnable層級（頂層函數）、一般函數層級（子函數）。

這其中，任務或中斷內包含的各種算法，普通函數內部的各種執行控制流分支，以及函數內部變量在內存中的分配對于函數的凈運行時間都有直接的影響，因而對于系統實時性有著最直接的影響，同時也影響著系統的效率。智能駕駛領域中針對各類算法的優化大多都可以歸入這一層級。

典型解決方案：

用于ROS2的開源中間件Eclipse Iceoryx。Eclipse Iceoryx是用于自動駕駛等高安全性應用場景中的一個“零拷貝”進程間通信中間件（Zero-copy IPC Middleware）,是處理自動駕駛系統中每秒數GB數據在多個不同ROS系統節點之間進行傳遞的“必由之路”。

圖：Iceoryx提供的“True Zero-copy”進程間通信原理（參考文獻5）

對于用于跑自動駕駛功能的POSIX系統而言，分布在不同進程上的各項功能無法直接訪問其它進程的地址空間，必須通過某種IPC方式進行數據交互，而這通常意味著需要對數據（如一幅圖片）進行多次拷貝。

由于此類應用中多為圖像和點云數據，數據量非常大，這些拷貝操作不僅消耗大量的內存資源，也占用了很長的執行時間，給系統造成了不可忽視的延遲，嚴重時甚至導致系統崩潰。

而Iceoryx通過在數據發布者和訂閱者之間設立共享內存，使得發布者直接將產生的數據寫入共享內存，而訂閱者可以從Iceoryx這一中間件中獲得所需數據的索引（可理解為指針）即可訪問這些數據，從而避免了數據的頻繁拷貝操作。

（2）基本代碼塊層級：指一系列不會跳轉的連續執行的指令。因此，基本塊中的指令將從第一條開始按順序依次執行，一旦CPU運行時鐘確定，其執行時間可以認為就是確定的。如需在此層面優化，只能對代碼進行修改。在這個層級上，通常聚焦針對系統會頻繁調用的代碼進行優化，從而獲得明顯的整體優化效果。特別對于底層驅動和中斷函數，寫出最優的代碼本身就是一種良好編碼習慣和能力的體現。

典型解決方案：

CRC校驗算法的優化。CRC校驗又稱為循環冗余校驗，是數據通訊中經常采用的算法，在汽車電子中的應用也非常廣泛，AUTOSAR標準中對此也有要求。它可以有效的判別出數據在傳輸過程中是否發生了錯誤，從而保障了傳輸數據的準確性。

圖: CRC算法常用生成多項式（來源：網絡）

計算CRC校驗時，最常用的計算方式有三種：查表、計算、查表＋計算。一般來說，查表法最快，但是需要較大的空間存放表格；計算法最慢，但是代碼最簡潔、占用空間最小；而在既要求速度，空間又比較緊張時常用查表＋計算法。由于CRC校驗在軟件運行過程中會被頻繁調用，因此有必要對它進行優化，以縮短執行時間，進而獲得明顯的系統運行效率提升，有利于系統實時性目標的達成。

（3）機器指令碼層級：指CPU所能處理的單一指令，各種指令的執行周期通常是固定的。這些指令是由軟件編譯后生成的，大部分軟件調試、追蹤、測量工具的分析精度都止于此。之所以單列這一層級，是因為不同的編譯器或者同一個編譯器采用不同的編譯配置選項，所生成的機器指令碼是不一樣的，因而將直接影響代碼的執行效率，進而對凈執行時間產生影響。

典型解決方案：

編譯器優化。從源代碼到機器指令碼的編譯過程其實存在無數種路徑，就像一道數學題有多種解法。通常編譯器會提供兩種優化目標供用戶選擇：“資源占用大小”和“運行時間長短”。多數情況下，這兩個目標是沖突的，用戶必須根據實際情況進行權衡。

圖：編譯器的作用（來源：網絡）

目前大多數項目中對于編譯器優化的關注都極少，行業內的編譯器也主要被國外壟斷，極少有企業計劃自研。建議大家先從詳細研究編譯器用戶手冊開始，通過優化編譯后生成代碼的執行效率，來逐漸掌握編譯器優化技術。

（4）操作碼狀態層級：每個機器指令均分為取指、譯碼、執行等多個步驟處理，操作碼的狀態即指這些步驟。對于軟件工程師而言，這是隱藏最深的一個層級了，因為這一層主要涉及CPU架構，而這部分主要由ARM及各大芯片廠商設計。同時，這也是極其關鍵的一個層級，它甚至決定了系統是否能支持硬實時特性。

典型解決方案：

?三種不同的處理器架構WCET對比。現代芯片技術的快速發展使我們不僅僅在更小的面積上實現了更高的運行頻率，而且形成了越來越強大的指令集，更長的流水線，更復雜的分支預測單元，具有復雜邏輯的分層緩存，從而提高CPU的處理效率，極大地促進了平均計算能力的永久提升，也就是“更快”。

然而，正是這種芯片架構的復雜性，導致對于同樣的代碼，最短執行時間和最長執行時間之間的差距也越來越大。

下圖定性（而非定量）展示了在三種不同的處理器架構中，某個特定函數的執行時間變化。這些架構均代表各自年代的最高水平，彼此相差20年左右。