作者 | 奮斗的農(nóng)民工

來源 | ADAS與ECU之吾見

首先，請問大家?guī)讉€小小的問題，你清楚：

• 你知道多核OS在什么場景下使用嗎？
• 多核系統(tǒng)OS又是如何協(xié)同啟動或者關(guān)閉的呢？
• AUTOSAR OS存在哪些功能安全等方面的要求呢？
• 多核OS之間的啟動關(guān)閉與單核相比又存在哪些異同呢？
• 。。。。。。

今天，我們來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：

AUTOSAR OS 保護

在上篇文章 AUTOSAR基礎(chǔ)篇之OS(上) 中我們可以了解到AUTOSAR OS的基本特點，基本對象以及各個對象之間的彼此關(guān)聯(lián)，本篇文章將承前啟后，在此基礎(chǔ)上來簡單談?wù)勎覍UTOSAR 多核OS的理解與認(rèn)識。鑒于本人水平能力有限，如存在錯誤之處，還請大家多多批評指正。

我們已知道AUTOSAR OS來源于OSEK OS，隨著汽車電子信息安全，功能安全等需求的不斷提出，傳統(tǒng)的OSEK OS已無法滿足當(dāng)前的需求，因此AUTOSAR組織在OSEK OS的基礎(chǔ)上為不同的用戶提供四類不同功能安全的OS可裁剪類型，分別為SC1-SC4。

AUTOSAR OS 可裁剪類型

AUTOSAR OS的四種可裁剪類型分別為SC1-SC4，具體含義如下：

• SC1:  OSEK OS + Schedule Table；
• SC2:  OSEK OS + Schedule Table + Timing Protection;
• SC3:  OSEK OS + Schedule Table + Memory Protection;
• SC4:  OSEK OS + Schedule Table + Timing Protection + Memory Protection；

如下圖1所示，較為清晰了描述了這四種不同可裁剪類型的區(qū)別與聯(lián)系。

圖1 AUTOSAR OS可裁剪類型

AUTOSAR OS 時間保護

從AUTOSAR OS四種可裁剪類型可以看出，時間保護(Timing Protection)是一項非常重要的功能保護機制。如之前文章所示，AUTOSAR OS作為一實時操作系統(tǒng)，那么就需要在預(yù)定的時間內(nèi)完成特定的任務(wù)，但有時由于某些原因?qū)е鲁瑫r錯誤，OS必須采用有效的方式來預(yù)防超時任務(wù)的發(fā)生，而這類措施則可以稱為時間保護。

一種較為常見的時間保護就是Deadline Monitoring。即當(dāng)OS檢測到某一任務(wù)的運行時間超過其截止時間時，則會調(diào)用相應(yīng)的Hook函數(shù)向系統(tǒng)報錯，但是AUTOSAR OS并不是通過監(jiān)控截止時間方式來實現(xiàn)時間保護的，因為針對截止時間的保護并不能準(zhǔn)確識別出當(dāng)前錯誤的原因。具體解釋如下：

• 現(xiàn)象： 任務(wù)1的運行時間超過其截止時間時，任務(wù)A本身可能并沒有出錯；
• 過程： 在執(zhí)行任務(wù)1之前的任務(wù)2頻繁的搶占或者過長的阻塞資源的訪問；
• 原因： 正由于任務(wù)2的上述行為，進而導(dǎo)致任務(wù)1執(zhí)行超時，從而直觀的認(rèn)為任務(wù)1發(fā)生錯誤便停止任務(wù)1，反而讓真正的罪魁禍?zhǔn)兹蝿?wù)2繼續(xù)逍遙法外，這就不合情理，也起不到對OS中各任務(wù)的時間保護。

下面為了進一步加強大家對上述簡單的監(jiān)控截止時間造成運行錯誤的理解，假設(shè)存在一個操作系統(tǒng)中存在下列任務(wù)A，B，C，并明確各自任務(wù)的優(yōu)先級，執(zhí)行時間，Deadline 如下表1中所示：

表1 操作系統(tǒng)任務(wù)的基本屬性假設(shè)

假設(shè)所有任務(wù)在0時刻均處于就緒狀態(tài)，期望運行的任務(wù)執(zhí)行時序如下圖2所示。具體的任務(wù)執(zhí)行時序如下所述：

• 由于任務(wù)A優(yōu)先級最高，因此任務(wù)A先執(zhí)行；
• 1個Tick之后任務(wù)B開始執(zhí)行，3個Tick之后任務(wù)C執(zhí)行；
• 當(dāng)任務(wù)C執(zhí)行1個Tick后被任務(wù)A打斷，任務(wù)A執(zhí)行完畢后，任務(wù)C繼續(xù)運行；
• 到第10個Tick任務(wù)C執(zhí)行完畢，周而復(fù)始，整個過程并未出現(xiàn)超時現(xiàn)象，并且仍有一個Tick的空閑狀態(tài)；

圖2 任務(wù)期望時序圖

接下來，如果發(fā)生如下圖3所示的異常狀況，那么我們看會發(fā)生什么呢？

• 任務(wù)A的第二個周期與任務(wù)B的第一個周期都出現(xiàn)運行時間過長的現(xiàn)象，但并沒有超過其截止時間。
• 任務(wù)B在第二個周期提前進入運行狀態(tài)，但也未超過其截止時間；
• 任務(wù)C按照正確的方式運行，但由于任務(wù)A與任務(wù)B的出錯導(dǎo)致任務(wù)C運行超時，則發(fā)生超時錯誤；

若此時采用簡單的超時監(jiān)控機制只能監(jiān)控到任務(wù)C超時，這時操作系統(tǒng)調(diào)用鉤子函數(shù)，由于出錯原因并未被檢測到，從而操作系統(tǒng)采取的措施將無法有效解決錯誤。

圖3 任務(wù)超時現(xiàn)象

因此，從上述例子分析可以得出任務(wù)或者中斷能否滿足其截止時間需取決于以下三大基本要素：

• 靜態(tài)任務(wù)或者中斷的執(zhí)行時間上限；
• 被低優(yōu)先級任務(wù)鎖住共享資源或屏蔽中斷所引起的阻塞時間；
• 任務(wù)或者中斷之間的間隔執(zhí)行時間；

針對上述三大基本要素，AUTOSAR OS采取了下列三種時間保護機制：

對于1：AUTOSAR OS為任務(wù)或者二類中斷服務(wù)設(shè)定了運行時間上限；

對于2：AUTOSAR OS設(shè)定了共享資源被任務(wù)或者二類中斷鎖定的時間上限，設(shè)定了OS中斷被任務(wù)或者二類中斷中斷掛起的時間上限，設(shè)定了所有中斷被任務(wù)或者二類中斷掛起或者屏蔽的時間上限；

對于3：AUTOSAR OS設(shè)定了任務(wù)或者二類中斷執(zhí)行間隔的時間下限；

特別的，需要注意的是AUTOSAR OS時間保護存在一些基本特性：

• 時間保護僅僅用于任務(wù)或者二類中斷，對于一類中斷不起作用；
• 在OS未開啟之前，時間保護將不起作用；
• 對于Trusted OS Application, OS應(yīng)當(dāng)有能力提供一種基于任務(wù)或者二類中斷的時間保護，而對于Non-Trusted OS Application，OS必須提供為這個非信任的OS Application中的每一個任務(wù)或者二類中斷提供時間保護；

AUTOSAR OS內(nèi)存保護

AUTOSAR OS的內(nèi)存保護需要特定的硬件支持，即處理器應(yīng)該存在MPU單元(Memory Protection Unit), 例如英飛凌AURIX單片機則具備這個特性。鑒于內(nèi)存保護可以有效防止出錯的應(yīng)用模塊影響到其他模塊，降低系統(tǒng)完全癱瘓的風(fēng)險，因此，AUTOSAR OS提供以下三種形式的保護：

棧保護

• 即每一個OS Application和其中的OS Object都有各自的私有棧，不同的OS Object無需存在共享棧。棧保護能夠更為快速的檢測出棧溢出，同時棧保護也是劃分OS Application的一種方式和依據(jù)。

數(shù)據(jù)保護

• 每一個OS Application和其中的Objects都具備各自私有數(shù)據(jù)，同時OS Application的私有數(shù)據(jù)區(qū)就是從屬于該OS Application的Objects的共享數(shù)據(jù)區(qū)；

代碼保護

• 代碼區(qū)既可以被私有，也可以被共享，在沒有代碼保護的前提下，錯誤代碼的執(zhí)行會導(dǎo)致內(nèi)存，時間和服務(wù)上的出錯。

OS通過MPU監(jiān)控內(nèi)存的訪問權(quán)限，其中AUTOSAR的訪問權(quán)限可分為受信任與非受信任的Object(Trusted and Non Trusted)兩級，受信任的Object有讀寫大部分內(nèi)存的權(quán)限，但沒有讀取其他非激活棧的權(quán)限。

而非受信任的Object僅有讀寫少數(shù)內(nèi)存的權(quán)限，包括當(dāng)前活躍的棧，當(dāng)前OS Application的數(shù)據(jù)以及LMU的共享數(shù)據(jù)。

AUTOSAR多核OS啟動與關(guān)閉

在AUTOSAR軟件基本架構(gòu)下，無論是單核操作系統(tǒng)還是多核操作系統(tǒng)，都與EcuM模塊和BswM模塊息息相關(guān)。因為這兩類模塊決定了OS啟動，初始化，運行，關(guān)閉等狀態(tài)及其過程。

從之前文章 AUTOSAR基礎(chǔ)篇之EcuM 我們可以知道ECU工作過程可分為啟動(STARTUP), 運行(UP), 睡眠(SLEEP)以及關(guān)閉(SHUTDOWN)四種狀態(tài)。

ECU在上電前處于SHUTDOWN階段，上電后便進入STARTUP階段，主要包括StartPreOS與StartPostOS兩個子階段。

在StartPreOS子階段主要完成一些OS啟動之前的一些準(zhǔn)備工作，如初始化MCU，IO，WatchDog等模塊；

在StartPostOS子階段則是啟動OS之后的階段，該階段主要執(zhí)行初始化BSW的調(diào)度器以及初始化BswM模塊兩個動作，如下圖4所示。

圖4 ECU啟動流程

由于ECU詳細(xì)的啟動過程在 ?AUTOSAR基礎(chǔ)篇之EcuM? 文章中已有大量篇幅介紹，本文就不再贅述，只是作為一個引子，大家如果有興趣，可以閱讀了解一下。

多核OS啟動過程

當(dāng)然無論是否存在OS，多核的啟動過程相比單核與硬件關(guān)系則更為密切。

通常情況下，硬件會首先啟動一個核作為主核(Master Core)，而從核(Slave Core)則由軟件啟動，這種啟動方式被稱為主從模式。AUTOSAR規(guī)范定義了多核啟動方式應(yīng)該為主從模式。

值得注意的是：即使硬件支持多核同時啟動，AUTOSAR規(guī)定也需要通過軟件模擬的方式來實現(xiàn)主從模式來啟動多核系統(tǒng)。

如下圖5所示，非常生動形象的描述了主從模式的各個環(huán)節(jié)的啟動時序及相互之間的交互關(guān)系。

圖5 多核OS的啟動過程

在上圖中，Core 0作為主核，其他核則作為從核。

• 主核Core 0完成前期的硬件初始化之后啟動從核Core 1 并隨后調(diào)用Start OS函數(shù)來啟動OS，OS完成初始化之后在第一個同步點等待所有從核完成OS的啟動。 
• 從核Core 1被主核啟動之后，首先完成硬件相關(guān)的初始化，然后激活從核Core2，Core3，并在第一個同步點等待其余從完成OS的啟動；
• 從核Core2，Core3被Core 1激活之后，首先完成各自的硬件相關(guān)初始化，然后調(diào)用StartOS完成OS的初始化并在第一個同步點進行同步；
• 在完成第一個同步點之后，主從核便分別執(zhí)行Startup Hook函數(shù)之后在第二個同步點進行同步，然后所有核的Kernel將一起運行，只有這樣才能夠更好的保證整個系統(tǒng)的穩(wěn)定性與魯棒性。

值得注意的是如果某從核運行的OS不是AUTOSAR OS時，此時則不能使用AUTOSAR OS API StartCore來啟動該從核，而應(yīng)當(dāng)使用StartNonAutosarCore來實現(xiàn)該從核的啟動。

多核OS關(guān)閉過程

與單核OS關(guān)閉過程類似，多核OS的關(guān)閉也是通過EcuM來完成，如果在關(guān)閉過程中出現(xiàn)喚醒事件，ECU則需要關(guān)閉之后立即重啟。

在關(guān)閉過程中可以選擇ShutDown Target分別為關(guān)閉(OFF), 睡眠(Sleep),和復(fù)位(Reset), 此處僅簡要描述其基本過程，如下圖6所示：

圖6 ECU關(guān)閉過程

如上圖的ECU關(guān)閉過程主要分為以下幾個階段：

• 反初始化BswM以及BSW調(diào)度器；
• 檢查是否存在喚醒事件發(fā)生；
• 選擇ShutDown Target；
• 關(guān)閉OS；

如下圖7所示，則較為生動形象的描述了多核OS的關(guān)閉過程。

圖7 多核OS的關(guān)閉過程

在多核系統(tǒng)中，關(guān)閉過程存在以下幾個特點：

• AUTOSAR4.x不支持僅僅關(guān)閉單個核，即若發(fā)送關(guān)閉指令或者致命錯誤時所有核必須全部關(guān)閉，具體的關(guān)閉過程如上圖所示；
• 若某一任務(wù)擁有調(diào)用ShutDown All Cores的權(quán)限時，關(guān)閉信號將會同步發(fā)送至所有核；
• 當(dāng)關(guān)閉過程啟動后，所有的中斷服務(wù)和任務(wù)都不能被激活，關(guān)閉前必須完成的程序由EcuM保證完成；
• 關(guān)閉完成前，各自的OS Application調(diào)用各自的Shutdown Hooks函數(shù)完成對應(yīng)的回調(diào)程序，然后等待到同步點所有核執(zhí)行關(guān)閉回調(diào)函數(shù)。

AUTOSAR多核OS調(diào)度

基本特點

多核OS調(diào)度相比單核OS調(diào)度而言并沒有什么區(qū)別，都是根據(jù)任務(wù)或者中斷的優(yōu)先級作為首要因素來決定調(diào)度順序。在同一處理器內(nèi)核上，優(yōu)先級越高的任務(wù)或者中斷優(yōu)先調(diào)度。如果優(yōu)先級相同，那么就根據(jù)激活順序進行調(diào)度。

需要明白一點的是對于單核系統(tǒng)，CPU每時每刻只能運行一個任務(wù)或者中斷，采用時間片輪轉(zhuǎn)法來實現(xiàn)看上去的并發(fā)執(zhí)行。

對于多核系統(tǒng)而言則不同，由于存在多核所以可以同時運行多個任務(wù)或者中斷，至于能夠同時運行幾個任務(wù)或者中斷由CPU內(nèi)核數(shù)量來決定，我們把這種執(zhí)行方式稱為并行執(zhí)行。

同時對于AUTOSAR操作系統(tǒng)而言，任務(wù)及中斷的優(yōu)先級是提前靜態(tài)分配的，在運行過程中不支持動態(tài)更改。

調(diào)度方式

如下圖8所示，清晰的表現(xiàn)了 多核OS調(diào)度任務(wù)的過程。根據(jù)調(diào)度規(guī)則，若在同一核上多個任務(wù)被同時調(diào)度，即這些任務(wù)均處于就緒狀態(tài)，那么高優(yōu)先級任務(wù)會被率先執(zhí)行，如圖中的Core0上的任務(wù)T2，Core1上的任務(wù)T3以及Core2上的任務(wù)T5，三個任務(wù)同時進入運行狀態(tài)，各個內(nèi)核上的任務(wù)獨立運行，互不干擾，其優(yōu)先級并沒有相互影響。

圖8 多核OS任務(wù)調(diào)度圖

同時，對于AUTOSAR 多核OS支持任務(wù)選擇調(diào)度模式，可分為全調(diào)度和拒絕調(diào)度模式。對于全調(diào)度模式，任務(wù)在運行過程中，可以被高優(yōu)先級的任務(wù)或者中斷搶占，而對于拒絕調(diào)度模式下，該任務(wù)不能夠被任何其他任務(wù)或者中斷搶占。

因此在任務(wù)分配優(yōu)先級的過程中，應(yīng)當(dāng)將起到關(guān)鍵作用的重要任務(wù)分配較高的優(yōu)先級，重要程度類似的任務(wù)周期越短，分配的優(yōu)先級越高。

AUTOSAR多核OS通信(IOC)

AUTOSAR規(guī)范定義了內(nèi)部通信與外部通信兩種方式，其中內(nèi)部通信包括核內(nèi)通信，核間通信。

每當(dāng)不同內(nèi)核中的用用程序需要進行數(shù)據(jù)交互時，操作系統(tǒng)就需要開辟單獨的內(nèi)存區(qū)域，通信雙方可以實現(xiàn)該內(nèi)存區(qū)域的讀寫，從而完成數(shù)據(jù)的傳輸。

但需要注意的是共享內(nèi)存區(qū)域有可能在讀取數(shù)據(jù)的過程中發(fā)生數(shù)據(jù)更新，這樣就會發(fā)生數(shù)據(jù)一致性問題。

為解決上述數(shù)據(jù)不一致問題，AUTOSAR多核OS提供了應(yīng)用于核間通信的IOC(Inter OS Application Communication)通信機制。

IOC不同于核內(nèi)通信，核內(nèi)通信則是通過RTE來實現(xiàn)。

在使用IOC的過程中如果應(yīng)用程序?qū)@一共享內(nèi)存區(qū)域進行讀寫時，會申請占用一個自旋鎖(SpinLock),以防止被其他內(nèi)核的應(yīng)用程序同時訪問，這樣便可以保證核間數(shù)據(jù)讀寫的一致性。

IOC僅提供Send-Recerver的通信方式，但是RTE可以將Client-Server的請求與應(yīng)答可間接轉(zhuǎn)換為Send-Recerver模型，因此IOC支持1：1，1：N，N：M的通信。

在每次傳輸過程中可以傳輸一個數(shù)據(jù)項，該數(shù)據(jù)項可以是基本類型的值或者復(fù)雜數(shù)據(jù)結(jié)構(gòu)的參考，而如果是復(fù)雜數(shù)據(jù)結(jié)構(gòu)，那么就必須被實現(xiàn)為單個內(nèi)存塊，這樣IOC便無需得知內(nèi)部的數(shù)據(jù)結(jié)構(gòu) ，僅需知道內(nèi)存地址和長度便可以完成該結(jié)構(gòu)體數(shù)據(jù)的傳輸。

Send-Receiver模型

如下圖9所示為也不帶通知的1：1的Sender-Recerver的通信模型。

圖9 不帶通知的RTE通信模式

如上圖，Core0中SW-C將數(shù)據(jù)發(fā)送至Core1中的SW-C模塊，以下是核間通信的具體步驟：

• 接收端實體被周期性調(diào)用通過Rte_Receive從RTE接收來自Core0的數(shù)據(jù)；
• 發(fā)送端調(diào)用函數(shù)Rte_Send函數(shù)發(fā)送數(shù)據(jù)，進而調(diào)用Ioc_Send函數(shù)寫入數(shù)據(jù)到Buffer中；
• 接收端便會通過Ioc_Read函數(shù)讀取共享內(nèi)存中的Buffer數(shù)據(jù)，并傳遞給到Rte_Read函數(shù)中供Core1中的SW-C使用。

IOC生成器會生成所有的發(fā)送及接受函數(shù)，為了優(yōu)化目的，這些函數(shù)被定義為宏指令，這種不帶通知的通信方式適用于以下場景：

• Send/Receiver通信；
• 隊列或非隊列通信；
• 1：1通信；

Client-Server模型

如下圖10所示，為帶通知的N：1的Client-Server模型。

圖10 帶通知的IOC模型

如上圖為Core 0 中的SW-C請求Core1中的服務(wù)操作。RTE通過將client-Server調(diào)用映射為send-Receiver來實現(xiàn)客戶端的服務(wù)，因為需要跨核通信，所以RTE調(diào)用IOC將數(shù)據(jù)從Core0傳輸至Core1,具體傳輸過程如下所示：

• 發(fā)送端調(diào)用函數(shù)Rte_Call函數(shù)進而調(diào)用函數(shù)IocSend函數(shù)，將數(shù)據(jù)寫入IOC內(nèi)部隊列緩存中；
• Rte_Call函數(shù)使用OS調(diào)用激活接受從核的服務(wù)任務(wù)來通知接收端；
• 接收端被激活的該任務(wù)將負(fù)責(zé)調(diào)用IocReceive函數(shù)從IOC共享內(nèi)存Buffer中讀取數(shù)據(jù)并將數(shù)據(jù)傳輸至服務(wù)端的運行實體中；
• Core1中服務(wù)函數(shù)的結(jié)果會被反向傳輸至Core0的客戶端中。

這種帶通知的通信方式適用于以下場景：

• 帶通知的Send-Receiver通信；
• Client-Server通信，在此類情況下，RTE需要將服務(wù)轉(zhuǎn)換為1：1的Send-Receiver模型通信，同時將服務(wù)結(jié)果反向傳輸?shù)娇蛻舳说倪^程轉(zhuǎn)換為另外一組Send-Receiver通信；
• 隊列或者非隊列通信；
• 1：1通信，如果接受端沒有被周期性的調(diào)用；
• N：1通信；

核間元素交互與任務(wù)同步

我們知道多核OS由任務(wù)，中斷，報警器和事件等元素組成，它們之間的相互作用使得操作系統(tǒng)能夠有條不紊的運作。

從一般意義上來講，AUTOSAR OS本質(zhì)上就是基于事件驅(qū)動的操作系統(tǒng)。如下可簡要描述核間各元素的交互關(guān)系：

• 報警器可以激活基本任務(wù)A或者設(shè)置某事件1;
• 擴展任務(wù)B等待事件1那邊可以激活基本任務(wù)C；
• 基本任務(wù)C可以設(shè)置某事件2，中斷可以設(shè)置某事件3；
• 擴展任務(wù)D等待事件2和事件3之后便可以開啟執(zhí)行；
• 基本任務(wù)E可以通過IOC機制實現(xiàn)與基本任務(wù)A之間的數(shù)據(jù)交互；

如上可知，在多核OS中事件是可以跨核傳輸?shù)模@也就意味著核與核之間的同步可以通過事件觸發(fā)的方式來實現(xiàn) 。

如下圖11所示，當(dāng)Core0中的任務(wù)T1執(zhí)行時，可以通過設(shè)置Event來激活位于Core1中的T2，這樣便完成了T1與T2之間的任務(wù)同步，該方法適用于事件觸發(fā)的任務(wù)或者定期執(zhí)行的任務(wù)之間的同步，當(dāng)然如果是定期執(zhí)行的任務(wù)只需使用Alarm或者調(diào)度表定期觸發(fā)Event即可。

圖11 多核OS任務(wù)基于事件同步示意圖

除此以外，我們還可以通過調(diào)度表來實現(xiàn)任務(wù)同步，由于報警器只能一次觸發(fā)一個任務(wù)，因此不能實現(xiàn)任務(wù)同步，而調(diào)度表則可以實現(xiàn)同時觸發(fā)不同核的多個任務(wù)，而該方法僅用于定期執(zhí)行的任務(wù)的同步。