引言

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

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

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

汽車電子領(lǐng)域的“實時性”就是指系統(tǒng)跑得快么？

把MCU換成MPU，系統(tǒng)的實時性就提升了么？

為什么說AUTOSAR CP的實時性要優(yōu)于AUTOSAR AP？

采用實時操作系統(tǒng)，系統(tǒng)是不是就滿足實時性要求了？

以太網(wǎng)、5G為什么也強調(diào)要支持確定性通信？

什么是端到端的系統(tǒng)級實時性？

系統(tǒng)實時性的影響因素有哪些？如何優(yōu)化？

希望本文能有助于大家更準確地理解車輛控制系統(tǒng)中的實時性，并能夠?qū)崟r性問題進行系統(tǒng)、全面的分析，從而使得開發(fā)出的智能駕駛產(chǎn)品功能更可靠，性能表現(xiàn)更優(yōu)，真正降低交通事故的概率和產(chǎn)生的危害。

什么是實時系統(tǒng)？

如果我們問一個軟件開發(fā)人員，尤其是IT行業(yè)的軟件工程師，“實時”是什么意思，得到的回答大概率是：“實時”就是非?？臁⒒蛘邘缀醺杏X不到延遲。對于常人而言，這么理解倒是也可以；但對于嵌入式領(lǐng)域，尤其是涉及人身安全的自動駕駛、整車控制等系統(tǒng)而言，這個回答完全沒Get到“實時”二字的真諦。

其實，對于嵌入式領(lǐng)域而言，“實時”應(yīng)理解為“及時”，英文用“in time”表達，即強調(diào)系統(tǒng)應(yīng)在一個確定的時間內(nèi)完成特定的任務(wù)，追求“確定性”和“可預(yù)期”。

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

可見，在本質(zhì)上，實時性跟系統(tǒng)運行的“快慢”其實沒有必然關(guān)系。

實際應(yīng)用中，不同系統(tǒng)對于實時性的滿足程度并不相同。為此，人們根據(jù)系統(tǒng)對規(guī)定時間內(nèi)完成任務(wù)的敏感性不同，將實時系統(tǒng)分為“硬實時系統(tǒng)”和“軟實時系統(tǒng)”。

圖：不同系統(tǒng)對于實時性的要求程度不同（來源：網(wǎng)絡(luò)）

?硬實時系統(tǒng)（Hard Real-time）嚴格限定在規(guī)定的時間內(nèi)完成任務(wù)，否則就可能導(dǎo)致系統(tǒng)功能的失效。例如對于線控轉(zhuǎn)向，如果駕駛員發(fā)出轉(zhuǎn)向操作后100ms內(nèi)車輪沒有執(zhí)行轉(zhuǎn)向，則可能導(dǎo)致碰撞事故，嚴重的甚至造成車毀人亡。

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

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

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

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

如何理解三者在實時性方面的差異呢？我們以操作系統(tǒng)理論中經(jīng)常提及的“優(yōu)先級反轉(zhuǎn)”為例來簡單解釋下。

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

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

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

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

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

什么是系統(tǒng)級實時性

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

圖：主動轉(zhuǎn)向系統(tǒng)中的端到端時序要求（參考文獻1）

整個系統(tǒng)包含傳感器、兩個ECU、CAN和Flexray總線以及執(zhí)行器。功能大意是通過對車輛側(cè)傾角度的持續(xù)監(jiān)測，及時主動調(diào)整轉(zhuǎn)向，避免車輛側(cè)翻。功能開發(fā)人員根據(jù)車輛動態(tài)模型和主動轉(zhuǎn)向功能的定義，提出了整個事件鏈（Event chain）的最大響應(yīng)時間不能超過30ms的要求。顯然，這是一個典型的硬實時要求。

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

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

影響系統(tǒng)實時性的三大層面、九個層級

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

01

通信層面

通信層面的時間主要指信號在網(wǎng)絡(luò)總線上的傳輸所消耗的時間。其中，報文響應(yīng)時間、帶寬、利用率（Payload）以及數(shù)據(jù)緩沖區(qū)大小對該層面的時間影響重大。

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

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

典型解決方案：

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

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

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

5G確定性網(wǎng)絡(luò)（5GDN：5G Deterministic Networking），是指利用5G網(wǎng)絡(luò)資源打造可預(yù)期、可規(guī)劃、可驗證，有確定性能力的移動專網(wǎng)，提供差異化的業(yè)務(wù)體驗。

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

典型解決方案：

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

傳統(tǒng)的以太網(wǎng)是一種“盡力而為”（Best effort）的傳輸方式。而TSN以太網(wǎng)是一種以時鐘同步為基礎(chǔ)實現(xiàn)對不同流量（時間敏感流量/非時間敏感流量，可搶占幀/不可搶占幀）的調(diào)度，兼顧幀的過濾和冗余設(shè)計，從而實現(xiàn)確定性通信。

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

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

典型解決方案：

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

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

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

02

調(diào)度層面

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

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

典型解決方案：

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

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

圖：Amdahl定律（來源：網(wǎng)絡(luò)）

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

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

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

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

典型解決方案：

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

保證任務(wù)或中斷的執(zhí)行不超出預(yù)設(shè)的最長執(zhí)行時間；

保證共享資源被鎖的時間不超出預(yù)設(shè)的最長時間；

保證中斷被禁止的時間不超過預(yù)設(shè)的最長時間；

保證任務(wù)的激活間隔不低于預(yù)設(shè)的時間；

保證中斷的發(fā)生間隔不低于預(yù)設(shè)的時間；

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

A. 執(zhí)行時間預(yù)算保護，即防止任務(wù)或中斷超出允許執(zhí)行的最長時間；

B. 執(zhí)行頻次保護，即防止任務(wù)或中斷的產(chǎn)生頻率超出允許的范圍；

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

03

代碼層面

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

（1）函數(shù)層級：這里的“函數(shù)”指所有與函數(shù)（C/C++中function的概念）類似的結(jié)構(gòu)，包括AUTOSAR OS任務(wù)和中斷服務(wù)例程，POSIX系統(tǒng)中的Thread等。

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

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

典型解決方案：

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

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

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

由于此類應(yīng)用中多為圖像和點云數(shù)據(jù)，數(shù)據(jù)量非常大，這些拷貝操作不僅消耗大量的內(nèi)存資源，也占用了很長的執(zhí)行時間，給系統(tǒng)造成了不可忽視的延遲，嚴重時甚至導(dǎo)致系統(tǒng)崩潰。

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

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

典型解決方案：

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

圖: CRC算法常用生成多項式（來源：網(wǎng)絡(luò)）

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

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

典型解決方案：

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

圖：編譯器的作用（來源：網(wǎng)絡(luò)）

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

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

典型解決方案：

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

然而，正是這種芯片架構(gòu)的復(fù)雜性，導(dǎo)致對于同樣的代碼，最短執(zhí)行時間和最長執(zhí)行時間之間的差距也越來越大。

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

圖：三種不同的處理器架構(gòu)WCET對比（參考文獻2）

8051是一款經(jīng)典的嵌入式處理器，既無緩存，也無復(fù)雜的流水線。每條指令的執(zhí)行時間僅取決于系統(tǒng)時鐘，因此，最短時間、平均時間和最長時間均相同。

PowerPC 5xxx架構(gòu)已在汽車領(lǐng)域應(yīng)用多年，動力、底盤等領(lǐng)域均有廣泛應(yīng)用。它提供了緩存和一條重要的流水線。雖然平均執(zhí)行時間相比8051已經(jīng)大幅縮短，但由于受函數(shù)開始時流水線的狀態(tài)和緩存狀態(tài)的影響，最短時間和最長時間之間也出現(xiàn)了明顯的差異。

總結(jié)

實時性不一定要求系統(tǒng)跑得越快越好，但一定要求系統(tǒng)是具有高度的確定性，滿足功能對于Deadline的要求。對于智能駕駛控制系統(tǒng)，單純依賴采用高實時性的操作系統(tǒng)并不能解決問題，實時性更應(yīng)該從系統(tǒng)級進行考慮，基于事件鏈進行端到端的實時性分析。

下表匯總了影響系統(tǒng)實時性的九個主要層級以及前面介紹的典型優(yōu)化實例，并列出了常見的分析方法，希望有助于大家采用系統(tǒng)思維綜合優(yōu)化系統(tǒng)的實時性。

審核編輯：劉清