在公众号“ADAS与ECU之吾见”的文章中《AUTOSAR-DEM模块几点思考》中我简要结合我自身工作经验分享了DEM模块在AUTOSAR的基础软件架构,希望能给大家带来些许帮助与共鸣,但并没有针对其内部每个技术点深入展开,应部分读者要求,我后续会按照由浅入深的方式分享下我对AUTOSAR基本模块内部技术点的认知与理解,与诸君一起进步。本文将聚焦于大家都耳熟能详的DTC(Diagnostic Trouble Code)技术点来聊一聊。
-
DTC基本介绍
DTC顾名思义即为诊断故障码,一种用来记录当某ECU发生或检测到某种故障时所呈现在大家目前的标识码,通过该标识码便可以查表的方式获得该故障信息,如故障触发条件、故障解除条件、系统功能表现等。这是当前供应商与主机厂普遍用来监测并识别故障的基础手段,所以也同样存在标准,普遍使用的标准是ISO15031-6,该标准中规定了DTC的基本组成,DTC如何命名等信息。
-
DTC基本组成
根据上述ISO标准,DTC由以下两个部分组成:DTC Catogory 与Failure Type,其中DTC Catogory 又可以根据Powertrain、Body、Chasis、N etwork四大子系统来进一步定义其范围,简称PBCU四大子系统,如下表1-1所示:
1-1 DTC Catogory 范围定义
在上表中可以看到每个子系统都划分为4个子范围,如B0-B3,C0-C3,P0-P3,U0-U3;其中值得注意的是B0、C0、P0、P2、P3、U0、U3这几个子范围被ISO预留以供未来使用,因此严格来说,现在很多供应商定义的DTC不符合规定,但一般来说不影响使用。接下来,我们就来看一下该DTC Catogory 占用的每个bi t的具体说明,如下图1-2所示:
1-2 DTC Catogory Bit定义
图中标号1表示后12bit大小范围可以为000-FFF;标号2表示对于动力系统而言,如00,10都是ISO/SAE特殊定义的范围;标号3则表示对于动力系统而言,即便定义为11,可以被供应商或主机厂自定义的范围为P3000-P33FF,而P3400-P3FFF则已被ISO/SAE预先定义。了解了ISO对于DTC C atogory的定义之后,接下来看个具体实例1-3:
1-3 3字节DTC基本组成
正如我们经常在客户诊断调查表见到的P(00)、C(01)、B(10)、U(11)来实现我们所说的DTC诊断显示码(PBCU开头码)与日常使用的3字节DTC转换 关系,实际上只需要将PBCU四个子系统对应的bit组合关系替换进去,便可以得到我们常说的DTC,这点很多小伙伴可能都会有误区,特此说明一下。
其中上图所示的低字节就是我刚刚说到的Failure Type,该Failure Type也不是随意填写,ISO都有规定,如常见的timeout应该用0x87,信号无效应该为0x81等等,该字节如何定义需要参考ISO15031-6并找到对应的故障单元来选择,值得注意的是:一般对于排放相关的ECU的DTC最低字位均为00,而对于非排放相关的ECU则需要参考ISO标准来定义。
上述四大故障基本上涵盖了所有ECU所用到的DTC故障类型,这对于我们设计一款新的ECU产品将会有一些指导作用。
联系:
-
DTC故障类型
以非排放相关的ECU为例,可以将DTC故障类型分为以下几个部分:
-
硬件故障;如RAM、Flash、CPU时钟等硬件本身失效的问题
-
软件故障;如配置字故障,标定故障或客户定义的软件功能性故障
-
外部环境故障;电压过高或者欠压、环境温度过高或过低等
-
通讯相关故障;如报文丢失、信号无效,Checksum/AliveCounter故障等
-
-
DTC与event区别与联系
区别:
-
DTC是某类故障的统称,能够大体定位到某个模块的故障,而event则是故障监控的基本单元,能够定位某个模块中的某个具体故障;
- 多个event可以mapping 同一个DTC;而同一个event不能mapping 多个DTC;
- DTC可以直接可见,但Event需通过进一步手段才能看到,有时仅对ECU供应商可见;
联系:
- DTC代表某类event集中表现,而event则是某个DTC的具体实例;
- DTC的状态位是其map的所有event的状态位的或集;
- event之间的依赖关系决定了DTC的依赖关系;
- event的优先级决定了DTC的优先级;
2. DTC状态位
当出现DTC时,我们只知道有故障发生了这一个基本事实,但是并不知道该故障什么时候发生,现在是否已经恢复、发生过几次,恢复过几次等细节性信息,因此国际标准组织ISO发布14229-1来引入DTC状态位这一概念来得到上述细节性信息,使我们对该故障的生前生后有个清晰的认识,便于我们快速定位问题所在。每一个DTC均有对应的DTC状态位,该DTC状态位由一个字节表示,每个bit都有其重要含义,具体解释如下图2所示:
图2 DTC Status bit
具体解释如下:
-
Bit0: 请求时刻测试结果为失败;
-
Bit1: 在当前点火循环至少失败过1次;
-
Bit2: 在当前或者上一个点火循环测试结果不为失败;
-
Bit3: 请求时刻DTC被确认,一般确认是在一个点火周期内发生错误1次;
-
Bit4: 自上次清除DTC之后测试结果已完成,即测试结果为PASS或者FAIL结果;
-
Bit5: 自上次清除DTC后测试结果都不是FAIL;
-
Bit6: 在当前点火周期内测试结果已完成,即为PASS或FAIL状态;
-
Bit7: ECU没有得到点亮警示灯请求;
相应的为了让大家对每一个bit的动态变化有个更为深刻的理解,结合最新版ISO14229-1 2020分别对每个bit的动态变化展示如下:
Bit 0:
Bit 1:
Bit 2:
Bit 3:
Bit 4:
Bit 5:
Bit 6:
Bit 7
对于上述每一个Bit变化的前提条件大家可以参考官方文档细细评味,这样才能印象深刻,在这里就不赘述了。
3. DTC信息存储
事实上当DTC产生时,并不会直接存储在NVM中,而是直接存储故障e event的方式,然后间接通过event-DTC的mapping关系来存储DTC,而DTC的状态位则是由其mapping的所有event的状态位的或集,如下图3-1所示。大多数情况下光有DTC号以及状态位信息往往不能一步到位定位root cause,需要引入环境信息才能够进一步确定问题所在,因此ISO组织便引入了以下两个基本概念:快照数据(Snapshot Data)、扩展数据(Extended Data)。
-
If Event 1 -> DTC A; Event 2 -> DTC A; ... Event N -> DTC A;
-
Then DTC A Status = Event 1 Status | Event2 Status | ...| Event N;
DTC A 同时Map了Event 1 ~ Event N,则DTC A Status即为上述map的或集,但是具体是哪个event先报,则取决于event之间的优先级以及上报策略来综合判断。
Snapshot Data:顾名思义快照信息即为故障发生时刻存下来的瞬态的环境数据,一般是指电源模式、温度、时间戳、车速等信息。
Extended Data:即为在故障发生时其他的辅助故障信息,如aging counter、aged counter 、Fault Counter以及event id等。
另外,对于DTC信息存储一般简单理解可以分为两部分存储空间,该划分更多的是逻辑意义上的定义,这样区分的意义在于能够更好的实现主机厂与供应商的信息隔离,防止出现不必要的误解与多余信息的讨论。
Primary Memory:对主机厂以及ECU供应商可见的DTC信息空间,如DTC Status、Snapshot Data、Extended Data等;
Second Memory:仅ECU供应商内部可见的信息,如event ID、ITC等信息。
限于主题,所以NVM信息存储点到为止,后续关于NVM信息存储的机制会通过专题与大家一起分享学习。
4. DTC信息及状态读取
DTC会在ECU运行过程中产生、变化并被实时记录下来,对于ECU供应商或者主机厂则可以通过诊断服务的方式来实现DTC信息及状态位的读取,如下图4所示,通过以下几种方式便可以得到ECU支持的DTC、当前或历史DTC、Snapshot Data、Extended Data ,DTC status等信息。
图4 DTC信息诊断获取方式
以上内容虽然是十分基础的内容,但是我发现有时候工作过程中同事还是由于时间太忙,没有深入去理解每个技术点,导致有些非常基础的内容并不知道,借此机会我也想通过自己对AUTOSAR等相关文档的理解,一来是当作自己平常工作技术点的备忘录,二来也希望能够给大家的日常工作带来些许帮助,后面会继续结合我自身的理解给大家介绍AUTOSAR基础技术点,希望大家喜欢,更多精彩内容可以关注公众号“ADAS与ECU之吾见”,在那里我会为大家分享更多精彩的文章,感谢大家的关注,也欢迎大家的批评指正!