AUTOSAR基础篇之DTC

在公众号“ADAS与ECU之吾见”的文章中《AUTOSAR-DEM模块几点思考》中我简要结合我自身工作经验分享了DEM模块在AUTOSAR的基础软件架构,希望能给大家带来些许帮助与共鸣,但并没有针对其内部每个技术点深入展开,应部分读者要求,我后续会按照由浅入深的方式分享下我对AUTOSAR基本模块内部技术点的认知与理解,与诸君一起进步。本文将聚焦于大家都耳熟能详的DTC(Diagnostic Trouble Code)技术点来聊一聊。

  1. 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之吾见”,在那里我会为大家分享更多精彩的文章,感谢大家的关注,也欢迎大家的批评指正!

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车小T

感谢打赏,我会继续努力奉献精彩

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值