全文约8,200字，建议收藏阅读

作者|直观解

出品|汽车电子与软件

目

录

一、背景

二、数据记录要求：I，II型记

录系统和A，B级数据

三、数据读取要求

四、硬件性能要求，类似于域

控盒子的要求

五、总结

一、背 景

GB 44497-2024自动驾驶数据记录系统 是444系列标准中最详细最复杂的一个，全文有43页，远比95-96两个标准要长。虽然后缀是2024，但实施日期是2026年一月一日。

图 GB 44497-2024出处

这个标准包括了硬件规格，防撞耐湿耐高低温度电磁干扰等等一系列要求；也包含了软件动作和数据规范；又和自动驾驶技术强相关。所以涵盖了电子电气，计算机科学和自动驾驶车辆知识三方面的知识，对于阅读要求很高。

如果粗略地分，大致分为三块：数据记录要求，数据读取要求，和硬件性能要求。这里的硬件性能主要指电气、温湿度、撞击震动等物理条件下的抗毁性，而不是CPU内存等等的电子性能。

二、数据记录要求：I，II型记录系统和A，B级数据

此国标规定了两种自动驾驶数据记录系统：I，II型系统，II型是更加高阶的形式。而且允许一辆车同时具有这两型记录系统。

• 适用车辆类型：

I 型系统：主要适用于 M1 类和 N1 类车辆。

II 型系统：适用于 M2 类、M3 类、N2 类和 N3 类车辆，M1、N1 类车辆也可搭载。

图 车辆类型分类

• 记录事件类型：

I 型系统：记录时间戳事件，如自动驾驶系统激活、退出、发出介入请求、执行最小风险策略、ADS 严重失效等。

II 型系统：不仅记录时间戳事件，还记录时间段事件。

• 数据存储能力：

I 型系统：至少能存储 5 次碰撞事件和 2500 次时间戳事件。

II 型系统：至少能存储 8 小时连续数据和 2500 次时间戳事件。

• 数据保护机制：

I 型系统：碰撞事件数据不应被覆盖，锁定事件数据优先保护。

II 型系统：实时连续记录数据与时间戳事件数据不应互相覆盖。

• 记录数据详细程度：

I 型系统：侧重记录基础行车数据，包括车辆位置、速度、转向信号等动态参数。

II 型系统：需满足更高阶要求，例如在碰撞风险事件中同步记录座舱内音频、驾驶员状态等复合信息，可形成多维度的责任判定依据。

A，B两级数据

根据GB 44497-2024《智能网联汽车 自动驾驶数据记录系统》，数据元素分为 A 级和 B 级。两者对比如下：

• 记录要求：

A 级数据元素：是配备自动驾驶数据记录系统的车辆应记录的数据元素，属于必须记录的数据。

B 级数据元素：是配备自动驾驶数据记录系统的车辆在相关功能处于被自动驾驶功能调用的状态时应记录的数据元素。

• 涵盖范围：

A 级数据元素：包含车辆状态（如速度、加速度）、自动驾驶系统运行信息（如请求的车速、加速度、转向角、灯光状态、档位等）、行车环境信息（如感知目标物类型、位置、速度图像）等，为分析车辆基本运行情况和自动驾驶状态提供基础数据。

B 级数据元素：主要针对特定功能被调用时的相关数据记录，例如某些高级辅助驾驶功能或特定自动驾驶模式下特有的传感器数据、系统决策参数等，记录范围相对更窄，但更具针对性。

所谓“配备自动驾驶数据记录系统的车辆在相关功能处于被自动驾驶功能调用的状态”，指的是车辆的特定子功能或模块被自动驾驶系统（ADS）主动激活并用于支撑自动驾驶决策与控制的场景。以下结合具体功能举例说明：

• 自动变道功能调用转向系统

当车辆处于高速公路自动驾驶模式（如L2 + 级的车道居中 + 自适应巡航）时，若驾驶员触发自动变道指令（或系统根据导航 / 车流自动发起变道），自动驾驶系统会调用转向系统调整方向盘角度，同时调用动力系统小幅调整车速以完成并线。此时，转向系统、动力系统的控制参数（如转向角、扭矩、油门开度）属于被自动驾驶功能调用的状态数据，需按 B 级数据要求记录。

• 障碍物避让调用制动与转向协同功能

当自动驾驶系统通过激光雷达、摄像头识别到前方突发障碍物（如行人横穿马路），系统判定需紧急避让时，会同时调用制动系统（降低车速）和转向系统（小幅偏移车道规避），并可能调用车身稳定系统（ESP）维持车辆姿态。此时，制动压力、转向角变化率、ESP 介入状态等数据属于被自动驾驶功能调用的实时控制数据，需作为 B 级数据记录，用于后续分析避让策略的有效性。

• 高精地图与定位功能被调用

在城市道路自动驾驶场景中，系统需依赖高精地图（含车道线、红绿灯位置、限速信息）规划行驶路径，并通过GNSS+IMU 组合定位确认车辆实时位置。此时，高精地图的调用状态（如地图版本、数据刷新时间）、定位模块的输出参数（如经纬度、航向角、定位精度）属于被自动驾驶功能调用的支撑性数据，若这些功能是自动驾驶决策的核心依据，则相关数据需按 B 级要求记录。

• 驾驶员状态监测系统被调用

部分自动驾驶系统（如L3 级）在特定场景下需确认驾驶员是否处于可接管状态（如系统即将退出自动驾驶时），此时会调用驾驶员状态监测系统（如摄像头识别面部表情、方向盘电容传感器检测手部接触）。若系统判定驾驶员未接管（如分心、睡着），则触发最小风险策略（如减速停车）。此时，驾驶员状态监测的输出结果（如视线方向、手部接触状态）属于被自动驾驶功能调用的关键数据，需作为 B 级数据记录，用于分析人机交互过程中的责任界定。

这些例子的核心是：当车辆的某一功能（如动力、制动、传感、定位等）并非由驾驶员直接操作，而是由自动驾驶系统主动激活并用于实现其决策目标时，该功能的运行状态与输出数据即属于“被自动驾驶功能调用的状态”，相关数据需按 B 级数据元素的要求记录，以支撑对自动驾驶系统行为逻辑的深度追溯。

有几点笔者需要说明：

首先，GB 44497 中的 A、B 级数据与 I、II 型系统不存在一一对应关系。不是I型对应A，II型对应B。

无论是I 型系统还是 II 型系统，都需按照标准要求记录 A 级数据和 B 级数据。A 级数据元素是配备自动驾驶数据记录系统的车辆应记录的数据，所以 I 型系统和 II 型系统都必须记录此类数据。B 级数据元素是在相关功能被自动驾驶功能调用时记录的数据，两种系统在遇到相应功能调用情况时，也都要记录 B 级数据。

I 型系统主要是事件触发式记录，侧重于记录基础行车数据，如车辆速度、转向信号等动态参数，在记录 A、B 级数据时，也是基于事件触发来确定具体记录时机和内容，例如碰撞事件或有碰撞风险事件发生时记录相关 A、B 级数据。II 型系统为连续记录式，除了记录时间戳事件外，还会实时连续记录数据，在碰撞风险事件中需同步存储座舱音频、驾驶员状态等复合信息，对于 A、B 级数据的记录会更全面和连续，能为事故分析等提供更丰富的数据支撑。

其次，千万不要通过定义来臆测A，B数据分类，这样容易出错。AB数据的定义是有重叠的。A的自动驾驶系统运行信息（如请求的车速、加速度、转向角、灯光状态、档位等），和B的“配备自动驾驶数据记录系统的车辆在相关功能处于被自动驾驶功能调用的状态”，是不能通过概念严格区分的。

只能对着表格用枚举的方法来区别A，B数据。

最后，我们解释一下时间段数据，时间戳数据，连续数据，锁定事件数据分别是什么？

1. 时间段数据

指在某一持续时间区间内连续记录的、反映事件过程的数据集合，能完整呈现事件从发生到结束的动态变化或者统计性数据。最典型的统计性时间段数据是平均XXX，平均速度，平均油耗等等

举例，当自动驾驶系统检测到前方车辆急减速（碰撞风险事件），从系统开始预警（如T1 时刻）到车辆完成减速避让（如 T2 时刻，持续 10 秒），这段时间内的车辆速度、与前车距离、制动压力、方向盘转角等数据，会被作为 “时间段数据” 连续记录。通过这段数据可还原整个避让过程中系统的决策逻辑和执行效果。

2. 时间戳数据

指在特定关键节点（瞬间）记录的数据，仅包含该时刻的状态信息，用于标记事件的“发生点”。

举例，自动驾驶系统激活瞬间（如驾驶员按下“自动驾驶启动键” 的 T0 时刻），记录此时的车速、档位、自动驾驶模式（如高速领航）；

系统发出驾驶员接管请求瞬间（如T3 时刻），记录此时的位置、环境障碍物距离；

系统退出自动驾驶瞬间（如T4 时刻），记录退出原因（如驾驶员接管 / 系统故障）。

这些数据仅标记关键事件的“时间点” 状态，不包含过程信息。

3. 连续数据

指按照固定时间间隔（如10ms / 次）不间断记录的数据，覆盖车辆正常行驶或特定场景下的全时段，是时间段数据和时间戳数据的基础来源。

举例，II 型系统要求记录 8 小时连续数据，包括车辆每 10ms 的实时位置（经纬度）、车速、加速度、激光雷达感知到的周边目标（如车辆、行人）的位置和速度等。即使没有发生碰撞或风险事件，这些数据也会持续存储，用于追溯长期行驶中的系统表现。

4. 锁定事件

指触发数据“强制保护” 机制的关键事件，一旦发生，相关数据会被永久锁定（不可覆盖或删除），确保用于事故分析或责任判定。锁定就是说永远不会被覆盖。

三、数据读取要求

GB 44497 花了很大篇幅来描述数据读取和相关要求。

图 数据读取流程图

1、左侧主流程（主要针对非视频文件）：

• 开始：流程启动起点。

• 进入扩展模式10₁₆03₁₆：设备进入特定的数据读取扩展工作模式，为后续操作做准备，这里的下标₁₆表示十六进制编码 。

• 数据整合31₁₆01₁₆：对要读取的数据进行整理、汇聚，按规则组合，便于传输等后续处理，31₁₆、01₁₆是对应步骤的十六进制标识 。

• 请求文件传输38₁₆：向数据存储端发送指令，申请传输相关文件数据 。

• 传输数据36₁₆：开始实际的数据传输操作，把整合好的数据向外发送 。

• 文件传输是否完成：判断传输过程是否结束，若没完成，回到“传输数据 36₁₆” 步骤继续；完成则进入下一步 。

• 退出数据传输37₁₆：传输完成后，退出数据传输状态 。

• 校验文件完整性31₁₆01₁₆：检查接收文件的数据是否完整、有无丢失或错误，保障数据可用 。

2、右侧分支流程（处理视频文件相关）：

• 解析JSON 文件：对包含数据描述等信息的 JSON 文件进行解析，获取文件相关元数据 。

• 判断是否有视频文件：依据解析结果，确定是否存在视频文件需处理，没有则直接到“退出扩展模式 10₁₆03₁₆”；有则进入下一步 。

• 请求文件传输38₁₆：和左侧流程中功能一致，申请传输视频文件 。

• 传输数据36₁₆：传输视频文件数据 。

• 文件传输是否完成：判断视频文件传输状态，没完成继续传输，完成进入下一步。

• 退出数据传输37₁₆：视频文件传输完，退出传输状态 。

• 校验文件完整性31₁₆01₁₆：检查视频文件数据完整性 。

• 视频文件是否读取完：确认所有视频文件是否都完成传输、校验，没读完回到“请求文件传输 38₁₆”（若有多个视频文件需循环处理 ）；读完进入下一步 。

• 退出扩展模式10₁₆03₁₆：所有数据读取、处理操作完成，退出扩展模式 。

• 结束：整个数据读取流程完结。

所谓扩展模式是自动驾驶数据记录系统的一种工作模式，用于支持数据读取等特定操作，与常规工作模式相对：

主要功能目的是方便数据读取。

进入扩展模式的主要目的之一是便于读取自动驾驶数据记录系统中存储的数据。如在事故调查、系统审计或数据分析时，相关人员可通过使系统进入扩展模式，实现对记录的车辆运行状态、自动驾驶系统运行信息、环境感知数据等各类数据的提取。

特殊操作支持：它为一些非常规的操作提供运行环境，这些操作可能涉及对数据的深度访问、格式转换或与外部设备的交互，以满足不同场景下对数据的处理需求。

为了方便数据读取具有如下工作特点：

数据访问权限变更：与常规模式相比，扩展模式下系统对数据的访问权限可能有所调整。在常规模式下，系统主要专注于数据的记录和存储，对数据的访问可能受到一定限制，以保证数据记录的准确性和稳定性；而在扩展模式下，为了实现数据读取等操作，系统会放宽对数据存储区域的访问限制，允许授权设备或人员读取特定的数据。

资源分配侧重变化：在扩展模式中，系统会将部分计算、存储等资源优先分配给数据读取相关的任务。例如，可能会暂停一些非关键的数据记录功能，或者降低某些实时性要求不高的监测任务的执行频率，以确保数据读取过程能够高效、稳定地进行。

从流程图可见，数据的唯一格式是JSON数据格式。

JSON是一种用纯文本的、键值对的、描述数据结构的格式，语法简洁（用 {} 表示对象、[] 表示数组、"key": "value" 表示键值对 ），能让不同系统（如车辆、服务器、分析软件）统一 “读懂” 数据。

key键是用来描述value数据是什么，可以是为value的元数据。而且允许多个键表示多种数据，并列存在。

而任何一条值（value）数据，内部又可以展开为多个键值对数据；层层展开，行测好难过树状数据结构。只不过这个树状结构使用一层层大括号{}来表示的。

A，B级JSON数据举例如下：

AEB锁定数据的JSON举例如下，锁定事件是任何情况下都不能覆盖的。

而读取数据的主要数据传输协议是DoIP协议，Diagnostic communication over Internet Protocol（基于IP网络的诊断通信协议）和UDS on IP 协议。UDS on IP 是 UDS（ISO 14229 定义的统一诊断服务）在 IP 网络环境下的具体实现，属于汽车诊断通信协议的一种。

UDSonIP（基于 IP 的统一诊断服务）和 DoIP（基于互联网协议的诊断通信）密切相关：

• 基于相同应用层协议：UDS 是一种汽车电子 ECU 环境下的诊断通讯协议，定义在 ISO 14229 中，规定了诊断服务用法、格式等。DoIP 协议通常会使用 UDS 作为其应用层协议，即 UDSonIP 是 DoIP 在应用层的具体体现，DoIP 通过封装 UDS 消息，实现车辆 ECU 与诊断设备之间的诊断通信。

• 共同实现诊断功能：二者都是为了实现车辆诊断功能而存在，旨在帮助快速准确判断车辆或某个控制器的故障及原因，为维修提供依据。诊断仪作为客户端发送请求，ECU 作为服务器响应，遵循类似 client - server 的通信方式。

二者也有以下区别

• 标准定义不同：DoIP 由 ISO 13400 标准定义，其中 ISO 13400 - 2 规定了 DoIP 传输层相关内容。UDSonIP 虽然基于 UDS，但在 IP 网络上的具体实现由 ISO 14229 - 5 标准定义，与 UDS 在 CAN 总线上实现的 ISO 14229 - 3 标准不同。

• 物理层和数据链路层不同：DoIP 基于 IEEE 802.3 以太网，物理层通常为 BroadR-Reach 或 100Base - T，数据链路层为以太网 MAC 层。而 UDSonIP 没有明确规定物理层和数据链路层，它可以基于多种网络，只要能承载 IP 协议即可，不过通常也是基于以太网等 IP 网络环境。

• 传输特性有差异：DoIP 具有更高的带宽，能处理大量数据，相比基于 CAN 总线的 UDS，其数据传输延迟更大，但由于数据格式更标准，数据传输的准确性更高，更适合如 OTA 升级等大数据量传输场景。UDSonCAN 受限于 CAN 总线的 8 字节数据帧限制，传输大量数据时需要分段，而 UDSonIP 在 DoIP 支持下可传输更大数据包。

• 功能侧重点不同：DoIP 除了实现诊断功能外，还定义了车辆网关相关要求，如车辆网络集成（IP 地址分配）、车辆基本状态信息检索、连接建立与维护等功能，更侧重于基于 IP 网络的车辆诊断系统整体架构和通信管理。UDSonIP 则更专注于在 IP 网络上实现 UDS 诊断服务，侧重于诊断服务的具体执行和数据交互。

由于二者都基于IP协议，所以都可以用于有线和无线传输，比如DoIP 可以用于无线和有线传输。具体如下：

DoIP 有线传输通常基于以太网，ISO 13400-3 定义了基于 IEEE 802.3 100Base-Tx 以太网接口的车辆通信接口以及外部测试设备的物理层及数据链路层需求。100Base-Tx 采用两对 5 类非屏蔽双绞线，一对用于发送数据，一对用于接收数据，此外还需要额外增加一根激活线，用于控制 DoIP 的使能状态。

DoIP 协议基于 TCP/IP，可通过 WLAN 等无线技术建立诊断连接，实现远程诊断、OTA 升级等功能。例如在车联网环境下，可通过真正的互联网络相互连接，利用 Internet 在远离车辆的情况下进行车辆诊断，实现智能网联汽车丰富的功能需求。

而且读取之前，要校验文件的完整性，办法是CRC校验。

图 CRC校验机制

熟悉计算机数学的人一眼就可以看出，CRC32本质是一种哈希算法，使得两段不同的二进制文件x和x'被hash映射到同一G（x）的可能性最小化（虽然不是绝对0）。如果当前读取的文件CRC值和以前记录的是一样的，说明文件没有被篡改或者缺数据，认为是完整的。而且x的次方计算是靠二进制移位来计算的，并不是真的乘法，所以计算量可控。

四、硬件性能要求，类似于域控盒子的要求

GB 44497对自动驾驶数据记录系统硬件可靠性的要求可谓巨细无遗，非常详细：

• 存储相关要求：

• 存储介质：数据应存储在车端非易失性存储器中，以确保在车辆运行过程中，即使遇到断电等情况，数据也不会丢失。

• 存储能力：Ⅰ型系统能存储的碰撞事件和有碰撞风险事件次数总体不应少于5次，且能存储的时间戳事件次数不应少于2500次；Ⅱ型系统能存储的连续数据不应少于8小时，且能存储的时间戳事件次数不应少于2500次。

• 存储覆盖机制：Ⅰ型系统中碰撞事件数据不应被覆盖，锁定事件数据优先保护；Ⅱ型系统中实时连续记录数据与时间戳事件数据不应互相覆盖，保证关键数据的完整性和可追溯性。

• 断电存储：自动驾驶系统激活期间，如碰撞事件导致自动驾驶数据记录系统无法被正常供电，自动驾驶数据记录系统应至少记录事件记录起点至事件起点的数据。

• 耐撞性能要求：在碰撞试验后，自动驾驶数据记录系统记录的数据应与试验前保持一致，确保碰撞过程中的数据能够完整保存，为事故分析提供准确依据。同时，试验后系统的绝缘电阻应大于10MΩ，防护等级需符合相关规定，以防止电气故障和外界环境对系统的影响。

• 环境适应性要求：系统应满足电气性能、防尘防水、环境耐候性、机械性能、化学负荷和电磁兼容性等多方面的车规级试验要求，需通过一系列严格的环境试验，如高温、低温、湿度变化、振动、冲击等试验，以保证在各种复杂的车载环境下都能稳定工作，试验后产品不准许损坏，且功能状态应满足相关要求。

• 数据读取要求：数据应能被正确读取和解析，支持整车和部件级别的读取。数据读取端口应符合以太网通信参数，支持基于DoIP（Diagnostic over Internet Protocol）的诊断通信，方便外部设备对记录的数据进行访问和分析。

• 安全启动要求：自动驾驶数据记录系统应具备安全启动功能，保护自动驾驶数据记录系统的可信根、引导加载程序、系统固件不被篡改，或被篡改后无法正常启动，防止恶意攻击和非法修改系统设置，确保系统运行的安全性和可靠性。

• 传感器精度要求：横向/纵向加速度传感器精度需达±10%，时间同步模块需采用汽车级晶振（精度≤50ppm），以保证数据记录的准确性和时间一致性，使得记录的车辆运动状态数据和事件时间信息可靠有效。

当然还有各种各样的测试手段，包括温循、振动，湿度等等一系列台架实验。

图 车辆域控制器，金属外壳是为了防撞和电磁屏蔽，图片来自网络

主持或者参加过域控制器设计的人一眼就可以看出，这些硬件要求（属于DV要求，design test，设计测试验证）完全是把自动驾驶记录系统当做一个域控在要求。

五、总结

从GB 44497巨细无遗地定义的自动驾驶数据记录系统来看，其强调硬件可靠性不亚于强调数据可靠性，特别还要求硬件系统在电磁干扰、极端温度、断电，逆电压以及极大冲击下能然保证数据完好，并且要及时往云端备份数据，保证数据万无一失。这显然是在按照飞机的黑匣子（飞行数据记录仪）的思路来设计自动驾驶数据记录系统。

图 飞机黑匣子，色泽鲜艳是为了便于寻找，来自网络

为了对自读驾驶数据产生速率有一个直观了解，我们用车载摄像头的数据举例如下：

1个camera，帧率为10，1秒录制的数据为1080*1080*3*10/1024/1024=33M，如果是800万像素的摄像头，单个camera一秒则产生237M的数据，10个摄像头一秒产生2.3G的数据，而且这还没有算上雷达数据的录制。所以说对于自动驾驶系统，1秒产生的数据是庞大的，对系统图像处理能力、系统带宽都有极高的要求，如果需要录制数据保存硬盘的话，硬盘读写也是要占用CPU时间片的，同时对数据存储速度有较高的要求。（参考

https://blog.csdn.net/weixin_43273308/article/details/130211251《自动驾驶硬件组成》一文）

即使保守估计，从Level 2 演进到Level 5 全自动驾驶，预计每秒钟有可能会生成10GB以上（依据车型不同而增减）的新增数据。这样庞大的数据量，即使不用全额记录，并且压缩到极致，也是需要独立的大容量的车内车外信道、存储和CPU时间（任何介质的数据读写也会占用CPU）。最好记录系统作为独立器件，才有足够的物理空间，存储空间，通信信道和芯片算力，才能满足GB 44497的要求。

所以，未来自动驾驶数据记录系统大概率会以独立域控盒子（虽然它只记录不控制）的形式，或者作为自动驾驶域控制器的组成部分，出现在各种有辅助驾驶功能的车辆中。