4. 车身电子软件架构与AUTOSAR实践
车身电子控制单元（BCM、门模块、座椅模块、尾门模块等）的软件规模在过去十年里从几十KB膨胀到数MB，功能安全、诊断、网络管理与OTA升级同时压在同一颗MCU上。Continental在车身域的量产项目中普遍采用AUTOSAR Classic Platform作为软件骨架，把“与硬件强相关”和“与整车功能强相关”的代码彻底分开，使同一套应用逻辑可以跨不同MCU、不同OEM项目复用。理解这套骨架的关键，是看清BSW、RTE、SWC三层各自负责什么、边界在哪里，以及Continental在标准AUTOSAR之上又叠加了哪些集成约定。
三层结构：谁在管硬件，谁在管功能
最底层是BSW（Basic Software，基础软件）。它不实现任何车身功能，只提供“让上层能跑起来”的能力：微控制器抽象层（MCAL）直接操作寄存器、ADC、PWM、CAN控制器；ECU抽象层把外设差异封装成统一接口；服务层提供OS、通信栈（CanIf、CanTp、PduR、Com）、诊断栈（Dcm、Dem、FiM）、NvM存储管理和EcuM/BswM状态管理。BSW的绝大部分由Vector、Elektrobit等供应商以配置代码形式交付，Continental工程师的工作重点是配置而非手写。
最上层是SWC（Software Component，软件组件）。一个SWC就是一段有明确职责的功能代码，例如“左前门锁控制”“雨量传感器信号处理”“氛围灯颜色管理”。SWC不直接调用寄存器，也不直接调用CAN驱动，它只通过RTE提供的端口（Port）收发数据。SWC内部可以再分为应用SWC和传感器/执行器SWC，后者负责把物理量转成信号或把命令转成驱动请求。
夹在中间的是RTE（Runtime Environment，运行时环境）。RTE是AUTOSAR最核心的“胶水层”，由工具根据SWC之间的连接关系和到BSW的访问关系自动生成。它把SWC的Runnable（可运行实体）映射到OS Task，把Sender-Receiver端口映射为数据读写，把Client-Server端口映射为函数调用，把SWC到BSW的访问（如NvM读写、Dcm回调）映射为标准化接口。RTE的存在让SWC完全不知道对方是在同一MCU上还是通过CAN跨ECU通信。
RTE生成与SWC集成：从模型到可执行代码
在Continental的实际项目中，SWC通常先用DaVinci Developer或类似工具建模：定义Port、Interface、Runnable和内部行为，再导出ARXML描述文件。RTE生成器读取所有SWC的ARXML以及BSW配置，生成Rte.c/Rte.h，把每个Runnable挂到OS Task上，并生成端口读写函数。例如门锁控制SWC的Runnable被映射到10ms周期Task，RTE会生成Rte_Read_P_LockCmd()和Rte_Write_P_LedColor()这类接口，SWC代码里只调用这些函数，不出现任何CAN ID或寄存器地址。
Continental的集成方法有几个鲜明特点。第一，SWC命名强制使用CT_前缀（Continental），后接功能域缩写，如CT_BCM_DoorLock，便于在大型ARXML中快速检索和避免与供应商组件冲突。第二，RTE生成文件被标记为“生成物”，纳入版本控制但禁止手工修改，任何接口变更必须回到模型层重新生成，防止“代码与模型不一致”这类量产顽疾。第三，对于AUTOSAR标准未覆盖的外设（如特定LED驱动芯片、LIN从节点专用逻辑），采用CDD（Complex Device Driver）实现，CDD直接访问硬件但必须通过安全评审，且其接口对SWC保持与普通BSW一致的调用方式。
一个可复现的集成示例：门锁状态上报
假设需要实现“左前门锁状态通过CAN上报给网关”。按AUTOSAR分层，数据流如下：门锁硬件状态由DIO采集，经IoHwAb抽象为Dio_ReadChannel；一个传感器SWC以10ms周期读取该值，做去抖（连续3次相同才确认），通过Sender-Receiver端口P_LockState发出；RTE把该端口映射到Com信号；Com按配置的周期和CAN ID打包，经PduR→CanIf→Can驱动发出。整个链路中，应用SWC只关心“去抖后的布尔值”，不关心CAN ID是0x2A0还是0x3B1。
集成时需要检查的关键点包括：Runnable周期是否与Com发送周期匹配（避免信号更新慢于发送）、端口初始值是否合理（防止上电瞬间误报）、以及NvM写入是否在正确的Task上下文中执行（NvM通常不能在中断或高优先级Task中同步写）。Continental项目里常用一个集成检查表来逐项确认，例如：
| 检查项 | 典型值/要求 | 不通过的后果 |
|---|---|---|
| Runnable周期 vs Com发送周期 | Runnable ≤ 发送周期/2 | 信号跳变丢失，网关收到旧值 |
| 端口初始值 | 与默认物理状态一致 | 上电误报门锁状态 |
| NvM写入Task优先级 | 低于Com，高于背景 | 阻塞通信或写入失败 |
| CDD安全评审 | 必须有评审记录 | 功能安全审核不通过 |
| RTE生成版本与ARXML一致 | 哈希校验通过 | 接口错位，运行时异常 |
Continental特定组件集成：变体管理与跨项目复用
车身ECU往往一个硬件平台要覆盖多个OEM、多个车型配置。Continental的做法是在BSW配置层引入“项目变体”（Project Variant）：把CAN矩阵、诊断DID、NvM块布局等差异项做成配置参数，通过编译时宏或生成时选择来切换，而SWC层尽量保持二进制一致。这样，同一个CT_BCM_DoorLock组件可以不经修改地用于A平台和B平台，只需重新生成RTE和BSW配置。集成工程师的核心任务因此从“写代码”转向“管配置、验接口、跑集成测试”。
最后需要强调，AUTOSAR分层不是目的，而是手段。它的价值在于让车身功能开发与硬件解耦、让跨项目复用成为默认选项、让功能安全分析有清晰的边界。Continental在量产中积累的命名约定、生成物管理、CDD评审和变体配置方法，本质上都是围绕“让分层真正落地”这一目标。理解这些约定背后的工程动机，比记住分层名称更重要。