3.2 诊断栈

3.2 诊断栈

本节摘要：诊断栈把分散的物理异常升维成统一故障语义。诊断通信管理器对外说统一诊断服务语言，诊断事件管理器对内管事件状态机和故障码，功能抑制管理器决定故障后哪些功能还允许跑。读完应能走通“检测 → 确认 → 存储 → 抑制 → 售后读取”这条链，并理解诊断为何进入功能安全监控，而不只是修车工具。

本节导航

阅读完本节，你应当能够：

1. 区分 DCM、DEM、FIM 三个角色。
2. 把一次电流采样异常映射到事件、故障码和抑制。
3. 说明老化、确认、待定等状态不是装饰字段。
4. 指出诊断覆盖盲区如何变成召回风险。

一、诊断不是读码器附件

有行业白皮书指出：因软件缺陷引发的召回里，相当比例可追溯到诊断覆盖盲区或响应延迟。比例会随样本变，方向稳定——诊断已经从售后便利变成运行时监控支柱。高等级功能安全要求系统能检测、隔离、把故障写入可追溯记录。没有诊断栈，安全机制缺少“被看见”的通道。

传统嵌入式里诊断常被简化成能读码、能清码、能刷写。Classic 里这三件事仍然在，但内核换成了统一故障语义空间。电机控制看到相电流偏离模型，ADC 驱动报参考电压漂移，电源模块记录到瞬态跌落——三份原始告警若不对齐，工程师面对的是三种方言。诊断事件管理器把它们收成同一个事件标识，带时间戳、快照和抑制状态。售后用读故障码服务看到的，是这条升维后的语义，而不是三份寄存器日志。

二、三个模块如何分工

诊断通信管理器面向总线和诊断仪。它实现统一诊断服务的会话、安全访问、读标识、读故障码、例程控制、刷写相关服务等。它不负责判断电机是否真的坏了，它负责把请求路由到正确的数据或例程，并维持协议状态机。会话切换错误、安全种子密钥失败，首先是 DCM 的事。

诊断事件管理器面向内部健康。每个事件有检测条件、去抖或确认计数、老化计数、与故障码的映射。状态从预失败到失败再到通过，不是布尔开关。待定、确认、警告灯请求这些位，决定仪表怎么亮、售后怎么解释“刚出现还是已确认”。快照冻结哪几个信号，决定半年后还能不能复现。

功能抑制管理器面向功能许可。某个事件失败后，哪些运行实体或功能组被禁止，应来自失效模式分析，而不是哪个工程师在应用里写了一句 if。应用在干活前询问“是否允许”，得到的是否，应能追溯到配置里的抑制矩阵。最小化干预：能降级就不要整机闭嘴，但该闭嘴时不能让应用自己投票。

存储栈会接住需要断电保存的故障计数和冻结帧。诊断栈决定“记什么”，存储栈决定“怎么在掉电后仍可信”。两者分工在评审里必须写清，否则会出现“RAM 里有码、下电全忘”或“Flash 被诊断写穿”。

三、一条请求的时空

诊断仪发读故障码，经传输协议进 DCM，DCM 向 DEM 查询状态位，再封装返回。看起来像一次事务，实际上可能打断正在跑的十毫秒控制任务。所以诊断服务的优先级、缓冲、是否允许在行车会话执行，必须配置，不能默认“工具一连什么都做”。刷写更极端：往往要进编程会话，停止正常通信组，看门狗策略切换。这些是模式管理和通信栈一起参与的协同，诊断栈是发起者之一，不是唯一操盘手。

事件确认策略直接影响误报。过敏感，路上警告灯常亮，用户不信任；过迟钝，真实故障赶不上安全机制。去抖次数、通过条件、是否需要连续多个周期正常才清除，都应来自安全分析和售后经验，而不是复制上一个项目的数字。

⚠️ 常见坑：在应用里私自解析诊断请求。安全访问、会话和权限会被绕开，整车诊断策略无法统一。
💡 关键直觉：诊断栈卖的是语义对齐。对齐失败时，三个模块各自正确，整车仍然不可修。

四、和通信、安全的交界

诊断走的物理路径仍是通信栈：同一套 PDU 路由、同一套传输协议。所以“诊断仪连不上”先别拆 DEM，先看网络管理是否唤醒、地址是否在路由表、传输层分块是否配错。安全访问和刷写签名属于信息安全叠加，见第 6.2 节。没有密钥体系时，诊断栈仍能读码，但不应能随便改写。

功能抑制与 RTE 的关系：许可检查应出现在功能入口，最好是生成或标准调用，而不是复制粘贴的全局变量。抑制一旦成为私货，安全案例里的“故障可隔离”就写不成。

麦肯锡报告里那个百分之四十一的召回追溯比例，提醒的是覆盖率：没设计成事件的异常，DEM 再完善也看不见。事件清单应来自危害分析和失效模式，而不是来自“我们实现了标准模块所以覆盖了”。模块是管道，清单才是内容。

物理异常 → 检测条件 → DEM 事件
                → 确认/老化 → 故障码与快照
                → FIM 许可 → 应用是否继续
                → DCM 服务 → 售后与产线
​

五、状态位、快照和刷写协同

统一诊断服务读故障码时，返回的状态掩码常常包含测试失败、待定、确认、警告灯请求等含义。待定表示刚刚检测到、尚未走完确认；确认表示达到了策略要求的失败次数；警告灯请求决定仪表怎么亮。把这些位当成“有码没码”的布尔，售后会无法解释“为什么灯亮了码却清不掉”或反过来。老化计数决定故障消失后还保留多久历史，对间歇性接触不良尤其重要。快照冻结哪些信号，决定半年后还能不能复现。快照太大写穿存储，太小没有线索，需要和存储栈一起定预算。

刷写是诊断栈最危险的协同。进入编程会话后，通常要停止部分通信组、改变看门狗策略、禁止行车相关运行实体。这些动作由模式管理和操作系统一起完成，诊断通信管理器是发起者之一。安全访问失败应保持旧系统可启动。签名校验属于信息安全叠加，见第 6.2 节。没有签名的刷写通道，在联网时代等于把执行器交给任意诊断仪。

事件清单必须来自危害分析和失效模式，而不是来自“我们集成了标准模块”。模块是管道，清单是内容。麦肯锡相关白皮书把召回里相当比例追溯到覆盖盲区，提醒的就是内容缺失。管道再标准，看不见的异常仍然看不见。

问题：灯亮了却读不到确认故障码，通常卡在哪？

常卡在待定与确认之间的策略：去抖次数还没到，或通过条件把状态清回，或读取的会话和掩码不对。把状态机当成布尔，售后只能说“有时候有码”。把待定、确认、老化、警告灯请求分开解释，才能和驾驶员描述对上。另一常见卡点是抑制已经生效但事件未确认：功能停了，码还在路上。这会表现为“车不对劲但工具说没码”。合同是：抑制矩阵与事件确认策略一起评审，不要两个团队各写各的阈值。

把一次相电流异常走成语义升维，是理解诊断栈的最短路径。物理层是采样偏离模型；驱动层可能报参考电压或通道失败；诊断事件层把它们收成同一个事件标识，走预失败、失败、通过；用户层是读故障码服务返回的状态掩码。升维失败时，三份原始告警会变成三种方言，工程师无法判断是同一故障的不同表征还是三件独立的事。升维成功时，快照和时间戳让半年后仍可能复现。复现能力是诊断栈对存储栈的依赖，也是对事件清单质量的依赖。清单若只有“通用故障”，升维只是把方言翻译成含糊的普通话。含糊的普通话不够修车，更不够写安全案例里的检测覆盖。覆盖要的是具体事件对应具体危害，而不是模块在位。

刷写协同是诊断栈最容易在项目后期爆炸的点。编程会话要停部分通信组、改看门狗、禁止行车运行实体。这些动作若只写在刷写工程师的笔记本里，模式管理和操作系统会在某次合并后忘记配合，于是出现刷写中复位、刷写后部分功能幽灵复活。幽灵复活可能绕过安全访问留下的权限假设。假设破裂是信息安全事件，也是功能安全事件。所以刷写剧本必须进描述和测试，而不是进个人经验。经验无法在构建时红灯。红灯只能来自：进入编程会话却仍有行车任务在跑，这类检查。检查需要跨模块可见的模式。可见性来自方法论，不来自英雄。
事件确认策略要同时服务误报和漏报。过敏感，警告灯常亮，用户关掉灯的信任；过迟钝，真实故障赶不上机制。去抖次数应从分析来，而不是从上个项目复制。复制会把上个项目的道路谱当成这个项目的道路谱。道路谱不同，阈值应不同。不同要被记录。记录在配置基线里，才能在召回时回答“当时为什么是这个数字”。回答不出数字来源的诊断栈，只是一个会读码的装饰。装饰通过不了把召回追溯到覆盖盲区的那种审计。审计要清单，清单要危害分析，分析要回到第 6 章的目标。目标不进事件表，检测覆盖是空集。空集很空，空得像标准模块都在、什么都看不见。

图：诊断语义升维

核心回顾

• 诊断是监控支柱：覆盖盲区会变成安全与召回问题。
• 三模块分工：协议、事件、抑制，不要让一个源文件全包。
• 状态机不是布尔：待定、确认、老化决定灯和维修策略。
• 抑制来自分析：不是应用临时 if。
• 连不上先查通信：DEM 健康不代表诊断仪能说话。
• 事件清单来自危害分析：标准模块不会自动长出覆盖率。

下一节存储栈讨论：这些故障码和校准值如何在掉电、复位、写穿风险里仍然可信。