一、背景
随着汽车技术，特别是新能源汽车的快速发展，车载电控单元数量激增，激光雷达、视频图像等高带宽数据的需求日益增长，传统的CAN总线已逐渐难以满足高效传输的要求。在此背景下，DoIP（以太网诊断协议）等新型通信协议应运而生。
近期，我们项目涉及 DSSAD （数据存储系统，用于自动驾驶）的相关开发。随着L3级自动驾驶在2025年逐步进入标准化与法规化阶段，主流主机厂大多已将其集成至域控制器中。然而，在试验车辆或为通过L3准入而必须加装的自动驾驶记录仪（即"自动驾驶黑匣子"）等领域，仍存在一定的市场机会。该设备本质上是对传统EDR（事件数据记录系统）在自动驾驶维度上的功能扩展。
本文旨在结合项目实践，对国标 《GB/T 44497-2024》 进行解读并提出部分实施建议，同时梳理其数据记录流程与报文拼接逻辑。该标准将记录系统分为I型 与II型 ：I型记录数据相对精简，主要针对时间段事件与时间戳事件；II型 则要求更为全面，至少需要连续存储8小时以上的数据其中包括视频和图片，有的主机厂要求增加激光雷达数据信息的记录，这对车辆的本地存储能力提出了新的挑战。那么我们如何才能赢得市场呢？更低的价格、更高的性能。我想会是一个比较好的方面对于成本严格把控的主机厂来说。
二、国标的相关解读（参考了其他网址的图片）
2.1 不同型系统对应的种类
2.2 不同型系统对于记录的数据要求及数据元素分类
2.3 存储能力的计算（大约）
三、doip的通信流程
3.1 链接流程及其报文
根据国标GB/T 44497-2024与相关协议规定，通过DoIP读取自动驾驶数据记录系统（DSSAD）数据的完整通信流程如下。请注意，流程中ECU的逻辑地址（0x0E01）为占位符，实际地址需由主机厂提供并在车辆说明书中明确。
通信流程概览
整个流程遵循 **GB/T 43258.2 (DoIP)** 与 **GB/T 40822 (UDS)** 标准，采用物理寻址，主要分为：建立连接、数据整合、请求文件、传输数据、校验完整性及处理辅助文件等阶段。
阶段一：建立诊断连接
- **路由激活**
* **目的**：在DoIP层建立连接。
* **请求**：`02 fd 00 05 00 00 00 07 0f 80 00 00 00 00 00`
* **肯定响应**：`02 fd 00 06 00 00 00 09 0f 80 0e 01 10 00 00 00 00`
- **维持会话（TesterPresent）**
* **目的**：保持诊断会话激活，需**每2秒发送一次**。
* **请求**：`02 fd 80 01 00 00 00 06 0f 80 0e 01 3e 00`
* **肯定响应**：`02 fd 80 02 00 00 00 06 0e 01 0f 80 7e 00`
- **进入扩展会话**
* **目的**：使ECU进入可执行特定服务的模式。
* **请求**：`02 fd 80 01 00 00 00 06 0f 80 0e 01 10 03`
* **肯定响应**：`02 fd 80 02 00 00 00 06 0e 01 0f 80 50 03`
阶段二：数据整合
此阶段用于按需整合事件数据，为文件生成做准备。
- **读取VIN（车辆识别码）**
* **目的**：获取车辆VIN，用于后续构造文件名。
* **请求**：`02 fd 80 01 00 00 00 07 0f 80 0e 01 22 f1 90`
* **肯定响应**：`02 fd 80 02 00 00 00 18 0e 01 0f 80 62 f1 90 56 49 4e...` （含VIN ASCII码）
- **整合事件数据（RoutineControl - 0x31）**
* **目的**：驱动ECU按条件整合"时间戳事件"或"时间段事件"数据。
* **关键**：时间范围（BCD码）或事件序号需**自行构建**。
* **a. 时间戳事件整合**
* **请求**：`02 fd 80 01 00 00 00 16 0f 80 0e 01 31 01 f1 aa [开始时间BCD] [结束时间BCD]`
* **肯定响应（成功）**：`...71 01 f1 aa 00`
* **否定响应**：`...7f 31 31` （可能因时间超范围或无数据）
* **b. 时间段事件整合**
* **请求**：`02 fd 80 01 00 00 00 09 0f 80 0e 01 31 01 f1 ac [事件序号]`
* **肯定响应（成功）**：`...71 01 f1 ac 00`
**阶段三：请求与传输数据文件
- **请求文件传输（RequestFileTransfer - 0x38）**
* **目的**：请求ECU准备指定的数据文件（JSON格式）以供下载。
* **关键**：文件路径为 `/var/DSSAD/<文件名>`，路径长度需**自行计算**。文件名中的 `XXXXXXXXXXXXXXXXX` 需替换为**实际读取的VIN**。
* **a. 请求时间戳事件文件**
* **示例请求**：`02 fd 80 01 ... 38 10 00 34 2f 76 61 72...` (路径: `/var/DSSAD/VIN*********_CN-DSSAD_Timestamp.json`)
* **b. 请求时间段事件文件**
* **示例请求**：`02 fd 80 01 ... 38 10 00 38 2f 76 61 72...` (路径: `/var/DSSAD/VIN*********_CN-DSSAD_Time-Sequence.json`)
* **肯定响应**：`02 fd 80 02 00 00 00 10 0e 01 0f 80 78 10 02 04 00 00 00 04 03 11 8a 11`
- **传输数据（TransferData - 0x36）**
* **目的**：分块传输文件数据流。
* **关键**：块序列计数器从 `0x01` 开始，每次请求递增，至 `0xFF` 后重置为 `0x00`。
* **请求**：`02 fd 80 01 00 00 00 06 0f 80 0e 01 36 [块计数器]`
* **肯定响应**：包含实际文件数据（如JSON内容）。
- **退出数据传输（RequestTransferExit - 0x37）**
* **目的**：结束当前文件的传输流程。
* **请求**：`02 fd 80 01 00 00 00 05 0f 80 0e 01 37`
* **肯定响应**：`02 fd 80 02 00 00 00 05 0e 01 0f 80 77`
**阶段四：校验与辅助文件处理**
- **校验文件完整性**
* **目的**：获取文件的CRC32值，用于验证传输完整性。
* **请求**：`02 fd 80 01 00 00 00 08 0f 80 0e 01 31 01 f1 ab`
* **肯定响应**：`...71 01 f1 ab [CRC32值]` （需**自行计算比对**）
- **解析JSON并读取辅助文件**
* **目的**：若JSON中引用了视频/图像文件，需循环读取。
* **流程**：对每个辅助文件路径，重复执行 **步骤6至9**。
* **注意**：请求路径通常为 `/var/DSSAD/...`，ECU内部会映射到实际存储位置（如 `/data/...`）。
**阶段五：结束诊断**
- **退出扩展会话**
* **目的**：使ECU返回默认会话模式。
* **请求**：`02 fd 80 01 00 00 00 06 0f 80 0e 01 10 01`
* **肯定响应**：`02 fd 80 02 00 00 00 06 0e 01 0f 80 50 01`
**总结**：本流程以标准服务为基础，实际开发中需重点注意 **ECU逻辑地址、时间/序号参数构建、文件路径动态生成（基于VIN）、CRC校验** 等需根据实际情况填充或计算的部分。