AUTOSAR基础篇之DTC

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

AUTOSAR基础篇之DTC相关推荐

AUTOSAR从入门到精通100讲（七十九）-AUTOSAR基础篇之DTC
本文将聚焦于大家都耳熟能详的DTC(Diagnostic Trouble Code)技术点来聊一聊. DTC基本介绍 DTC顾名思义即为诊断故障码,一种用来记录当某ECU发生或检测到某种故障时所呈现在 ...
AUTOSAR基础篇之Event（上）
祥鼠辞旧岁,犇牛踏雪来. 入沪且伊始,便是就地年. 异乡何足惧,同心万里牵. 且待疫散去,幸福中国年. 谨以此打油诗献给诸多跟我一样异地过年的小伙伴们,祝大家在新的一年里能够身体健康,心想事成,牛气冲 ...
AUTOSAR基础篇之OS(上)
AUTOSAR基础篇之OS(上) 前言首先,请问大家几个小小的问题,你清楚: 为什么汽车电子ECU需要使用OS呢,它的必要性在哪里? ECU软件运行过程中是如何实现任务切换的吗? 多核系统OS又是如 ...
AUTOSAR从入门到精通100讲（八十一）-AUTOSAR基础篇之FiM
前言你清楚以下几个问题吗? 当系统发生故障时,系统应该怎样做出反应呢? 如何实现当故障发生时,系统做出相应的可预知行为呢? 我们经常讲的系统降级跟FiM到底是什么关系? FiM与其他基础软件模块是如 ...
AUTOSAR基础篇之CanNM
前言首先,问大家几个问题,你清楚: 为什么要引入网络管理呢?上电同时启动,下电同时关闭,它不香吗? 你知道车上的ECU节点可以分为哪几种类型吗? 汽车启动时,ECU之间怎么保持同步唤醒的呢? 下电时 ...
AUTOSAR从入门到精通100讲（八十五）-AUTOSAR基础篇之BswM
前言首先,请问大家几个小小问题,你清楚: 你知道BswM是做甚的吗? 常说的APP Mode或者System状态机与BswM关系又是如何的呢? BswM模块作为AUTOSAR的一个标准模块,内部工作 ...
UDS服务基础篇之2F
前言在汽车ECU诊断服务开发的过程中,有很多常见的诊断服务,比如10, 11, 22, 2E等,但是对于2F服务则会显得有些陌生,因为这类诊断服务主要在车身域比较常见,比如车窗控制,传感器开关.执行 ...
UDS服务基础篇之28
前言首次,请教大家关于诊断服务28的几个问题: 28服务有何作用,为什么要有28服务呢? 28服务在使用过程中有哪些注意事项呢? 28服务诊断请求与诊断响应如何交互? 这篇,我们来一起探索并回答这些 ...
搞一下CP AUTOSAR 入门 | 02 CP AUTOSAR 基础模块功能描述
前言本系列请点击:<搞一下CP AUTOSAR入门> 所有系列请点击:<汽车电子系列分享> 在上一篇介绍了CP AUTOSAR的分层结构,对于多数使用AUTOSAR架构开发汽 ...

AUTOSAR基础篇之DTC

AUTOSAR基础篇之DTC相关推荐

最新文章

热门文章