揭秘RT-Thread上的AUTOSAR CP系统-电子发烧友网

本文探讨了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系统上运行。