搞诊断开发的小伙伴对DTC（Diagnostic Trouble Code，诊断故障码）和快照数据（Snapshot Data）应该并不陌生。其中，快照数据也称为冻结帧（Freeze Frame）。为了精准地定位车辆故障，往往需要读取DTC对应的快照数据。所以，两者有着一定的联系，那么，故障事件（Event）发生，与DTC以及快照数据是怎样的一种联系呢？
1、Event、DTC、Snapshot Data关系
关于Event与DTC的关系，可以参考前文《DTC问题排查模板（一）：诊断需求明确》。这里主要解释一下Snapshot Data，Snapshot Data是一些列数据集合。
（一）为什么需要Snapshot Data？
答：车辆诊断是对某个事件（Event）的监控（Monitor）,当某个Event偏离预期时，我们称其为“故障”，eg：CAN 收发器（Transceiver）故障。而这个故障事件可能因为多种因素诱发，比如：欠压、过温等。为了区分出到底是欠压还是过温引发的CAN 收发器故障，就需要将故障发生时的这些信息捕获出来，示意如下所示：
（二）如何捕获故障信息
答：为了后续排查问题，需要将故障发生时，关联的数据（Data）存储下来。怎么做呢？在软件层面，可以把数据用一个个具体的变量表示出来。即：温度、电压等都可以定义成变量。为了便于区分和识别这些变量，为每个变量分配一个独有的DID（Data Identifier，数据标识符），示意如下：
当故障事件（Event #1）发生时，关联的DTC #1将相关的变量信息一并存储到NVM（Non-Volatile Memory，非易失存储区）。后续问题排查时，通过上位机将信息从NVM中读取出来，进行分析和问题定位，示意如下：
但是，如果DTC关联的数据变量多且不同DTC可以复用时，每个DTC都去关联这些变量，操作上比较冗余。所以，为了便于处理和维护，在工程上，常常将一系列变量（DID）分组，这些分组称之为快照组（Snapshot Group）。不同的DTC可以关联不用的快照组，也就关联了不同的变量。一个DTC可以关联一个或者多个快照组，甚至不关联快照组，示意如下：
有些配置工具可能并不支持一个DTC关联多个快照组，如果是这样，实现上可以将需要关注的信息放到一个快照组里，缺点：浪费资源，相比于追查问题，牺牲一点存储空间是可以接受的。2、快照数据的存储时机
既然可以通过存储快照数据分析故障的具体原因，那么，快照数据何时存储呢？答：取决于存储条件，即：存储条件满足时，快照数据存储（存储到NVM）。（一）存储条件满足是指故障状态位（bit 3，confirm bit）置位吗？答：不一定。虽然工程上，常常将故障状态位bit3置位作为存储快照数据的条件，但是，并不能说快照数据存储就是bit3置位。实际上，在Autosar DEM（Diagnostic Event Manager，诊断事件管理）中，给出了多种快照数据存储的触发条件，示意如下：所以，故障状态bit3并不是快照数据（冻结帧）触发存储的唯一条件。（二）一个驾驶循环，故障多次发生，快照数据如何存储？答：这个存储策略因需求而定。这里给出常见的几种存储策略：1、当前驾驶循环发生多次故障，存储第一次快照数据，示意如下：
2、当前驾驶循环发生多次故障，存储最后一次快照数据（覆盖存储），示意如下：
3、当前驾驶循环发生多次故障，第一次存储指定快照组#1，最后一次存储快照数据#2，示意如下：
参考资料
Specification of Diagnostic Event Manager AUTOSAR CP Release 4.4.0.pdf