RTE(Run-Time Environment)是AUTOSAR體系結構的核心。RTE在AUTOSAR軟件架構中介於應用層和基礎軟件層之間，是AUTOSAR虛擬功能總線(VFB)接口的實現，從而爲應用軟件（Application Software）組件之間的通信提供基礎設施服務，並促進對包括OS在內的基礎軟件(Basic Software)組件的訪問。
應用軟件組件包含的系統軟件是與CPU和位置相關的。這就意味着，受系統設計人員施加的約束，應用程序軟件組件可以在系統配置期間映射到任何可用的ECU。RTE負責確保組件能夠通信，並且無論在哪裏映射組件，系統都能按預期繼續工作。RTE包含系統基礎設施的可變元素，這些可變元素來自於組件到ECU的不同映射以及標準化的RTE服務。每個ECU生成和配置RTE，來確保RTE是ECU的最佳選擇。
上面說了這麼多，具象地描述下這個過程。如下圖，可以將RTE理解成AUTOSAR架構中的服務員角色。它是來溝通、交互不同SW-C之間，以及SW-C與BSW之間信息的傳遞者。
需要解釋個名詞：Runnables。它是可運行實體(Runnable entities)的縮寫，SWC的一部分，可以包含實際實現的函數，具體邏輯算法或者可執行操作內容，由RTE週期性或事件觸發調用。概括地看RTE包含以下內容：
‰ RTE需要配置(e.g. 把runnables對應到OS的tasks中去)
‰ 通過RTE的事件觸發runnables的運行
‰ 生成調用runnables的task代碼
‰ 配置OS的一部分 (tasks, events, alarms)
‰ 實現SWC之間的通信
‰ 每個ECU的RTE因SWC的需求而異
‰ RTE抽象了OS，防止SWC直接訪問OS和BSW
SWCs與runnables之間的調用和實現過程大致如下：
從上圖的調度過程可以看出，與傳統ECU進程函數調度不同，AUTOSAR通過RTE，將OS抽象出來了，SWC不會直接訪問OS或BSW，均通過RTE來實現，以此解耦不同應用策略對ECU平臺的依賴。當然，ECU的RTE也會由於SWC功能需求的不同而存在差異。
那麼，RTE對於Runnables的觸發條件有哪些呢？主要有以下幾種：
‰ 定時時間
週期性觸發 (例如使用OS的Alarm)
‰ 數據接收事件(S/R)
當收到數據時觸發
‰ 異步服務調用返回事件(C/S)
‰ 操作調用事件(C/S)
‰ 數據接收錯誤事件(S/R)
‰ 數據發送完成事件(S/R)
‰ 狀態切換事件
RTE作爲SWC和BSW之間的通信機構，多了幾個不同端口的概念：
‰ Sender-Receiver
‰ Client-Server
‰ Intra-ECU and Inter-ECU (via COM)
‰ RTE implements callbacks of AR-COM
具體這幾個端口的概念和應用，後續有機會展開介紹。可以這麼理解，Sender-Receiver：當成一個global變量的讀寫；Client-Server：就是一個function call。另外，除了上面幾個接口外，保證數據一致性(e.g. exclusive area)，支持簡單數據及複雜數據(records)和SWC多途徑應用在RTE中也扮演着很重要的角色。
Sender-Receiver:
Client-Server:
SWC內部通信:
RTE中還有個重要的概念就是每個層級交互的接口模塊Interfaces。
Interfaces：
Standardized Interface：
AUTOSAR Interface：
Standardized AUTOSAR Interface：
最後，還有RTE的生成器。
RTE生成器是基於ECU配置描述中的信息爲ECU創建AUTOSAR VFB總線的一組工具。RTE生成器負責創建AUTOSAR軟件API函數：將AUTOSAR軟件組件鏈接到操作系統的組件，並管理AUTOSAR軟件組件之間、AUTOSAR軟件組件與BSW的通信。
RTE是AUTOSAR體系結構的核心，其中很多元素都可以展開來說，篇幅限制，後續有機會將針對各個部分分別介紹，今天就overview地介紹到這裏，歡迎大家後臺留言溝通交流。
作者簡介：
Demu，傳統汽車電控向智能駕駛轉變的汽車人。從事發動機控制器系統工程師和軟件工程師多年，有豐富的ECU系統和軟件設計經驗。歡迎大家一起留言交流，共同進步。