前阵子在做售后诊断仪的小项目核心任务之一就是把车辆的VIN码和生产日期读出来显示在设备屏幕上。听起来是个挺基础的功能但真正调试起来才发现这背后牵扯到CAN总线报文格式、UDS诊断服务、ISO-TP多帧重组、不同厂商的编码习惯甚至还有协议文档缺失时的“逆向”工作。这篇就围绕这段“读VIN号和日期”的诊断开发代码把从原理到落地、从踩坑到工程化改造的完整过程拆开聊聊希望能给正在搞嵌入式诊断、售后工具、产线检测的朋友一些参考。1. 先把VIN码和日期在诊断协议中的位置摸清楚很多人拿到这类任务的第一反应是“直接发个读请求不就行了”结果抓包一看总线上一堆报文根本不知道哪条才是自己想要的。要读VIN码和日期至少得先搞明白三件事这个数据在ECU内部长什么样、诊断协议里通过什么服务去取、CAN总线上怎么定地址。1.1 VIN码为什么是17个ASCII字节VIN码是车辆识别代号全球标准里固定17位字符由世界制造商识别码WMI、车辆描述部分VDS、车辆指示部分VIS组成。工程上讲它在诊断协议里就是一个“内存段”每个字符按ASCII码方式存储一个字符占一个字节所以读出来就是17个字节。举个例子一个虚构的VIN码“LA123456789012345”在诊断响应里实际是这样排布的0x62 0xF1 0x90 0x4C 0x41 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x34 0x35其中0x62是0x22服务的正响应标识0x22 0x400xF1 0x90是我们要读的数据标识符DID后面17个字节就是ASCII字符。理解了这一点解析逻辑其实就很机械了定位到数据字段按ASCII转成字符再拼成字符串。1.2 “日期”在诊断报文里经常不是人话生产日期的存储格式比VIN麻烦得多。VIN至少还是统一的ASCII字符日期则可能遇到三种完全不同的编码BCD编码每个字节的高四位和低四位各表示一个十进制数比如0x20表示年份的“20”0x24可能表示月份的“24”这明显非法所以还要做合理性校验。常见格式是年、月、日各占一个字节或者年、月、日、时、分占五个字节。ASCII编码直接存字符串“2024-05-08”一个字符一个字节总共10字节。有些ECU还会存成“20240508”8字节。生产周格式这是最恶心的。整车厂排产按周维度管理所以某些ECU只存“年份 第几周”比如两个字节0x24 0x19表示2024年第19周。如果你想在界面上显示精确到日还得自己写一套“周数转日期”的算法。我在代码里统一封装了解析函数先通过配置决定用哪种格式再按对应规则解析。后面会给出具体实现但有一点必须先强调拿到日期原始字节后第一件事不是解析而是先用CAN抓包工具看一遍真实响应长度和字节值确定格式再动手。1.3 读取它们用的服务UDS 0x22与DID诊断协议里有一套服务ID的约定读数据统一用UDS服务0x22 ReadDataByIdentifier。这个服务的特点是“请求里告诉ECU你想读哪个DIDECU就把那个DID对应的数据返回给你”。请求格式是0x02 0x22 0xF1 0x90其中0x02是单帧PCI字节表示后续有效数据长度为2字节0x22是服务ID0xF1 0x90是DID这个地址是ISO标准里推荐的VIN码存储位置。日期类的DID并没有全球统一的标准我用0xF1C0、0xF1C1这类地址时都是通过抓包或者逆向配置确认过的。还有一个细节是CAN标识符。诊断通信里通常有“物理寻址”和“功能寻址”两种方式。功能寻址一般是0x7DF发出去后总线上所有支持该服务的ECU都可能响应适合做“全局读取”或“扫描ECU列表”物理寻址是请求ID0x7E0、响应ID0x7E8这只是常见示例值具体取决于整车网络配置只发给指定的ECU。读VIN这种数据几乎都是用物理寻址因为VIN是车上的唯一身份标识只存在某一个ECU里。如果发功能寻址多个ECU同时响应就会造成CAN总线冲突抓包时一片混乱。2. 请求侧代码构造一条能读到VIN码和日期的CAN诊断帧原理清楚了之后就可以落到代码上了。我习惯把诊断请求拆成“构造请求”“发送CAN帧”“等待并接收响应”三个独立模块方便在多个DID之间复用。2.1 整个读取过程的时序设计实际项目里读取VIN和日期的完整流程大致是初始化CAN控制器配置对应通道的波特率常规是500kbps老一点的车可能是250kbps设置滤波器允许接收指定响应ID。构造0x22请求报文添加必要的ISO-TP PCI字节。将请求报文发送到CAN总线。等待ECU响应。要注意这里不是简单的“收到一帧就完事”因为VIN响应很可能超过单个CAN帧的8字节载荷必须按ISO-TP协议处理多帧。对完整的诊断响应做解析把VIN和日期转换成人能看的格式。处理超时、错误响应0x7F、总线忙等异常情况。2.2 请求字节怎么拼单帧还是多帧对于读取VIN和日期这种两个DID各2字节的请求请求方向一直是单帧因为有效数据只有4字节以内。单帧的PCI字节格式是高四位为0x0表示单帧低四位表示后续有效数据长度。所以0x02 0x22 0xF1 0x90里的0x02就是“单帧 后面有2字节数据”。这里有一个容易混淆的地方0x22 0xF1 0x90三个字节服务ID 2字节DID为什么PCI长度写的是0x02因为PCI里面的长度指的是“除PCI字节以外的有效数据长度”也就是服务ID和参数的总长度不包括PCI自己。很多初学者在这里算错长度导致ECU直接不回响应。2.3 核心代码片段下面是我在项目里使用的简化版C代码清楚展示了构造请求和发送的过程#include stdint.h #include string.h #define CAN_ID_REQUEST 0x7E0 /* 物理请求ID示例值 */ #define CAN_ID_RESPONSE 0x7E8 /* 物理响应ID示例值 */ #define DIAG_SID_READ 0x22 #define DID_VIN 0xF190 /* VIN码标准推荐DID */ #define DID_DATE 0xF1C0 /* 生产日期项目自定义DID */ typedef struct { uint32_t can_id; uint8_t data[8]; uint8_t len; } CanFrame; /** * 构造一个0x22读请求报文 * param did 要读取的数据标识符 * param frame 输出的CAN帧 */ void diag_build_read_request(uint16_t did, CanFrame *frame) { frame-can_id CAN_ID_REQUEST; frame-len 4; /* PCI SID DID(2字节) */ frame-data[0] 0x02; /* 单帧后续2字节 */ frame-data[1] DIAG_SID_READ; /* 0x22 */ frame-data[2] (uint8_t)(did 8); /* DID高字节 */ frame-data[3] (uint8_t)(did 0xFF); /* DID低字节 */ } /** * 将CAN帧发送到总线这里假设hal层已经实现了can_send_frame */ void diag_send_request(uint16_t did) { CanFrame tx; diag_build_read_request(did, tx); can_send_frame(tx); /* 具体平台函数按实际接口替换 */ }实际项目中我会在diag_build_read_request里加一个返回值方便确认PCI长度是否合法。还可以把“填充CAN帧ID”的逻辑抽出去因为不同车型的诊断ID可能不同通过配置表管理会更灵活。3. 响应侧代码把原始字节变成能看的字符串请求发出去之后真正花时间调的是响应处理。ECU返回的数据可能是一个CAN帧也可能是好几个连续的CAN帧必须先重组再解析。3.1 单帧/首帧/连续帧的判断ISO-TP协议里CAN帧的第一个字节叫PCI字节根据高四位区分帧类型0x0单帧低四位表示数据长度。0x1首帧表示后面还有连续帧实际总长度在第二字节。0x2连续帧按顺序拼接前面首帧的数据。0x3流控帧一般是接收方向发送方做流量控制用的读取VIN时如果ECU响应较小不一定需要。我写了一个简化的接收重组逻辑typedef struct { uint8_t buf[256]; /* 重组缓冲区 */ uint16_t len; /* 当前已接收长度 */ uint16_t total; /* 完整响应总长度 */ } IsoTpReceiver; /** * 处理每一帧CAN数据 * param recv 接收器上下文 * param data 当前帧数据 * param len 当前帧数据长度 * return 1表示完整响应已收齐0表示还需要更多帧 */ int isotp_feed_frame(IsoTpReceiver *recv, uint8_t *data, uint8_t len) { uint8_t pci data[0]; uint8_t type pci 4; if (type 0x0) { /* 单帧 */ uint8_t dl pci 0x0F; if (dl 7) dl 7; memcpy(recv-buf, data[1], dl); recv-len dl; recv-total dl; return 1; } if (type 0x1) { /* 首帧第二字节为完整响应总长度 */ recv-total ((uint16_t)(pci 0x0F) 8) | data[1]; recv-len 0; /* 首帧后续部分也要拼接 */ uint8_t seg_len len - 2; memcpy(recv-buf[0], data[2], seg_len); recv-len seg_len; return (recv-len recv-total) ? 1 : 0; } if (type 0x2) { /* 连续帧最大可带7字节数据 */ uint8_t seg_len len - 1; if (recv-len seg_len recv-total) { seg_len recv-total - recv-len; } memcpy(recv-buf[recv-len], data[1], seg_len); recv-len seg_len; return (recv-len recv-total) ? 1 : 0; } return 0; }这个代码是标准的ISO-TP处理逻辑。实际项目里还要处理超时清空缓冲区、连续帧序号回绕等问题但核心思路就是“先攒全再解析”。3.2 VIN解析先裁剪再转ASCII当响应完整收齐后缓冲区里的数据一般是这样的0x62 0xF1 0x90 4C 41 31 32 33 34 35 36 37 38 39 30 31 32 33 34 350x62是正响应服务ID0xF1 0x90是DID回显从偏移3开始才是数据。解析VIN时要注意的是“必须以实际DID响应的数据长度为准”而不是无脑取17字节。有些ECU会有额外字节我后面会讲到这个坑。下面是VIN解析函数/** * 从ISO-TP重组后的完整响应中解析VIN码 * param resp 响应缓冲区 * param resp_len 响应总长度 * param vin_out 输出VIN字符串长度至少18字节 * return 成功返回0失败返回-1 */ int parse_vin(uint8_t *resp, uint16_t resp_len, char *vin_out) { if (resp_len 3) { return -1; /* 不可能合法 */ } /* 判断正响应第一个字节应该是0x62 */ if (resp[0] ! 0x62) { return -2; /* 负响应或非期望服务 */ } /* DID回显校验防止解析错数据 */ if (resp[1] ! 0xF1 || resp[2] ! 0x90) { return -3; } uint16_t offset 3; uint16_t payload_len resp_len - offset; if (payload_len 17) { return -4; /* VIN数据不足17字节 */ } uint16_t i; for (i 0; i 17; i) { vin_out[i] (char)resp[offset i]; /* 简单合法性检查可打印ASCII字符 */ if (vin_out[i] 0x20 || vin_out[i] 0x7E) { return -5; } } vin_out[17] \0; return 0; }为什么先做合法性检查因为抓包时经常能发现某些字节是0x00、0xFF之类的异常值多半是DID配置错误或者数据段偏移量不对。打印出来的VIN是乱码一看就知道定位偏了。3.3 日期解析三种格式的统一处理日期解析要做的第一件事是“识别格式”我建议把格式类型做成配置项而不是在代码里写死。typedef enum { DATE_FMT_BCD 0, /* 年/月/日 各一个BCD字节 */ DATE_FMT_ASCII 1, /* YYYY-MM-DD ASCII字符串 */ DATE_FMT_WEEK 2, /* 年份 生产周 */ } DateFormat; /** * BCD字节转十进制数 */ static uint8_t bcd_to_dec(uint8_t bcd) { return (uint8_t)(((bcd 4) 0x0F) * 10 (bcd 0x0F)); } /** * 解析生产日期 * param resp 响应缓冲区 * param resp_len 响应总长度 * param fmt 日期格式 * param year 输出年份如2024 * param month 输出月份 * param day 输出日 * return 成功返回0失败返回-1 */ int parse_date(uint8_t *resp, uint16_t resp_len, DateFormat fmt, uint16_t *year, uint8_t *month, uint8_t *day) { if (resp_len 3) return -1; if (resp[0] ! 0x62) return -2; /* 这里示例读取DID为0xF1C0回显校验略 */ uint16_t offset 3; /* 数据起始偏移 */ if (fmt DATE_FMT_BCD) { if (resp_len - offset 3) return -3; uint16_t y bcd_to_dec(resp[offset]); uint8_t m bcd_to_dec(resp[offset 1]); uint8_t d bcd_to_dec(resp[offset 2]); if (m 1 || m 12 || d 1 || d 31) return -4; *year 2000 y; /* 这里按2000年基准处理完整项目里要配置世纪基准 */ *month m; *day d; return 0; } if (fmt DATE_FMT_ASCII) { /* 期望 YYYY-MM-DD 或 YYYYMMDD */ char str[16]; uint16_t data_len resp_len - offset; if (data_len 8) return -3; memcpy(str, resp[offset], data_len 15 ? 15 : data_len); str[data_len] \0; /* 简单用字符串解析实际项目可以用标准库 */ if (strlen(str) 10 str[4] -) { *year (uint16_t)((str[0] - 0) * 1000 (str[1] - 0) * 100 (str[2] - 0) * 10 (str[3] - 0)); *month (uint8_t)((str[5] - 0) * 10 (str[6] - 0)); *day (uint8_t)((str[8] - 0) * 10 (str[9] - 0)); return 0; } else if (strlen(str) 8) { *year (uint16_t)((str[0] - 0) * 1000 (str[1] - 0) * 100 (str[2] - 0) * 10 (str[3] - 0)); *month (uint8_t)((str[4] - 0) * 10 (str[5] - 0)); *day (uint8_t)((str[6] - 0) * 10 (str[7] - 0)); return 0; } return -4; } if (fmt DATE_FMT_WEEK) { if (resp_len - offset 2) return -3; uint16_t y bcd_to_dec(resp[offset]); uint8_t week bcd_to_dec(resp[offset 1]); /* 周转日期的算法需要查表这里示意性地返回一个无效日期 */ *year 2000 y; *month 0; *day week; return 0; } return -5; }这段代码有两个细节值得说明一是BCD解析时做了月份、日期的合理性检查能有效避免“读错字节位”导致显示离谱日期二是ASCII格式解析必须在前面判断分隔符有些ECU返回的是带横杠的有些没有。实际项目中我还遇到过“日期DID返回8字节但最后两字节是补位0xFF”的情况所以解析前同样要做数据长度裁剪。4. 实测中必须面对的“不按套路出牌”代码写完只是开始。真正连上实车抓包调试时你会发现这些“不按套路出牌”的情况几乎人人都会遇到。4.1 坑1说好的17字节怎么多出两字节第一次实车测试我发0x22 0xF1 0x90读VIN抓包看到响应总长度是19字节而不是想象的20字节3字节头 17字节数据。打印出来一看VIN码是读到了但后面还跟着两个字节的辅助信息有的是0xFF 0xFF有的则是整车的生产序号。根因是某些ECU在VIN这个DID后面又追加了别的数据或者在VIN数据后面填充了歧义性的补位字节。解决思路是先抓包看完整响应确认数据长度。解析时不要从固定偏移直接取17字节而是先判断数据区实际长度是否大于等于17。截取时严格按DID定义和数据区的已知布局来多余字节直接丢弃。我后来把VIN解析改成“先判断长度再修剪最后校验可打印字符”这样即使厂商追加了额外字段也不会污染VIN字符串。4.2 坑2日期格式的“窗口期”现象有次测试时日期解析一直报错抓包发现返回的字节看起来是ASCII格式但我代码配置成BCD。我把响应打出来看32 30 32 34 30 35 30 38这其实是ASCII的“20240508”但如果不看抓包光从字节离线分析很容易当成BCD——320x20看起来像年份20300x24像月份24这明显是解析错位了。这个坑给我最大的教训是永远不要假设ECU的存储格式。在正式写解析代码之前一定要先让ECU响应原始字节直接十六进制打印出来观察。尤其在同一个项目里可能有多个车型平台共用一套诊断仪软件每个平台返回的日期格式不一定一样。我在工程上给出的方案是复杂项目里为每个车型平台维护一个“诊断数据格式表”包括DID地址、数据长度、日期编码格式、世纪基准等信息全部通过配置文件加载。这样即便哪天新增了一个车型也不用改C代码只改配置就行。4.3 坑3多帧响应别只读第一帧这是我个人早期踩得最惨的坑。当时图省事接收响应只处理单帧测试普通DID没问题直到读VIN时傻眼了ECU明明回复了但程序一直超时。原因很好理解VIN的完整响应是0x62 DID(2) 17字节 20字节超过单帧最大7字节有效载荷所以ECU按ISO-TP发了一个首帧加两个连续帧。如果没有做多帧重组应用层拿到首帧的6字节数据就以为结束了自然解析失败。解决方式就是我前面写的isotp_feed_frame函数。实际工程里还可以借用开源CAN栈的ISO-TP实现比如Linux内核的can-isotp模块或各MCU厂商自带的诊断协议栈。但无论用什么都必须把重组逻辑和解析逻辑分开这样测试时也更容易定位问题。4.4 坑4没有协议文档DID地址全靠逆向整车厂或Tier 1给诊断仪开发商提供的协议文档有时候并不完整。尤其是一些“非标准”DID比如生产日期、配置版本号、软件升级日期文档可能只写了一个字待定。遇到这种情况我推荐一个优先顺序先翻整车厂公开发布的DID表再去网上找同平台车型的诊断抓包案例最后才是在实车上“扫DID”——也就是遍历已知范围内的DID地址观察哪些地址有合法响应。扫描时要注意频率不要太快以免ECU进入总线休眠或者过载。需要注意0xF190这个VIN DID在ISO标准里是推荐值多数ECU会支持。但日期类DID每个厂商差异很大甚至同一个厂商的轿车和商用车平台都不一样。在没有文档的情况下最稳妥的方式是拿一台已知配置的实车从ECU的“系统信息”界面看到生产日期然后反向比对抓包的DID响应确认地址对应关系。4.5 坑5CAN ID和滤波器配置错了还有一个常见的低级错误请求ID和响应ID不对应。有些平台的诊断请求ID不是0x7E0而是0x7E8或0x18DB33F1扩展帧格式响应ID也不一定是请求ID8。我就遇到过请求发出去CAN总线完全没有回应排查半天发现滤波配置只接收了一个完全无关的ID。排查这类问题的办法是先用CAN卡或分析仪监听总线确认ECU到底是否响应、响应ID是多少。检查CAN控制器接收滤波寄存器确保响应ID在放行名单里。确认诊断通信走的是标准帧还是扩展帧ISO-TP在两种帧格式下的PCI字节规则相同的但CAN ID长度不同滤波配置也不一样。另外还要关注“哪条CAN网络”现在的车通常有好几条CAN总线动力CAN、车身CAN、信息娱乐CAN。VIN可能在车身域控也可能在网关里。如果诊断仪从动力CAN入口发请求得到的响应可能不在物理寻址的预期节点上。开始测试前最好先确认ECU挂在哪条总线上。5. 从“能读出来”到“项目能用”的工程化改造调试阶段跑通之后距离“交付给客户使用”还差得很远。下面这几个改造点我几乎在每一个诊断开发项目里都会做。5.1 用DID映射表替代写死的if-else前面代码里解析VIN固定写死DID日期也固定用一个DID。真实项目里同一个0x22服务可能对应几十个DID如果每个解析逻辑都写一个函数和一群if-else代码很快就会变得不可维护。我的做法是面向DID建一张表typedef struct { uint16_t did; uint16_t data_len; /* 期望的数据长度0表示不确定 */ DateFormat date_fmt; /* 如果这个DID是日期记录格式 */ int (*parse_func)(uint8_t *resp, uint16_t resp_len, char *out, uint16_t out_len); } DidMapEntry;初始化和查表逻辑很简单本质就是把“DID地址”和“解析动作”解耦。新增一个DID时只需要增加表项和解析函数不需要改主流程。对量产工具来说这样扩展成本极低。5.2 超时重试与诊断状态机真实ECU并不是每次都能响应。总线繁忙、ECU内部在跑其他任务、网络被网关限流都可能导致请求石沉大海。所以我从不写“发一次就死等”的阻塞代码而是设计一个小的诊断状态机状态1发送请求。状态2等待响应设置超时200~500ms。状态3收齐ISO-TP数据解析数据。状态4失败则进入重试计数超过3次后上报错误。#define DIAG_TIMEOUT_MS 300 #define DIAG_RETRY_COUNT 3 int diag_read_did_safe(uint16_t did, uint8_t *resp, uint16_t *len) { int retry; for (retry 0; retry DIAG_RETRY_COUNT; retry) { diag_send_request(did); if (diag_wait_response(resp, len, DIAG_TIMEOUT_MS) 0) { return 0; /* 成功 */ } /* 等待一帧间隔避免总线冲突 */ delay_ms(50); } return -1; /* 重试次数用尽 */ }超时时间不能太短尤其是ISO-TP多帧传输时ECU的首帧和连续帧之间可能存在间隔也不能太长否则诊断界面卡顿明显。300ms是我常用的起步值具体项目根据实测调整。5.3 数据校验、日志与异常兜底解析出的VIN或日期在上屏之前建议再做一道“业务层校验”VIN长度必须为17且每一位都是可打印ASCII。VIN的第9位是校验位可以根据ISO 3779规定的算法验证如果校验失败可能说明读取到了错误DID的数据。日期必须合法比如月份1-12日期1-31年份不能早于车辆下线年份减去10年。日志是诊断开发里看不见但极其重要的工程化环节。每一次收发最好都以结构化格式记录时间戳、CAN ID、方向、原始字节、解析结果。这样在现场出问题时只需要把日志发回来就能快速还原总线通信过程。我之前的习惯是把所有诊断帧同时存成两种格式可读文本和十六进制原始帧后者方便用工具做协议对比。5.4 后续扩展批量读、安全访问与更复杂场景这个例子虽然只讲了VIN码和日期但同样的思路可以扩展到很多场景批量读取多个DID把多个读请求放进队列状态机逐个发送、统一收集结果在界面上做成一个“车辆信息总览”页面。写数据服务0x2E比如写VIN码、写配置信息逻辑和读正好对称只是请求里多了数据段还要注意“安全访问”服务0x27的种子-密钥流程。带子功能的读取有些DID需要先通过ID标识符子功能才能读到比如先进入特定的诊断会话。备份与刷写车厂售后场景里经常要在刷写前读取VIN/软硬件版本号读完的这些数据最终要进入刷新流程决定刷哪个版本的固件。工程化改造的核心原则只有一个把能配置的尽量配置化把能重试的尽量可重试把可能出问题的每一步都留好日志。诊断代码写得再花哨最终目的都是现场少出一次“连不上”的问题。最后再分享一个工作习惯接手的任何一个诊断项目我都不会急着写满代码而是先用一块CAN分析仪把目标ECU对0x22服务的真实响应抓出来看一遍确认每个DID的返回长度、格式、起始偏移然后再开始解析层编码。这个习惯让我的返工率低很多。诊断开发的本质就是“和ECU对话”如果连对方的语言习惯都没搞清楚代码写得再漂亮也白搭。 
长河君 · 2026/10/13 23:03:50 · 阅读 1.2k CAN总线诊断开发实践：UDS读取VIN码与生产日期的踩坑记录
前阵子在做售后诊断仪的小项目核心任务之一就是把车辆的VIN码和生产日期读出来显示在设备屏幕上。听起来是个挺基础的功能但真正调试起来才发现这背后牵扯到CAN总线报文格式、UDS诊断服务、ISO-TP多帧重组、不同厂商的编码习惯甚至还有协议文档缺失时的“逆向”工作。这篇就围绕这段“读VIN号和日期”的诊断开发代码把从原理到落地、从踩坑到工程化改造的完整过程拆开聊聊希望能给正在搞嵌入式诊断、售后工具、产线检测的朋友一些参考。1. 先把VIN码和日期在诊断协议中的位置摸清楚很多人拿到这类任务的第一反应是“直接发个读请求不就行了”结果抓包一看总线上一堆报文根本不知道哪条才是自己想要的。要读VIN码和日期至少得先搞明白三件事这个数据在ECU内部长什么样、诊断协议里通过什么服务去取、CAN总线上怎么定地址。1.1 VIN码为什么是17个ASCII字节VIN码是车辆识别代号全球标准里固定17位字符由世界制造商识别码WMI、车辆描述部分VDS、车辆指示部分VIS组成。工程上讲它在诊断协议里就是一个“内存段”每个字符按ASCII码方式存储一个字符占一个字节所以读出来就是17个字节。举个例子一个虚构的VIN码“LA123456789012345”在诊断响应里实际是这样排布的0x62 0xF1 0x90 0x4C 0x41 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x34 0x35其中0x62是0x22服务的正响应标识0x22 0x400xF1 0x90是我们要读的数据标识符DID后面17个字节就是ASCII字符。理解了这一点解析逻辑其实就很机械了定位到数据字段按ASCII转成字符再拼成字符串。1.2 “日期”在诊断报文里经常不是人话生产日期的存储格式比VIN麻烦得多。VIN至少还是统一的ASCII字符日期则可能遇到三种完全不同的编码BCD编码每个字节的高四位和低四位各表示一个十进制数比如0x20表示年份的“20”0x24可能表示月份的“24”这明显非法所以还要做合理性校验。常见格式是年、月、日各占一个字节或者年、月、日、时、分占五个字节。ASCII编码直接存字符串“2024-05-08”一个字符一个字节总共10字节。有些ECU还会存成“20240508”8字节。生产周格式这是最恶心的。整车厂排产按周维度管理所以某些ECU只存“年份 第几周”比如两个字节0x24 0x19表示2024年第19周。如果你想在界面上显示精确到日还得自己写一套“周数转日期”的算法。我在代码里统一封装了解析函数先通过配置决定用哪种格式再按对应规则解析。后面会给出具体实现但有一点必须先强调拿到日期原始字节后第一件事不是解析而是先用CAN抓包工具看一遍真实响应长度和字节值确定格式再动手。1.3 读取它们用的服务UDS 0x22与DID诊断协议里有一套服务ID的约定读数据统一用UDS服务0x22 ReadDataByIdentifier。这个服务的特点是“请求里告诉ECU你想读哪个DIDECU就把那个DID对应的数据返回给你”。请求格式是0x02 0x22 0xF1 0x90其中0x02是单帧PCI字节表示后续有效数据长度为2字节0x22是服务ID0xF1 0x90是DID这个地址是ISO标准里推荐的VIN码存储位置。日期类的DID并没有全球统一的标准我用0xF1C0、0xF1C1这类地址时都是通过抓包或者逆向配置确认过的。还有一个细节是CAN标识符。诊断通信里通常有“物理寻址”和“功能寻址”两种方式。功能寻址一般是0x7DF发出去后总线上所有支持该服务的ECU都可能响应适合做“全局读取”或“扫描ECU列表”物理寻址是请求ID0x7E0、响应ID0x7E8这只是常见示例值具体取决于整车网络配置只发给指定的ECU。读VIN这种数据几乎都是用物理寻址因为VIN是车上的唯一身份标识只存在某一个ECU里。如果发功能寻址多个ECU同时响应就会造成CAN总线冲突抓包时一片混乱。2. 请求侧代码构造一条能读到VIN码和日期的CAN诊断帧原理清楚了之后就可以落到代码上了。我习惯把诊断请求拆成“构造请求”“发送CAN帧”“等待并接收响应”三个独立模块方便在多个DID之间复用。2.1 整个读取过程的时序设计实际项目里读取VIN和日期的完整流程大致是初始化CAN控制器配置对应通道的波特率常规是500kbps老一点的车可能是250kbps设置滤波器允许接收指定响应ID。构造0x22请求报文添加必要的ISO-TP PCI字节。将请求报文发送到CAN总线。等待ECU响应。要注意这里不是简单的“收到一帧就完事”因为VIN响应很可能超过单个CAN帧的8字节载荷必须按ISO-TP协议处理多帧。对完整的诊断响应做解析把VIN和日期转换成人能看的格式。处理超时、错误响应0x7F、总线忙等异常情况。2.2 请求字节怎么拼单帧还是多帧对于读取VIN和日期这种两个DID各2字节的请求请求方向一直是单帧因为有效数据只有4字节以内。单帧的PCI字节格式是高四位为0x0表示单帧低四位表示后续有效数据长度。所以0x02 0x22 0xF1 0x90里的0x02就是“单帧 后面有2字节数据”。这里有一个容易混淆的地方0x22 0xF1 0x90三个字节服务ID 2字节DID为什么PCI长度写的是0x02因为PCI里面的长度指的是“除PCI字节以外的有效数据长度”也就是服务ID和参数的总长度不包括PCI自己。很多初学者在这里算错长度导致ECU直接不回响应。2.3 核心代码片段下面是我在项目里使用的简化版C代码清楚展示了构造请求和发送的过程#include stdint.h #include string.h #define CAN_ID_REQUEST 0x7E0 /* 物理请求ID示例值 */ #define CAN_ID_RESPONSE 0x7E8 /* 物理响应ID示例值 */ #define DIAG_SID_READ 0x22 #define DID_VIN 0xF190 /* VIN码标准推荐DID */ #define DID_DATE 0xF1C0 /* 生产日期项目自定义DID */ typedef struct { uint32_t can_id; uint8_t data[8]; uint8_t len; } CanFrame; /** * 构造一个0x22读请求报文 * param did 要读取的数据标识符 * param frame 输出的CAN帧 */ void diag_build_read_request(uint16_t did, CanFrame *frame) { frame-can_id CAN_ID_REQUEST; frame-len 4; /* PCI SID DID(2字节) */ frame-data[0] 0x02; /* 单帧后续2字节 */ frame-data[1] DIAG_SID_READ; /* 0x22 */ frame-data[2] (uint8_t)(did 8); /* DID高字节 */ frame-data[3] (uint8_t)(did 0xFF); /* DID低字节 */ } /** * 将CAN帧发送到总线这里假设hal层已经实现了can_send_frame */ void diag_send_request(uint16_t did) { CanFrame tx; diag_build_read_request(did, tx); can_send_frame(tx); /* 具体平台函数按实际接口替换 */ }实际项目中我会在diag_build_read_request里加一个返回值方便确认PCI长度是否合法。还可以把“填充CAN帧ID”的逻辑抽出去因为不同车型的诊断ID可能不同通过配置表管理会更灵活。3. 响应侧代码把原始字节变成能看的字符串请求发出去之后真正花时间调的是响应处理。ECU返回的数据可能是一个CAN帧也可能是好几个连续的CAN帧必须先重组再解析。3.1 单帧/首帧/连续帧的判断ISO-TP协议里CAN帧的第一个字节叫PCI字节根据高四位区分帧类型0x0单帧低四位表示数据长度。0x1首帧表示后面还有连续帧实际总长度在第二字节。0x2连续帧按顺序拼接前面首帧的数据。0x3流控帧一般是接收方向发送方做流量控制用的读取VIN时如果ECU响应较小不一定需要。我写了一个简化的接收重组逻辑typedef struct { uint8_t buf[256]; /* 重组缓冲区 */ uint16_t len; /* 当前已接收长度 */ uint16_t total; /* 完整响应总长度 */ } IsoTpReceiver; /** * 处理每一帧CAN数据 * param recv 接收器上下文 * param data 当前帧数据 * param len 当前帧数据长度 * return 1表示完整响应已收齐0表示还需要更多帧 */ int isotp_feed_frame(IsoTpReceiver *recv, uint8_t *data, uint8_t len) { uint8_t pci data[0]; uint8_t type pci 4; if (type 0x0) { /* 单帧 */ uint8_t dl pci 0x0F; if (dl 7) dl 7; memcpy(recv-buf, data[1], dl); recv-len dl; recv-total dl; return 1; } if (type 0x1) { /* 首帧第二字节为完整响应总长度 */ recv-total ((uint16_t)(pci 0x0F) 8) | data[1]; recv-len 0; /* 首帧后续部分也要拼接 */ uint8_t seg_len len - 2; memcpy(recv-buf[0], data[2], seg_len); recv-len seg_len; return (recv-len recv-total) ? 1 : 0; } if (type 0x2) { /* 连续帧最大可带7字节数据 */ uint8_t seg_len len - 1; if (recv-len seg_len recv-total) { seg_len recv-total - recv-len; } memcpy(recv-buf[recv-len], data[1], seg_len); recv-len seg_len; return (recv-len recv-total) ? 1 : 0; } return 0; }这个代码是标准的ISO-TP处理逻辑。实际项目里还要处理超时清空缓冲区、连续帧序号回绕等问题但核心思路就是“先攒全再解析”。3.2 VIN解析先裁剪再转ASCII当响应完整收齐后缓冲区里的数据一般是这样的0x62 0xF1 0x90 4C 41 31 32 33 34 35 36 37 38 39 30 31 32 33 34 350x62是正响应服务ID0xF1 0x90是DID回显从偏移3开始才是数据。解析VIN时要注意的是“必须以实际DID响应的数据长度为准”而不是无脑取17字节。有些ECU会有额外字节我后面会讲到这个坑。下面是VIN解析函数/** * 从ISO-TP重组后的完整响应中解析VIN码 * param resp 响应缓冲区 * param resp_len 响应总长度 * param vin_out 输出VIN字符串长度至少18字节 * return 成功返回0失败返回-1 */ int parse_vin(uint8_t *resp, uint16_t resp_len, char *vin_out) { if (resp_len 3) { return -1; /* 不可能合法 */ } /* 判断正响应第一个字节应该是0x62 */ if (resp[0] ! 0x62) { return -2; /* 负响应或非期望服务 */ } /* DID回显校验防止解析错数据 */ if (resp[1] ! 0xF1 || resp[2] ! 0x90) { return -3; } uint16_t offset 3; uint16_t payload_len resp_len - offset; if (payload_len 17) { return -4; /* VIN数据不足17字节 */ } uint16_t i; for (i 0; i 17; i) { vin_out[i] (char)resp[offset i]; /* 简单合法性检查可打印ASCII字符 */ if (vin_out[i] 0x20 || vin_out[i] 0x7E) { return -5; } } vin_out[17] \0; return 0; }为什么先做合法性检查因为抓包时经常能发现某些字节是0x00、0xFF之类的异常值多半是DID配置错误或者数据段偏移量不对。打印出来的VIN是乱码一看就知道定位偏了。3.3 日期解析三种格式的统一处理日期解析要做的第一件事是“识别格式”我建议把格式类型做成配置项而不是在代码里写死。typedef enum { DATE_FMT_BCD 0, /* 年/月/日 各一个BCD字节 */ DATE_FMT_ASCII 1, /* YYYY-MM-DD ASCII字符串 */ DATE_FMT_WEEK 2, /* 年份 生产周 */ } DateFormat; /** * BCD字节转十进制数 */ static uint8_t bcd_to_dec(uint8_t bcd) { return (uint8_t)(((bcd 4) 0x0F) * 10 (bcd 0x0F)); } /** * 解析生产日期 * param resp 响应缓冲区 * param resp_len 响应总长度 * param fmt 日期格式 * param year 输出年份如2024 * param month 输出月份 * param day 输出日 * return 成功返回0失败返回-1 */ int parse_date(uint8_t *resp, uint16_t resp_len, DateFormat fmt, uint16_t *year, uint8_t *month, uint8_t *day) { if (resp_len 3) return -1; if (resp[0] ! 0x62) return -2; /* 这里示例读取DID为0xF1C0回显校验略 */ uint16_t offset 3; /* 数据起始偏移 */ if (fmt DATE_FMT_BCD) { if (resp_len - offset 3) return -3; uint16_t y bcd_to_dec(resp[offset]); uint8_t m bcd_to_dec(resp[offset 1]); uint8_t d bcd_to_dec(resp[offset 2]); if (m 1 || m 12 || d 1 || d 31) return -4; *year 2000 y; /* 这里按2000年基准处理完整项目里要配置世纪基准 */ *month m; *day d; return 0; } if (fmt DATE_FMT_ASCII) { /* 期望 YYYY-MM-DD 或 YYYYMMDD */ char str[16]; uint16_t data_len resp_len - offset; if (data_len 8) return -3; memcpy(str, resp[offset], data_len 15 ? 15 : data_len); str[data_len] \0; /* 简单用字符串解析实际项目可以用标准库 */ if (strlen(str) 10 str[4] -) { *year (uint16_t)((str[0] - 0) * 1000 (str[1] - 0) * 100 (str[2] - 0) * 10 (str[3] - 0)); *month (uint8_t)((str[5] - 0) * 10 (str[6] - 0)); *day (uint8_t)((str[8] - 0) * 10 (str[9] - 0)); return 0; } else if (strlen(str) 8) { *year (uint16_t)((str[0] - 0) * 1000 (str[1] - 0) * 100 (str[2] - 0) * 10 (str[3] - 0)); *month (uint8_t)((str[4] - 0) * 10 (str[5] - 0)); *day (uint8_t)((str[6] - 0) * 10 (str[7] - 0)); return 0; } return -4; } if (fmt DATE_FMT_WEEK) { if (resp_len - offset 2) return -3; uint16_t y bcd_to_dec(resp[offset]); uint8_t week bcd_to_dec(resp[offset 1]); /* 周转日期的算法需要查表这里示意性地返回一个无效日期 */ *year 2000 y; *month 0; *day week; return 0; } return -5; }这段代码有两个细节值得说明一是BCD解析时做了月份、日期的合理性检查能有效避免“读错字节位”导致显示离谱日期二是ASCII格式解析必须在前面判断分隔符有些ECU返回的是带横杠的有些没有。实际项目中我还遇到过“日期DID返回8字节但最后两字节是补位0xFF”的情况所以解析前同样要做数据长度裁剪。4. 实测中必须面对的“不按套路出牌”代码写完只是开始。真正连上实车抓包调试时你会发现这些“不按套路出牌”的情况几乎人人都会遇到。4.1 坑1说好的17字节怎么多出两字节第一次实车测试我发0x22 0xF1 0x90读VIN抓包看到响应总长度是19字节而不是想象的20字节3字节头 17字节数据。打印出来一看VIN码是读到了但后面还跟着两个字节的辅助信息有的是0xFF 0xFF有的则是整车的生产序号。根因是某些ECU在VIN这个DID后面又追加了别的数据或者在VIN数据后面填充了歧义性的补位字节。解决思路是先抓包看完整响应确认数据长度。解析时不要从固定偏移直接取17字节而是先判断数据区实际长度是否大于等于17。截取时严格按DID定义和数据区的已知布局来多余字节直接丢弃。我后来把VIN解析改成“先判断长度再修剪最后校验可打印字符”这样即使厂商追加了额外字段也不会污染VIN字符串。4.2 坑2日期格式的“窗口期”现象有次测试时日期解析一直报错抓包发现返回的字节看起来是ASCII格式但我代码配置成BCD。我把响应打出来看32 30 32 34 30 35 30 38这其实是ASCII的“20240508”但如果不看抓包光从字节离线分析很容易当成BCD——320x20看起来像年份20300x24像月份24这明显是解析错位了。这个坑给我最大的教训是永远不要假设ECU的存储格式。在正式写解析代码之前一定要先让ECU响应原始字节直接十六进制打印出来观察。尤其在同一个项目里可能有多个车型平台共用一套诊断仪软件每个平台返回的日期格式不一定一样。我在工程上给出的方案是复杂项目里为每个车型平台维护一个“诊断数据格式表”包括DID地址、数据长度、日期编码格式、世纪基准等信息全部通过配置文件加载。这样即便哪天新增了一个车型也不用改C代码只改配置就行。4.3 坑3多帧响应别只读第一帧这是我个人早期踩得最惨的坑。当时图省事接收响应只处理单帧测试普通DID没问题直到读VIN时傻眼了ECU明明回复了但程序一直超时。原因很好理解VIN的完整响应是0x62 DID(2) 17字节 20字节超过单帧最大7字节有效载荷所以ECU按ISO-TP发了一个首帧加两个连续帧。如果没有做多帧重组应用层拿到首帧的6字节数据就以为结束了自然解析失败。解决方式就是我前面写的isotp_feed_frame函数。实际工程里还可以借用开源CAN栈的ISO-TP实现比如Linux内核的can-isotp模块或各MCU厂商自带的诊断协议栈。但无论用什么都必须把重组逻辑和解析逻辑分开这样测试时也更容易定位问题。4.4 坑4没有协议文档DID地址全靠逆向整车厂或Tier 1给诊断仪开发商提供的协议文档有时候并不完整。尤其是一些“非标准”DID比如生产日期、配置版本号、软件升级日期文档可能只写了一个字待定。遇到这种情况我推荐一个优先顺序先翻整车厂公开发布的DID表再去网上找同平台车型的诊断抓包案例最后才是在实车上“扫DID”——也就是遍历已知范围内的DID地址观察哪些地址有合法响应。扫描时要注意频率不要太快以免ECU进入总线休眠或者过载。需要注意0xF190这个VIN DID在ISO标准里是推荐值多数ECU会支持。但日期类DID每个厂商差异很大甚至同一个厂商的轿车和商用车平台都不一样。在没有文档的情况下最稳妥的方式是拿一台已知配置的实车从ECU的“系统信息”界面看到生产日期然后反向比对抓包的DID响应确认地址对应关系。4.5 坑5CAN ID和滤波器配置错了还有一个常见的低级错误请求ID和响应ID不对应。有些平台的诊断请求ID不是0x7E0而是0x7E8或0x18DB33F1扩展帧格式响应ID也不一定是请求ID8。我就遇到过请求发出去CAN总线完全没有回应排查半天发现滤波配置只接收了一个完全无关的ID。排查这类问题的办法是先用CAN卡或分析仪监听总线确认ECU到底是否响应、响应ID是多少。检查CAN控制器接收滤波寄存器确保响应ID在放行名单里。确认诊断通信走的是标准帧还是扩展帧ISO-TP在两种帧格式下的PCI字节规则相同的但CAN ID长度不同滤波配置也不一样。另外还要关注“哪条CAN网络”现在的车通常有好几条CAN总线动力CAN、车身CAN、信息娱乐CAN。VIN可能在车身域控也可能在网关里。如果诊断仪从动力CAN入口发请求得到的响应可能不在物理寻址的预期节点上。开始测试前最好先确认ECU挂在哪条总线上。5. 从“能读出来”到“项目能用”的工程化改造调试阶段跑通之后距离“交付给客户使用”还差得很远。下面这几个改造点我几乎在每一个诊断开发项目里都会做。5.1 用DID映射表替代写死的if-else前面代码里解析VIN固定写死DID日期也固定用一个DID。真实项目里同一个0x22服务可能对应几十个DID如果每个解析逻辑都写一个函数和一群if-else代码很快就会变得不可维护。我的做法是面向DID建一张表typedef struct { uint16_t did; uint16_t data_len; /* 期望的数据长度0表示不确定 */ DateFormat date_fmt; /* 如果这个DID是日期记录格式 */ int (*parse_func)(uint8_t *resp, uint16_t resp_len, char *out, uint16_t out_len); } DidMapEntry;初始化和查表逻辑很简单本质就是把“DID地址”和“解析动作”解耦。新增一个DID时只需要增加表项和解析函数不需要改主流程。对量产工具来说这样扩展成本极低。5.2 超时重试与诊断状态机真实ECU并不是每次都能响应。总线繁忙、ECU内部在跑其他任务、网络被网关限流都可能导致请求石沉大海。所以我从不写“发一次就死等”的阻塞代码而是设计一个小的诊断状态机状态1发送请求。状态2等待响应设置超时200~500ms。状态3收齐ISO-TP数据解析数据。状态4失败则进入重试计数超过3次后上报错误。#define DIAG_TIMEOUT_MS 300 #define DIAG_RETRY_COUNT 3 int diag_read_did_safe(uint16_t did, uint8_t *resp, uint16_t *len) { int retry; for (retry 0; retry DIAG_RETRY_COUNT; retry) { diag_send_request(did); if (diag_wait_response(resp, len, DIAG_TIMEOUT_MS) 0) { return 0; /* 成功 */ } /* 等待一帧间隔避免总线冲突 */ delay_ms(50); } return -1; /* 重试次数用尽 */ }超时时间不能太短尤其是ISO-TP多帧传输时ECU的首帧和连续帧之间可能存在间隔也不能太长否则诊断界面卡顿明显。300ms是我常用的起步值具体项目根据实测调整。5.3 数据校验、日志与异常兜底解析出的VIN或日期在上屏之前建议再做一道“业务层校验”VIN长度必须为17且每一位都是可打印ASCII。VIN的第9位是校验位可以根据ISO 3779规定的算法验证如果校验失败可能说明读取到了错误DID的数据。日期必须合法比如月份1-12日期1-31年份不能早于车辆下线年份减去10年。日志是诊断开发里看不见但极其重要的工程化环节。每一次收发最好都以结构化格式记录时间戳、CAN ID、方向、原始字节、解析结果。这样在现场出问题时只需要把日志发回来就能快速还原总线通信过程。我之前的习惯是把所有诊断帧同时存成两种格式可读文本和十六进制原始帧后者方便用工具做协议对比。5.4 后续扩展批量读、安全访问与更复杂场景这个例子虽然只讲了VIN码和日期但同样的思路可以扩展到很多场景批量读取多个DID把多个读请求放进队列状态机逐个发送、统一收集结果在界面上做成一个“车辆信息总览”页面。写数据服务0x2E比如写VIN码、写配置信息逻辑和读正好对称只是请求里多了数据段还要注意“安全访问”服务0x27的种子-密钥流程。带子功能的读取有些DID需要先通过ID标识符子功能才能读到比如先进入特定的诊断会话。备份与刷写车厂售后场景里经常要在刷写前读取VIN/软硬件版本号读完的这些数据最终要进入刷新流程决定刷哪个版本的固件。工程化改造的核心原则只有一个把能配置的尽量配置化把能重试的尽量可重试把可能出问题的每一步都留好日志。诊断代码写得再花哨最终目的都是现场少出一次“连不上”的问题。最后再分享一个工作习惯接手的任何一个诊断项目我都不会急着写满代码而是先用一块CAN分析仪把目标ECU对0x22服务的真实响应抓出来看一遍确认每个DID的返回长度、格式、起始偏移然后再开始解析层编码。这个习惯让我的返工率低很多。诊断开发的本质就是“和ECU对话”如果连对方的语言习惯都没搞清楚代码写得再漂亮也白搭。