AUTOSAR DEM （二）:DTC

在章节一中提到了事件对应的DTC的状态变化。DTC是一种用来记录当某ECU发生或检测到某种故障时所呈现在大家目前的标识码，通过DTC便可以查表的方式获得该故障信息，如故障触发条件、故障解除条件、系统功能表现等。
在ISO-15031-6这个标准中规定了dtc的基本组成，DTC如何命名等信息。

DTC与故障事件

DTC（Diagnostic Trouble Code）：

• 定义：DTC是一种标准化的诊断故障码，用于识别和报告车辆或系统中的故障。每个DTC都有一个唯一的标识符，表示特定的故障类型。
• 功能：DTC用于诊断系统中的故障，并提供关于故障的信息，如故障类型、严重程度、发生条件等。DTC可以通过诊断工具或故障指示灯等方式进行读取和显示。

故障事件（Fault Event）

• 定义：故障事件是指系统中发生的故障或错误事件。它可以是由硬件故障、软件错误、传感器故障等引起的异常情况。
• 功能：故障事件用于通知系统中的其他模块或外部设备发生了故障或错误。它可以触发相关的故障处理流程，如生成DTC、记录故障信息、通知用户等。

两者区别和联系

• DTC是一种标准化的故障码，用于诊断和报告故障。它提供了关于故障类型和属性的信息。
• 故障事件是指系统中发生的故障或错误事件，它可以触发相关的故障处理流程。
• DTC通常与故障事件相关联。当发生故障事件时，DEM模块可以生成相应的DTC，并将其报告给其他模块或外部设备。
• DTC可以用于故障诊断和故障排查，而故障事件可以用于故障处理和故障通知。
• DTC是某类故障的统称，能够大体定位到某个模块的故障，而event则是故障监控的基本单元，能够定位某个模块中的某个具体故障；
• 多个event可以mapping 同一个DTC；而同一个event不能mapping 多个DTC；
• DTC可以直接可见，但Event需通过进一步手段才能看到，有时仅对ECU供应商可见；
• DTC代表某类event集中表现，而event则是某个DTC的具体实例；
• event的优先级决定了DTC的优先级；
• event之间的依赖关系决定了DTC的依赖关系；
• DTC的状态位是其map的所有event的状态位的或集；

以下是一个示意图，展示了DTC和故障事件之间的关系：

+------------------+               +-----------------+
|    DTC           |               |  故障事件        |
|                  |               |                 |
| - 唯一标识符       |               | - 发生条件       |
| - 故障类型        |               | - 故障处理流程    |
| - 严重程度        |               | - 通知其他模块    |
| - 发生条件        |               | - 生成DTC        |
|                  |               |                 |
+------------------+               +-----------------+

需要注意的是，具体的DTC和故障事件的定义和属性可以根据系统设计和应用需求进行配置和扩展。在实际应用中，需要根据具体情况进行选择和配置，以满足系统的故障诊断和处理要求。

DTC基本组成

ISO 14229-1的故障诊断码格式规定，故障码信息由四字节组成

DTCHighByte，DTCMiddleByte，DTCLowByte表示服务中的故障诊断码，是高16位、中8位，和DTC code & 0xFF生成的；
StatusOfDTC表示故障码状态。
DTCHighByte，DTCMiddleByte两字节表示故障内码，对应5位标准故障码

第1位是字母，后面4位是数字，如P0120
第一位字母表示故障所属系统，我们把汽车系统分为四大类。分别是动力，底盘，车身，网络通信，分别用PCBU表示。

第二位数字是0、1、2或3表示故障类型，意义如下：“0”代表SAE(美国汽车工程师协会)定义的通用故障码；“1”代表汽车厂家定义的扩展故障码；“2”或“3”表示预留故障码 。

第三位字符表示故障所属的子系统。
最后两位数字表示具体故障对象和类型。
DTCLowByte描述故障种类和子类型，该部分内容描述需遵循ISO 15031-6。对于不需要该字节信息的DTC，该字节填充为0x00。

DTC状态掩码

基础概念

1. Test：在线诊断算法，该算法决定系统的故障状态。一个算法对应于一个唯一DTC，非连续性测试在一个监控周期内仅运行一次，连续测试在每次循环中进行调用，可以是毫秒级的；
2. Failure：系统不能满足功能，则为一个故障。
3. Monitor：可以是一个test也可由多个test组成，用于决定系统故障状态；
4. Monitoring cycle：由设备制造商定义，在这个周期下Test可以运行。当然制造商也可定义其它的周期，只要这个定义满足法规要求；
5. Complete：在当前监控周期内，test决定是否有故障存在的一种指示。(不仅指failed)；
6. Operation Cycle：操作循环定义了从监控运行的开始和结束条件。一个操作循环内，监控循环可能运行多次；一个ECU可能支持多个操作循环；对于车身、底盘相关ECU，由制造商定义一个操作循环（如power up到power down或ignition on到ignition off）；排放相关的ECU使用engine-running or engine-off时间周期来定义一个操作循环（也称作driving cycle)，其由法规来定义
7. Pending：Failure的pending状态定义为：在当前操作循环或上一个完成的操作循环内，测试结果为"Failed"; 一旦该故障在一个完整操作循环内测试结果为"Passed"， 则复位；
8. Aging Threshold：老化阈值，测试未报Failed的操作循环次数；满足某个标准，如warm-up cycles, 老化计数器开始计数，达到阈值后将DTC从non-volatile内存中清除，confirmed位从1变为0；
   DTC状态位定义

bit	DTC状态	描述
0	TestFailed	最近执行测试的结果，Failed则置"1"；最近测试通过(pass)或发送清故障码（14）服务则置"0"。
1	TestFailedThisOperationCycle	在当前操作循环内的测试结果，该操作循环内只要发生过Failed，则置"1"; 开始新的操作循环或发送清故障码服务后，置"0";
2	PendingDTC	在当前操作循环或上一个完成的操作循环内，测试是否报告过"Failed"; 该状态位只在测试运行和操作循环完成且在该操作循环内从未"Failed"过或发送清故障码（14）服务后才置0；如果在当前操作循环内未完成测试，则状态不变。例如,若设定确认DTC后监测程序停止运行,则pendingDTC(待定DTC)须保持为’1’。对于OBDDTC,在第一个行驶循环检测到故障后,需将其保存为待定DTC。
3	ConfirmedDTC	表示故障是否检测到了足够的故障次数让DTC存储到long-term memory，若足够，则置"1"; 其为1的时候并不意味着此刻故障存在；发送清除故障码或达到老化阈值则置"0";
4	TestNotCompletedSinceLastClear	表示一个DTC测试从上次清故障码开始，是否运行过或完成过测试；若没有，则置"1";否则置"0"；清故障码置"1";
5	TestFailedSinceLastClear	表示一个DTC测试从上次清故障码开始，是否测试失败过；若没有，则置"0"；否则置"1"；清故障码置"0";
6	TestNotCompletedThisOperationCycle	表示一个DTC测试在当前操作循环内是否运行完成；若没完成，置"1"；否则，置"0"; 开始新的操作循环或清故障码后则置"1";
7	WarningIndicatorRequested	报告与特定DTC相关的任何警告指示器的状态；没有警告，则置"0",有警告,则置"1"；如果有警告，则confirmedDTC也应设置为1；清故障码或满足制造商定义的要求，则置"0";

上图解释：

• 0 发送清故障码服务后，各状态位进行初始化；
• 1, 2 在完成测试时，bit6,4状态均由1变为0；
• 3, 4, 5, 6 测试结果Failed时，bit0,1,2,5状态均从0变为1；
• 7, 8 测试结果Failed时，bit0为1，测试结果Passed时，bit0为1；
• 9, 10, 12 开始一个新的操作循环，bit1变为0；bit5先变成1，待测试完成再变成0；
• 11 开始下一个操作循环时，该位是否保持上一个操作循环的结果由制造商定义；
• 13, 14, 15 在第二个循环中再次测试Failed,bit0,1,3变为1