3. T-Box软件架构与AUTOSAR集成

Continental T-Box 的软件架构并不是“把功能堆到一块 MCU 上”，而是围绕 AUTOSAR 的分层思想，把通信、诊断、网络管理、存储、OTA 与远程服务拆成可独立演进、可分别验证的组件。理解这套架构的关键，是分清 Classic 与 Adaptive 两类平台各自承担什么职责，以及 BSW、RTE、应用层之间的接口边界在哪里。

Classic 与 Adaptive 的分工

AUTOSAR Classic Platform（CP）面向深嵌入式实时控制，运行在 MCU 上，典型特征是静态配置、OSEK/VDX 操作系统、以 RTE 为中枢的 SWC 通信。T-Box 中与车辆实时性、低功耗、硬实时相关的部分——CAN/CAN-FD 收发、网络管理、诊断栈、存储栈、电源管理——通常落在 CP 侧。AUTOSAR Adaptive Platform（AP）面向高性能计算，运行在 MPU 上，典型特征是 POSIX 操作系统、面向服务的通信（SOME/IP）、动态进程管理。T-Box 中需要大算力、需要频繁升级、需要跑复杂协议栈的部分——OTA 客户端、远程服务代理、日志与数据管道——更适合放在 AP 侧。

两者不是替代关系，而是通过车载以太网或内部高速链路协作：CP 侧负责“车规实时与总线接入”，AP 侧负责“服务编排与升级”。在 Continental 的典型方案中，CP 侧 MCU 与 AP 侧 MPU 之间通过 SOME/IP 或共享内存 + IPC 交换数据，CP 侧把车辆信号、诊断结果、网络状态上报给 AP 侧，AP 侧把 OTA 任务、远程控制指令下发到 CP 侧执行。

BSW 与 RTE 配置要点

在 CP 侧，BSW 的配置通常由工具链（如 Continental 的 EB tresos 或类似配置工具）完成，输出 ARXML 描述文件，再由生成器产生代码。配置的核心对象包括：ECU 提取（ECU Extract）定义硬件资源与引脚映射；系统描述（System Description）定义 SWC 之间的连接与数据映射；BSW 模块配置定义各模块参数。RTE 生成时，需要明确每个 SWC 的 Runnable 触发方式（周期、事件、模式切换），以及 S/R（Sender/Receiver）和 C/S（Client/Server）端口的连接关系。

一个常见的配置错误是：车辆信号采集 SWC 的 Runnable 周期设为 10ms，但 CAN 信号实际更新周期为 100ms，导致 RTE 层产生大量无效调度。正确做法是根据信号实际更新率设置 Runnable 周期，或在 COM 层配置信号接收超时与更新标志，由 RTE 按事件触发。另一个关键点是 NvM 与 Fee 的块配置：需要为每个非易失数据块指定块 ID、长度、默认值、CRC 校验方式以及写保护策略。例如，OTA 升级状态块应配置为“写前校验 + 双备份”，防止升级过程中断电导致状态丢失。

诊断栈与网络管理

诊断栈由 DCM（诊断通信管理）、DEM（诊断事件管理）、FIM（功能抑制管理）和 DET（开发错误追踪）组成。DCM 负责 UDS 服务处理（0x10 会话控制、0x27 安全访问、0x2E 写数据、0x31 例程控制、0x34-0x37 传输）。在 T-Box 中，远程诊断请求从 TSP 下发到 AP 侧，再通过 SOME/IP 转发到 CP 侧 DCM，DCM 处理后经 CAN 发送到目标 ECU。DEM 负责故障码存储与老化，FIM 根据故障状态决定是否抑制某些功能。

网络管理采用 AUTOSAR Nm 与 ComM 配合：Nm 负责总线睡眠与唤醒协调，ComM 负责通信模式管理。T-Box 作为网关节点，需要在整车网络休眠时保持自身低功耗监听，收到唤醒帧后快速恢复通信。配置时需注意 Nm 的节点 ID、唤醒源映射以及 ComM 通道与 Nm 通道的对应关系。

存储栈与 OTA 组件

存储栈从下到上为 Fls（Flash 驱动）、Fee（Flash EEPROM 模拟）、Ea（EEPROM 抽象）、NvM（非易失存储管理）。NvM 提供块级读写接口，支持立即写、延迟写和写保护。OTA 组件在 AP 侧负责下载、校验、解包和升级编排，在 CP 侧负责 Bootloader 交互与 Flash 写入。典型流程是：AP 侧 OTA 客户端从 TSP 下载升级包，校验签名与 CRC 后写入 AP 侧持久化存储；对于 CP 侧固件，AP 侧通过诊断或专用接口通知 CP 侧进入 Bootloader 模式，由 Bootloader 完成 Flash 擦写与校验，最后复位并确认版本。

应用层与远程服务模块的接口划分

应用层与远程服务模块之间应通过明确定义的接口解耦。推荐做法是：远程服务模块只负责与 TSP 的协议交互（MQTT/HTTPS/WebSocket）、消息编解码、安全认证与重连管理；应用层负责业务逻辑（车辆状态聚合、远程控制鉴权、OTA 任务编排）。两者之间通过内部 API 或 SOME/IP 服务接口通信，接口数据模型使用 ARXML 或 IDL 定义，确保 CP 与 AP 两侧可独立生成代码。

例如，远程控制指令的接口可以定义为：远程服务模块收到 TSP 的“解锁”指令后，先做签名验证与权限检查，然后调用应用层的 RemoteControl_Execute(commandId, payload) 接口；应用层根据当前车辆状态（车速、挡位、电源模式）判断是否允许执行，再通过 RTE 调用 CP 侧的执行 SWC。执行结果通过回调或事件返回给远程服务模块，由其封装为 TSP 响应。这样，远程服务模块不直接操作车辆信号，应用层也不关心 TSP 协议细节，双方可以独立测试与升级。

整体来看，T-Box 的 AUTOSAR 集成不是一次性配置，而是随着车型配置、TSP 协议版本和 OTA 策略持续演进的过程。CP 侧保持稳定与实时，AP 侧保持灵活与可升级，两者通过清晰的接口边界协作，才能在满足车规要求的同时支撑远程服务的快速迭代。