K5-01 OBD/UDS 诊断与故障码（DTC）设计

课程代码 K5-01 · 板块 K 控制、软件与标定 / 诊断与故障管理 时长 约 3.5 小时（7 讲） 前置 K1-01 热管理传感器信号处理与故障诊断；K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K5-01 大纲的完整展开版

---

引言：你读到一条码，然后呢

售后技师把诊断仪插上诊断口，读出一条故障码。这门课要讲的东西全在这一刻之后：他接下来该测哪一个点、动哪一个件、修完怎么确认真的修好了。三问里但凡有一问答不出来，这条码在设计侧看起来是「诊断覆盖率又多了一条」，在售后侧就是一条噪声——它把工时耗在翻码表上，最后以「查无故障」结账。

所以本课不把 DTC 当成检测的输出，而当成售后动作的索引。上游那一段前置课已经交完了：K1-01 热管理传感器信号处理与故障诊断 讲信号怎么被判成异常、怎么打置信度标签、怎么向控制侧发出降级请求，K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成 讲这些信号在总线上怎么走、跨节点的失效长什么样。交到本课手上的只剩两问——这件已经被发现的事，要不要变成一条码；变成码之后，它得带着什么证据、指向哪一个动作。

第一根钉子：一条 DTC 的价值不由「检测到了什么」决定，由「售后据它能不能做出一个正确动作」决定。把它落成可执行的形式，就是写码之前必须答的三问：① 谁读——法规年检、产线下线（EOL）工位、售后技师、远程车队、研发台架，几类读码方对同一条码的要求并不一样，动笔之前先说出它主要服务谁；② 读到什么证据——冻结帧加上故障前的趋势片段，够不够让技师把故障当时的工况重新复现出来；③ 据此做哪个动作——哪个可测点、哪个维修动作、修完怎么复验、要不要跑一遍重学例程。⚠ 「读码方」这一维、以及「谁读／读什么／约束来自哪」这三格，都是本课归纳出来的看法而不是既有条款，拿去用之前请按本项目的服务体系核一遍。三问里答不出任何一问的码，就是一条只会制造「查无故障」的码。这根钉子直接决定后面四件事的解法：码域归口与定位粒度（第 2 讲）、冻结帧字段拿什么当验收判据（第 6 讲）、故障通道与非故障策略通道怎么分工（第 6 讲）、以及要交付给售后的那两份东西（第 7 讲）。

第二根钉子：三层时间基不能压成一个计数器。去抖按诊断任务周期走，成熟确认按驾驶／操作循环走，老化自愈按老化（暖机）循环走——三层的单位不同、复位规则不同、承接的失效形态也不同：去抖抑制的是信号噪声与瞬态，成熟确认要的是跨循环复现，老化自愈只在「本循环未复现」时步进、一旦复现立即复位。压成一层的直接后果是故障一停就在同一次行驶里自愈，间歇故障根本留不到售后；而现场看到的表象是「用户一直投诉、一条码都读不到」，这个表象完全不像诊断问题，于是排查方向从第一步就错。这根钉子向两侧各延伸一条：向下接非易失存储——三个状态量与冻结帧必须跨点火周期保存，否则每次上电清零、故障永远成熟不了（第 6 讲）；向上接一条射程边界——这三层都是毫秒到秒量级的抗瞬态工具，周到月量级的慢变退化它们结构上接不住，参数也不可互相沿用（第 4 讲，那一类的方法体系归 K5-05 在役健康度与渐变衰减辨识：从车端信号到服务决策）。⚠ 顺带一句必须当堂交代的消歧：本课说的「老化」是故障码的成熟-自愈状态机，与部件的物理老化、与控制里的「老化补偿／自适应」毫无关系，只是恰好共用一个中文词，三者的分列在第 3 讲。

还有一句听起来最尽责、方向却是反的话，请从现在起把它换掉：「每一个检测到的失效都该配一条自己的 DTC——码报得越全，售后拿到的信息越多。」前半截确实是对的（检测到的东西确实更多了），后半截反了。售后读码的目的不是「知道发生了什么」，是「决定拆哪一个件、做哪一个动作」；一个码集的信息量不随条数增长，它随每条码能不能唯一指向一个动作增长。多加一条不能唯一定位的码不是加信息，是往索引里加一个指向模糊的条目，它会稀释整个码集，让本来指向明确的那几条更难被找到。⚠ 它的镜像误读同样要防：不能反过来把「少报码」当成美德，该报的也不报、全塞进内部标志位，那样售后连线索都没有。判据既不是多也不是少，是唯一定位。这一条会在第 2 讲从归口侧被正面点破，在第 6 讲从证据侧再讲一次，「常见误区」节里写成完整的三段式。

本课的射程要先划清，免得学完以为诊断设计到置位就结束了。本课只管「怎么发现」这一段：置了码不等于该点故障灯，点了灯不等于该限功率，三条判据链各自独立，而硬件已失效之后整车怎么降级归 K5-02 热管理故障处理与降级策略。阈值取什么数不在本课射程内——本课只讲判据的形式与定性权衡，取值、验证与复验归 K5-07 诊断与保护阈值的整定、验证与复验；几百条码汇成一个码集之后的去重、抑制矩阵与使能窗口归 K5-08 诊断使能窗口与故障抑制矩阵：多故障并发的根因仲裁；「所有电气诊断都正常、系统就是不制冷不散热」那一类失效的判据本体，按被诊断对象分头落在 K5-06 冷却液流量的在线估计与流量/内漏类故障诊断、K5-03 制冷剂泄漏检测与安全响应 与 K3-10 热管理在线状态与负荷估计：观测器整定、软测量置信度与退出条件；诊断数据的存储介质怎么选、掉电一致性怎么保归 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化。还有一条读法上的纪律：本课引用的几份标准，只写标准号与去向，不写条款内容与取值——服务的子功能编号、否定响应码取值表、定时参数默认值、DTC 状态位的位定义、具体码号与法规限值，本课一律不给，需要时请查现行版本，版次与年份也以现行目录为准。这条纪律第 1 讲会显式再说一次，因为它决定你把这门课当方法读还是当查表手册读。

七讲是一条链：第 1 讲把三个诊断体系的射程与服务对象分开；第 2 讲判一条诊断该报成哪一类码、粒度定在哪一层；第 3 讲把一条完整的置位链路建起来，三层时间基就在这一讲；第 4 讲落到具体的传感器与执行器上，把合理性检查与驱动电流窗口做成能置码的链，并点出两处不是靠调紧阈值能覆盖的结构性盲区；第 5 讲讲这套东西靠哪些 UDS 服务被读走、被强制、被重学，以及权限分级与收尾纪律；第 6 讲讲证据——冻结帧、扩展数据记录与两条提示通道的分工；第 7 讲收口到验证与售后交付闭环，两份交付物在这里。案例取压缩机指令转速与反馈转速长期偏差，它是两根钉子的合钉处：既要走一遍完整的置位链路，也要回答售后拿到这条码之后去测哪里、换什么、怎么复验。动手做把这四步串起来，收工判据只有一句——这条码是否已经可以交付售后。

第 1 讲　诊断体系总览：先答「谁读、读什么、约束来自哪」，再谈这条诊断归谁

一份热管理诊断需求评审，通常是从第二个问题开始的——「这条诊断的阈值取多少」。第一个问题被跳过了：这条诊断到底归哪个体系，它写出来的码将来是给谁读的。跳过它的代价不在评审当场，而在两三年后的售后工位：技师读出一条码，读不出该测哪里、该换什么，于是记一笔查无故障（NTF）。这一讲把这个被跳过的问题补回来，并且把它从一道「凭经验判断」的题，改成一道能当场填完、当场核对的题。

本讲交付五件：① 三个诊断体系（法规 OBD、UDS 厂内服务诊断、售后服务诊断）各自的射程与服务对象，以及判归属用的三格法；② 「纯电不用管 OBD」这条读法反在哪，跨动力形式复用诊断需求表时该逐格重判的是哪几格；③ DTC、MIL、限功率/跛行这三条链为什么必须分开设计；④ UDS 的四层结构，与「权限按层做、不按服务号逐个开」这条设计要求；⑤ 诊断报文层与传输层的两件事——寻址范围选错会在总线上出什么事，以及诊断超时该先分哪一层。

本讲不交付：DTC 编号体系与码域归口（第 2 讲）；使能条件、阈值、去抖与三层成熟机制的形式与权衡（第 3 讲，取值前指 K5-07 诊断与保护阈值的整定、验证与复验）；各 UDS 服务在热管理 ECU 上的具体用法、权限分级与作业纪律（第 5 讲）；冻结帧与扩展数据记录的字段设计（第 6 讲）。凡本讲写「见第 N 讲」或「前指某门课」的地方都是刻意的分工，不是漏讲。

1.1 判「这条诊断归谁」不靠贴来源标签，靠填三格——而 OBD 这一栏的射程由「影不影响排放控制的工作点」圈定

先把三个体系的定位摆开。

OBD-II 的历史定位是排放相关的车载监控。它的诊断项集合不是「车上重要的诊断」的集合，而是由一条判据圈出来的子集：这项失效会不会让排放控制偏离它设计的工作点。UDS（ISO 14229）是另一回事——它是厂内与售后用的通用诊断服务集合，本身不预设诊断对象，只提供读、写、例程与权限这几条通道。售后服务诊断则是「拿这套通道去做售后要做的事」的那一层用法，它的对象由服务需求定，不由法规定。

三者的关键差别不在技术先进性，在约束来源：OBD 项的存在与否、语义与可读性受法规与年检工具约束，改一项要走法规符合性；厂内诊断项由 OEM 自己定，改它只需要走内部变更流程。这条差别决定了混淆的代价是双向的——往法规 DTC 里塞大量非排放相关内容，会把法规诊断变成一个改不动的大杂烩，以后每改一条都要重走一遍符合性；反过来，把该进 OBD 的项只做成厂内诊断，那是符合性缺口，问题会在型式认证或年检环节才暴露。

⚠ 这条判据有两个易错点要当场钉死：① 把「重要」当成「排放相关」——高压绝缘故障很重要，但它不是排放相关，它有自己的归口（见第 2 讲）；② 把「法规要求车上有 OBD 接口」当成「所有码都要走 OBD 语义」——前者是通道要求（接口与通信可达），后者是内容要求（哪些项必须在里面、语义按公开定义），这是两件事。

判归属用三格，不用来源标签。（★ 三格法是本课归纳的判定形式，不是既有的标准判据。）「这条诊断是法规的还是厂内的」这种来源标签有一个结构性缺陷：它是互斥的，而现实里同一条诊断经常同时服务法规年检与售后技师。被迫二选一，就会做出「为了法规那一栏好看，把售后最需要的几个冻结帧字段删掉」这类决策——决策做完还看不出损失，损失兑现在售后。三格法把这道题从「选边」改成「填空」：

• 谁读——这条诊断产出的码，主要给哪一类或哪几类读者用；
• 读到什么——他读到的是码本身、还是码加冻结帧、还是再加一段扩展数据记录里的哪几个字段；
• 约束来自哪——法规符合性 / 内部规范 / 售后服务协议，可以并列多项。

三格允许一条诊断有多个读者，并且逼着设计者把每个读者的要求分别写下来。⛔ 三格里没有任何数量指标——本课不给「每类读者至少几条码」这种数，那种指标会立刻退化成凑数。

两个易错点：① 三格填完就收工，不接着答「据此做什么」——⚠ 那一问不在三格里，它属下面那组三问，正因为它在另一组，最容易被整条漏掉；这正是 NTF 的源头：知道谁读，却不知道他读完能做哪一个动作；② 把「研发台架」当成读者写进交付物——台架是验证方不是使用方，把它混进读者清单，会让码的字段设计偏向工程师想看的量，而不是技师复现故障要用的量。

读码方与使用场景全集（★ 整个全集是本课归纳的，共六类）。三格里的第一格「谁读」需要一个全集来对照，否则很容易只想到自己最熟的那一类，而漏掉的那几类不会以「少写一行」的形式暴露——它们会以「这条码到了那个场景就不可用」的形式暴露。六类各自的要求与本课的射程：

读码方	它对一条码的要求	本课射程
法规年检 / 在线监测	能被通用扫描工具读出，语义按公开定义	射程内只到归属判定（哪些项必须进法规 OBD）；具体条款与监控频率要求须按现行版本核，本课不复述
产线 EOL 工位	判定快、结果二值、作业期间不被无关码淹没	射程内只到服务层（第 5 讲讲的 0x85 与 0x28 正是为这一格准备的）；工位清单与节拍前指 K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理
售后技师	能唯一定位到一个可测点与一个维修动作	射程内，本课的主要服务对象
远程诊断 / 车队	能在没有车的情况下判断严重度	射程外，前指 K7-03 数据驱动的能效自学习控制 / K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算
研发 HIL 与标定	可注入、可复现、可回归	射程内只到「验收要验什么」，流程前指 K4-03 MIL/SIL/HIL 验证流程
索赔与质量分析	能与故障码—工时码—零件码对上	射程外，前指 M2-05 售后保修与在役失效数据分析：从索赔表读出真实故障率并反馈设计

这张表是本课第一根钉子的载体：一条 DTC 的价值不由「检测到了什么」决定，由「售后据它能不能做出一个正确动作」决定。这句话不是口号，它落成写码之前必须答的三问。⚠ 先分清一件事：三问与上面那三格不是同一组，只是前两项同名同义——三格判的是「这条诊断归哪个体系」（第三格是「约束来自哪」），三问判的是「这条码值不值得存在」（第三问是「据此做哪个动作」）。⛔ 把两者混成一件事的直接后果，就是三格填完就收工、第三问从来没有被问过——

① 谁读：上表六类里的哪一类或哪几类，写码之前必须先说出来； ② 读到什么证据：冻结帧加扩展数据记录，能不能让技师把故障当时的工况复现出来。⚠ 注意判据的主语是技师不是工程师，这条会在第 6 讲变成冻结帧字段的验收判据； ③ 据此做哪个动作：哪一个可测点、哪一个维修动作、修完怎么复验、要不要跑重学例程。这三样最终要落成第 7 讲的两份交付物。

三问里答不出任何一问的码，在设计侧看起来是「诊断覆盖率又多了一条」，在售后侧它就是噪声——它会稀释整个码集，让那几条真正指向明确的码更难被找到。

1.2 「纯电不用管 OBD」是把范围收窄读成了范围归零——混动与增程的发动机侧仍然全套适用

这句话在项目早期出现的频率很高，而它前半截是对的：纯电车没有内燃机排放监控对象，因此传统意义上「排放相关监控项」这一类在它上面确实明显收窄。反在后半截——收窄不是归零，而且这条结论只对纯电成立，不能推广到整条产品线。混动与增程车带着发动机，发动机侧的冷却、暖机与排放控制那一整套监控项一条不少。

它的代价不是写错一句话，是整块工作没人做：这条判断决定的是项目早期的工作量估计与符合性责任划分。热管理侧尤其容易踩——同一个平台的纯电版与增程版往往共用一套热管理域控软件，纯电版按「不用管」写出来的诊断需求表，搬到增程版上就缺了发动机冷却回路那几项。而这个缺口在软件层面看不出来：代码跑得通，码也报得出，只是该有的那几条从来没被要求过；它只在符合性审核或型式认证时才暴露。

两个方向的错都要防：

① 拿纯电版的诊断需求表直接复用到增程版——收窄掉的那几格没有逐格重判，直接照搬； ② 反过来，把发动机侧那套监控项原样搬到纯电的电池冷却回路上——两者机理不同，判据不可互套：发动机冷却回路的暖机温升模型建立在燃烧放热这个热源上，而电池冷却回路的热源形态、时间常数与目标温度窗口全都不一样，公式与门槛一条都不能沿用。

⛔ 纯电与混动各自必交的监控项清单由现行法规版本给出。本课不给清单、不给条款内容、不给限值与监控频率要求，只给「怎么判一项归不归它」的方法与去向。

1.3 DTC、MIL、限功率/跛行是三件独立的事：置了码不等于该点灯，点了灯不等于该限功率

DTC 是「发现并记录」的产物，本课的主线就在这一段。MIL（故障灯）是给驾驶员的提示，它的点亮条件是另一套判据——严重度、法规要求、是否需要立即停车，这三样与「有没有检测到异常」不是同一个问题。限功率与跛行是控制侧的降级动作，由降级策略决定，前指 K5-02 热管理故障处理与降级策略。三者的判据链各自独立，本课只管最前面那一段：怎么发现、要不要记成一条码。

三者绑死会产生两类都很难查的错。

把「置码即点灯」写死：任何一条厂内诊断码——包括那些只用来给标定工程师看的——都会点亮故障灯。用户回店，技师读出一条自己也说不出该修什么的码，结果是无故障返修；而下一次真故障点亮时，用户已经学会了不理它。

把「点灯即限功率」写死：一条只影响舒适性的码（例如座舱配风执行器的某个位置反馈异常）会引发动力受限，用户体验与行车安全两侧都受损，而这条因果链在代码里往往只是一行「有码则进跛行」。

正确的形式要求只有一条，但必须写进需求：每一条码都要显式声明它挂哪一档提示、挂哪一档降级。⛔ 严重度分级本身以及各级对应的提示与降级动作，是平台相关量与法规要求的叠加，本课不给分级表，只给这条形式要求。

两个易错点：

① 在诊断需求条目表里只写码位、不写「系统响应与降级挂接」这一列。于是降级由谁定没人负责，最后由写控制代码的人临时决定，而他手上并没有那条码的严重度信息。 ② 把「跛行」当成一个开关。它至少要区分三种时机：立即降、渐降、下一次上电后降。这三种对用户的观感与对行车安全的影响完全不同，写成一个布尔量，等于把这个决策删掉了。

本讲到「要不要报码」为止；报了之后控制怎么降级归 K5-02 热管理故障处理与降级策略，正常保护动作要不要升格成码见第 3 讲。

1.4 UDS 是分层的服务集合，不是一张平铺的服务清单——权限要按层设计，不能按服务号逐个开

把 UDS 读成一张「服务号—服务名」的平铺清单，是诊断设计里最常见的一种降维。它实际是分层的，四层的分工是：

• 会话控制（0x10 DiagnosticSessionControl）——切换诊断会话（默认会话、扩展会话、编程会话等），不同会话下可用的服务集不同。它回答的是「现在允许调什么」。
• 安全访问（0x27 SecurityAccess）——用种子-密钥把高风险服务锁起来，并且分级。它回答的是「你有没有资格调」。
• 例程控制（0x31 RoutineControl）——封装一段有始有终的动作：启动、查询进展、取结果。
• DID 读写（0x22 ReadDataByIdentifier / 0x2E WriteDataByIdentifier）——按标识符读数据、按标识符写数据。

还有一个不干活、但必须一起设计的服务：保活（0x3E TesterPresent）。诊断会话有超时，长例程执行过程中如果保活断了，ECU 会把会话踢回默认会话。现场表现是「例程跑一半自己退了」，而查的人往往先在例程逻辑里找了很久——因为看上去是例程失败，不像是会话没保住。

按层设计权限的价值在于扩展性：新增一个服务时，只需要判它属于哪一级，权限自然落位。按服务号逐个开权限则有两个结构性后果——每加一个服务都要重做一次风险评估；而且必然出现「两个同样危险的服务，权限等级不一样」这种不自洽，因为逐个开靠的是评审那一刻的注意力，不是一条规则。各服务在热管理 ECU 上的具体用法、分级怎么分、钥匙发给谁，是第 5 讲的事。

⛔ 本课在服务这一层只写服务号与服务名，以及它在热管理 ECU 上干什么。各服务的子功能编号、会话与服务的可用性矩阵、否定响应码取值表、DTC 状态位的位定义——这四类都属标准条款内容，本课未取原文，一律不写取值；用到时须查现行版本。

一个易错点值得单独点出来：把「进了扩展会话」当成「拿到了权限」。会话与安全访问是两件事——会话决定服务在不在菜单上，安全访问决定你按不按得动，两者都过了才叫可调用。把它们混成一件，写出来的权限设计会在某个会话下意外放行一批本该锁着的服务。

1.5 物理寻址与功能寻址不是两种接线方式，是两种提问范围

物理寻址是点对点问一个 ECU，功能寻址是广播式问一组 ECU。它们走同一根线、用同一套服务，差别只在这一问问的是谁。

诊断请求—响应报文的基本结构是「服务号 + 子功能或标识符 + 数据」。ECU 处理完之后有两种回法：肯定响应把服务号加上一个固定偏移回来；否定响应用一个固定的否定响应服务号，带上原服务号与一个否定响应码 NRC，明确说「我收到了，但我不做，理由是这个」。⛔ 偏移值与 NRC 的取值表属标准条款内容，本课未取原文，不写取值。

选错寻址方式的后果发生在总线层，不在诊断逻辑层，所以它是这一段里最费排查时间的一类。把需要逐个应答的请求发成功能寻址，一组 ECU 会同时开始回，总线上挤满同时到达的响应。现场表现是「用某台诊断仪能读、换一台就超时」——两台诊断仪的接收缓冲与重发策略不同，同样的响应风暴在一台上表现为丢帧、在另一台上表现为超时。查的人会先去怀疑诊断仪，而诊断仪没有问题。

两个易错点，第一个后果最大：

① 用功能寻址下发清码（0x14 ClearDiagnosticInformation）或关闭 DTC 记录（0x85 ControlDTCSetting）时，没想清楚它会作用到哪些 ECU。这两个恰恰是最常用功能寻址的服务——因为「全车清一遍」听起来正是要做的事——而它们的副作用也最大：清码会把别的域刚记下来的故障证据一起清掉；关闭 DTC 记录若作用范围超出预期，会有 ECU 带着抑制状态离开工位。这两条的作业纪律在第 5 讲写死。 ② 把否定响应当成「没收到」去重发。它不是丢帧，它是收到了并且明确拒绝了。重发只会得到同一个拒绝，而真正要做的是读那个 NRC 说的理由——权限不够、会话不对、前置条件不满足，三者的处置完全不同。

各 ECU 的诊断标识符分配与功能寻址组的划分属整车 EEA 设计，前指 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成；⛔ 本课不给标识符，也不给报文长度上限的取值。

1.6 按「一帧一服务」的心智模型设计诊断链路必然踩坑；而诊断超时该往哪儿看，要先分层

单帧装不下的请求或响应，要走分段传输（ISO 15765-2 / DoCAN）：首帧、连续帧，接收方用流控帧回一组参数（BS 与 STmin）告诉发送方一次可以连发几帧、帧间至少隔多久。分段与流控的主体归 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成，本课只要求记住一句话：多帧一定会发生。

哪些场景天然是多帧？读故障码列表、读冻结帧——这两个恰好是诊断的日常动作，也正是本课后面几讲要设计的东西。⛔ 一次读码能返回多少条、要不要分页，受报文承载、ECU 缓冲区与诊断描述文件三方约束，属项目约定，本课不给数；本课只给一条设计要求：读码与读冻结帧的时序不能按单帧估算。

另一件事必须与它分开：ECU 处理不完时可以回一个响应挂起（0x78），意思是「请你再等等」，它把等待上限从常规档延到延长档（对应 P2 与 P2* 两个定时参数）。⚠ 响应挂起与 P2 / P2* 属会话层（ISO 14229）；首帧、连续帧、流控帧与 BS / STmin 属传输层（ISO 15765-2）——这是两层，⛔ 别把定时问题都推给传输层。

为什么必须先分层：这两层的失效表象几乎一样，诊断仪上都显示超时；而排查方向完全相反——传输层问题去看流控参数与总线负载，会话层问题去看 ECU 的服务处理时间与它的挂起策略。分错层，整个排查方向从第一步就错，而且错得不容易察觉：往任一方向查都能查出一些「看起来不太对」的东西。

⛔ BS、STmin、P2、P2* 的取值属标准与项目双重约定，本课未取标准原文，一律不给数，只写参数名、它归哪一层、它管什么。以太网侧的对应承载（DoIP）本课不展开。

三个易错点：

① 冻结帧读取、DTC 列表读取这类天然长响应，设计时按单帧估算时序，到台架或工位上才发现超时设定不够，而那时诊断需求表已经冻结。 ② 把 0x78 当成故障——它是正常机制，ECU 正忙于其他任务时出现它完全正常。 ③ 反过来，把真超时当成 0x78 一直等下去——诊断仪侧必须有一个挂起次数上限，否则一次真故障会让工位停在那里空等。

1.7 发动机冷却回路那三项之所以必交，是因为它们影响暖机与排放控制的工作点——而三项的判据本体不在本课

前面几节讲的是判归属的方法。这一节给它一个可核对的落地例子：发动机冷却回路上有三项监控属排放相关、必须进法规 OBD，而不只是做成厂内诊断——

• 节温器合理性；
• 冷却液温度传感器的范围 / 合理性；
• 冷却系统性能监控。

顺着 1.1 那条判据走一遍，就能看出它们为什么在里面：这三项监控的对象都直接决定发动机多久到达、以及能否维持在排放控制设计的温度工作点。暖机慢了、水温稳不住，排放控制就工作在设计点之外——所以它们是排放相关，不是因为它们「重要」。举这三项的意义就在这里：让「归属判定」这个抽象动作有一个读者能自己走一遍的例子。

⚠ 但这三项的判据本体不在本课，分两处落：节温器合理性与冷却系统性能监控（温升速率模型与残差构造）前指 K5-06 冷却液流量的在线估计与流量/内漏类故障诊断；冷却液温度传感器的范围 / 合理性（范围与速率检查、消抖时间整定）前指 K1-01 热管理传感器信号处理与故障诊断。而 K5-06 冷却液流量的在线估计与流量/内漏类故障诊断 自己也把合理性检查的通用方法让回 K1-01 热管理传感器信号处理与故障诊断——三门课之间没有重复，这是刻意的分工。⛔ 三项各自的判定窗口、阈值与监控频率要求由现行法规与项目标定给出，本课不给。

两个易错点：① 把「这三项在法规里」记成「冷却回路的所有诊断都在法规里」——同一条回路上的水泵驱动电气诊断就不是，它是厂内诊断；② 在本课里试图把判据本体也讲一遍，结果同一件事在三门课各写一套、互相不一致，而读者不知道该信哪一套。

本课对标准的引用纪律，在这里显式声明一次（⛔ 而不是默默执行）。本课引用的标准按角色分七组（⛔ 组数不是文件数——其中两组各含两份互相对应的文件）：ISO 14229 提供服务框架与会话层定时的概念；ISO 15031 与 SAE J1979 提供 OBD 通信与码体系；ISO 15031-6 与 SAE J2012 提供 DTC 编号结构；ISO 15765-2 提供 CAN 上的分段传输；ISO 11898 是 CAN 本身；GB 18352.6 含 OBD 相关要求；GB/T 32960 体系只在第 6 讲讲遥测通道时出现一次，用来说明那条通道受另一套体系约束（本课只写体系名与去向，前指 K7-03 数据驱动的能效自学习控制）。

本课未取其中任何一份的原文。因此正文只写这几类框架信息与去向——服务号与服务名、字母域的语义、参数名归哪一层；⛔ 不写子功能编号、否定响应码取值、定时参数默认值、DTC 状态位的位定义、具体码号、法规限值与监控频率要求。标准的版次与实施日期同样不单值化：写法是写标准号，并加一句「版次与年份以现行目录为准，引用前须核」。

这条纪律的价值在于它对读者说清了一件事：这门课给的是方法，不是查表手册。需要取值的时候去查现行版本，而不是照抄讲义。⚠ 两种破坏它的方式要一起防：① 把某本手册或某篇文章里的转述值当成标准值写进设计文档——转述层既没有版本号，也没有射程；② 跨射程引用——例如拿传输层标准的参数去解释会话层的定时问题，1.6 点破的正是这一形态。