电子发烧友App
曾经看到汽车仪表出现故障灯时，总是很好奇想知道这个图标是什么意思，什么时候会出现，又什么时候会消失。恰好这两年接触到了这些知识，有所了解，在此分享给感兴趣的朋友。
本文将从系统，设计和实现3个角度来介绍汽车控制器（ECU）故障诊断系统：
在系统角度，了解为什么需要故障诊断系统，利用它可以做什么，以及它是什么；
在设计角度，了解故障怎么管理，怎么识别，怎么处理；
在实现角度，了解基于AUTOSAR架构的故障诊断系统实现机制。
1 ECU故障诊断系统介绍
汽车上任何一个零件或任何零件间都可能会产生失效，即使失效的概率极低，但没法保证百分之百不会失效。基于这样的事实，我们没办法阻止，但是尽可能去识别到潜在的失效，这样才能最大限度去避免伤害。所以，汽车的各个控制器都需要故障诊断系统，去不断检测系统、零件等的异常之处，从中找出故障，找出故障后，还希望一方面可以采取临时补救措施，将伤害减到最小，另一方面，保存故障信息，以供后续排查和解决故障。因此，基于这样的需求，完整的ECU故障诊断系统包括车内在线诊断系统和车外离线诊断系统两个部分，将两者配合使用，就可以进行完整地故障诊断。
其中，车内在线诊断系统用于监测车内部的传感器，电子控制单元和执行器的工作状态，并根据这些数据信息自动检测系统故障，并将以故障码的形式保存，同时做出相应的故障处理措施，并点亮相对应的故障灯提醒驾驶人员。
车外离线诊断系统用于提取已保存的故障信息，通过向车内在线诊断系统发送服务请求（即使用UDS服务）的形式，可进行读取故障码信息、清除故障码和刷写软件等操作，完成故障的调查与维修。
也就是说：当汽车出现故障，车内在线诊断系统就应该起作用，最终提醒驾驶员有故障，那驾驶员将汽车返修。维修人员进行查因和维修，就需要使用车外离线诊断系统，查看故障信息、查找原因和更新软件操作等。
2 ECU故障诊断系统设计的若干要点
为了实现上文的ECU故障诊断系统，同时也为铺垫下文的ECU故障诊断系统ECU故障诊断系统实现，需要先介绍设计方面的几个重要知识点，主要包括：诊断故障码DTC，故障诊断机制和UDS服务。
2.1 诊断故障码DTC
ECU故障诊断系统检测的故障主要有五种类型：
机械/系统故障，以变速箱控制器所涉及的故障为例，像挡位执行器坏了，离合器坏了等故障；
电子电器故障，比如电磁阀或传感器短路，电源电压不在工作范围等故障；
硬件故障，主要指PCB上的器件故障，比如处理器故障，外围芯片故障等；
软件故障，比如死循环， 除零，溢出等故障；
通讯故障， 比如CAN连不上，CAN报文丢失等故障。
对于这些故障，基于管理和处理方面的考虑，采用诊断故障码（Diagnostic Trouble Code，DTC）来表示。下面就具体了解DTC的几个重要概念：
2.1.1 DTC定义
DTC可以说是故障类型的"身份ID"，一个DTC映射一个故障类型（诊断事件）。DTC格式是根据几个国际标准协议来定义的，比如ISO-14229-1，SAE J2012 OBD DTC和SAE J1939-73等。总的来说，DTC分为non OBD和OBD两种格式，如下所示：
以non OBD为例，DTC包含3个字节数据。其中HighByte和MiddleByte这2个字节表示故障内码，对应5位标准故障码（第一位是字母，后四位是数字）。
前两位用来区分故障来自的控制系统, 是系统代码，比如B0-B3 是用在车身控制系统，C0-C3 是用在底盘控制系统，P0-P3是用在发动机控制系统，U0-U3 是用在通讯故障；
第三位是数字，表示表示故障所属的子系统码；
最后两位数字提供故障的对象和类型。
比如"P080081"这个故障码中，故障内码为"P0800"，其中“P08”代表动力系统的传动系统控制故障，“00”代表传感器。
LowByte这个字节表示Failure Type，包含Failure category和Failure Sub Type两个部分，具体可参考SAE J2012-DA，比如常见的timeout应该用0x87，信号无效应该为0x81等等；而对于OBD相关的ECU的DTC最低字位均为0x00。
接着"P080081"这个故障码，“P08”代表动力系统的传动系统控制故障，“00”代表传感器，“81”代表信号无效，所以这个DTC代表就是动力系统的传动系统控制的传感器信号无效。
到此认识了DTC，除此之外还需要了解它的严重程度，因为不同的严重程度将会有不同的处理方式。DTC严重程度采用1个字节来存储，它分为A、B、 C、D四个等级。比如说A类表示立即维修车辆，B类表示及时维修车辆，C类表示影响不大，有时间再维护，D类表示没影响。
引自ISO14229
2.1.2 DTC附属信息
根据上述DTC的定义，我们可以知道是什么故障以及故障是否严重，但这不能清晰得知故障什么时候发生的，什么原因导致发生的，因此还需要DTC的关键信息，比如DTC状态（DTC status）、DTC快照信息（Snapshot）和DTC扩展数据信息(Extended data)。只有存储下了这些关键信息，才能助于故障的解决。
1> DTC 状态
先看DTC状态，用1个字节来存储，其8个bit分别代表为：
引自ISO14229
常听说历史故障和当前故障，对应上表，当前故障为bit0为1的故障，历史故障指bit0为0但是bit3为1的故障，DTCStatus = 0x09 表示当前故障，即DTCStatus = 0x08 表示历史故障。
历史故障是过去发生但当前还没有清除的故障码。历史故障产生的原因有两种情况，一种是故障己经排除，只是未清除故障码，此代码清除后，故障就不会再次发生；另一种是故障并未排除，只是当前没有发生，此代码清除后，当故障再次发生时，故障还会出现。
当前故障是正发生的故障产生的故障码。当前故障是确实存在的故障引起的，它属于持续性故障产生的故障码，它不会被清除。
当前故障是当前确实存在的故障，比较容易判断。而历史故障比较难于判断，因为它是曾经发生的故障而现在没有，重现故障产生的状态，可能需要很长时间来捕捉历史故障码的重现，或者需要人为的创造可重现故障的条件，如加热、振动等，同时需要较好的设备来捕捉故障出现瞬间各种数据参数的变化才行。因此，一般先解决当前故障，而对于历史故障暂时作为故障诊断的参考。
以上就是通常当前故障和历史故障对DTC状态的说明，关于8个bit对应的具体状态解析，可参考ISO14229 或
张丁：汽车控制器（ECU）中DTC的状态位
2> 快照信息
快照信息就类似照相机一样，在故障发生的时刻，对整车信息按下快门，做个记录，以便后续分析问题。快照信息一般包括供电电压、里程读数、点火状态、发动机冷却液温度，节气门位置，发动机转速，车速等信息，如下所示。这些会按规定的方式保存下来。
引自ISO14229
3> 扩展数据
扩展数据信息是一组提供DTC相关扩展状态信息的数据组，包括故障出现计数器、故障待定计数器、已老去计数器和老化计数器等，这些信息的具体内容一般都由客户来定义。如下示意：
引自ISO14229
以上就是DTC相关的几个重要概念，这样就可以知道故障是什么，也可以得到该故障的附件信息。
DTC的这些内容设计要么是根据标准协议，要么是根据客户的特定需求，不管是哪种形式，一般都是以需求形式要求实现方实现。当然，除了这些内容会作为需求的一部分，接下来要介绍的故障诊断机制内容也会作为需求的另一部分。
2.2 ECU故障诊断机制
故障诊断包括检测，确认和处理3个部分。
2.2.1 故障的检测
故障的检测是由车内在线诊断系统来执行，先通过ECU内部软硬件功能模块实现自我诊断，对故障的检测分两步：先看检测故障的前提条件，即什么时候或情况需要去检测某一种故障。比如电磁阀关闭时，若检测电磁阀有无堵塞故障，是不合理也不需要的，但电磁阀已开启，则检测有必要。再看检测故障的判断条件，即通过怎样的逻辑去识别某一种故障。比如电磁阀已打开，但监测通过电磁阀的流量非常小，那么怀疑是电磁阀堵塞故障。
2.2.2 故障的确认
故障的确认是指上述检测到“故障”出现多少次或多长时间才算是真正的故障。因为有时可能只是某个信号极其偶尔波动一下，而这种波动对汽车没有影响，这时如果识别为故障，那么就过敏感了，反而会给驾驶员带来困扰。因此，为了规避这样的情况也被识别为故障，那么就提出了debouncing的概念，即通过一次次数或时间的累加，才能确认是否出现了真正的故障。只有当“故障”出现次数或时间累加到一定的值，才确认故障。当前常用Debouncing算法有基于计数器和基于时间两类，如下所示：
基于计数器的Debouncing算法，引自[1]
基于时间的Debouncing算法,引自[1]
总的来说，Debouncing算法原理是：根据检测到“故障”状态（PREFAILED, FAILED, PREPASSED, PASSED）来增减计数器或定时器，只有次数或时间达到阈值，才能确认或消除故障。如上图所示，当报告的状态是PREFAILED时，计数器或定时器就累加一次；当累加次数或时间到Failed的域值，那么“故障”就被确认。这里会涉及的一些参数需要定义清楚，因此为这些参数将会决定故障需要多长时间确认或恢复，像图中所示的步长和阈值等。比如对于某个故障的确认时间为200ms，计数器每5ms计数一次，假设设定阈值为40，报告状态切换时，计数器总是从0开始计数，那么这时针对故障确认的固定步长设置为1。总之，不同Debouncing算法的细节处理会不同，可根据实际诊断需求选择适合的Debouncing算法。
2.2.3 故障的处理
当故障被确认，那么车内在线诊断系统一方面将故障码DTC及相关数据存入ECU内部的非易失存储器内；另一方面将对故障进行处理，主要包括点灯策略和故障处理策略。其中，点灯策略是指根据故障的严重程度决定是否点亮故障指示灯以及点亮何种颜色，以此警示驾驶员故障的存在，而故障处理策略是指根据故障的严重程度决定做怎样的临时处理措施。比如出现了变速箱高档位损坏故障，那么这时点黄灯，显示变速箱故障，同时限制汽车行驶速度，采用跛行回家模式；或者出现了车窗无法下降故障，那么这时不点灯，此时也不会对汽车行驶有任何限制。
车辆行驶过程中，通过上述机制就可以由车内诊断诊断系统实时监控ECU各部分的工作状态，从而检测出故障。
2.3 统一诊断服务UDS
上述的故障码DTC及相关数据存入ECU内部的非易失存储器后，要怎么获取呢？这就涉及到车外离线诊断系统，需要使用到统一诊断服务（Unified Diagnostic Services，UDS），当然涉及排放会使用到OBD服务，这里仅介绍UDS服务。UDS服务是诊断服务的规范化标准，规定了读取DTC的指令，读诊断数据流的指令等。
先看一个使用UDS服务的例子：假如车窗系统出现故障，则维修人员需要先使用UDS读写服务去获取软、硬件版本号，供电电压等，以获取一些最基本的信息；再使用UDS服务查看DTC相关信息，了解具体出现了什么故障，比如出现电机故障，那可以使用UDS例程控制服务去控制开启电机。当发现这个故障在旧版本的软件都存在，新版本的软件已经修复了这些故障，那么使用UDS刷写服务更新软件。当然这个过程所使用的这些UDS服务都是通过诊断设备发送的，所使用到的服务如下示意。
总的来说，按功能划分，UDS服务可分为6类，共26种服务，分别是：
1）诊断和通信管理功能单元，包括10，11，27，28，3E，83，84，85，86，87共10种服务；
2）数据传输功能单元，包括22，23，24，2A，2C，2E，3D共7种服务；
3）存储数据传输功能单元，包括14，19共2种服务；
4）输入输出控制功能单元，包括2F服务；
5）例行程序功能单元，包括31服务；
6）上传下载控制功能单元，包括34，35，36，37，38共5种服务。
这些UDS服务的层次关系是：首先是确定在什么诊断会话模式（$10），即是默认会话，还是扩展会话，还是编程会话；在此基础上，再明确是否需要使用安全访问服务（$27）解锁，有些功能服务需要通过该服务解锁才能使用，有些则不需要考虑该服务；最后才能实现具体的服务控制。
关于UDS服务的具体介绍，可参考我的专栏：汽车ECU软件开发的UDS协议详解系列（点击进入）。
2.4 小结
回顾上述本节内容的介绍可知，车内在线诊断系统负责故障的检测，确认和处理，以及存储故障信息到ECU的非易失性存储器。车外离线诊断系统则通过UDS服务查询DTC及其相关信息，消除故障和更新软件。
3 基于AUTOSAR的ECU故障诊断系统
为了进一步了解ECU故障诊断系统，可在软件层面进一步了解其如何实现。对于AUTOSAR软件架构，故障诊断既会在底层软件BSW实施，也会在应用层软件ASW实施，具体看如何定义两者的边界。
基于AUTOSAR的软件架构
3.1 基于AUTOSAR架构的故障诊断系统介绍
下面来了解下基于AUTOSAR架构的故障诊断系统，如下所示：
基于AUTOSAR架构的故障诊断系统，，引自[1]
诊断事件管理模块Dem负责对故障诊断、处理、保存和管理。比如Dem通过NvM提供的接口访问非易失存储器，读取和保存故障信息。同时Dem向Dcm提供访问故障数据的接口，如读故障码，清楚故障码等操作。
应用层SW-C监控函数Monitor负责故障的检测，也可能包括确认，SW-C通过接口函数Dem_SetEventStatus将诊断结果报告给Dem。如果监控函数Monitor包含Debouncing算法，即应用层能确认故障，那么SW-C给Dem报告诊断结果是DEM_EVENT_STATUS_PASSED或DEM_EVENT_STATUS_FALIED，即Dem接收确认故障。否则SW-C传递给Dem的诊断结果为DEM_EVENT_STATUS_PREPASSED或DEM_EVENT_STATUS_PREFALIED，即需要在底层软件确认故障。
底层SW-C监控函数Monitor负责诊断像NvM读写失败，或排队任务数溢出，或校验错误等类型故障，该类故障通常不需要使用Debouncing算法进行确认，故障状态只有2种，即DEM_EVENT_STATUS_FAILED或DEM_EVENT_STATUS_PASSED，SW-C也是通过接口函数Dem_ReportErrorStatus将诊断结果报告给Dem。
诊断通讯管理模块Dcm负责UDS或OBD服务请求与发送管理，即收到AUTOSAR支持的UDS或OBD服务请求时，通过调用Dem，应用层软件组件或其他基础软件模块提供的接口，进行相应的操作。
NvM是指非易失性存储管理模块，管理非易失性数据的存储和维护。当Dem确认到故障，Dem调用NvM的写函数，把故障信息和发生故障时的环境数据写入到NvM。当Dem要查询故障信息，Dem调用NvM的读函数，从NvM中，读取故障信息和发生故障时的环境数据。
EcuM模块负责调用相关函数对Dem初始化，包括初始化每个故障的debounce状态，Dem存储的故障数据。
FiM模块是为SW-C提供一个控制机制，即使能或抑制SW-C功能。比如当故障确认后，可以通过FiM抑制一些与此故障相关的SW-C功能，像抑制了检测速度的SW-C功能，那就意味着基于速度来检测故障的前提条件就无法满意，相应地此类故障都将无法诊断。
SW-C除了监控函数，还有针对故障发生后的临时故障处理函数，比如以变速箱控制器来说，检测到某个档位无法使用，可能决定采用跛行回家，或者打开离合器中断动力等处理方式；也有故障指示灯的控制函数，一方面故障出现时点亮故障指示灯的控制，另一方面是故障被维修处理或因故障自愈而进行消去故障指示灯的控制。
3.2 基于AUTOSAR架构的故障诊断系统运行逻辑实例
假设有这样一个案例：驾驶员在行驶过程中看到仪表出现了发动机方面的故障，然后导致车辆动力中断，进而不能继续行驶。经查该故障为控制节气门的电磁阀短路到地，导致该电磁阀无法开启，而这个电磁阀采用高边驱动的控制方式，高边驱动有反馈电流到控制器，开启工作时会反馈高电平，短路到地则会反馈低电平。
这里对于该故障的检测定义在ASW的SW-C模块，如下图所示。也就是说，在这里的Monitor模块将先有函数去判断是否需要检测节气门的电磁阀故障，比如发动机熄火的时候可能就不需要检测，而发动机启动则需要；当需要检测时，就有函数去判断是否出现节气门的电磁阀故障，对于短路到地故障，就会通过条件之一的反馈电流来判断，如果反馈电流为高电平，则不会检测到短路到地，否则，就有可能。当有可能但还不足以确认时，那么可以采用debouncing算法，通过基于计数或计时的方法来确认。
一旦故障确认，Monitor调用接口函数Dem_ReportErrorStatus向Dem报告DEM_EVENT_STATUS_FAILED。接着Dem模块就会与相关功能模块交互，像上文提到存储故障数据信息，传递故障信息给ASW故障处理SW-C模块等操作。
对于控制节气门的电磁阀短路到地，电磁阀无法开启，这意味着供油中断，那么一方面SW-C模块的相关函数将给出发动机熄火命令，同时通知其他控制器中断动力，比如请求变速箱打开离合，挂空挡操作等处理措施；另一方面SW-C模块的相关函数发出点亮发动机故障灯命令，要求靠边停车提醒。
当故障车辆到维修车间，维修人员将使用测试仪器，查询故障信息。比如，使用19服务获取电磁阀短路得到这个DTC相关信息，这时Dcm模块的19服务映射的函数将调用Dem提供的接口函数，通过这些函数获取DTC相关信息。类似的逻辑，可以通过14服务清楚故障。
编辑：黄飞
工商网监
评论