2. AURIX诊断系统架构与核心组件

AURIX的“诊断”并不是单一模块,而是由芯片内部硬件自检子系统与外部软件诊断栈共同构成的两层体系。硬件层负责在运行中持续发现、记录并上报故障;软件层负责把硬件事件翻译成标准化的故障码,管理故障状态,响应诊断仪请求,并决定整车功能如何降级。理解这两层之间的接口与数据流,是后续做DEM配置、DCM服务和FIM功能抑制的前提。

一、芯片内部诊断子系统

AURIX内部与诊断直接相关的硬件资源主要有四类:SMU、LBIST、MBIST和ECC。

SMU(Safety Management Unit,安全管理单元)是片上安全事件的汇聚与响应中心。各安全机制(锁步核比较错误、ECC不可纠正错误、时钟/电压监控越限、看门狗超时等)产生的报警信号先进入SMU的报警节点,SMU再按配置的报警动作决定响应方式:仅置位状态标志、触发中断、拉低错误引脚、请求复位,或直接进入安全状态。SMU的关键配置对象是“报警→动作”的映射表,以及报警的使能/屏蔽位。开发中常见的做法是:把可恢复的报警映射为中断,让软件记录并降级;把不可恢复的报警映射为复位或错误引脚输出。

LBIST(Logic Built-In Self-Test,逻辑内建自检)针对CPU、总线和外设的逻辑电路,通过片上伪随机激励与签名压缩判断逻辑是否失效。它通常在启动阶段运行,也可在安全监控下周期性运行。LBIST的典型配置参数包括测试模式、种子、签名期望值和运行时长;结果通过SMU报警或专用状态寄存器上报。

MBIST(Memory Built-In Self-Test,存储器内建自检)针对SRAM、Flash等存储阵列,用算法图形(如March类算法)遍历存储单元,检测固定故障、耦合故障和地址译码故障。MBIST一般在启动时对关键RAM执行,也可在运行中对非关键RAM分块执行,以缩短启动时间。

ECC(Error Correcting Code,纠错码)是运行期最重要的在线检测手段。以常见的SECDED(单纠错双检错)为例:对32位数据附加7位校验位,可纠正1位错误、检测2位错误。当发生可纠正错误(CE)时,硬件自动纠错并置位状态位,软件应统计CE计数;当同一存储区域CE频繁出现,说明该单元存在劣化趋势,应提前记录并考虑降级。当发生不可纠正错误(UE)时,数据已不可信,必须通过SMU触发中断或复位,避免错误数据继续参与控制运算。

CE与UE的处理策略不同:CE以“计数+趋势监控”为主,UE以“立即响应+安全状态”为主。DEM中通常把CE配置为可自恢复故障,把UE配置为不可自恢复故障。

二、诊断软件栈的组成

软件侧的核心是AUTOSAR诊断栈,主要由MCAL、DEM、DCM、FIM四部分构成。

MCAL(Microcontroller Abstraction Layer)提供对上述硬件资源的底层访问:Fls/Fee驱动Flash与EEPROM仿真,FlsTst执行Flash测试,RamTst执行RAM测试,Wdg管理看门狗,Mcu/Port完成时钟与引脚配置,Dio/Adc采集外部状态。MCAL还负责把SMU报警、ECC状态等硬件事件通过回调或通知接口上报给上层。

DEM(Diagnostic Event Manager,诊断事件管理器)是故障管理的核心。它接收来自SWC、BSW和MCAL的事件上报,维护每个事件的“事件存储器条目”,包括状态字节(testFailed、testFailedThisOperationCycle、pendingDTC、confirmedDTC、testNotCompleted等)、老化计数器、故障确认阈值和快照数据。DEM还负责DTC的存储、清除和老化,并通过回调通知DCM和FIM。

DCM(Diagnostic Communication Manager,诊断通信管理器)负责与外部诊断仪交互。它解析UDS请求(如0x10会话控制、0x14清除DTC、0x19读取DTC信息、0x22读数据、0x2E写数据、0x31例程控制、0x27安全访问),调用DEM或应用回调完成操作,并组织响应。DCM还管理会话状态、安全等级和P2/P2*超时。

FIM(Function Inhibition Manager,功能抑制管理器)根据DEM中事件的当前状态,决定哪些功能或功能组被禁止。例如当“氧传感器电路故障”确认后,FIM可禁止闭环燃油控制功能,使系统进入开环降级模式。

三、组件之间的交互关系

四者的数据流可以概括为:硬件事件→MCAL→DEM→(DCM/FIM)。DEM是枢纽:向上为DCM提供DTC状态与快照,向下接收MCAL和SWC的事件;FIM从DEM读取事件状态,向应用功能输出抑制标志。DCM的0x14服务清除DTC时,会调用DEM清除接口,DEM再通知FIM解除抑制。

AURIX诊断系统架构与数据流 芯片内部诊断子系统(硬件层) SMU 报警汇聚/动作映射 LBIST 逻辑自检/签名 MBIST 存储阵列自检 ECC CE计数 / UE上报 Wdg/Clk 监控 报警/状态/中断 MCAL 微控制器抽象层 Fls / Fee / FlsTst / RamTst / Wdg / Mcu / Dio / Adc 事件上报 DEM 诊断事件管理器 事件状态字节 / 老化 / 确认阈值 / 快照 / DTC存储 testFailed · pendingDTC · confirmedDTC · 老化计数 DTC状态/快照 DCM UDS服务 0x10/0x14/0x19/0x22 事件状态 FIM 功能抑制管理器 按事件状态禁止/允许功能组 → 应用降级 0x14 清除DTC 外部诊断仪 UDS over CAN/DoIP 诊断请求/响应 硬件事件流 DTC/服务流 抑制控制流 外部诊断通信

四、一个典型故障的完整链路

以“SRAM某区域发生不可纠正ECC错误”为例,走一遍完整链路:硬件ECC检测到UE→置位状态并触发SMU报警→SMU按配置产生中断→MCAL中断服务程序读取状态寄存器,调用DEM接口上报事件→DEM将事件状态置为testFailed,达到确认阈值后置confirmedDTC,并保存快照(故障发生时的关键变量)→FIM读取该事件状态,禁止依赖该RAM区域的功能组→DCM在诊断仪发送0x19 02时返回该DTC及其状态字节。若诊断仪发送0x14清除,DEM清除DTC并通知FIM解除抑制,但若故障仍存在,下一个运行周期会再次置位。

这条链路说明:硬件负责“发现”,DEM负责“记忆与判定”,FIM负责“动作”,DCM负责“对外表达”。四者缺一不可,配置时也必须保持事件ID、DTC号、抑制功能组三者的一致映射。

五、配置要点与常见问题

实际工程中,最容易出问题的不是单个模块,而是模块之间的映射关系。建议在配置阶段建立一张“事件—DTC—抑制功能”对照表,逐条核对。常见问题包括:SMU报警未使能导致事件根本不上报;DEM确认阈值设置过小导致偶发故障被误确认;FIM抑制了安全相关功能却未定义恢复条件;DCM的0x14清除后FIM未及时解除抑制。这些问题都可以通过上面的数据流图逐段排查。

注意:CE计数达到阈值并不等于必须立即更换硬件,但应作为劣化趋势记录;UE则必须按安全概念立即响应,不能仅记录后继续运行。