深入解析 wandb core 中的 Go JOSE v4：基于 RFC 7515/7516/7519 的 JWS、JWE 与 JWT 实现指南
2026/9/24 3:02:02
简介：ISO 22900-2:2017 是道路车辆模块化车辆通信接口（MVCI）系列标准中关于诊断协议数据单元（D-PDU）API 的规范性文件。这份中英文对照文档（DeePL 翻译）聚焦 D-Server 如何基于 ODX 运行时数据，将应用诊断请求转换为字节流形式的 D-PDU，再通过 D-PDU API 交付给 MVCI 协议模块，从而实现与 ECU 的通信。D-PDU 作为承载应用层请求的基本数据结构，其 API 的规范设计直接影响诊断工具的兼容性与互操作性。内容覆盖标准范围、规范性引用文件、术语定义、版本发布信息、MVCI 使用场景，并重点涉及请求转换、错误处理、数据编码、安全性、实时性等关键机制，对开发诊断协议栈、设计测试仪通信接口具有直接参考价值。资源为 1 个 docx 文件，体积约 760KB，中英文逐段对照、排版清晰，适合汽车电子诊断软件工程师、工具开发人员及测试人员对照原版学习，也可作为开发 D-PDU API 或进行标准符合性检查的速查资料。目前已有 1864 人学习下载，无论是刚接触 MVCI 概念的初学者，还是需要核对具体接口定义的资深工程师，都能从中找到有价值的信息。
1. 诊断上位机换总线就崩？D-PDU API 是分层的关键
做过诊断仪上位机的人应该都遇到过这类问题：UDS 诊断栈在 CAN 上跑得好好的，换到 DoIP 或者 CAN FD，发送请求的代码就得重写一遍，底层超时、流控、寻址模式全乱套。问题根源在于应用层诊断请求和底层协议通道耦合得太紧。ISO 22900-2:2017 的 D-PDU API 就是用来切掉这层耦合的：它定义了一个独立于总线的接口，让 D-Server 把应用请求转换成诊断协议数据单元（D-PDU），再交给 MVCI 协议模块去发送。这份资源是标准正文的中英对照译文，DeePL 翻译打底、人工校对术语，适合做诊断工具链、D-Server 或者协议模块的工程师配合原文阅读，也适合刚接触 ISO 22900-2 的人快速建立整体认知。
2. 从 ODX 运行时数据到 D-PDU 字节流：D-Server 的工作链路
2.1 MVCI 软件栈里三层各管什么
ISO 22900-2 是 MVCI（Modular Vehicle Communication Interface）系列标准的第二部分，它不直接定义硬件，而是先把软件架构分成三个层次。标准第 6 章对 Modular VCI 软件架构的描述很明确：上层是 Application，中间是 D-Server，下层是 MVCI 协议模块软件，三者之间通过标准化的接口衔接。
| 层次 | 组件 | 核心职责 |
|---|---|---|
| 上层 | Application | 运行诊断功能、测试序列、刷写流程，不关心底层是 CAN 还是 DoIP |
| 中间层 | D-Server | 基于 ODX 运行时数据信息，把应用请求解析并转换为 D-PDU 字节流 |
| 下层 | MVCI Protocol Module | 通过 D-PDU API 接收 D-PDU，按具体总线协议发送并接收响应 |
这个分层的好处在于：应用层和 D-Server 之间是诊断语义，D-Server 和协议模块之间是字节流。换句话说，换总线的时候，应用层代码基本不动，D-Server 和协议模块之间的接口也不动，只要替换 MVCI 协议模块即可。标准第 5 章提到的 OEM 跨平台 ECU、售后诊断工具支持、中央诊断数据源等用例，本质上都是靠这层抽象来降低维护成本。
2.2 ODX 运行时数据信息在转换链里的位置
摘要里有一句话点得很准：利用 ODX 运行时数据信息，D-Server 将 Application 的请求转换成字节流，称为 D-PDU。这里的 ODX（Open Diagnostic Data Exchange）提供的是诊断数据的描述信息，比如诊断会话、DID、例程、参数格式、寻址信息等。D-Server 并不是硬编码这些信息的，而是在运行时加载 ODX 数据，再根据当前请求找到对应的参数定义，最后填充成字节流。
常见做法是 D-Server 内部维护一张「请求到 D-PDU」的映射表。比如应用层发起一个读 DID 的请求，D-Server 从 ODX 运行时数据里查到该 DID 对应的地址、长度、是否需要子功能，然后组装 D-PDU。下面是一个示意结构，用来理解 D-PDU 里大致装了什么：
/* D-Server 根据 ODX 运行时数据把请求映射成 D-PDU（结构示意） */ typedef struct dpdu { uint8_t service; /* 诊断服务，如 0x22 读数据 */ uint8_t sub_function; /* 子功能或会话类型 */ uint16_t did; /* 数据标识符，来自 ODX 定义 */ uint8_t addr_mode; /* 物理寻址还是功能寻址 */ uint8_t sa; /* 源地址，来自链路配置 */ uint8_t ta; /* 目标地址，来自诊断会话 */ uint8_t payload[64]; /* 附加参数 */ uint16_t len; /* 有效长度 */ } dpdu_t;这段代码说明一件事：D-PDU 不只是一个「发出去的报文」，它包含了寻址模式、源地址、目标地址、服务参数等完整信息。sa和ta通常不是应用层传下来的，而是 D-Server 从 ODX 运行时数据和当前会话配置里取出来的。所以协议模块拿到 D-PDU 后，不需要理解诊断语义，只需要知道往哪个地址发、用什么寻址模式发。
2.3 标准对协议层提出的硬性要求
D-PDU 从 D-Server 交给协议模块，这条路径不是随便传个数组就完了。标准第 8.1 节列出了几组软件需求，其中最容易忽视的是时序、序列化和兼容性。
时序需求（8.1.3）针对的是协议处理程序消息的延迟边界，因为诊断通信里 P3、P2 这类定时器的启动点必须以字节流到达协议模块的时刻为准。序列化需求（8.1.4）解决的是多请求并发的问题：同一个逻辑链路上可能同时存在多个待发送的 D-PDU，如果协议模块内部每个线程各发各的，总线上就会乱序。常见实现是 D-PDU API 内部为每条逻辑链路维护一个发送队列，入队前做序列化，保证同一链路上的消息按顺序落到总线。
兼容性需求（8.1.5）则规定了 API 实现必须能同时支持不同厂商的协议模块，这一点在标准第 7 章的用例 2 和用例 3 里体现得很直接：多个 MVCI 协议模块可以由同一个 D-PDU API 实现管理，也可以由不同的 API 实现各自管理。后一种情况对上层是透明的，因为 API 函数入口都一样。
3. ComPrimitive 与事件回调：D-PDU API 的通信骨架
3.1 31 个 API 函数的分组视角
标准第 8.4 节从PDUConstruct到PDUGetTimestamp一共定义了 31 个 API 函数。初次接触的人容易把这些函数看成一个个孤立的接口，但实际上它们可以按生命周期和职责分成几组。
| 分组 | 函数 |
|---|---|
| 生命周期 | PDUConstruct、PDUDestruct |
| 版本与状态 | PDUGetVersion、PDUGetStatus、PDUGetLastError |
| 链路管理 | PDUCreateComLogicalLink、PDUDestroyComLogicalLink、PDUConnect、PDUDisconnect |
| 模块管理 | PDUGetModuleIds、PDUGetResourceIds、PDUGetResourceStatus、PDUModuleConnect、PDUModuleDisconnect |
| 参数配置 | PDUGetComParam、PDUSetComParam、PDUIoCtl |
| 通信原语 | PDUStartComPrimitive、PDUCancelComPrimitive |
| 事件机制 | PDUGetEventItem、PDUDestroyItem、PDURegisterEventCallback |
| 资源锁定 | PDULockResource、PDUUnlockResource、PDUGetConflictingResources |
| 多 ECU 响应 | PDUGetUniqueRespIdTable、PDUSetUniqueRespIdTable |
| 对象与时间戳 | PDUGetObjectId、PDUGetTimestamp |
这个分组不是标准给定的，但按这个视角去读源码或厂商 SDK 会清晰很多。比如PDUGetVersion和PDUGetStatus是典型的启动期探测函数，PDUGetLastError则是所有调用返回错误码后必须立刻查询的兜底函数，而不是等到最后再查。
3.2 逻辑链路与通信原语：一次诊断请求的完整生命周期
要理解 D-PDU API 的通信模型，关键是分清两个概念：ComLogicalLink 和 ComPrimitive。
ComLogicalLink 是逻辑通信链路，它把上层的通信需求和一个具体的物理信道绑定在一起。创建链路时，调用PDUCreateComLogicalLink，传入模块句柄、信道句柄和通信原语类型；之后所有通信都基于这条链路句柄进行。销毁时调用PDUDestroyComLogicalLink，把链路句柄还回去。
ComPrimitive 是通信原语，描述的是一个完整的诊断消息交互单元。发送一个请求原语，协议模块负责把它按总线的时序要求发出去，并把响应原语通过事件机制上报。标准第 8.2.6 节强调了 ComPrimitive 的使用规则：原语必须在逻辑链路的上下文里启动，不能跨链路混用。
一次典型的读 DID 流程是：创建逻辑链路 → 连接 → 设置通信参数 → 启动请求原语 → 等待响应事件 → 获取事件数据 → 销毁链路。也就是说，API 函数本身是有调用顺序的，不是想先调哪个就调哪个。工具集成商最容易犯的错误是跳过PDUConnect直接PDUStartComPrimitive，这时候 API 实现会因为链路未连接而返回错误，而返回的错误码往往还要靠PDUGetLastError才能拿到详细原因。
3.3 同步、异步与资源锁定的取舍
标准第 8.2.4 节明确说明，D-PDU API 的通信模型是异步的。PDUStartComPrimitive启动原语后立即返回，真正的发送结果和响应数据通过事件机制反馈。对于习惯写同步请求-响应代码的开发者来说，这一步需要转换思维：上层代码不能阻塞等待响应，而是要注册回调或者轮询事件队列。
资源锁定则解决了多线程环境下的竞争问题。PDULockResource和PDUUnlockResource提供的是资源级互斥，锁定期间，其他调用方不能再使用该资源发送请求。常见的使用场景是：刷写过程中，后台诊断线程想插入一个读取请求，必须先尝试锁定资源，锁不到就放弃或者排队。标准第 8.2.5 节对锁的使用给了约束：锁定必须成对出现，且锁定期间不能调用可能阻塞的 API。
事件机制有两种获取方式：PDURegisterEventCallback注册回调，或者PDUGetEventItem轮询事件队列。回调方式实时性好，适合响应时间敏感的刷写场景；轮询方式实现简单，适合上位机主循环里复用现有的事件循环。两种方式可以同时存在，但事件项的释放都必须通过PDUDestroyItem完成，否则会出现事件内存泄漏。
3.4 回调函数的实现骨架
PDURegisterEventCallback注册的回调函数原型由 API 实现定义，但常见的骨架是传入事件类型、事件数据和用户参数。下面是一个回调函数的示意实现：
/* D-PDU API 事件回调骨架，事件类型以厂商头文件为准 */ static void PDU_CALL_CONV event_callback( uint32_t event_type, /* 事件类型：接收、发送确认、错误等 */ void *event_data, /* 事件数据，对应一个 D-PDU */ void *user_arg) /* 注册时传入的用户上下文 */ { if (event_type == EVENT_TYPE_RX) { handle_rx((dpdu_event_t *)event_data); } else if (event_type == EVENT_TYPE_TX_CONFIRM) { handle_tx_confirm((dpdu_event_t *)event_data); } else if (event_type == EVENT_TYPE_ERROR) { handle_proto_error((dpdu_event_t *)event_data); } }这里的事件分类把接收、发送确认和协议错误分开了，实际 SDK 里的事件类型会更多，比如链路断开、队列溢出等。回调里执行的任务要尽量轻量，不要在回调里做耗时操作，否则会影响后续事件的分发。需要处理复杂逻辑时，把事件数据拷贝出来，投递到自己的工作线程里处理。另外，event_data指向的内存在回调返回后可能被 API 实现释放，所以不能把指针保存下来跨线程使用。
4. C 代码落地：加载 dpduapi 库、建链、发请求
4.1 动态加载 D-PDU API 实现库
D-PDU API 的实体通常以动态库形式交付，Windows 下是 DLL，Linux 下是 so。和静态链接相比，动态加载有实际的好处：标准允许多个 MVCI 协议模块由不同的 D-PDU API 实现管理（第 7 章用例 3），上层工具可能同时加载两套 API 实现，动态加载可以避免符号冲突。
用 Windows 下的 LoadLibrary/GetProcAddress 加载是常见做法：
#include <windows.h> typedef unsigned long (__stdcall *PDUGetVersion_t)(unsigned long *version); typedef unsigned long (__stdcall *PDUStartComPrimitive_t)(void *link_handle); HINSTANCE hDll = LoadLibraryA("dpduapi.dll"); if (!hDll) { /* 找不到库时，检查路径和依赖项 */ return -1; } PDUGetVersion_t pduGetVersion = (PDUGetVersion_t)GetProcAddress(hDll, "PDUGetVersion"); PDUStartComPrimitive_t pduStartComPrimitive = (PDUStartComPrimitive_t)GetProcAddress(hDll, "PDUStartComPrimitive");注意这里的函数指针签名是示意，实际参数类型要以厂商提供的头文件为准。但动态加载的模式是通用的：先加载库，再按名字取函数地址，之后所有调用都走函数指针。这样做还有一个好处是可以在日志里记录每个函数的调用耗时，方便定位性能瓶颈。库加载失败时，除了检查路径，还要确认依赖的运行时库是否齐全，很多 D-PDU API 实现依赖特定版本的 VC++ 运行库，缺了会在 LoadLibrary 阶段直接失败。
4.2 建链、连接、发送的标准调用序列
D-PDU API 的调用顺序是固定的，跳过任何一步都会在运行时暴露问题。标准流程如下：
- 调用
PDUGetVersion确认 API 版本兼容。 - 调用
PDUGetModuleIds枚举可用模块。 - 调用
PDUCreateComLogicalLink创建逻辑链路。 - 调用
PDUConnect建立连接。 - 调用
PDUSetComParam设置通信参数。 - 调用
PDUStartComPrimitive启动请求原语。 - 调用
PDUGetEventItem或等待事件回调获取响应。 - 调用
PDUDisconnect断开连接。 - 调用
PDUDestroyComLogicalLink销毁链路。
下面是这个流程在代码层面的浓缩版本：
/* D-PDU API 调用流程示例，省略了错误处理和内存释放细节 */ unsigned long api_version = 0; void *link_handle = NULL; pduGetVersion(&api_version); /* 创建逻辑链路，这里需要模块句柄、信道句柄和原语类型 */ pduCreateComLogicalLink(&module_handle, &channel_handle, &link_handle, &primitive_type); /* 连接链路 */ pduConnect(link_handle); /* 设置定时参数，比如 P2/P3 超时时间 */ pduSetComParam(link_handle, PARAM_P2_TIMEOUT, &p2_value); /* 启动请求原语 */ pduStartComPrimitive(link_handle, &request_primitive); /* 轮询事件，直到收到响应或超时 */ while (pduGetEventItem(link_handle, &event_item) == 0) { if (event_item->type == EVENT_TYPE_RX) { /* 处理响应数据 */ break; } } pduDisconnect(link_handle); pduDestroyComLogicalLink(&link_handle);这段流程里最容易出问题的是PDUSetComParam的时机。定时参数必须在PDUConnect之后、PDUStartComPrimitive之前设置，因为连接建立后协议模块才会应用这些参数。P2_TIMEOUT这类参数如果设置得过短，慢速 ECU 的响应会被当成超时；设置得过长，整个诊断流程会被拖慢。实际项目里，我一般会把 P2 设为 50ms，把 P2 扩展超时设为 5000ms，具体值要参照车辆 OEM 的诊断规范，不同的 ECU 平台差异很大。
4.3 IOCTL 命令与 TX/RX 队列控制
PDUIoCtl是 D-PDU API 里的控制通道，类似 socket 的 ioctl，用来执行标准 API 之外的底层控制。标准第 8.5 节定义的几个命令对排障特别有用：
| IOCTL 命令 | 作用 | 典型使用场景 |
|---|---|---|
| PDU_IOCTL_RESET | 复位协议模块或信道 | 协议栈卡死时强制复位 |
| PDU_IOCTL_CLEAR_TX_QUEUE | 清空发送队列 | 丢弃积压的请求 |
| PDU_IOCTL_SUSPEND_TX_QUEUE | 挂起发送队列 | 流控暂停发送 |
| PDU_IOCTL_RESUME_TX_QUEUE | 恢复发送队列 | 流控恢复 |
| PDU_IOCTL_CLEAR_RX_QUEUE | 清空接收队列 | 丢弃残留响应 |
举个例子，在刷写过程中如果上层逻辑需要暂停发送，但不想断开连接，挂起发送队列是比用资源锁更轻量的方式。PDU_IOCTL_SUSPEND_TX_QUEUE挂起后，后续的PDUStartComPrimitive仍然可以调用，但消息会积压在队列里，直到PDU_IOCTL_RESUME_TX_QUEUE恢复。这种机制比阻塞在发送调用里要安全得多，因为超时控制仍然掌握在上层手里。
5. 多模块冲突、UniqueRespIdTable 与时间戳：收尾必看的边界
5.1 资源冲突比想象中常见
PDUGetConflictingResources这个函数看起来不起眼，但在多模块场景下作用很大。当一个 API 实现管理多个 MVCI 协议模块时，两个模块可能共享同一个物理信道，比如一个模块占用 CAN 总线，另一个模块也试图使用同一信道，冲突就产生了。调用PDUGetConflictingResources可以在启动原语之前检查资源占用情况，避免发送到一半才发现冲突。常见做法是在每次PDUConnect之后调用一次，把冲突结果记录到日志里。
5.2 UniqueRespIdTable 解决多 ECU 响应匹配
PDUGetUniqueRespIdTable和PDUSetUniqueRespIdTable解决的是一个很实际的痛点：功能寻址发出去的请求，可能会有多个 ECU 同时响应，而协议模块需要根据响应地址区分来源。标准允许协议模块维护一张唯一响应标识表，PDUSetUniqueRespIdTable把需要关注的响应地址写入表中，不在这张表里的响应会被过滤掉。对工具集成商来说，这个机制比在应用层自己过滤更高效，因为过滤发生在协议模块内部，可以减少上位机的无效中断和事件流量。
5.3 时间戳的一致性
PDUGetTimestamp返回的通常是协议模块的时间戳，用于关联发送请求和接收响应的时序。标准第 8.1.6 节对时间戳有明确要求，实现必须提供单调递增的时间参考，不能因为系统时钟调整而回退。抓取总线报文做离线分析时，D-PDU 时间戳和抓包工具的时间戳之间的偏移需要做校准。我一般会在每次会话开始时，同时读一次PDUGetTimestamp和本机系统时钟，计算固定偏移量，后续分析就按这个偏移量换算。
5.4 中英对照文档的阅读建议
这份中英对照译文在术语上花了不少功夫，但机器翻译和人工校对混合的文档，读的时候要留意几个点。ComLogicalLink在不同章节可能被译成「通信逻辑链路」或「逻辑通信链路」，对照原文时优先看英文括号。ComPrimitive这类复合词，DeePL 常直译为「通信原语」，项目内部建议固定术语表后再让团队统一使用。另外，标准正文里的 OCR 残留字符（比如目录页的页码粘连）不影响正文阅读，但引用条款号时最好回原文核对一遍。
本文还有配套的精品资源，点击获取