一文深扒“確定性執(zhí)行”

本文來源：智車科技

確定性執(zhí)行是目前汽車電子市場的技術熱點，但是筆者仍覺得此項技術需更多的驗證，因為這項技術是有難度的，對系統(tǒng)的穩(wěn)定性、魯棒性都有要求。此外，確定性執(zhí)行是否適合所有的域控制器仍然是一個未知數。

01確定性執(zhí)行的概念

確定性執(zhí)行是指在給定輸入的情況下，在有限的時間內產生一致的輸出，也就是輸入到輸出的運行過程是確定的，輸入與輸出有如下關系：

輸出=f(輸入)

這個概念不是很像可重入函數嘛，輸入確定的情況下，輸出也是確定的，不管怎么運行，什么時候運行，有多少調用者，輸出就是確定的，輸出只依賴輸入。

相比較于可重入的概念，確定性多了一個對運行時間的限制。實際應用過程中，我們對確定性還有一個隱式的需求，要求在確定的時間點執(zhí)行，并且在確定的時間點之前結束。那么確定性執(zhí)行就產生如圖所示的幾個因素。

實際操作中，輸出依賴輸入不現(xiàn)實，總會有狀態(tài)切換，其他依賴項的失效或者硬件失效等等原因導致同一個輸入產生多個輸出。但是，可以盡可能做到在不同的工況下，輸出依賴于輸入。

因此，對于確定性執(zhí)行，就產生了如下需求：

1.要求函數或者任務是單例或者可重入，正常工況下的，這就保證了輸出和輸出基本處于一一對應的狀態(tài)，保證了輸出的可控。

2.運行時長受限，就需要盡量不存在運行時間不可控的代碼。例如，阻塞型代碼，帶有自旋鎖的代碼。

3.運行時長受限，隱式的指明，任務的截止時間是確定的。

4.運行時間點要求時間同步是系統(tǒng)必備的需求。

5.運行時間點要求確定性執(zhí)行的任務應在需求指定的時間點運行。

6.確定性執(zhí)行的任務應明確任務激活源。

對于確定性執(zhí)行，并沒有很明確的需求或者在實踐中需要關中斷，或者任務保持原子執(zhí)行。也就是說，確定性執(zhí)行的過程中，任務可能會被打斷，暫停，搶占。

02確定性執(zhí)行的過程分析

確定性執(zhí)行是有它自身應用的場景的，它需要整個系統(tǒng)處于穩(wěn)定并且存在一定的運行規(guī)律。在自動駕駛領域，對確定性執(zhí)行有著極高的需求，它需要傳感器數據，特殊的任務在規(guī)定的時間點執(zhí)行，并在規(guī)定的時間內結束。此外，確定性執(zhí)行對數據處理的延遲性有很好的抑制作用，可以滿足自動駕駛對實時性的需求。

確定性執(zhí)行經常和確定性通信綁定在一起使用，正常的帶有數據轉發(fā)的確定性執(zhí)行流程如下圖所示：

1.應用層在1000us時間點請求中間件發(fā)送數據

2.中間件任務在3000us時間點執(zhí)行并發(fā)送數據

3.經過協(xié)議棧處理，并物理傳輸，在3300us時到達對方的協(xié)議棧

4.對端中間件任務在3500us時間點運行接收數據，并轉發(fā)給應用

5.應用在5000us時間點運行并處理

當然，此處還有一個優(yōu)化點，將中間件的數據接收或者發(fā)送 與 應用綁定到同一個確定性執(zhí)行的任務中。

我們假定底層的協(xié)議棧，硬件配置，參數配置均保持一致，也就是假定了硬件平臺的傳輸范疇的運行時間是穩(wěn)定的，波動較小的。其實這邊拋開了TSN、傳輸負載等相關因素的影響。我們假定關鍵數據幀的傳輸最大時間，從請求協(xié)議棧發(fā)送接口調用開始計算，到達對端協(xié)議棧并且協(xié)議棧把數據準備好給中間件處理為計算的終點，整個的傳輸最大時間為500us。

非確定性執(zhí)行關鍵點在于執(zhí)行時間點一直在波動，可能在應用運行之前，也可能會在應用執(zhí)行之后準備好數據。這就導致了應用層獲取的數據一直在抖動，可能某些時刻數據已經失去了時效性。

而確定性執(zhí)行恰恰相反，數據總是在應用執(zhí)行之前就會準備好，應用層每次運行都不會空跑一輪代碼然后讓渡CPU的運行時間。

對于CPU負載而言，非確定性執(zhí)行的CPU負載是雜亂無章的，但是確定性執(zhí)行的CPU負載就是波浪形的。

簡單說來，確定性執(zhí)行的負載是均勻的分布在該有的時間點范圍內，而非確定性執(zhí)行的時間點和截止點都是未知的，有可能非確定性執(zhí)行的任務在本次時間片內處理了三個數據，下一個時間片處理1個數據。確定性執(zhí)行的任務每一個時間片都處理2個數據，運行時長也是比較穩(wěn)定的。

03確定性執(zhí)行的優(yōu)點

確定性執(zhí)行對于運行截止時間，降低延時是非常有效的。此外，設計得當的話，確定性執(zhí)行可以降低內存消耗。如下表格所示，非確定性執(zhí)行因為數據申請和數據釋放的速度不一致，為了保證數據不丟失，必然需要緩存多次數據。而確定性執(zhí)行在一個任務周期內，可以完成數據申請和數據釋放，因此只需要緩存一個數據。這個作用對MCU這種資源緊缺型的芯片而言，真是天大的福音。

‍

‍

實踐過程中，意外的發(fā)現(xiàn)，確定性執(zhí)行對我們的軟件設計比較友好。以下是幾個可以快速提高效率的點，不需要考慮太多其他副作用。

第一點：無鎖的中間件設計。第二點：零拷貝的內存模型軟件設計。這兩點本質上是一點，但此處還是拆開來講，因為這里面的側重點不一樣。

第一點，無鎖的中間件設計。

首先，有一點需要澄清，當我們談到中間件，第一印象就是Linux，QNX,域控制器，但是MCU側也就是CP側也需要中間件設計。其次，對于無鎖我們第一印象是Lock-Free，但它真的是Free并且沒有代價的嗎？這種無鎖需要代價，各種編譯器提供的各種原子操作以及內存序的需求對程序的運行是有影響的。此處講的無鎖是指不用原子操作，也不用鎖！當然，cache同步的問題還是需要解決的。我們將其抽象成一個單讀單寫問題，以便于舉例說明。

讀和寫都在同一款芯片內，如果不用原子操作，當核0寫數據之后，核1讀數據需要在硬件MESI機制起作用并完全核間同步之后讀取數據，那么此時數據就不是Dirty Data。確定性執(zhí)行可以保證核0寫內存和核1讀內存的時間差大于MESI的同步耗時，那么，我們寫內存完全不需要考慮各種鎖，以及內存同步的機制對運行效率的影響，因此局部運行效率將大大提高。

對于MCU而言，一般不存在cache同步的問題，但是核間數據訪問需要做互斥，確定性執(zhí)行保證兩個任務不在同一個時間點執(zhí)行，那么就不存在互斥（鎖）的問題。

第二點，零拷貝的內存模型軟件設計。

我們經常碰到一個很苦惱的問題，同一塊內存如何給其他程序訪問。我們將這個問題簡化成一個單寫2讀的模型，這其實在汽車電子中很常見，同一個topic的數據，其實也就那么兩個或者3個程序需要用。我們再明確一下場景，假設一個溫度傳感器的數據需要被2個程序獲取，為了軟硬解耦，我們在設計時可能會有一個任務周期性的獲取溫度數據，然后傳遞給其他2個程序。整個流程如下圖所示，讀取數據時，如果是Linux系統(tǒng)，直接將溫度數據內存首地址傳遞給內核，內核直接將數據拷貝到此內存中，不需要借助臨時變量，然后再拷貝到溫度數據內存中。不同的程序在不同的時間點讀取使用數據，也就是說，不同程序只是拿到這個內存地址，然后用這個數據，不需要任何拷貝。當然，這邊有個前提，最后一個需要使用數據的程序必須在溫度數據下一次獲取之前結束使用。

04確定性執(zhí)行面對的現(xiàn)實

然而，確定性執(zhí)行并沒有那么美好，很多因素制約著確定性執(zhí)行的發(fā)揮，確定性執(zhí)行的穩(wěn)定性和可靠性也有待考量。

就整車層級而言，確定性面臨的現(xiàn)實：

1.確定性執(zhí)行在整車層級實現(xiàn)是有一定的困難的，并不是所有控制器均可以實現(xiàn)確定性執(zhí)行的。

2.面臨的第一個挑戰(zhàn)是時間同步！確定性執(zhí)行的基礎是時間同步必須要精準，抖動要小。不是所有的控制器能做到。尤其是某些同步時刻，時間會有一些奇奇怪怪的跳變或者抖動。當然，時間回滾是必須要避免的。

3.小周期運行的任務，比如說2.5毫秒周期運行的任務，確定性執(zhí)行實施起來非常困難。

4.由于時間同步需要時間，這就影響車輛啟動了。確定性執(zhí)行的任務啟動可能會存在啟動延遲，過大的延遲對于整車來說可能無法接受。

從單個域控制器的角度來說，面臨的現(xiàn)實挑戰(zhàn)更大：

1.必須要正視操作系統(tǒng)的實時性，Linux打個實時patch真不算什么真實時性，確定性執(zhí)行對觸發(fā)到程序響應是有要求的，響應太慢或者響應的時間忽長忽短，必然影響確定性執(zhí)行的配合。

2.就同樣的操作系統(tǒng)而言，不是所有任務都可以上確定性執(zhí)行，必然面對確定性執(zhí)行任務和非確定性執(zhí)行任務混合運行的情況。綁核可以解決一部分問題，讓所有確定性任務都運行在同一個核上，非確定性任務運行在其他核上，解決部分問題。然而，確定性任務和非確定性任務之間的數據交互，仍然需要去解決。

3.就不同的操作系統(tǒng)而言，確定性任務和非確定性任務的配合也十分困難。不同的操作系統(tǒng)必然面對著以太網，CAN，SPI或者異構核間的mailbox等類似硬件機制主導的數據傳輸機制。考慮跨芯片，跨操作系統(tǒng)，數據傳輸延時等各方面因素。眾多因素考量下，需要合理排布好確定性執(zhí)行任務，保證確定性執(zhí)行任務間的低延時。

4.系統(tǒng)的卡滯，偶發(fā)的系統(tǒng)卡滯。直接導致確定性執(zhí)行的任務執(zhí)行錯亂。是否會引發(fā)級聯(lián)失效，仍待更多的驗證。

5.系統(tǒng)調用的風險。有些系統(tǒng)調度會阻塞，有些系統(tǒng)調用有自旋鎖，這些系統(tǒng)調用又不可能不用，但是用了，確定性執(zhí)行還確定嗎？

6.軟件模塊設計的挑戰(zhàn)，確定性執(zhí)行必然要求軟件接口必須是非阻塞的，很多第三方庫或者其他軟件庫存在阻塞行為，確定性執(zhí)行與其配合，必然需要一番思考。

7.硬件的品控的挑戰(zhàn)。最簡單的體現(xiàn)是EOL下線時各種測試沒問題，一跑量產代碼就會有問題。有時候，由于各種原因，某次硬件操作耗時不一樣，這可能會直接或者間隔影響確定性執(zhí)行的時間。

8.確定性執(zhí)行的效率相對來說是比較低的，對于Linux系統(tǒng)而言，需要自己設計適配調度器。

9.高負載尤其是偶發(fā)高負載下的確定性執(zhí)行的搶占與穩(wěn)定性保證。

10.確定性執(zhí)行偶發(fā)運行耗時過長。某些情況下，由于確定性程序也會被內核任務搶占，如何保證確定性執(zhí)行的截止時間仍在設計的范圍內，或者在超時時間之后，確定性執(zhí)行仍然可靠，也是需要特殊考慮的。

11.功能安全對確定性執(zhí)行的影響。確定性執(zhí)行可能會失效，那么它的失效模式是什么？失效之后后處理的策略是什么？ASIL-B控制器的確定性執(zhí)行失效是否會引發(fā)ASIL-D控制器的確定性執(zhí)行？

12.功能安全島無法完全保證確定性執(zhí)行的功能安全。

13.以上都考慮之后，開始調度器的特殊設計挑戰(zhàn)！跨核，跨進程，跨芯片，跨操作系統(tǒng)的考量設計。如果還要其他公司配合，那么恭喜你，加倍難度。

05總結

確定性執(zhí)行仍面臨著很多挑戰(zhàn)，需要操作系統(tǒng)的配合，各個控制器供應商的配合。功能安全也挑戰(zhàn)著確定性執(zhí)行的實現(xiàn)。目前確定性執(zhí)行方案還存在著各種各樣的問題，但是歷史總是螺旋式的上升前進。技術發(fā)展的大浪淘沙，確定性執(zhí)行總將在汽車電子行業(yè)占據一席。

原文標題:一文深扒“確定性執(zhí)行”