📚 课程目录第3章软件架构与AUTOSAR

3. 软件架构与AUTOSAR

底盘域控项目在软件层面首先要回答一个问题：这套软件到底“长什么样”。制动、转向、悬架、驻车等功能被拆成多个软件组件后，它们运行在什么操作系统之上、通过什么接口通信、哪些部分由AUTOSAR标准提供、哪些部分必须自己实现，这些决定了后续集成与交付的难度。本节围绕分层结构、CP/AP选型、BSW配置以及RTE与SWC集成四条主线展开。

一、底盘域控软件分层结构

在AUTOSAR语境下，底盘域控软件通常自下而上分为：微控制器抽象层（MCAL）、ECU抽象层、服务层、RTE、应用层。MCAL直接操作芯片寄存器，把ADC、CAN、SPI、PWM、DIO等外设封装成统一接口；ECU抽象层把板上器件（如外部看门狗、驱动芯片、传感器接口）抽象为与具体引脚无关的模块；服务层提供操作系统（OS）、通信（ComM、PduR、CanIf）、诊断（Dcm、Dem）、存储（NvM）、模式管理（EcuM、BswM）等基础能力；RTE位于BSW与应用之间，是虚拟功能总线（VFB）的具体实现；应用层由若干SWC组成，承载控制算法与功能逻辑。

这种分层的价值在于“隔离变化”：芯片更换主要影响MCAL与ECU抽象层，通信矩阵调整主要影响通信栈与RTE，控制策略迭代只影响SWC。对底盘域控而言，功能安全等级高、通信实时性要求强，分层边界必须清晰，否则一个应用改动可能牵动底层配置，集成回归成本会迅速上升。

二、AUTOSAR CP与AP的选型判断

底盘域控中同时存在两类需求：一类是硬实时、周期确定、与执行器强绑定的控制回路，例如ABS/ESC的轮速采样与压力调节、EPS的力矩闭环；另一类是算力密集、数据吞吐大、需要灵活部署的功能，例如多传感器融合、域级协调控制、OTA升级管理。前者适合AUTOSAR Classic Platform（CP），后者更适合AUTOSAR Adaptive Platform（AP）。

选型不能只看“新不新”，而要看约束。CP基于OSEK OS，任务静态配置、优先级固定、运行时可预测，通信以CAN/CAN FD、FlexRay、LIN为主，SWC通过RTE以Runnable方式被周期或事件触发。AP基于POSIX操作系统，支持动态进程、面向服务通信（SOME/IP）、C++应用，适合以太网骨干与高算力SoC。实际项目中常见的是“CP+AP混合”：安全关键控制留在CP侧，融合与协调放在AP侧，两者通过网关或SOME/IP-CAN转换交互。

判断维度	倾向CP	倾向AP
实时性	硬实时、周期确定	软实时、允许抖动
通信方式	CAN/CAN FD、FlexRay	以太网、SOME/IP、DDS
部署方式	静态配置、编译期确定	动态进程、可在线更新
典型功能	ABS、EPS、EPB控制	融合、协调、OTA管理

三、BSW配置的关键动作

BSW配置不是“把工具跑一遍”，而是把整车通信矩阵、诊断规范、网络管理策略翻译成模块参数。以CAN通信为例，典型配置链路是：CanIf配置CAN控制器与硬件对象（HOH、HTH、HRH），CanIf配置收发PDU与邮箱映射，PduR配置路由关系，Com配置信号打包/解包与发送模式，最后ComM与BswM配置网络请求与状态切换。诊断侧则配置Dcm的服务表（如0x22读数据、0x2E写数据、0x31例程控制）与Dem的事件、故障码、去抖策略。

配置完成后必须做一致性检查：PDU长度与信号布局是否匹配、周期发送是否与任务调度对齐、诊断响应时间是否满足规范、NvM块与Dem存储是否冲突。这些检查如果留到集成阶段才发现，返工成本会成倍增加。

示例：某底盘域控CAN信号配置片段（示意）
ComSignal: VehSpd
  BitPosition = 0
  BitSize     = 16
  Factor      = 0.01
  Offset      = 0
  Unit        = km/h
  UpdateBit   = 1
ComIPdu: ESP_Status_0x1A0
  DLC         = 8
  CycleTime   = 20 ms
  TxMode      = PERIODIC

四、RTE与SWC集成方法

SWC是功能的最小可复用单元，它通过端口（Port）与外界交互：发送端口（P-Port）提供数据或服务，接收端口（R-Port）消费数据或服务，接口可以是Sender-Receiver（数据）或Client-Server（服务）。RTE负责把这些端口映射到具体通信路径：同一ECU内的SWC间通信走RTE内部队列或直接调用，跨ECU通信则映射到Com信号或SOME/IP服务。

集成时的核心动作是“先定接口、再定调度、后做联调”。接口定义阶段要明确数据类型、初值、超时与更新策略；调度阶段要把Runnable绑定到OS Task，确定触发方式（周期、数据接收事件、模式切换）与执行顺序；联调阶段则通过RTE事件、Com信号、诊断DID观察数据是否按预期流动。底盘域控中，制动与转向SWC之间可能存在跨功能协调，此时接口的时序与失效处理必须提前约定，否则容易出现“单件正常、集成异常”的问题。

集成检查建议：每个SWC至少确认三件事——Runnable触发周期是否与信号更新周期匹配、R-Port数据超时是否有默认值或降级策略、跨ECU信号是否在Com层配置了正确的超时监控。

把上述四部分串起来看，底盘域控软件架构的本质是“用标准化的分层与接口，把安全关键控制、通信、诊断和可扩展功能解耦”。CP/AP选型决定运行基座，BSW配置决定基础能力是否可用，RTE与SWC集成决定功能能否真正跑通。三者任何一环配置不当，都会在集成或整车验证阶段暴露出来，因此架构设计阶段就必须把接口、时序和失效策略一并考虑清楚。