自动驾驶系统ADAS中间件开发

接本公众号对自动驾驶系统软件架构设计的分析，本文将对自动驾驶域控制器的中间件开发展开介绍。中间件是连接底层硬件、操作系统与上层应用的关键软件层，其核心作用是实现系统模块间的高效协同、资源管理和数据流通，同时屏蔽硬件差异，确保系统的实时性、安全性和可扩展性。

自动驾驶域控制器的主控芯片包括SOC（System-on-Chip）与MCU（Microcontroller Unit），SoC多为异构多核架构（如CPU+GPU+NPU），主频高（GHz级），内存和存储资源丰富（GB级），支持高性能计算，如感知、规划、深度学习模块，通常需要处理高吞吐量、非实时或软实时任务，同时协调多核/异构计算单元（如任务卸载到GPU/NPU），支持动态资源分配。而MCU通常基于单核或简单多核架构（如Cortex-M/R系列），主频较低（百MHz级），内存和存储资源有限（KB~MB级），侧重实时性和低功耗。基于SOC芯片与MCU芯片的不同特点，其对应中间件的开发需求也存在很大差别。

 

 

添加图片注释，不超过 140 字（可选）

理想L9域控制器（双SOC+双MCU）

下面主要介绍MCU中间件的通信管理、诊断与错误管理两个功能模块。

1通信管理

在自动驾驶MCU中，AUTOSAR Classic Platform（CP）的通信管理模块是确保车辆控制指令、传感器数据及诊断信息高效可靠传输的核心。其设计需满足硬实时性、功能安全（ASIL-D）及资源高效利用要求。以下是其核心内容及工作机制：

通信管理架构

AUTOSAR CP的通信管理基于分层设计，主要包含以下模块：

a、MCAL（Microcontroller Abstraction Layer）：

硬件驱动抽象（CAN、LIN、SPI控制器配置）；

直接操作MCU寄存器（如STM32的FDCAN邮箱配置）。

b、 ECU抽象层（ECU Abstraction Layer）：提供统一接口（如CanIf模块管理CAN收发）。

c、服务层（Services Layer）：协议栈（CAN TP、UDS、J1939）；网络管理（NM）、诊断事件管理（DEM）。

d、RTE（Runtime Environment）：连接应用层（SWC）与底层通信服务。

 

 

添加图片注释，不超过 140 字（可选）

Autosar中间件通信管理

1.1核心通信机制

a、 通信协议栈

CAN/CAN FD通信：

• CanDrv：配置CAN控制器硬件参数（波特率、过滤器）。
• CanIf：提供收发API，管理硬件邮箱（Mailbox）与信号路由。
• CanTp：处理多帧传输（ISO-TP协议），分片长数据（如诊断日志）。
• 如刹车控制SWC通过CanIf_Transmit()发送刹车压力信号至CAN总线。

LIN通信：

• LinIf：管理主/从节点调度表（Schedule Table）。
• LinTp：支持诊断数据传输（如车窗位置反馈）。

FlexRay通信：

• FrIf：配置静态/动态段时隙，支持确定性通信。

b、信号路由与PDU处理

PDU Router（Protocol Data Unit Router）：

• 负责信号组包（Tx）与解包（Rx），处理不同通信通道间的数据转发。
• 信号网关（Signal Gateway）：

将CAN信号映射到LIN或FlexRay（如车速信号跨总线传输）。

• 信号组（Signal Group）：

将多个信号合并为单个PDU，减少总线负载（如组合刹车压力、轮速信号）。

c、实时性保障机制

静态配置：

• 通信矩阵（Communication Matrix）在编译时预定义（如CAN ID、信号周期）。
• 避免运行时动态分配资源（无动态内存操作）。

中断优先级管理：

• 高优先级中断处理关键信号（如紧急制动报文）。
• 配置CAN接收中断服务程序（ISR）快速响应。

截止时间监控：

• 使用Watchdog Manager（WdgM）监控任务执行时间，超时触发安全状态。
• 1.2 通信管理开发流程

a、通信矩阵设计：定义所有信号（CAN ID、信号长度、周期、发送方/接收方）。

b. 工具链配置

Vector工具链：

• DaVinci Configurator：配置CanIf、CanTp、DCM模块参数。
• CANoe：仿真总线行为，验证信号收发逻辑。

c. 代码生成与集成

RTE接口生成：

• 根据SWC端口定义，自动生成Rte_Brake_SWC_Read()等API。

静态代码优化：

• 禁用动态内存分配，使用预分配缓冲区（如CanTp的Tx/Rx Buffer）。

d. 测试与验证

单元测试：

• 使用CANoe模拟总线负载，测试最大信号吞吐量。
• 验证PDU分片重组逻辑（如发送100字节诊断数据）。

HIL测试：

• 在硬件在环台架中注入总线错误（如CAN Error Frame），验证容错机制。
• ms内接管。
• DEM记录刹车信号超范围DTC（如P0571）。

AUTOSAR CP中间件的通信管理通过标准化协议栈、静态资源配置及安全机制，为自动驾驶MCU提供了高可靠、低延迟的通信能力。其核心价值在于确保关键控制指令在严格时间内送达，模块化设计支持快速迭代与升级，同时满足车规级功能安全与信息安全要求。 在自动驾驶系统中，MCU的通信管理是保障车辆实时控制与安全冗余的基石，需与SoC中间件协同实现全栈智能化。

2诊断与错误管理

诊断与错误管理是保障功能安全（ISO 26262 ASIL-D）和系统可靠性的核心。AUTOSAR Classic Platform（CP）通过标准化模块（如DCM、DEM、FIM）实现故障检测、记录、响应及修复的闭环管理。

2.1诊断与错误管理架构

AUTOSAR CP的诊断系统分层设计如下：

层级	模块	功能
应用层	SWC（软件组件）	触发诊断事件（如传感器超限报警）
服务层	DCM、DEM、FIM、DET	诊断服务、故障存储、功能抑制、错误追踪
ECU抽象层	BSW（基础软件）	诊断通信协议栈（UDS、KWP2000）、网络管理
硬件层	MCAL（硬件驱动）	支持诊断接口（CAN/LIN收发器、调试接口）

2.2核心模块功能与机制

a.诊断通信管理（DCM，Diagnostic Communication Manager）

功能：处理外部诊断仪的请求，实现UDS（ISO 14229）服务。

核心服务：

• 会话控制（0x10）：切换诊断模式（默认模式、扩展诊断模式、编程模式）。
• 读取数据（0x22）：按DID（Data Identifier）读取标定值或状态（如读取车速信号DID=0xF1）。
• 写入数据（0x2E）：更新参数（如修改底盘系统标定阈值）。
• 故障码清除（0x14）：删除DEM中存储的DTC。

通信流程：

1. 诊断仪通过CAN总线发送请求帧（如0x22 F1 00）。
2. DCM解析请求，调用RTE接口读取SWC数据。
3. DCM组响应帧（如0x62 F1 00 45表示车速为69 km/h）并发送至总线。

b. 诊断事件管理（DEM，Diagnostic Event Manager）

功能：记录故障事件（DTC）及上下文数据，触发故障响应。

核心机制：

• DTC存储： 存储格式：包含故障码（如P0700）、状态（Active/Inactive）、发生次数、时间戳。

 

• 快照（Snapshot）：记录故障发生时的环境数据（如车速、电压、温度）。
• 扩展数据（Extended Data）：附加信息（如故障发生时的软件版本）。
• 老化机制：若故障未重复发生，DTC在一定周期后转为Inactive。

事件触发：

• SWC调用Dem_ReportErrorStatus()报告故障（Dem_SetEventStatus(P0700, DEM_EVENT_FAILED)）。
• DEM更新DTC状态，并触发关联响应（如通过FIM限制功能）。

c. 功能抑制管理（FIM，Function Inhibition Manager）

功能：在故障发生时限制或禁用特定功能，防止危险操作。

配置策略：

• 功能组（Function Group）：将多个SWC功能绑定为逻辑组（如“自动驾驶模式”）。
• 抑制条件：当DTC状态为Active时，禁止功能组执行。
• 示例：若雷达传感器故障（DTC=U0123），FIM禁用自适应巡航控制（ACC）功能。

d. 默认错误追踪（DET，Default Error Tracer）

• 功能：记录BSW模块的运行时错误（如API参数非法、资源耗尽）。
• 错误类型：
• 开发错误：API调用不符合规范（如传递空指针）。
• 运行时错误：硬件故障（CAN控制器BusOff）、内存溢出。
• 处理机制：记录错误码、模块ID及错误位置，触发系统复位或安全状态。

2.3诊断与错误管理流程

a. 故障检测与上报

SWC检测异常：

• 应用层算法检测到异常（如轮速信号超限）。
• 调用Dem_ReportErrorStatus(DEM_EVENT_ID, DEM_EVENT_FAILED)上报至DEM。

DEM记录DTC：

• 更新DTC状态为Active，存储快照及扩展数据。
• 触发关联事件（如通知FIM抑制功能）。

b. 故障响应与抑制

FIM执行抑制：

• 根据预配置规则，禁用相关功能（如ESP功能受限）。
• 通过RTE通知HMI显示故障灯（如ABS警告灯点亮）。

DCM响应诊断请求：

• 诊断仪读取DTC列表（服务0x19），获取故障详情。
• 工程师分析快照数据，定位故障原因（如传感器供电异常）。

c. 故障恢复与清除

修复与测试：

• 更换故障硬件或更新软件后，SWC检测恢复正常。
• 调用Dem_ReportErrorStatus(DEM_EVENT_ID, DEM_EVENT_PASSED)更新DTC状态。

DTC清除：

• 诊断仪发送0x14服务清除DTC，DEM重置故障状态。
• FIM解除功能抑制，系统恢复正常运行。

2.4开发与配置工具链

1. 需求定义：

• 使用Vector PREEvision定义DTC列表、FIM抑制规则及事件关联。

1. 模块配置：

• DaVinci Configurator配置DEM事件、DCM服务及FIM功能组。
• 示例：绑定DTC=U0123到FIM功能组“ACC”。

1. 代码生成：

• 工具链自动生成DCM服务处理代码、DEM事件表及FIM抑制逻辑。

1. 测试验证：

• CANoe模拟诊断仪发送UDS请求，验证DTC读写及清除功能。
• HIL测试台注入故障（如强制CAN总线错误），检查FIM抑制行为。

AUTOSAR CP中间件的诊断与错误管理通过标准化协议、故障闭环控制及安全抑制机制，为自动驾驶MCU提供了符合车规级功能安全的解决方案。MCU中间件的资源分配与调度、RTE接口生成与调用、存储管理、安全与加密、ECU状态管理与通用系统服务。

 

参考文献链接

自动驾驶系统中间件开发