汽车电子Autosar之DTC

目录

一、DTC基本介绍

1、DTC基本组成

2、DTC故障类型

3、DTC与event区别与联系

4、 DTC状态位

5. DTC信息存储

6. DTC信息及状态读取


本文将聚焦于大家都耳熟能详的DTC(Diagnostic Trouble Code)技术点来聊一聊。

一、DTC基本介绍

        DTC顾名思义即为诊断故障码,一种用来记录当某ECU发生或检测到某种故障时所呈现在大家目前的标识码,通过该标识码便可以查表的方式获得该故障信息,如故障触发条件、故障解除条件、系统功能表现等。这是当前供应商与主机厂普遍用来监测并识别故障的基础手段,所以也同样存在标准,普遍使用的标准是ISO15031-6,该标准中规定了DTC的基本组成,DTC如何命名等信息。

1、DTC基本组成

       根据上述ISO标准,DTC由以下两个部分组成:DTC Catogory 与Failure Type,其中DTC Catogory 又可以根据Powertrain、Body、Chasis、N etwork四大子系统来进一步定义其范围,简称PBCU四大子系统,如下表1-1所示:

                                                       

汽车电子Autosar之DTC_第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所示:

                                                            

汽车电子Autosar之DTC_第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产品将会有一些指导作用。

联系:

2、DTC故障类型

以非排放相关的ECU为例,可以将DTC故障类型分为以下几个部分:

  • 硬件故障:如RAM、Flash、CPU时钟等硬件本身失效的问题
  • 软件故障:如配置字故障,标定故障或客户定义的软件功能性故障
  • 外部环境故障:电压过高或者欠压、环境温度过高或过低等
  • 通讯相关故障:如报文丢失、信号无效,Checksum/AliveCounter故障等

3、DTC与event区别与联系

区别:

  • DTC是某类故障的统称,能够大体定位到某个模块的故障,而event则是故障监控的基本单元,能够定位某个模块中的某个具体故障;
  • 多个event可以mapping 同一个DTC;而同一个event不能mapping 多个DTC;
  • DTC可以直接可见,但Event需通过进一步手段才能看到,有时仅对ECU供应商可见;

 联系:

  • DTC代表某类event集中表现,而event则是某个DTC的具体实例;
  • DTC的状态位是其map的所有event的状态位的或集;
  • event之间的依赖关系决定了DTC的依赖关系;
  • event的优先级决定了DTC的优先级;

4、 DTC状态位

        当出现DTC时,我们只知道有故障发生了这一个基本事实,但是并不知道该故障什么时候发生,现在是否已经恢复、发生过几次,恢复过几次等细节性信息,因此国际标准组织ISO发布14229-1来引入DTC状态位这一概念来得到上述细节性信息,使我们对该故障的生前生后有个清晰的认识,便于我们快速定位问题所在。每一个DTC均有对应的DTC状态位,该DTC状态位由一个字节表示,每个bit都有其重要含义,具体解释如下图2所示:

                                                 

汽车电子Autosar之DTC_第3张图片

 图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:

                 

汽车电子Autosar之DTC_第4张图片

                                                

 

Bit 1:

                     

汽车电子Autosar之DTC_第5张图片

                      

 

Bit 2:

                               

汽车电子Autosar之DTC_第6张图片

                     

 

Bit 3:

                               

汽车电子Autosar之DTC_第7张图片

      

 

Bit 4:

                                   

汽车电子Autosar之DTC_第8张图片

    

 

Bit 5:

                                     

汽车电子Autosar之DTC_第9张图片

      

 

Bit 6:

                                     

汽车电子Autosar之DTC_第10张图片

 

Bit 7

                                   

汽车电子Autosar之DTC_第11张图片

 

 

        对于上述每一个Bit变化的前提条件大家可以参考官方文档细细评味,这样才能印象深刻,在这里就不赘述了。

5. 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信息存储的机制会通过专题与大家一起分享学习。

6. DTC信息及状态读取

        DTC会在ECU运行过程中产生、变化并被实时记录下来,对于ECU供应商或者主机厂则可以通过诊断服务的方式来实现DTC信息及状态位的读取,如下图4所示,通过以下几种方式便可以得到ECU支持的DTC、当前或历史DTC、Snapshot Data、Extended Data ,DTC status等信息。

汽车电子Autosar之DTC_第12张图片

 

                                                                           

 图4 DTC信息诊断获取方式
 

你可能感兴趣的:(汽车电子,汽车电子,Autosar,DTC)