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

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

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

RT-Thread操作系統(tǒng)的架構(gòu)圖，摘自github/RT-Thread，典型的分層結(jié)構(gòu)

當(dāng)RT-Thread實(shí)時(shí)操作系統(tǒng)與車載AUTOSAR標(biāo)準(zhǔn)體系實(shí)現(xiàn)融合時(shí)，將呈現(xiàn)何種技術(shù)形態(tài)呢？二者顯然存在顯著差異，但同時(shí)具備協(xié)同互補(bǔ)潛力：通過相互借鑒核心優(yōu)勢(shì)，實(shí)現(xiàn)技術(shù)特性的優(yōu)化整合。

AUTOSAR（AUTomotive Open System ARchitecture，汽車開放系統(tǒng)架構(gòu)）是一種標(biāo)準(zhǔn)化的汽車電子控制單元（ECU）軟件架構(gòu)，旨在通過統(tǒng)一底層軟件封裝，使不同廠商的ECU能夠兼容，從而減少重復(fù)開發(fā)，提高效率。AUTOSAR聯(lián)盟于2003年由9家汽車行業(yè)巨頭（如寶馬、博世、大陸等）聯(lián)合成立，其核心理念是“標(biāo)準(zhǔn)上合作，實(shí)現(xiàn)上競(jìng)爭(zhēng)”，即行業(yè)共同制定底層標(biāo)準(zhǔn)，各廠商專注于上層應(yīng)用開發(fā)。

作為汽車電子電氣架構(gòu)領(lǐng)域的核心軟件規(guī)范與標(biāo)準(zhǔn)體系，AUTOSAR自創(chuàng)立伊始便專注于車載應(yīng)用領(lǐng)域，其發(fā)展歷程始終聚焦于汽車產(chǎn)業(yè)需求，未涉足其他行業(yè)應(yīng)用。這種專注性使其構(gòu)建了高度系統(tǒng)化、專業(yè)化的完整技術(shù)框架，同時(shí)也形成了相對(duì)封閉的技術(shù)生態(tài)系統(tǒng)。該體系以方法論體系與工具鏈為核心特征，為汽車軟件的開發(fā)、集成與驗(yàn)證提供了標(biāo)準(zhǔn)化的技術(shù)解決方案。

一起來看看AUTOSAR都有些什么，以及有哪些優(yōu)點(diǎn)吧：

由AUTOSAR的架構(gòu)圖，可以很明顯的看出是采用了分層，分模塊的方式：最底層是微控制器硬件層；最上層是應(yīng)用層（Application Layer）、運(yùn)行環(huán)境（Runtime Environment）；以及中間的基礎(chǔ)軟件（BSW）。

除嵌入式軟件架構(gòu)外，AUTOSAR CP方法論在汽車電子系統(tǒng)開發(fā)中亦具有著重要地位。其核心理念在于：車載電子控制單元并非孤立存在，而是作為整車網(wǎng)絡(luò)體系中的關(guān)鍵節(jié)點(diǎn)，需與其他組件協(xié)同運(yùn)作以實(shí)現(xiàn)系統(tǒng)整體功能。

汽車電子電氣架構(gòu)中的總線及ECU

當(dāng)處在復(fù)雜的車載網(wǎng)絡(luò)環(huán)境中，特別是包含多條主干總線，數(shù)十甚至上百個(gè)節(jié)點(diǎn)時(shí)，還需考慮以下關(guān)鍵因素：通信、調(diào)試以及時(shí)延的問題等。

車載電控單元面臨的挑戰(zhàn)

通信

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

調(diào)試

當(dāng)車輛控制器安裝好后，通常無法再采用JTAG/SWD或UART等傳統(tǒng)方式進(jìn)行調(diào)試。鑒于車輛網(wǎng)絡(luò)系統(tǒng)具備互聯(lián)特性，此時(shí)應(yīng)建立標(biāo)準(zhǔn)化的診斷機(jī)制。具體而言，當(dāng)車輛在運(yùn)行過程中發(fā)生故障時(shí)，系統(tǒng)需自動(dòng)記錄并存儲(chǔ)相應(yīng)的故障代碼。在4S店進(jìn)行維修時(shí)，技術(shù)人員可通過診斷接口（OBD，CAN口或以太網(wǎng)口）調(diào)取所有相關(guān)故障信息，以確保維修工作的準(zhǔn)確性和高效性。

功能安全

當(dāng)涉及到控制時(shí)，安全性就成為必然要考慮的點(diǎn)。車控系統(tǒng)涉及多個(gè)安全關(guān)鍵點(diǎn)，例如：

代碼bug導(dǎo)致的異常；

非法內(nèi)存訪問，導(dǎo)致軟件異常；

事件或周期性任務(wù)頻率紊亂；

任務(wù)處理超時(shí)；

需建立雙重防護(hù)機(jī)制：針對(duì)這些情況的預(yù)防性措施，以及當(dāng)這些異常出現(xiàn)時(shí)的容錯(cuò)處理。

基于模型的設(shè)計(jì)方法

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

RT-Thread破局之路

RT-Thread＋AUTOSAR CP

當(dāng)RT-Thread和AUTOSAR CP相遇時(shí)，雖然存在沖突（例如RT-Thread非常靈活，允許動(dòng)態(tài)內(nèi)存分配的方式），但更多的是把雙方的優(yōu)點(diǎn)進(jìn)行融合。

系統(tǒng)在實(shí)現(xiàn)AUTOSAR CP規(guī)范的同時(shí)兼容POSIX API。這使得車控系統(tǒng)在運(yùn)行時(shí)，依然保留了RT-Thread便捷的shell命令行，甚至可以在Can總線上使用shell。另外，RT-Thread是一個(gè)可裁剪性較優(yōu)的系統(tǒng)，所以當(dāng)不需要POSIX特性時(shí)，也可以完全裁減掉上層的系列組件，只保留最基本的內(nèi)核。而當(dāng)需要時(shí)，依然可以通過menuconfig方式靈活添加進(jìn)來，包括上層的DFS設(shè)備文件系統(tǒng)，TCP/IP網(wǎng)絡(luò)協(xié)議棧。這種靈活性使得系統(tǒng)能夠輕松集成更多POSIX功能庫(kù)，包括DDS實(shí)現(xiàn)（在新的AUTOSAR CP規(guī)范標(biāo)準(zhǔn)中也加入了DDS的功能，不過加入得比較晚。在程翧車控系統(tǒng)上帶了AUTOSAR CP風(fēng)格SOME/IP實(shí)現(xiàn)，而DDS實(shí)現(xiàn)則更依賴于POSIX部分）。

rt-safety os和rt-safety auto os

在操作系統(tǒng)內(nèi)核層面，系統(tǒng)基于RT-Thread實(shí)現(xiàn)了AUTOSAR Os，但這里的RT-Thread內(nèi)核并非傳統(tǒng)意義上的RT-Thread內(nèi)核，而是一個(gè)能夠向上提供安全機(jī)制的安全型內(nèi)核。這種實(shí)現(xiàn)方式形成了兩個(gè)層次的概念：

rt-safety os，底層的實(shí)時(shí)型安全內(nèi)核，它在內(nèi)核層保持了與RT-Thread API的兼容性，本質(zhì)上是對(duì)RT-Thread內(nèi)核API的安全實(shí)現(xiàn)；

rt-safety auto os，基于rt-safety os實(shí)現(xiàn)了AUTOSAR Os API的AUTOSAR Os。

而在rt-safety os層面，需要重點(diǎn)考慮功能安全機(jī)制：

osa - os application

首先在在系統(tǒng)整體運(yùn)行過程中，應(yīng)用與系統(tǒng)應(yīng)該是邏輯分離的：應(yīng)用運(yùn)行在應(yīng)用的空間；系統(tǒng)（內(nèi)核）應(yīng)該運(yùn)行在內(nèi)核的空間，兩者相互獨(dú)立、相互隔離。這種設(shè)計(jì)需要引入應(yīng)用的概念。雖然傳統(tǒng)計(jì)算機(jī)采用進(jìn)程方式。但在MCU上，顯然進(jìn)程差強(qiáng)人意，而且如果把應(yīng)用獨(dú)立開發(fā)，反而會(huì)把一個(gè)簡(jiǎn)單的事變得相對(duì)更復(fù)雜了（例如調(diào)試、燒寫等過程）。

在rt-safety os內(nèi)核上抽象了一份os application實(shí)現(xiàn)，這與AUTOSAR Os中的OsApplication相對(duì)應(yīng)。類似進(jìn)程方式，osa是一個(gè)內(nèi)核對(duì)象的容器，可以包括線程，semaphore，mutex，event等對(duì)象（這些對(duì)象創(chuàng)建后，屬于一個(gè)osa，而不屬于系統(tǒng)內(nèi)核）。

內(nèi)核態(tài)和用戶態(tài)分離

基于osa的設(shè)計(jì)，系統(tǒng)實(shí)現(xiàn)了內(nèi)存隔離機(jī)制，應(yīng)用并不能也不應(yīng)自行調(diào)整內(nèi)存訪問權(quán)限。所以osa應(yīng)用本身應(yīng)該運(yùn)行在用戶態(tài)（不具備直接配置底層內(nèi)存分區(qū)的功能），而當(dāng)需要系統(tǒng)服務(wù)時(shí)，（通過系統(tǒng)調(diào)用）陷入到內(nèi)核中進(jìn)行操作，然后結(jié)束后返回到用戶態(tài)。

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

osa的代碼依然和系統(tǒng)整體代碼一起編譯，一起運(yùn)行；

osa的代碼在運(yùn)行過程中，從入口位置進(jìn)入到用戶態(tài)，以用戶態(tài)方式執(zhí)行；

進(jìn)程需要有虛擬的隔離地址空間。

這種設(shè)計(jì)使得整個(gè)系統(tǒng)作為一個(gè)完整的工程，方便于燒寫到flash空間及調(diào)試。

AUTOSAR Os實(shí)現(xiàn)

rt-safety os作為底層安全型實(shí)時(shí)內(nèi)核，而AUTOSAR Os需要更豐富的功能支持，這些功能由rt-safety auto os提供，它實(shí)現(xiàn)了完整的AUTOSAR Os規(guī)范：

完整依據(jù)AUTOSAR Os規(guī)范進(jìn)行實(shí)現(xiàn)，包括它的需求和軟件設(shè)計(jì)；

OsApplication作為操作系統(tǒng)應(yīng)用，基于osa的上層封裝和實(shí)現(xiàn)，具備多項(xiàng)基礎(chǔ)功能包括并不限于：

Task，CAT2 ISR

Counter，Alarm，Schedule Table

Resource，Event

支持多核的實(shí)現(xiàn)，包括OsApplication間、核間安全通信的IoC通信機(jī)制；

得益于AUTOSAR CP的規(guī)范性，系統(tǒng)已在數(shù)個(gè)項(xiàng)目上實(shí)現(xiàn)了與其他AUTOSAR CP系統(tǒng)的單核或多核Os平替。

中間件

當(dāng)涉及到AUTOSAR CP時(shí)，必然也包括AUTOSAR CP架構(gòu)中的眾多中間件。這些組件按照AUTOSAR CP規(guī)范劃分為不同的列（功能列）：

分成了：

System Services，系統(tǒng)服務(wù)

Memory Services，存儲(chǔ)服務(wù)

Communication Services，通信服務(wù)

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

Complex Drivers，復(fù)雜驅(qū)動(dòng)

這里重點(diǎn)對(duì)System Services（系統(tǒng)服務(wù)），Memory Services（存儲(chǔ)服務(wù)），Communication Services（通信服務(wù)）做簡(jiǎn)單介紹。

系統(tǒng)服務(wù)涉及到AUTOSAR Os，以及WdgM，StbM，BswM，EcuM等，這些都和系統(tǒng)相關(guān)。例如EcuM涉及到上下電的管理，會(huì)和RT-Thread原生的啟動(dòng)順序差異很大，對(duì)RT-Thread的初始化進(jìn)行深度調(diào)整后，兼容了EcuM（也包括其中的CallOut）。而WdgM則是多個(gè)功能安全模塊相關(guān)，例如邏輯監(jiān)督，實(shí)現(xiàn)了內(nèi)圖算法。StbM（時(shí)鐘同步模塊），不僅實(shí)現(xiàn)了Can的時(shí)鐘同步，也包括對(duì)以太網(wǎng)時(shí)鐘同步的支持。

存儲(chǔ)服務(wù)，主要涉及Nvm和Fee，Nvm提供Block存儲(chǔ)的隊(duì)列和備份機(jī)制，也包括crc校驗(yàn)等特性；而Fee負(fù)責(zé)提供flash的磨損平衡，塊一致性信息管理?？梢愿鶕?jù)實(shí)際情況靈活的進(jìn)行異步/同步存儲(chǔ)。它們?cè)谇度胧狡囓浖谐袚?dān)了對(duì)持久性數(shù)據(jù)存儲(chǔ)和恢復(fù)的關(guān)鍵職責(zé)。

通信服務(wù)，中間件中的核心模塊，包括了Com/LdCom，PduR，IpduM，以及到不同通信鏈路的路由和通信（Can，Lin，Eth）。PduR作為系統(tǒng)核心的路由表，由工具靜態(tài)配置生成。有了路由表后，收到的PDU會(huì)自動(dòng)向不同端口進(jìn)行路由。而Com模塊則和系統(tǒng)信號(hào)密切相關(guān)，作為系統(tǒng)信號(hào)的數(shù)據(jù)池。此外，網(wǎng)絡(luò)管理模塊和ECU節(jié)點(diǎn)的上下電密切相關(guān)，是系統(tǒng)的重要組成部分，包括部分網(wǎng)絡(luò)管理。

診斷和標(biāo)定功能雖然分散在不同功能列中，但很多時(shí)候也會(huì)被單獨(dú)討論。診斷模塊（Dcm/Dem/FiM），既包括了核心數(shù)據(jù)傳輸（也包括對(duì)診斷請(qǐng)求的應(yīng)答），也包括了故障碼處理（又和NvM關(guān)聯(lián)起來），而FiM則負(fù)責(zé)失效管理。

標(biāo)定則類似于在線調(diào)試器，可以通過上位機(jī)工具接入到網(wǎng)絡(luò)中，對(duì)參數(shù)進(jìn)行修改并保存，從而供后續(xù)使用標(biāo)定后的參數(shù)進(jìn)行工作。標(biāo)定協(xié)議包括CCP和XCP，其中CCP只工作于Can總線上，而XCP則可以是Xcp on Can和Xcp on Eth。

這些中間件，在RT-Thread Safety AUTO上的實(shí)現(xiàn)都采用解耦的方式，它們可以不依賴于AUTOSAR Os，即這些BSW中間件也可以工作在開源的RT-Thread系統(tǒng)上運(yùn)行。

配置工具

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

在程翧車控系統(tǒng)上，也支持這樣的方式，對(duì)應(yīng)的工具叫Clarence Studio（Clarence程翧英文名，Clarence Studio簡(jiǎn)稱C-Studio）。以下是整體的流程過程：

結(jié)語

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

和開源RT-Thread的對(duì)比

程翧車控系統(tǒng)更多的信息，后續(xù)會(huì)有針對(duì)性的快速原型開發(fā)平臺(tái)，可以讓開發(fā)者，科研人員，高校人員基于這套快速原型開發(fā)平臺(tái)（使用建模設(shè)計(jì)方式）進(jìn)行快速原型開發(fā)。