ISO15031 DTC

好久不更新了，本来像分享许飞的父亲的散文诗这首歌的，然而QQ音乐找不到原唱，还是算了。因为翻唱听不出鼻子一酸的味道。也许不久的将来，我也会成为某人的父亲，也会做这么一首诗，也会给自己两拳。

正文开始:

首先得先介绍两个诊断服务：来源ISO 15031-5协议

Service $07

作用：请求在当前或最后完成的驾驶周期中检测到与排放有关的诊断故障代码。

这个服务用来请求当前或者上一个驾驶周期中监测到的“待定故障码”。与service$03不同的的是，service $03用来请求“确认并激活的故障码”。如原文所说，用service $07读取到的故障并不意味着系统就存在故障，并且此时MIL灯处于非激活状态(偶发事件、干扰等)，如果在下一个驾驶循环再检测到故障，则意味着发生故障，并会激活MIL灯（故障指示器），同时DTC就会给设定，并且报给给service $03。

service $03

该服务的用来给外部设备读取确认激活的故障列表。注意是确认并激活得故障，但是实际上，$03也可以读取到“待定故障码”。

ISO 14229

这里从ISO14229的DTC定义开始：DTC状态掩码和DTC状态位定义。实际上柴油机的国六法规用的ISO27145-3定义的，这个作为后话了。

下列是用于DTC状态位定义描述一系列定义。

测试test：test是一个确定元件或系统故障状态的车载诊断软件算法. 某些测试只在操作循环运行一次。某些测试每个程序循环都运行，几毫秒就一次。（举个栗子：凸轮信号缺失故障，这个故障在上电不启动发动机的情况下，是不会检测到这个故障的。但是如温度传感器电压高这些故障，一上电就会被检测到。PS：栗子不知道举得是否合理，学习阶段，不妄下定论）。

测试结果Test results：指代一个完全成熟/有限的故障条件。这意味着在认定一个元件失效前，在特定时间内要求一个失效条件或评估附加的可行性检查的测试在所有成熟条件满足后返回一个“失效”条件。每一个测试都与一个专用DTC相关，该DTC体现了根源失效和可检测的故障症状。

完成：Complete表明了测试可以确定在当前操作循环中故障是否存在（complete 不会指示“失效”）。

测试结果：当测试运行或在其已完成后，将呈现下列其中一个结果给内部失效处理者。

_ 预失效：在ECU中使用该状态表明测试目前正在催熟一个失效条件。使用示例如：在字段保持容错性的同时其促进加速对优化工作流程的失效检测。

_ 失效：该状态在监控运行完成后是可用的，表明失效条件已完全成熟。

_ 通过：该状态在监控运行完成后是可用的，表明系统或元件未失效。

失效：失效是指元件或系统无法完成其要求的功能。若检测到故障条件时长足够证明挂起（只针对排放相关元件）或确认DTC存在，则失效已发生。挂起或确认DTC指明测试返回了一个“失效”结果。术语“失效”和“故障”两个概念可以互相交换。

监控：监控由一个或多个测试组成以确定元件或系统是否正常工作。

监控循环：监控循环是指监控运行至完成的时间区间。此为制造商定义的监控测试可运行时间区间。监控循环可在一个操作循环期间按执行几次。

操作循环：操作循环定义监控运行的开始和结束的条件。在一个操作循环期间，可能通过几个监控循环（不论其测试结果）。ECU可支持多个操作循环。对于车身和底盘ECU，制造商定义操作循环（如ECU上电至断电期间或点火打开或关闭时间）。对于动力系统ECU，操作的循环具有附加条件。排放相关ECU使用引擎运行或引擎关闭时间阶段定义操作循环，即指时间周期。

注：对于排放相关l监控，操控循环的开始和结束标准是法定的。

挂起：失效的挂起状态定义为：在当前或上一完成操作循环期间测试结果已报道为“失效”状态。对于操作循环完成的失效一旦测试报道为“通过”，则须复位挂起状态。

行驶周期：此为用于排放相关ECU的特别的操作循环。更多详情见“操作循环”。对于排放相关ECU，只有一个操作循环受支持，其等同于法定的行驶周期。

接下来介绍DTC的状态位。每个DTC（故障）相当于大小为一个字节的变量，一个字节八位，每位都代表不同的含义。

关于状态位直接贴图了，已经解释很清楚。

接下来还要介绍另外一个概念：故障消抖。这个概念三言两语说不清，这里只简单介绍。

如下图，fault leve称为故障水平，一般普通故障只分为两种状态，异常100%，正常0%。当系统监控模块监测到异常，fault level=100%，此时监控模块会将这个异常report到DSM模块，DSM模块进行故障消抖（debounce）。DSM模块被称为故障处理模块，还包括了OBD的功能实现，诊断接口实现。

简单说就是，DSM认为：监控抛出一个的异常必须并且这个异常持续一定时间才能认为这个异常属于故障。

但是并不是所有的故障都适合用持续一定时间来判断这个异常是否真的是故障的。比如接触不良之类的故障，这类故障的特点是断续，一会正常一会异常，持续时间短，因为很明显接触不良故障可能持续时间达不到系统要求的时间，而被DSM认为这个不是故障。很明显，这种判断方法存在缺陷。

解决办法是基于事件去抖：以异常的触发的次数达到一定值时，认为该异常属于故障。

接下来看一个ISO14229官方给的DTC状态位操作的示例：

该示例是关于关于排放相关OBD DTC两操作循环的DTC状态位操作的总述。图说明了排放相关OBD DTC两操作循环的DTC的处理情况。此处理方式可应用于非排放相关OBD DTC，可看作通用信息。

注：该示例中，当引擎开始时，OBD服务器开始操作循环。当下次引擎启动时，操作循环结束且下个操作循环开始。

解释一下：该图包括两个操作循环operation cycle。Test即是前面说得测试，这里可以认为是隔几百毫秒测试一次异常（故障）的状态。一般有200ms，也叫触发器。

FaultDetectionCounter：不懂翻译，为方便称为故障计数器吧，这个跟前面说的故障debounce 很像。

看到当FaultDetectionCounter累计到127时，testfailed=1，意味着测试报告了一个失效结果（故障），同时待定故障pendingDTC=1，confirmedDTC=0，MIL也未激活，testFailedThisOperationCycle=1并且直到下一个循环才会清0。

下一个操作循环，可以发现前面一小段FaultDetectionCounter已经累计到了127，但是TripCounter=1,pendingDTC还等于1， confirmedDTC也未激活,原因是testFailedThisOperationCycle=1，testFailedThisOperationCycle是用来表明当前操作循环期间DTC测试是否运行并已完成（或自上次调用诊断信息后当前操作循环期间是否已完成）逻辑1指明DTC当前操作循环期间测试未运行完成。显然测试未完成，那么就不会对该故障进行累计。（这很绕口，在OBD，MIL激活准则有很多种：如两个操作循环激活mIL、立即激活等）。当故障进入confirm状态，MIL状态一般也得同时激活。