AUTOSAR 基础篇之 DTC
在之前文章《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 的具体实例；
event 的优先级决定了 DTC 的优先级；
event 之间的依赖关系决定了 DTC 的依赖关系；
DTC 的状态位是其 map 的所有 event 的状态位的或集；
2. DTC 状态位
当出现 DTC 时，我们只知道有故障发生了这一个基本事实，但是并不知道该故障什么时候发生，现在是否已经恢复、发生过几次，恢复过几次等细节性信息，因此国际标准组织 ISO 发布 14229-1 来引入 DTC 状态位这一概念来得到上述细节性信息，使我们对该故障的生前生后有个清晰的认识，便于我们快速定位问题所在。每一个 DTC 均有对应的 DTC 状态位，该 DTC 状态位由一个字节表示，每个 bit 都有其重要含义，具体解释如下图 4 所示：
图 4 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;
图 3-1
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 信息诊断获取方式
作者：汽车小 T
文章来源：上汽零束 SOA 开发者论坛
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7489
还未添加个人签名 2021.09.06 加入
还未添加个人简介
评论