3. AUTOSAR Classic Platform在车身域控制器中的落地

车身域控制器（Body Domain Controller，BDC）通常要同时处理车门锁、车窗、灯光、雨刮、座椅、无钥匙进入、LIN 从节点管理以及整车网络唤醒等任务。这类控制器对实时性要求不像动力域那样苛刻，但对功能数量、通信矩阵规模、休眠唤醒策略和诊断一致性要求极高。AUTOSAR Classic Platform（CP）之所以成为 Continental 等 Tier1 在车身域的主流软件平台，正是因为它用分层架构把“硬件相关”和“应用逻辑”解耦，让同一套应用软件可以在不同 MCU、不同收发器配置下复用。

一、三层结构：BSW、RTE、SWC 各管什么

AUTOSAR CP 的软件架构自上而下分为应用层、运行时环境（RTE）和基础软件层（BSW）。应用层由若干软件组件（SWC）构成，SWC 只描述“我要什么数据、我提供什么数据、我什么时候被调用”，不关心数据来自 CAN 还是 LIN，也不关心引脚电平。RTE 是虚拟功能总线（VFB）在具体 ECU 上的实现，负责把 SWC 之间的端口连接翻译成实际的函数调用或数据拷贝。BSW 则进一步分为服务层、ECU 抽象层和微控制器抽象层（MCAL），向下直接操作寄存器、收发器、驱动芯片。

在车身域中，一个典型 SWC 是“车门状态管理”。它通过 S/R 端口接收来自 COM 的 DoorLockStatus，通过 C/S 端口调用 SetWindowPosition()，再通过 P-Port 向诊断事件管理器上报 DEM_EVENT_DOOR_OPEN。这些端口在 RTE 生成阶段被绑定到具体信号，SWC 代码里看不到 CAN ID，也看不到 LIN 调度表。

二、方法论：从 ARXML 到可执行代码

AUTOSAR 的落地不是“写代码”，而是“配置生成”。整个流程围绕 ARXML 描述文件展开：系统描述（System Description）定义 ECU 之间的通信矩阵和拓扑；ECU 提取（ECU Extract）把与本 ECU 相关的部分抽取出来；ECU 配置描述（ECU Configuration Description）补充 BSW 的具体参数，如 CAN 波特率、PDU 周期、NvM 块大小、DEM 事件优先级。工具链（如 Continental 常用的 Elektrobit Tresos、Vector DaVinci Configurator）读取这些 ARXML，生成 RTE 代码、BSW 配置代码和 MCAL 初始化代码。

以车门锁信号为例，系统描述中定义 DoorLockStatus 为 1 字节信号，周期 20 ms，从 BCM 发送到 BDC。ECU 提取后，在 BDC 侧生成接收 PDU 和 COM 信号配置。RTE 生成器根据 SWC 的 S/R 端口，生成 Rte_Read_DoorLockStatus() 函数。SWC 的 Runnable 在 10 ms 任务中被调用，读取该信号并判断锁状态。整个过程没有手写 CAN 收发代码，所有映射由工具链保证一致性。

三、Continental 工程实践约束

在 Continental 的车身域项目中，AUTOSAR 落地通常伴随若干硬性约束。第一，MCAL 和复杂驱动（CDD）必须通过 ISO 26262 功能安全认证，ASIL-B 及以上模块需要独立的看门狗和内存保护。第二，BSW 配置必须支持多核分区，车身域控制器常采用双核锁步 MCU，COM 和 DCM 运行在核 0，应用 SWC 运行在核 1，核间通信通过 RTE 的跨核端口或共享内存实现。第三，休眠唤醒策略必须与 EcuM、ComM、CanSM 的状态机严格对齐，任何 SWC 不得直接操作收发器使能引脚，必须通过 IoHwAb 和 BswM 的规则表。

四、一个可参考的配置片段

下面是一个 COM 信号配置的示例片段（基于 ARXML 导出后的参数表），用于说明车身域中车门锁信号的典型参数。这些数值属于教学示例，实际项目需根据通信矩阵和 OEM 规范确定。

Signal: DoorLockStatus
  Length: 1 byte
  TransferProperty: PENDING
  UpdateBit: 0
  Timeout: 100 ms
  InitValue: 0x00
  Filter: MASKED_NEW_EQUALS_X
  FilterMask: 0x03
  Notification: RTE_EVENT_DOOR_LOCK_CHANGED

PDU: BCM_Status_PDU
  Length: 8 bytes
  CanId: 0x2A0
  CycleTime: 20 ms
  ComTxMode: PERIODIC
  SignalMapping: DoorLockStatus @ bit 0..7

配置完成后，RTE 会生成 Rte_Read_DoorLockStatus() 和 Rte_Switch_DoorLockStatus() 等接口。SWC 的 Runnable 在 Rte_Runnable_DoorState_10ms() 中读取信号，判断 0x01 为解锁、0x02 为上锁、0x03 为故障。若 100 ms 内未收到更新，COM 会触发超时通知，SWC 将状态置为 DOOR_LOCK_UNKNOWN 并上报 DEM 事件。

五、落地检查要点

• 端口方向一致性：S/R 端口的 sender/receiver 必须与系统描述中的信号方向一致，否则 RTE 生成报错。
• 任务映射：车身域常用 10 ms、20 ms、100 ms 三个周期任务，Runnable 必须映射到对应任务，避免高优先级任务被低优先级阻塞。
• NvM 块对齐：车门锁状态、座椅位置等需要掉电保存的数据，NvM 块大小必须与 Fee 扇区对齐，否则写入失败。
• 诊断事件优先级：DEM 事件优先级影响故障存储顺序，安全相关事件（如车门未关行驶）应设为高优先级。
• 休眠唤醒验证：用 CANoe 或示波器观察收发器使能引脚和 MCU 电流，确认 EcuM 进入 Sleep 后电流低于 100 µA（示例目标值）。

总结来说，AUTOSAR CP 在车身域控制器的落地，核心是“配置驱动、分层解耦、工具链保证一致性”。BSW 负责硬件和通信，RTE 负责连接，SWC 负责业务逻辑。Continental 的工程约束进一步要求功能安全、多核分区和休眠唤醒的严格对齐。只有把 ARXML 配置、RTE 生成、任务映射和诊断事件管理串成闭环，才能让车身域控制器在量产项目中稳定运行。