【AUTOSAR】 Classic Platform 分层软件架构入门刚开始看 AUTOSAR CP 的代码和配置最先要搞清楚的就是这套分层结构谁在上、谁在下、谁可以调谁。本文按这个顺序讲一遍结论以官方规范为准。主要参考的几份规范AUTOSAR_CP_EXP_LayeredSoftwareArchitecture.pdf— 分层架构总览建议先看这份AUTOSAR_CP_SWS_RTE.pdf— RTE 软件规范AUTOSAR_CP_TPS_SoftwareComponentTemplate.pdf— 软件组件模板AUTOSAR_CP_TPS_SystemTemplate.pdf— 系统模板AUTOSAR_CP_SWS_ECUStateManager.pdf— ECU 状态管理AUTOSAR_CP_SWS_BSWGeneral.pdf— 基础软件通用规范文中的图统一约定蓝色实线箭头是调用方向绿色虚线是回调或返回箭头上写的是真实的接口函数名。目录架构总览与设计原则逐层拆解接口体系与调用规则多核、分区与安全隔离软件集群开发方法学与规范索引常见问题1. 架构总览与设计原则1.1 为什么会有这套架构传统 ECU 开发里应用逻辑和驱动代码是混在一起的算法函数里直接出现某个 MCU 的寄存器名板级外设的操作散落在业务代码中间。这样写出来的东西有两个绕不开的问题——换个芯片基本要重写不同供应商的模块也拼不到一起。ECU 数量一多、功能一合并集成和测试成本就压不住了。AUTOSARAUTomotive Open System ARchitecture就是为解决这件事成立的联盟标准OEM、Tier-1、芯片厂和工具商一起定了套 ECU 软件的分层结构和接口规范。Classic PlatformCP是其中面向深度嵌入式、强调实时性和确定性的那一支。1.2 三条设计原则CP 的思路可以概括成一句话基础设施标准化应用功能自定义Standardize the Infrastructure, Customize the Application。落到具体做法上是三条硬件无关应用层不直接碰 MCU 和板级硬件寄存器操作被压在 MCAL 里。位置可重分配写 SWC 的时候不用管它最后落在哪颗 ECU 上映射是配置阶段的事。工具生成代码系统拓扑、端口连接、BSW 参数都写在 ARXML 里RTE 和 BSW 之间的桥接代码由工具生成不手写。第三条经常被低估。它的实际含义是工程里真正需要人写的是 SWC 内部逻辑剩下的层间胶水代码全是配置产物。1.3 两个视角顶层视角最粗三层软件叠在一颗微控制器上。粗粒度视角把 BSW 再拆开服务层、ECU 抽象层、MCAL 依次相邻复杂度驱动CDD横在旁边不受这个次序约束。后面两章就按这两张图自上而下展开。2. 逐层拆解2.1 应用层SWC、端口与 VFB2.1.1 软件组件应用层由一个个 AUTOSAR 软件组件SWC组成它是应用逻辑的最小封装单元原子软件组件Atomic SWC不可再拆具体算法写在这里。传感器/执行器软件组件与本地硬件信号绑得比较紧的一类 SWC通常固定映射在某颗 ECU 上。组合软件组件Composition把若干相关 SWC 在逻辑上打包本身不含实现代码。2.1.2 端口与接口SWC 之间、SWC 与 BSW 服务之间不允许直接读写全局变量或者直接调函数必须经由端口PortP-Port提供端口向外输出数据或提供服务。R-Port需求端口向内要数据或请求服务。端口要挂在某种接口Interface上接口决定数据长什么样、怎么传Sender-ReceiverS/R数据元素的异步传递接近广播/订阅的思路。Client-ServerC/S服务调用客户端发请求服务端执行并回结果同步异步都支持。Mode Switch模式切换通知比如工作模式、休眠模式。2.1.3 VFB设计阶段的一层抽象VFBVirtual Functional Bus不是某个模块而是设计阶段的一个约定架构师把 SWC 挂在一条虚拟总线上连起来此时不需要回答“SWC 落在哪颗 ECU”“信号走 CAN 还是以太网”这两个问题。系统配置阶段把 SWC 分配到具体 ECU 之后这条虚拟总线才被消解成真实代码同一颗 ECU 内的通信变成 RTE 里的内存拷贝或指针传递跨 ECU 的通信由 RTE 调用 BSW 的 COM 模块经总线发出去。关键点是上层 SWC 的代码在这几种情况下完全一样差别只体现在 RTE 的实现里。这就是“位置透明”的实际含义。2.2 RTERTE 是应用层和 BSW 之间的那层薄胶水有两点容易忽略它是生成代码不是静态库。RTE 由 RTE 生成工具Vector DaVinci、EB tresos 等按 ECU 的 ARXML 描述生成换一颗 ECU 就要重新生成一份。它保证位置透明。SWC 调Rte_Write_p_o()或Rte_Call_p_o()时不需要知道目标在同核、跨核还是在别的 ECU 上。RTE 的接口分两个方向向上给 SWC 的是Rte_前缀的标准 API向下BSW 收到总线数据后通过回调Callback通知 RTE由 RTE 触发对应的 Runnable Entity。2.3 基础软件层BSW 从高到低分三个子层。2.3.1 服务层服务层给应用和 BSW 其他模块提供系统级服务按功能分成几组。系统服务模块干什么OS实时操作系统基于 OSEK/VDX 扩展管 Task 调度、Resource 互斥、Event 同步、Counter/Alarm 定时EcuMECU 的上电、初始化、下电、休眠时序BswM仲裁模式请求协调各 BSW 模块的状态切换WdgM程序流监控看逻辑顺序和执行时间是否正常Det收集开发阶段的 API 误用和断言错误Dem诊断事件管理负责 DTC 存储和冻结帧存储服务模块干什么NvM非易失数据管理同步/异步读写、CRC 校验、冗余备份通信服务模块干什么Com信号级通信打包解包、大小端转换、传输属性控制PduRPDU 路由总管在 Com、CanTp、CanIf、Dcm 之间转发DcmUDSISO 14229诊断协议栈2.3.2 ECU 抽象层ECU 抽象层的任务是屏蔽板级硬件的连接方式。同一个 LED可能是 MCU 的 GPIO 直连也可能挂在外扩的 SPI 芯片上对上两者都表现为 IoHwAb 的同一个接口对下直连的调Dio_WriteChannelSPI 扩展的调Spi_SyncTransmit。这一层主要有三组I/O 硬件抽象IoHwAb板级数字量、模拟量的抽象。通信硬件抽象CanIf、CanTp、CanTrcv、CanNm、CanSm 等。CanIf 是这一层的枢纽屏蔽具体的 CAN 控制器和收发器CanTp 夹在 PduR 和 CanIf 之间做 ISO 15765-2 的分片与重组不同资料把 CanTp 归到服务层或 ECU 抽象层都有位置上它就是这两者中间的一层。存储硬件抽象MemIf / Fee / EaFlash、EEPROM 的抽象。2.3.3 MCALMCAL 在 BSW 最底层直接读芯片寄存器驱动由芯片原厂提供代码强依赖芯片架构TriCore、ARM Cortex-M/R 等换芯片必须换这一层但向上暴露的 API 是 AUTOSAR 规范里写死的标准 C 函数。主要模块MCU、GPT、WDG 这类微控制器驱动PORT、DIO、ADC、PWM 这类 I/O 驱动CAN、SPI、ETH 这类通信驱动以及 FLS 这类存储驱动。2.4 复杂度驱动CDD2.4.1 什么情况下用它CDD 是唯一可以直通 RTE 和硬件的模块。AUTOSAR 留这个口子主要是为了三类场景高实时性控制比如喷油、电机高频闭环逐层经过 MCAL → IoHwAb → RTE 的调用深度会带来不可接受的延迟。非标硬件规范里没有定义的特殊外设。老代码搬迁把原来非 AUTOSAR 的代码快速接进来。2.4.2 代价和限制用 CDD 就等于放弃移植性代码和具体硬件、具体应用绑死。另外两条也要记住CDD 向应用层暴露接口同样要走 RTE 的 Port不能自己开一条路让 SWC 直接调。CDD 如果要调其他 BSW 模块的 API得先确认那个 API 是可重入的因为 CDD 经常被多个上下文同时调用。3. 接口体系与调用规则3.1 四类接口AUTOSAR 里“接口”这个词用得很满实际上有四类区分依据是“谁调谁”和“名字谁定”!接口类型谁调谁名字谁定AUTOSAR 接口AUTOSAR InterfaceSWC → SWC经 RTE工程师在 ARXML 里按端口命名生成的 API 名随配置变如Rte_Write_*标准化 AUTOSAR 接口Standardized AUTOSAR InterfaceSWC → BSW 服务模块规范固定如Rte_Call_NvMService_*标准接口Standardized InterfaceBSW 模块 → BSW 模块直接的 C 函数调用规范固定形参和返回值由 SWS 定义如PduR_ComTransmit硬件依赖接口Hardware Dependent InterfaceMCAL → MCU 寄存器芯片原厂定没有统一形式这张表最实际的用处是看到Rte_Write_x_y就知道它是配置生成物换个端口名函数名就变了看到Com_SendSignal就知道这个名字是规范写死的换哪家 BSW 都叫这个名字。3.2 垂直与水平调用规则分层的可维护性靠调用链规约保证规矩不多但要记准垂直方向相邻层之间上下调用是正常的上层调紧邻下层提供的接口。不允许跨层跳跃应用层不能直接调 MCAL更不能直接操作寄存器。这类代码一旦出现换芯片时基本没法自动化处理。存在一条黄线极少数性能敏感的场景典型就是 CDD允许绕过一层但要有明确理由并做过风险评估。水平方向服务层允许横向调用。例如 Dem 要存故障记录时会横着调 NvM。ECU 抽象层允许横向调用。MCAL严格禁止。CAN 驱动不能去调 SPI 或 PORT 驱动的函数硬件之间的依赖协调必须由上层的配置或模块完成。这条也很好理解——MCAL 是芯片驱动一旦互相调用依赖关系会变成一团乱麻芯片厂也没法单独替换某个驱动。4. 多核、分区与安全隔离4.1 多核与 Master/Satellite芯片往多核走Infineon AURIX TC399/TC499 这类之后CP 也扩展了多核支持分布式 BSWCanIf、Dio 这类模块可以在多个核上各跑一份实例。Master/Satellite通信栈Com和状态管理EcuM通常采用主从结构。Master 跑在主核Core 0掌握全局状态、负责仲裁Satellite 跑在辅核只收集本核的请求通过 IOCInter-OS-Application Communication与 Master 通信。IOC 是 OS 提供的跨核通信机制本身不是 BSW 模块。4.2 内存分区防止一个模块越界写指针把整个系统带走靠的是芯片的 MPU内存保护单元AUTOSAR 把它用 OS-Application 的形式管起来Trusted Partition受信任分区不受 MPU 限制可以直接访问硬件和任意内存。BSW 默认放在这里。Non-Trusted Partition非受信任分区受 MPU 监控只能访问自己分区内的内存。应用 SWC 一般放在这类分区里。需要注意的是分区是资源和权限的概念不是“一个 SWC 一个分区”。具体怎么切由项目按安全等级和耦合程度决定。4.3 混合关键度同一颗 ECU 上同时跑 ASIL-D如制动控制和 QM如空调调节是常见情况前提是两者之间做到互不干扰Freedom From Interference隔离具体要管三件事内存不能互踩、CPU 时间不能被对方抢占、外设不能被对方改配置。看门狗是很典型的例子。WdgM、WdgIf 和 Wdg 驱动被单独放进 ASIL 分区这样即使 QM 侧的以太网栈因为内存非法访问崩掉看门狗栈仍然跑得动还能把 ECU 复位拉回来。反过来如果看门狗和 QM 代码混在一个分区里前者就救不了后者。5. 软件集群5.1 为什么要拆传统 CP 镜像是单体编译的改一行 SWC 代码整颗 ECU 就要重新编译、链接、全量刷写。放到 OTA 场景里这没法接受。AUTOSAR 在新版本里引入了软件集群CP Software Clusters把镜像拆成两块Host Software Cluster宿主集群大部分 BSW、OS 和驱动与硬件绑得最紧通常不频繁更新。Application Software Cluster应用集群应用 SWC 加一小截局部 RTE可以独立编译、独立生成镜像单独做 OTA 升级Host 侧不动。5.2 SwCluC 与代理机制跨镜像调用靠 Software Cluster ConnectionSwCluCBinary ManifestBManif集群二进制对象的接口描述里面是导出的函数指针表、内存映射地址等元数据。代理Proxy机制代理模块的作用是顶替应用集群里不存在的 BSW 模块分成两半——High Proxy位于 Application Cluster对外提供被顶替模块的接口把应用侧的调用接住Low Proxy位于 Host Cluster拿到请求后真正去调用底层的 BSW 模块。对调用方来说这个替换是透明的应用代码里写的还是原来那个 BSW 模块的 API 名High Proxy 只是把调用重定向过去。6. 开发方法学与规范索引6.1 工具链流程CP 的开发流程高度依赖工具链输入输出基本全是 ARXML每一步做的事System Description系统描述整车视角的系统描述所有 SWC、拓扑、信号和端口连接都在这里。System Extract of System Description按 ECU 切出来的系统描述视图。ECU ExtractECU 抽取文件单颗 ECU 的视图OEM 把它交给 Tier-1 作为开发输入。ECU ConfigurationECU 配置用 DaVinci、EB tresos 这类工具把 Can、Com、NvM、OS 等模块的参数配完。Generated Code生成代码生成Rte.c、Com_Cfg.c、Os_Cfg.c等代码和手写代码一起编译成镜像。第 2 步和第 3 步经常被混淆System Extract 是给 Tier-1 的视图ECU Extract 是单颗 ECU 的视图两者不是同一份文件。6.2 规范从哪份开始看AUTOSAR 的规范文档很多翻的时候按这张图找![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传]思路是先在总览规范里定位模块属于哪一层、和谁交互再去对应模块的 SWS 里查 API 和配置参数。两边描述对不上时以 SWS 为准——总览文档里的图偏示意SWS 才是可实现的细节。7. 常见问题Q1为什么 CDD 不能随便跨核去调 BSW 的函数BSW 内部那些 C 函数标准接口通常不是完全可重入的而且默认自己在同一个核上跑。辅核上的 CDD 如果直接调主核 BSW 的内部函数会撞上多核并发竞态严重时直接内存访问违例。CDD 在辅核上要访问 BSW得经 RTE 的端口走由 IOC 处理跨核同步。Q2AUTOSAR 接口和标准化 AUTOSAR 接口为什么要分开前者用于 SWC 之间的数据交换端口名和数据类型由工程师在 ARXML 里定义生成的 API 名跟着配置变如Rte_Write_DoorState_State后者是 SWC 访问 BSW 标准服务的入口API 名由规范固定如NvM_ReadBlock。分开的实际收益是换一家 BSW 供应商应用代码不用改。Q3VFB 和 RTE 代码差在哪VFB 是设计时的逻辑抽象一行 C 代码都没有RTE 是运行时的代码实体。配置工具把 SWC 映射到具体 ECU 之后RTE 生成器负责把虚拟连接翻译成真实的内存写操作、指针传递或 COM 调用——VFB 在这个阶段就被消解掉了。小结把上面这些收一下平时最常用到的是四点分层先记一句话上层只能调紧邻下层MCAL 内部不许横向调。接口看名字来源Rte_*是配置生成物其他“模块_动作”形式的 API 名基本都是规范固定的。CDD 是口子不是常规手段用它换来实时性和非标硬件支持代价是这块代码不可移植。多核和分区先想清楚谁和谁不能混状态管理走 Master/Satellite安全等级不同的代码靠分区隔开。架构本身不复杂真正花时间的是每个模块的职责边界和配置参数那部分只能对着 SWS 一份一份啃。