Linux實時性研究及其在汽車智能駕駛中的應用實踐

摘要：隨著智能駕駛技術的迅猛發(fā)展，軟件定義汽車的理念[1]逐漸受到廣泛關注。同時，整車傳感器和執(zhí)行器也變得越來越豐富和復雜。在此背景下，高實時性和高確定性的操作系統(tǒng)成為實現(xiàn)智能駕駛的關鍵技術，用于驅動各種傳感器并滿足智能駕駛算法模型部署和軟件運行需求。本文著重探討了對汽車智能駕駛的實時性嚴格要求，并分析了Linux實時調度機制在汽車操作系統(tǒng)中的缺陷和不足。在此基礎上，提出了一種確定性的系統(tǒng)任務統(tǒng)一調度的管理機制，既能滿足系統(tǒng)整體計算性能的要求，又能實現(xiàn)關鍵任務的確定性執(zhí)行和確定性調度。最后，在實際的量產車型環(huán)境下，對該統(tǒng)一調度管理機制的Linux系統(tǒng)進行了綜合驗證。測試結果表明，該系統(tǒng)能夠滿足智能駕駛平臺對實時性的要求，證明了本研究的有效性。

關鍵詞：智能駕駛；實時調度；實時性；確定性調度；調度管理

一、引言

隨著嵌入式平臺上傳感器種類及其數(shù)量的增加，例如攝像頭、激光雷達、毫米波雷達和慣性測量單元，傳感器的精度也在不斷提升。與此沖突的是系統(tǒng)資源有限，為了充分發(fā)揮系統(tǒng)性能，實現(xiàn)資源的合理動態(tài)分配，對軟件系統(tǒng)的實時性要求變得非常高。目前，在嵌入式系統(tǒng)領域存在一些商用實時操作系統(tǒng)（RTOS），例如vxWorks、QNX等。盡管這些商用系統(tǒng)能夠滿足一定的實時性要求，但由于微內核存在多核系統(tǒng)調用、IPC等性能問題，限制了智能駕駛對海量數(shù)據(jù)并發(fā)計算能力的要求。此外，這些系統(tǒng)的源代碼不開放，難以進行深度定制裁剪，也無法滿足智能駕駛快速迭代的需求。相比之下，Linux是一個源代碼開放、完全免費、可裁剪移植到多種硬件平臺的操作系統(tǒng)。雖然Linux最初是設計為分時操作系統(tǒng)，但是從2.6內核版本開始，在任務調度方面引入了高精度定時器、任務優(yōu)先級繼承等策略，以提高系統(tǒng)的實時性，這使得Linux在高實時性的嵌入式系統(tǒng)領域有應用前景。因此，研究Linux實時性，彌補Linux實時性方面的不足，并提高Linux實時性以滿足汽車智能駕駛的需求，具有重要意義。

二、汽車智能駕駛對操作系統(tǒng)實時性的要求

在智能駕駛領域，操作系統(tǒng)需要及時響應傳感器數(shù)據(jù)、進行決策和控制，以確保車輛的穩(wěn)定性和安全性。為了保證各環(huán)節(jié)的任務能夠在規(guī)定的時間內完成，需要嚴格控制汽車操作系統(tǒng)的延遲時間。圖1中解釋了車輛智能駕駛系統(tǒng)中的延遲時間，即計算推理結果（包括預處理、后處理以及AI處理）所需的時間（t2-t1），這個過程中車輛已經(jīng)從A點移動到B點。延遲時間的長短直接關系到車輛的安全駕駛。

圖2展示了以自動剎車系統(tǒng)[2]為例的最大允許延遲時間。在此例中，智駕控制器處理階段的最大允許延遲時間為350毫秒。

圖3列出了智駕控制器處理階段內傳輸通信和算法處理階段可能的最大處理時間。通過計算，可以得出在智駕控制器處理階段，除了通信傳輸和算法最大處理時間（25 + 25 + 25 + 71 + 25 + 71 + 25 + 25 + 25 + 25 = 342毫秒），只剩下8毫秒的余量來完成其他任務。因此，如果此階段發(fā)生的調度延遲超過8毫秒，就有可能超過最大處理時間，從而引發(fā)安全事故。

智能駕駛對算法與控制具有實時性和確定性的要求。確定性調度是指任務在規(guī)定的時間內以確定的方式執(zhí)行，并且在系統(tǒng)發(fā)生內部異常時，其行為也是可預測的，即任務的最壞情況執(zhí)行時間是可預測的。為了滿足智能駕駛對操作系統(tǒng)的需求，本文著重研究了Linux實時性的缺陷、 RT-Preempt Patch對Linux實時性的提升，以及一種確定性調度方法，以提高Linux操作系統(tǒng)的實時性，并降低調用延遲。

三、 Linux實時性的缺陷

（一）內核自旋鎖和讀寫鎖不支持搶占

Linux操作系統(tǒng)最初是根據(jù)分時操作系統(tǒng)的設計原則構建的，其主要目標是優(yōu)化系統(tǒng)的平均響應時間，以服務大量用戶。其內核在任務調度上實現(xiàn)的是一種幾乎公平的任務調度機制。盡管Linux在用戶態(tài)支持任務搶占調度策略，但是在核心態(tài)被大量使用的自旋鎖和讀寫鎖關鍵區(qū)卻不支持這種搶占策略。當?shù)蛢?yōu)先級任務運行到核心態(tài)的自旋鎖或讀寫鎖關鍵區(qū)之后，由于其不支持搶占性，導致此時一些優(yōu)先級更高的實時任務只有等到正在運行的低優(yōu)先級任務執(zhí)行結束后才能運行。這樣就無法保證實時任務的響應時間。而在實時操作系統(tǒng)中，這種情況通常是不允許發(fā)生的。

（二）中斷屏蔽的缺陷

Linux內核對于中斷處理采用Bottom Half Handling方法。在這種處理方法中，系統(tǒng)會屏蔽其他中斷，無法處理優(yōu)先級更高任務的搶占。因此，Linux中斷句柄是不可調度的。然而，在實時系統(tǒng)中，有時期望能在一個可調度整體內處理這些中斷句柄，從而能更有效地區(qū)分各個實時任務的處理需求，分配不同的優(yōu)先級。因此，單純采用Bottom Half Handling方法縮短時間片，在對實時性有嚴格要求的場景中無法滿足要求。

（三）任務調度的局限性

Linux 實現(xiàn)了四種調度策略[3]：SCHED_DEADLINE、SCHED_FIFO、SCHED_RR、SCHED_OTHER。其中SCHED_DEADLINE屬于DEADLINE任務調度策略，SCHED_FIFO和SCHED_RR屬于實時任務調度策略，SCHED_OTHER屬于普通任務調度策略。

在SCHED_DEADLINE調度策略下，任務運行在最高優(yōu)先級。然而，這種任務不宜過多，否則會導致其他非SCHED_DEADLINE任務無法獲得CPU。

在SCHED_FIFO調度策略下，當任務開始調度執(zhí)行時，它將會一直運行直至完成或遇到資源阻塞。對于一個設置為SCHED_FIFO調度策略的任務，它需要等待與其優(yōu)先級相同的其他SCHED_FIFO任務讓出CPU，才能獲得執(zhí)行時間。這種情況下，無法滿足對實時性的要求。

而在SCHED_RR調度策略下，任務會被系統(tǒng)分配時間片，當時間片用完時，該任務會被移動到優(yōu)先級隊列的尾部。如果存在同優(yōu)先級的其他任務，則會執(zhí)行它們；否則，下一個時間片該任務將繼續(xù)運行。系統(tǒng)在每次時鐘中斷時，會檢查該任務的時間片是否已經(jīng)用完，如果已用完，則會停止該任務，并在下一個時間片中調度下一個已準備好的SCHED_RR任務。對于一個設置為SCHED_RR調度策略且需要長時間運行的任務，一旦時間片用完并讓出CPU，它需要等待較長時間（N倍的時間片時間）才能再次獲得CPU，這也有可能無法滿足對實時性的要求。

SCHED_OTHER為非實時任務調度策略，由Linux CFS（完全公平調度器） 統(tǒng)一進行調度。對于設置為SCHED_OTHER的任務，無法滿足對實時性的需求。

四、Linux實時性增強方案

由于Linux系統(tǒng)內核自旋鎖和讀寫鎖不支持搶占，在中斷屏蔽方面存在缺陷，并且任務調度具有局限性，無法很好地滿足實時性要求。目前，改進Linux系統(tǒng)的實時性有許多方法，其中比較主流的有以下幾種[4]：

雙內核法：添加一個實時內核，與Linux內核同時存在于內核空間中，并將標準的Linux內核作為一個普通任務在實時內核上進行調度。

單內核法：直接對內核代碼進行修改，增加可搶占性，降低調度延遲等方法，從而提高Linux系統(tǒng)的實時性。

雙內核法的優(yōu)點是能夠實現(xiàn)硬實時性，并且可以方便地實現(xiàn)新的調度策略。但是，它需要單獨維護和開發(fā)實時內核的接口，增加了額外成本。單內核方案的優(yōu)點在于其修改方案經(jīng)過Linux社區(qū)的廣泛討論，因此減少了開發(fā)時間和成本。

本文重點研究單內核方案，采用RT-Preempt Patch解決內核態(tài)自旋鎖和讀寫鎖不支持搶占和中斷屏蔽的問題，從而提升Linux的實時性。同時，通過統(tǒng)一管理系統(tǒng)中各個任務的優(yōu)先級和調度策略，確保在滿足整體計算性能的前提下，控制關鍵任務對CPU時間的占用，保證關鍵任務執(zhí)行完成的確定性，以解決Linux任務調度的缺陷。

（一） RT-Preempt Patch主要修改內容

RT-Preempt Patch由實時 Linux 核心開發(fā)組開發(fā)和維護的一個項目，它提供了一套針對 Linux 內核的修改和補丁，使得 Linux 內核能夠滿足實時系統(tǒng)和嵌入式系統(tǒng)的需求。它的主要修改內容包括：臨界區(qū)可搶占、中斷處理機制優(yōu)化、定時器優(yōu)化、內存管理優(yōu)化。

1.臨界區(qū)可搶占

在標準Linux中，當執(zhí)行到被自旋鎖和讀寫鎖保護的代碼段時，不允許搶占，也不允許被中斷搶占或中斷。在這段時間內，其他任務無法獲取CPU。如果加鎖代碼的處理時間相對較長，將影響其他實時任務的運行，并且此影響具有較大的不確定性，因此很難準確評估。實時補丁引入了可搶占的臨界區(qū)，在普通任務加鎖的關鍵代碼執(zhí)行過程中，可以被高優(yōu)先級的任務搶占，但不能被同等優(yōu)先級的任務搶占。實時補丁對自旋鎖和讀寫鎖進行了改進，解決了鎖饑餓和優(yōu)先級反轉等問題，但在內核中仍然存在一些不可搶占的區(qū)域，例如非線程化的中斷[5]。

2.中斷處理機制優(yōu)化

實時補丁引入中斷線程化機制[6]來解決中斷屏蔽本身的缺陷。在中斷線程化機制中，中斷仍然會打斷實時任務，但中斷處理程序所執(zhí)行的操作被限制為喚醒中斷線程，原始的中斷服務程序主體被放置到一個內核線程中延遲執(zhí)行。這樣，中斷被迅速且準確地執(zhí)行，實時任務可以快速恢復運行，而中斷服務程序（中斷線程）會在實時任務掛起后被系統(tǒng)調度執(zhí)行。

中斷線程化后，中斷將作為內核線程運行，且被賦予獨立的實時優(yōu)先級。實時任務可以有比中斷線程更高的優(yōu)先級，這使得即使系統(tǒng)在嚴重負載下仍能保證其實時性。對于執(zhí)行頻率比較高，且中斷服務程序非常簡單的中斷，線程化對實時性的改善不大，反而會帶來不必要的性能開銷。所以中斷線程化使用時需要根據(jù)情況進行選擇，否則會給系統(tǒng)帶來巨大負擔。

3.定時器優(yōu)化

RT-Preempt Patch對定時器子系統(tǒng)進行了改進，引入了高精度定時器。相比傳統(tǒng)的定時器機制，高精度定時器提供了更細粒度的時間分辨率。它可以以納秒級別甚至更小的時間間隔觸發(fā)定時器事件，提供更準確的定時和延遲處理能力。這對實時任務和對時間敏感的應用程序非常重要。

4.內存優(yōu)化

RT-Preempt Patch 引入了更為可控和可預測的內存分配算法，以減小內存分配的延遲和碎片化問題。它采用了更精細的內存分區(qū)策略，將內存劃分為不同的區(qū)域，以適應不同類型和大小的內存分配需求。

（二） RT-Preempt Patch的實時性測試

1.測試工具 Cyclictest

Cyclictest是 rt-tests 工具集中用于評估內核實時性能的測試工具。它通過啟動一個master的普通任務，再啟動指定數(shù)量和優(yōu)先級的實時任務。實時任務會設置一個定時器，周期性地喚醒自己。當定時器溢出觸發(fā)中斷并進入中斷處理程序（即ISR）時，通過調用“wake_up_process（）”函數(shù)喚醒實時任務。需要測試的是從中斷觸發(fā)到實時任務實際執(zhí)行的延遲時間。

2.測試用例及結果

使用stress 工具模擬CPU 負載、IO 負載、啟動多個worker 運行壓力算法、啟動2倍CPU個數(shù)的線程、在優(yōu)先級為1的未引入實時補丁系統(tǒng)和引入實時補丁系統(tǒng)延遲差異，最終測試結果如下。

（1）根據(jù)測試結果可以看出，運行低優(yōu)先級的測試用例：

在高CPU負載的環(huán)境下長時間運行，未引入實時補丁系統(tǒng)的最大延遲接近2ms，而引入實時補丁系統(tǒng)最大延遲能夠維持在100us以內。

在正常CPU負載的環(huán)境下長時間運行，未引入實時補丁系統(tǒng)最大延遲接近5ms，而引入實時補丁系統(tǒng)最大延遲能夠維持在30us以內。

（2）根據(jù)測試結果可以看出，運行高優(yōu)先級：

在高CPU負載的環(huán)境下長時間運行，未引入實時補丁系統(tǒng)的最大延遲接近2ms，而引入實時補丁系統(tǒng)最大延遲能夠維持在50us以內。

在正常CPU負載的環(huán)境下長時間運行，未引入實時補丁系統(tǒng)最大延遲接近5ms，而引入實時補丁系統(tǒng)最大延遲能夠維持在30us以內。

3.RT-Preempt Patch存在的問題

上述測試是在實驗室桌面臺架上開展的。在實驗室中，傳感器的輸入輸出相對確定，因此智能駕駛相關算法的實時性測試結果也是確定的。然而，在實際量產車型上，外界環(huán)境的復雜度非常高，傳感器的輸入輸出不確定性非常大。在實際車型測試中，可能會發(fā)現(xiàn)低概率的算法延時的情況。通過分析系統(tǒng)日志，可以確定延時的原因，如內核鎖機制延時、中斷延時、任務調度延時等，這些原因會導致算法無法在確定的時間點調度。其中比較嚴重的情況是，決策算法由于硬件中斷的執(zhí)行，導致自身延遲了2.63毫秒才被調度到（參見圖7）。如果這類延遲情況發(fā)生在多個算法階段并疊加效應，就會導致智能駕駛控制器處理階段的調度延時超過8毫秒，給智能駕駛帶來了巨大的安全隱患。

五、Linux確定性調度方案

研發(fā)實踐過程中，為了解決引入RT-Preempt Patch后智駕算法仍然存在調度延時的情況，本文設計了一種基于Linux的確定性調度方案。該調度方案的主要思想是：

①對系統(tǒng)各任務的優(yōu)先級及調度策略進行統(tǒng)一管理和編排，在滿足系統(tǒng)整體計算性能的基礎上，實現(xiàn)對關鍵任務占用CPU時間片的控制，確保關鍵任務得到及時調度以及該任務執(zhí)行結束時間的確定性。

②鑒于智能駕駛相關算法的復雜，計算量龐大等特點，又要確保及時調度，所以系統(tǒng)硬件中斷必須集中管理。為了避免硬件中斷頻繁出現(xiàn)，智駕算法頻繁遷移導致的資源消耗，甚至出現(xiàn)系統(tǒng)滿負載的情況下，智駕算法延遲調度的情況，本文利用Linux affility隔離機制將系統(tǒng)硬件中斷統(tǒng)一綁定到某一確定的CPU執(zhí)行，配合（1）中統(tǒng)一調度編排的調度策略實現(xiàn)智駕算法的執(zhí)行和硬件中斷的隔離。

通過該方案，可有效解決引入RT-Preempt Patch后智駕算法調度延時的問題，提高系統(tǒng)的確定性和響應性，確保關鍵任務的及時調度和確定性的任務執(zhí)行。

（一）統(tǒng)一確定性調度方案

為了滿足智能駕駛算法任務的實時性要求，本文對智能駕駛平臺線程進行統(tǒng)一調度管理。同時，為了避免硬件中斷的執(zhí)行導致相關算法的延遲執(zhí)行，本文還重點研究了將某些驅動對應的中斷綁定在確定的核心上，并優(yōu)化了此類驅動的執(zhí)行時間，減少中斷的開銷。在滿足系統(tǒng)整體計算性能的基礎上，實現(xiàn)了對關鍵任務占用CPU時間的控制，并確保關鍵任務執(zhí)行完畢的時間確定性。

首先對系統(tǒng)所有任務制定推薦的調度策略和優(yōu)先級范圍。

然后，對關鍵任務編寫任務編排表（如圖8），對其申請CPU時間、最大CPU使用時間進行編排控制，確保關鍵任務執(zhí)行完畢時間的確定性和互不干擾性。

最后，通過大量實際運行場景抓取任務調度情況，并進行分析和確認，不斷調優(yōu)更新任務編排表，確保系統(tǒng)整體任務運行處于最優(yōu)最合理狀態(tài)。

（二）確定性調度方案測試

通過記錄任務調度trace數(shù)據(jù)，統(tǒng)計調度異常次數(shù)，并匯總任務調度實際結果與編排結果進行對比，確認系統(tǒng)整體任務調度情況。

實測任務調度時間和任務編排表對比的測試結果如圖9，其中淺色部分為實際測試的任務調度運行時間，黑色部分為任務編排表編排的允許最大運行時間。從圖中可以看出實際進程調度運行時間，都在編排的允許最大運行時間范圍內。

測得的調度異常統(tǒng)計結果（僅列出部分示例）可以看出，出現(xiàn)調度異常的次數(shù)為0，說明實際任務調度運行時間都在編排的允許最大運行時間范圍內。

在引入RT-Preempt Patch和確定性調度方案后，本研究使用了實際量產測試車在實際路況下對相關智能駕駛算法進行了測試。經(jīng)過測試，結果顯示智能駕駛相關算法的平均延時時間在100us左右（見圖10），滿足了智能駕駛系統(tǒng)的實時性要求。

六、結束語

本文詳細探討Linux操作系統(tǒng)的實時性方面存在的問題，并提出了相應的改進方案。針對這些不足之處，本文對改進后的操作系統(tǒng)進行了實時性能和穩(wěn)定性測試。測試結果表明，經(jīng)過改進的Linux操作系統(tǒng)既能夠滿足汽車智能駕駛對實時性的要求，又能夠保證汽車穩(wěn)定高效地運行。

作者單位：王圭 孟超 徐龍軍 王金寶 零束科技有限公司

參考文獻

[1]陳如冰.“軟件定義汽車”時代：風險與應對[J].智能網(wǎng)聯(lián)汽車，2022（1）：50-52.

[2] 劉建平，鄭望曉，鄭陽.AEB系統(tǒng)性能與碰撞時間關聯(lián)性研究[J].汽車技術，2018（8）：51-53.

[3]馮川放，馬季.基于嵌入式LINUX系統(tǒng)的實時任務調度算法的研究[J].計算機應用與軟件，2014，31（12）：278-282.

[4]徐德.Linux操作系統(tǒng)實時性的分析與改進策略[J].電腦知識與技術，2013，9（30）：6827-6828.

[5]吳章金. Linux實時搶占補丁的研究與實踐[D].蘭州大學，2010.

[6]洪雪玉，張凌，陳寶鋼，等.Linux實時性研究及其中斷進程化的實現(xiàn)[J].計算機工程，2007（10）：64-65+94.