AUTOSAR基础篇之DTC

智能汽车电子与软件 2022-10-21 15:46 3053浏览 0评论 0点赞

案例解析打通芯片/系统验证"任督二脉" 全球首发！3D IC协同设计“黑科技”，效率提升200%

关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯

来源：ADAS与ECU之吾见

作者：奋斗的农民工

应部分读者要求，我后续会按照由浅入深的方式分享下我对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标准来定义。

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

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

上述四大故障基本上涵盖了所有ECU所用到的DTC故障类型，这对于我们设计一款新的ECU产品将会有一些指导作用。

DTC与event区别与联系
区别：

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

联系：

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

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等信息。