極氪軟件及電子中心 jojo
實時操作系統（RTOS）是指當外界事件或數據產生時，能夠接受並以足夠快的速度予以處理，其處理的結果又能在規定的時間之內來控制生產過程或對處理系統做出快速響應，調度一切可利用的資源完成實時任務，並控制所有實時任務協調一致運行的操作系統。
與實時操作系統對應的就是非實時操作系統了，例如Linux（可以通過給內核打上RT補丁使其變為實時操作系統），windows。這類操作系統將系統處理機時間和內存空間按照一定的時間間隔，輪流地切換給各終端用戶的程序使用，會給低優先級進程分一些運行時間，避免高優先級重負載任務把鍵盤鼠標控制台桌面之類堵死。
實時操作系統有很多如μCos、FreeRTOS、Vxworks、QNX、Osek os。AUTOSAR的core OS就是OSEK，他早已廣泛應用於汽車工業。OSEK源於德語，是一種嵌入式操作系統，被設計用於提供整車的各種電子控制單元的軟件系統。AUTOSAR OS 向后兼容OSEK OS，基於OSEK OS 擴展了一些特性和需求，比如內存保護(memory protection)和時間保護（time protection）等。
OS-Application是AUTOSAR OS 的重要的功能單元， 負責收集操作系統對象，如Tasks, ISRs, Alarms, Schedule tables, Counters等。
AUTOSAR_SWS_OS規范中7.6章節對AUTOSAR OS的框架定義。其中包含：
| 序號 |
操作系統對象 |
作用 |
| 1 |
APPLICATION |
OS-APP，負責收集操作系統對象 |
| 2 |
SCHEDULETABLE |
調度表 |
| 3 |
ALARM |
報警器，一般用於在操作系統運行過程中，可進行實時的報警周期設置，典型的用於功能安全相關的調度機制 |
| 4 |
COUNTER |
計數器 |
| 5 |
TASK |
周期任務 |
| 6 |
ISR |
中斷任務，響應外部和內部事件觸發的中斷 |
| 7 |
ErrorHook |
當軟件運行遇到Error，調用hook |
| 8 |
StartupHook |
當軟件上電且需要從boot進入到操作系統之前，往往需要調用hook，完成啟動操作。 |
| 9 |
ShutdownHook |
軟件下電且需要退出操作系統，往往會調用hook，跳轉到shutdown完成下電操作。 |
如果在系統中使用OS-Application，則所有的Task, ISR, Counter, Alarm, Schedule Table都必須屬於某一個OS-Application 。
接下來我們來聊聊AUTOSAR操作系統中的多核處理。AUTOSAR中的多核操作系統並不是一個虛擬ECU概念，而是一個共享相同配置和大部分代碼的操作系統，但是不同的核上進行不同的運算。操作系統的生成部分的相關信息來源於同一個配置。這意味着，ID(例如TASKID、RESOURCEID…)在核之間是唯一的。任務的優先級定義來源於調度表的配置。因此多個內核可以真正並行運行，可以同時執行多個任務。
- Startup階段。初始化MCU，每個核完成EcuM_Init() （AUTOSAR定義功能），且每個核完成StartOS。
- 運行階段。從啟動模式切換到操作系統運行模式，完成OS:Startuphook，並開始操作系統的運行,e.g. 10ms, 100ms等周期性任務開始運行。
- Shutdown階段。從OS運行模式切換到下電模式。下電關閉程序由BswM和EcuM協調。所有核上的EcuM都表明它們已經准備好了關閉，EcuM在主內核上調用shutdownallcore(),完成整個ECU的下電。
在AUTOSAR OS中具體的分配策略有如下幾種：
1）ChainTask鏈任務機制
什么是ChainTask機制，AUTOSAR規范中又是如何定義的呢？一個鏈任務由幾個任務組成，每個鏈任務OS-Mechanism相互激活。所以不同的任務可以按照定義的順序在不同的核上執行。
例如下圖所示。左邊是單核芯片core X，右邊是雙核芯片core Y和core Z。
原來任務Task A是單獨在單核芯片core X上運行， Task A => proc1(); proc2(); proc3(); proc4()。當把Task A拆分為兩個任務Task A’和Task A’’ 並且分別在2個單獨的核core Y和core Z上運行時，鏈任務ChainTask機制確保，流程順序是與任務A一樣，在不同的內核中運行。
跨核task又是如何開銷ChainTask呢？例如下圖所示。拿1ms任務舉例，首先Core X觸發OS_BswStart_1ms_Task任務，由於鏈任務的作用，直接跨核到Core Y執行OS_1ms_Task，執行完后又通過鏈任務跨核回到Core X執行OS_BswEnd_1ms_Task。這種任務鏈的缺點會開銷runtime，比如1ms的任務，2次的來回的Chaintask，大約會開銷2x30us的負荷，約占6% runtime。
2）分布式運行機制
分布式運行機制，AUTOSAR規范中解釋為”task clusters are freely distributable”。該分布式運行機制是當前AUTOSAR多核分配方式的主流，task在一個核上運行，不存在跨核之間的鏈任務，耦合性不高。缺點是容易造成不同核之間的負荷不均。如下圖所示，某一個雙核的控制器Core X運行所有CAT1 的中斷，Core Y運行所有的周期性任務，不存在跨核間的調度，所有的任務都在自己的核上單獨運行。
操作系統的運行時間可以通過優化減少數據的訪問時間來實現。如下圖舉例。某個3核的MCU，Core0為Peripheral Core，Core 1為Locked Core，Core 2為Performance Core。每個core都有單獨的RAM分別為RAM0,1,2，同時通過總線外部掛有system Ram。通過下圖可以發現當core1訪問自己的RAM1只需要1個tick的時間，而core1訪問core2的RAM需要9個tick的時間。同時訪問外掛system ram需要9個tick的時間。
由此可見，當代碼運行在特定的內核上，盡量把該段功能所屬的變量定義在相同的RAM上，以便優化核減少運行時間。我們在做功能開發的時候特別需要關注變量的分配和任務的分配，使其盡量保持一致，以便減小MCU的開銷。優秀的軟件工程師通過優化內存，可以降低10%左右的負荷。
AUTOSAR的軟件架構已經成為汽車電子控制領域不可逆轉的趨勢，當前國內不少車企，已經把非AUTOSAR軟件架構的電子控制器供應商排除在供應商目錄之列。同時隨着汽車電子芯片的飛速發展，用於AUTOSAR Classic的MCU也發展迅猛。迅速從單核跨入到多核時代，主頻和內存空間也有了大幅度的提升。很多車型已經集成了基於AUTOSAR的軟件架構和多核芯片的控制單元，以滿足日益復雜的電子電器架構。目前，極氪的軟件及電子中心正在開發下一代行業頂尖的ZEEA3.0電氣架構平台，其中的中央計算平台CSC（Core Super Computer）包含A核和M核，A核上運行由極氪自研的ZEEKR_OS ，M核上將運行Classic AUTOSAR OS來實現多核處理，因此本文介紹基於AUTOSAR OS和多核控制芯片的控制策略，幫助大家盡快理解基礎軟件的運行架構。