本文探討了RT-Thread與AUTOSAR CP的融合，解決車載ECU開發中實時性、安全性與靈活性的平衡問題。通過分層安全內核（rt-safety os/auto os）和工具鏈整合，兼容AUTOSAR標準，同時保留RT-Thread的POSIX支持與可裁剪性，實現了通信隔離、診斷模塊集成等關鍵技術突破，為車載系統提供高安全、可擴展的解決方案。

車載電子系統與傳統實時操作系統（RTOS）領域雖有關聯，但也存在顯著差異。傳統RTOS更注重實時性，并在此基礎上擴展其他的功能需求，這些需求多來源于傳統計算機的應用場景，例如對文件系統數據存儲上的支持、對以太網數據交互的支持等。由于涉及到和PC的交互，所以相關功能最好可以與PC兼容：存儲上是否支持PC可識別的文件系統，例如FAT文件系統，使SD卡取出時可以直接在PC上進行讀取；而以太網上則希望采用主流的TCP/IP協議，包括Web服務，及后續誕生的MQTT協議。傳統計算機廣泛采用POSIX（Portable Operating System Interface，可移植操作系統接口，是一組由IEEE制定的標準，旨在確保操作系統提供應用程序可移植性的API規范）作為編程接口。

在傳統實時操作系統（RTOS）領域，RT-Thread以其卓越性能脫穎而出。其卓越性體現在多個方面：首先是對POSIX標準的全面支持（從PSE51的完整支持，到PSE53/54標準部分支持）；其次是對多樣化芯片架構的廣泛兼容；尤為重要的是，RT-Thread始終秉持著"小而美"的操作系統設計理念。所謂"小"，體現在專為嵌入式設備量身定制，并將操作系統內核嚴格限定在基礎功能范疇（包括多任務調度、文件系統、網絡協議棧及shell命令行等核心模塊）。而"美"則體現在系統架構與代碼實現的精煉性——既保持高度合理性，又避免過度復雜化。這一設計理念同時強調可維護性，使工程技術人員能夠快速掌握系統核心機制，在遇到技術問題時能夠精準定位解決路徑（遇到問題，但不知從何下手解決問題，這個相信是工程師最抓腦的事情）。

RT-Thread操作系統的架構圖，摘自github/RT-Thread，典型的分層結構

當RT-Thread實時操作系統與車載AUTOSAR標準體系實現融合時，將呈現何種技術形態呢？二者顯然存在顯著差異，但同時具備協同互補潛力：通過相互借鑒核心優勢，實現技術特性的優化整合。

AUTOSAR（AUTomotive Open System ARchitecture，汽車開放系統架構）是一種標準化的汽車電子控制單元（ECU）軟件架構，旨在通過統一底層軟件封裝，使不同廠商的ECU能夠兼容，從而減少重復開發，提高效率。AUTOSAR聯盟于2003年由9家汽車行業巨頭（如寶馬、博世、大陸等）聯合成立，其核心理念是“標準上合作，實現上競爭”，即行業共同制定底層標準，各廠商專注于上層應用開發。

作為汽車電子電氣架構領域的核心軟件規范與標準體系，AUTOSAR自創立伊始便專注于車載應用領域，其發展歷程始終聚焦于汽車產業需求，未涉足其他行業應用。這種專注性使其構建了高度系統化、專業化的完整技術框架，同時也形成了相對封閉的技術生態系統。該體系以方法論體系與工具鏈為核心特征，為汽車軟件的開發、集成與驗證提供了標準化的技術解決方案。

一起來看看AUTOSAR都有些什么，以及有哪些優點吧：

由AUTOSAR的架構圖，可以很明顯的看出是采用了分層，分模塊的方式：最底層是微控制器硬件層；最上層是應用層（Application Layer）、運行環境（Runtime Environment）；以及中間的基礎軟件（BSW）。

除嵌入式軟件架構外，AUTOSAR CP方法論在汽車電子系統開發中亦具有著重要地位。其核心理念在于：車載電子控制單元并非孤立存在，而是作為整車網絡體系中的關鍵節點，需與其他組件協同運作以實現系統整體功能。

汽車電子電氣架構中的總線及ECU

當處在復雜的車載網絡環境中，特別是包含多條主干總線，數十甚至上百個節點時，還需考慮以下關鍵因素：通信、調試以及時延的問題等。

車載電控單元面臨的挑戰

通信

在車載網絡架構中，通信層面的技術實現方案是首要考量的核心要素。在數據報文交互過程中，必須采用標準化的識別機制，而非傳統的逐字段定義或多方協商模式。當前車輛網絡架構采用標準的格式描述體系，具體而言：各網絡節點均配置唯一標識符（ID），并通過標準化描述文件對字段進行系統化定義與規范。該技術路徑衍生出DBC文件格式，并進一步演進為ARXML（AUTOSAR XML）文件格式。基于此標準化框架，可自動生成對應實現代碼，有效規避人工編碼可能引入的缺陷，同時構建起完整的工程實施規范體系。

調試

當車輛控制器安裝好后，通常無法再采用JTAG/SWD或UART等傳統方式進行調試。鑒于車輛網絡系統具備互聯特性，此時應建立標準化的診斷機制。具體而言，當車輛在運行過程中發生故障時，系統需自動記錄并存儲相應的故障代碼。在4S店進行維修時，技術人員可通過診斷接口（OBD，CAN口或以太網口）調取所有相關故障信息，以確保維修工作的準確性和高效性。

功能安全

當涉及到控制時，安全性就成為必然要考慮的點。車控系統涉及多個安全關鍵點，例如：

代碼bug導致的異常；

非法內存訪問，導致軟件異常；

事件或周期性任務頻率紊亂；

任務處理超時；

需建立雙重防護機制：針對這些情況的預防性措施，以及當這些異常出現時的容錯處理。

基于模型的設計方法

當逐漸形成一個專有體系時，開發過程需要采用更加精細化的方法。當圍繞著車輛環境構建一個整體的生態體系時，需要注意如何盡可能避免差錯方式的開發，也就有了建模方式的上層應用開發——建模開發：基于模型的設計（MBD）方法，通過工具如Simulink或ASCET將系統功能抽象為可視化模型，實現算法和邏輯的仿真驗證。其核心流程包括靜態驗證（如MISRA規則檢查）、動態驗證（模型仿真與代碼測試）以及性能優化（內存與實時性管理），確保符合車載嵌入式系統的安全與實時性要求。此外，建模也會遵循AUTOSAR分層架構標準，將應用層與底層硬件解耦，提升軟件的可復用性和可擴展性。

RT-Thread破局之路

RT-Thread＋AUTOSAR CP

當RT-Thread和AUTOSAR CP相遇時，雖然存在沖突（例如RT-Thread非常靈活，允許動態內存分配的方式），但更多的是把雙方的優點進行融合。

系統在實現AUTOSAR CP規范的同時兼容POSIX API。這使得車控系統在運行時，依然保留了RT-Thread便捷的shell命令行，甚至可以在Can總線上使用shell。另外，RT-Thread是一個可裁剪性較優的系統，所以當不需要POSIX特性時，也可以完全裁減掉上層的系列組件，只保留最基本的內核。而當需要時，依然可以通過menuconfig方式靈活添加進來，包括上層的DFS設備文件系統，TCP/IP網絡協議棧。這種靈活性使得系統能夠輕松集成更多POSIX功能庫，包括DDS實現（在新的AUTOSAR CP規范標準中也加入了DDS的功能，不過加入得比較晚。在程翧車控系統上帶了AUTOSAR CP風格SOME/IP實現，而DDS實現則更依賴于POSIX部分）。

rt-safety os和rt-safety auto os

在操作系統內核層面，系統基于RT-Thread實現了AUTOSAR Os，但這里的RT-Thread內核并非傳統意義上的RT-Thread內核，而是一個能夠向上提供安全機制的安全型內核。這種實現方式形成了兩個層次的概念：

rt-safety os，底層的實時型安全內核，它在內核層保持了與RT-Thread API的兼容性，本質上是對RT-Thread內核API的安全實現；

rt-safety auto os，基于rt-safety os實現了AUTOSAR Os API的AUTOSAR Os。

而在rt-safety os層面，需要重點考慮功能安全機制：

osa - os application

首先在在系統整體運行過程中，應用與系統應該是邏輯分離的：應用運行在應用的空間；系統（內核）應該運行在內核的空間，兩者相互獨立、相互隔離。這種設計需要引入應用的概念。雖然傳統計算機采用進程方式。但在MCU上，顯然進程差強人意，而且如果把應用獨立開發，反而會把一個簡單的事變得相對更復雜了（例如調試、燒寫等過程）。

在rt-safety os內核上抽象了一份os application實現，這與AUTOSAR Os中的OsApplication相對應。類似進程方式，osa是一個內核對象的容器，可以包括線程，semaphore，mutex，event等對象（這些對象創建后，屬于一個osa，而不屬于系統內核）。

內核態和用戶態分離

基于osa的設計，系統實現了內存隔離機制，應用并不能也不應自行調整內存訪問權限。所以osa應用本身應該運行在用戶態（不具備直接配置底層內存分區的功能），而當需要系統服務時，（通過系統調用）陷入到內核中進行操作，然后結束后返回到用戶態。

雖然這種設計看起來和進程有許多相似之處，但不一樣的包括：

osa的代碼依然和系統整體代碼一起編譯，一起運行；

osa的代碼在運行過程中，從入口位置進入到用戶態，以用戶態方式執行；

進程需要有虛擬的隔離地址空間。

這種設計使得整個系統作為一個完整的工程，方便于燒寫到flash空間及調試。

AUTOSAR Os實現

rt-safety os作為底層安全型實時內核，而AUTOSAR Os需要更豐富的功能支持，這些功能由rt-safety auto os提供，它實現了完整的AUTOSAR Os規范：

完整依據AUTOSAR Os規范進行實現，包括它的需求和軟件設計；

OsApplication作為操作系統應用，基于osa的上層封裝和實現，具備多項基礎功能包括并不限于：

Task，CAT2 ISR

Counter，Alarm，Schedule Table

Resource，Event

支持多核的實現，包括OsApplication間、核間安全通信的IoC通信機制；

得益于AUTOSAR CP的規范性，系統已在數個項目上實現了與其他AUTOSAR CP系統的單核或多核Os平替。

中間件

當涉及到AUTOSAR CP時，必然也包括AUTOSAR CP架構中的眾多中間件。這些組件按照AUTOSAR CP規范劃分為不同的列（功能列）：

分成了：

System Services，系統服務

Memory Services，存儲服務

Communication Services，通信服務

I/O Hardware Abstraction，I/O硬件抽象

Complex Drivers，復雜驅動

這里重點對System Services（系統服務），Memory Services（存儲服務），Communication Services（通信服務）做簡單介紹。

系統服務涉及到AUTOSAR Os，以及WdgM，StbM，BswM，EcuM等，這些都和系統相關。例如EcuM涉及到上下電的管理，會和RT-Thread原生的啟動順序差異很大，對RT-Thread的初始化進行深度調整后，兼容了EcuM（也包括其中的CallOut）。而WdgM則是多個功能安全模塊相關，例如邏輯監督，實現了內圖算法。StbM（時鐘同步模塊），不僅實現了Can的時鐘同步，也包括對以太網時鐘同步的支持。

存儲服務，主要涉及Nvm和Fee，Nvm提供Block存儲的隊列和備份機制，也包括crc校驗等特性；而Fee負責提供flash的磨損平衡，塊一致性信息管理。可以根據實際情況靈活的進行異步/同步存儲。它們在嵌入式汽車軟件中承擔了對持久性數據存儲和恢復的關鍵職責。

通信服務，中間件中的核心模塊，包括了Com/LdCom，PduR，IpduM，以及到不同通信鏈路的路由和通信（Can，Lin，Eth）。PduR作為系統核心的路由表，由工具靜態配置生成。有了路由表后，收到的PDU會自動向不同端口進行路由。而Com模塊則和系統信號密切相關，作為系統信號的數據池。此外，網絡管理模塊和ECU節點的上下電密切相關，是系統的重要組成部分，包括部分網絡管理。

診斷和標定功能雖然分散在不同功能列中，但很多時候也會被單獨討論。診斷模塊（Dcm/Dem/FiM），既包括了核心數據傳輸（也包括對診斷請求的應答），也包括了故障碼處理（又和NvM關聯起來），而FiM則負責失效管理。

標定則類似于在線調試器，可以通過上位機工具接入到網絡中，對參數進行修改并保存，從而供后續使用標定后的參數進行工作。標定協議包括CCP和XCP，其中CCP只工作于Can總線上，而XCP則可以是Xcp on Can和Xcp on Eth。

這些中間件，在RT-Thread Safety AUTO上的實現都采用解耦的方式，它們可以不依賴于AUTOSAR Os，即這些BSW中間件也可以工作在開源的RT-Thread系統上運行。

配置工具

正如前文所述，AUTOSAR CP更類似于工具配置模式，通過建模開發，導入模型文件，然后配置，最終生成代碼。最理想的方式是，全程使用工具進行配置，生成代碼后編譯，直接在控制器上運行起來。通過工具的方式，降低人工代碼出錯的概率。

在程翧車控系統上，也支持這樣的方式，對應的工具叫Clarence Studio（Clarence程翧英文名，Clarence Studio簡稱C-Studio）。以下是整體的流程過程：

結語

文章介紹了衍生自RT-Thread的程翧車控系統情況，它衍生自RT-Thread，但并不是RT-Thread，可以用以下的表格進行對比：

和開源RT-Thread的對比

程翧車控系統更多的信息，后續會有針對性的快速原型開發平臺，可以讓開發者，科研人員，高校人員基于這套快速原型開發平臺（使用建模設計方式）進行快速原型開發。