UDS会话切换0x10服务详解：报文解析、S3超时与刷写踩坑指南

做UDS诊断测试的工程师每天少不了发那一帧02 10 03。这帧报文短得不能再短但它的作用是把ECU从默认会话切到扩展会话后面能不能读敏感数据、写标定参数、做例程控制全都取决于这次切换有没有成功。UDS里的Session会话虽然只是Service 0x10下的一个子功能但它是整条诊断链路的总开关很多看起来莫名其妙的负响应NRC最终都能追溯到会话状态不对。我会结合自己在台架测试中真实跑过的报文和踩坑记录把Session切换从头到尾讲透ECU为什么要设计会话机制、0x10服务的请求/响应报文怎么解析、从默认会话切到扩展会话再进编程会话会经历什么以及切换之后为什么会出现看着成功、实则没权限的怪事。刚接触UDS协议、在实验室跑诊断、或者正在写刷写脚本的朋友这篇应该能省下你不少翻规格书的时间。1. 一个测试工程师眼中的Session这玩意解决的是权限与状态问题刚碰UDS那会儿我最不理解的就是为什么ECU这么不信任人想读个VIN码直接读就行但想写一个标定参数或者执行一次例程却要先换个会话。后来在台架上亲眼看到一次误刷事故才明白会话机制本质上是ECU给自己设的一道权限门禁。1.1 从ECU不信任你说起ECU在车上连着CAN总线任何挂在总线上的节点都能往总线上发报文。如果每个节点都能随意写Flash、改标定、执行自检整个车辆系统就没什么安全性可言。会话机制做的第一件事就是限定只有诊断仪Tester主动请求进入特定会话之后ECU才开放对应权限。这就像机房的门禁系统默认会话只让你隔着玻璃看设备状态想进去操作必须刷卡换权限。在ISO 14229-1里诊断会话Diagnostic Session被定义为一个ECU内部运行的持续状态。不同的会话决定了当前允许使用哪些诊断服务、安全访问等级、通信参数比如响应超时时间。这种设计在外行人看来是繁琐但在工程上恰恰是防呆和防误操作的核心手段——默认会话下只能做读操作和部分基础服务避免一个手滑把关键数据写坏非默认会话才开放写操作、例程控制、刷写这些危险动作。1.2 三种标准会话和它们能做什么ISO 14229-1规定了三种标准会话默认会话Default Session子功能0x01、编程会话Programming Session子功能0x02和扩展诊断会话Extended Diagnostic Session子功能0x03。除了这三个之外OEM还可以在0x40~0x7F范围内定义自己的会话比如某些厂商的工厂模式会话、特殊安全等级会话。三种标准会话的权限边界大致是这样的会话类型子功能主要用途典型可用服务默认会话0x01上电后的初始状态基础诊断0x10、0x19、0x22、0x3E等编程会话0x02Flash刷写、底层重编程0x10、0x27、0x31、0x34、0x36、0x37等扩展会话0x03标定、写参数、例程、高级诊断0x10、0x27、0x2E、0x28、0x31等注意这张表不是绝对严格的具体能执行哪些服务还得看ECU的CDDCANdela Diagnostic Description文件或者诊断调查表。但有一个共同点默认会话下几乎不含任何写和例程类服务安全访问0x27在默认会话下也通常不允许执行。换句话说不管你想刷写还是标定第一步都是先把会话切到对应的非默认会话。1.3 会话切换不是改一个标志位那么简单从软件实现上看会话切换会引发一串连锁反应已解锁的安全等级被重置标准推荐行为具体看OEM实现、S3定时器重新计时、通信参数可能切换尤其进入编程会话后P2*会变、DTC记录行为可能被暂停甚至应用层的某个线程会被挂起。我在做刷写测试时发现切到编程会话后有些ECU连本身的周期报文都不发了总线安静得像断电——这就是应用层任务被挂起的结果。所以Session切换虽然只是0x10服务下的一个子功能但它牵动的状态非常多。这也是为什么排查诊断问题时第一条永远要确认当前ECU到底在哪个会话。2. 把0x10服务的报文拆开看请求、正响应、负响应各自的门道光知道概念不够报文才是诊断测试真正的语言。这一节把0x10服务的请求帧和响应帧逐字节拆开方便你以后对着日志能一眼看出问题。2.1 请求报文一帧装满所有信息在CAN/CAN FD上发0x10服务请求报文结构很简洁。以标准CAN、物理寻址为例假设诊断请求ID是0x7E0ECU响应ID是0x7E8从默认会话切到扩展会话的请求帧是CAN ID: 0x7E0 Data: 02 10 03 00 00 00 00 00逐个字节看0x02PCIProtocol Control Information表示后续跟随2个数据字节0x10服务IDSID也就是DiagnosticSessionControl0x03子功能目标会话ID这里指扩展会话后面5个字节补0凑满标准CAN的8字节长度。如果要切到编程会话把子功能改成0x02即可02 10 02 ...。如果ECU用的是CAN FDPCI的编码规则会略有不同单帧长度指示符换成了SF_DL但服务字节的含义完全不变。这里有个实际建议会话切换请求最好用物理寻址发给具体ECU。虽然ISO标准里0x10服务理论上可以通过功能寻址0x7DF发送但实际项目里OEM一般要求逐台控制。用功能寻址可能让总线上多个ECU同时切换会话随后的常规通信直接乱套。我见过测试员图省事发广播请求结果整个CAN网段的ECU全部切到编程会话后面所有应用报文都停了排查了半天才缓过来。2.2 正响应ECU告诉你我切好了以及新的时间参数正常情况下ECU会立刻回一帧正响应。比如从默认会话切到扩展会话后CAN ID: 0x7E8 Data: 06 50 03 00 32 01 F4 00逐字节解释0x06PCI表示后续6个数据字节0x50正响应SID即0x10 0x400x03回显子功能确认当前已切到扩展会话0x00 0x32P2_Server_max这里0x0032即50ms表示本会话下ECU对一般诊断请求的响应时间上限0x01 0xF4P2*_Server_max0x01F4即500ms表示ECU处理较长任务时的增强响应时间上限。P2和P2这两个参数很多人会忽略但测试脚本里极其重要。后续每个诊断请求如果超过P2还没收到正响应才应该判定超时如果只超过P2但还没超过P2*ECU通常会先回一帧0x7F ... 0x78Response Pending告诉你我再忙一下别急。而且这个参数不是ECU随便填的不同会话差别很大。编程会话下P2*经常被设成5秒甚至更长因为擦Flash确实很慢。2.3 负响应切换失败时ECU会说些什么如果切换失败ECU会返回负响应格式是03 7F 10 NRC。其中0x7F是负响应服务ID0x10是被拒绝的服务ID最后一个字节是NRC。我把会话切换中最常碰到的几种NRC整理成了表NRC含义常见触发场景排查方向0x12子功能不支持发了OEM未定义的会话子功能查CDD里0x10服务支持的会话列表0x13报文长度或格式错误请求数据字节长度不对、PCI错误检查PCI字节和服务数据长度0x22条件不满足切换编程会话但电压超范围、总线负载过高、未满足前置条件查切换前置条件尤其是电源电压0x78响应待处理ECU正忙内部任务尚未完成等待P2*时间后重试或继续请求其中0x22最值得注意。很多ECU切编程会话要求电源电压稳定在特定范围台架上用低压电源供电就会出现会话切不过去但又没报0x12的怪现象实际一查是条件不满足。这时候别急着改脚本先看供电和点火信号是否正常。3. 跟着报文走一遍默认会话切扩展会话的完整时间线理论知识说完了来点真刀真枪的。我用CANoe环境演示一次最典型的切换默认会话切到扩展会话验证生效再等S3超时观察ECU回跳。每一步都有报文和时间戳你可以直接在台架上照着复现。3.1 把测试环境准备好我用的是CANoe加VN1640A接口卡总线波特率500kbpsDUT是一块国产控制器。接线不复杂CAN-H、CAN-L分别接到ECU对应的诊断CAN引脚PC端打开一个CAN报文发送窗口发送ID设为0x7E0接收ID设为0x7E8。没有CANoe也没关系PCAN-View、Vehicle Spy或者诊断工具自带的自定义发送功能都能做同样的操作关键是必须能看到报文和时间戳。启动前先确认ECU上电完成、总线处于静默状态。如果ECU已经在发应用报文最好等它跑完启动流程避免诊断会话切换和应用层初始化打架。3.2 正常切换的报文时间线下面是一段真实抓到的报文时间戳是CANoe里的相对时间t0.000s TX 0x7E0 02 10 03 00 00 00 00 00 t0.012s RX 0x7E8 06 50 03 00 32 01 F4 00 t0.015s TX 0x7E0 03 22 F1 A0 00 00 00 00 // 读取扩展会话专用DID t0.028s RX 0x7E8 05 62 F1 A0 01 0C 00 00 // 读回数据说明会话已生效第1帧是切换请求第2帧是ECU确认。注意从请求到正响应只隔了12ms小于P250ms说明ECU处理很快。第3帧我读了一个厂商自定义的DIDF1A0假设它是刷写计数这一类只有扩展会话才开放的数据既然能正常读回数据就证明扩展会话权限已经生效——这类DID在默认会话下通常会直接拒绝。如果你用的是诊断工具而不是裸发报文工具会在后台自动处理PCI和请求长度你只需要选服务0x10、子功能0x03然后点发送。但对于写脚本调试我反而建议直接看裸报文因为能看到工具帮你隐藏的细节比如时间间隔、P2参数变化。3.3 关键时刻停发请求看S3定时器怎么把会话拉回默认扩展会话切成功了先别急着做别的。把诊断请求全部停掉观察ECU的行为。这里有个新手容易误解的地方ECU回默认会话时不会主动发任何提示S3超时后它只是默默回到默认状态你不发请求它也不会开口。所以正确的验证方式是t0.000s TX 0x7E0 02 10 03 00 00 00 00 00 t0.012s RX 0x7E8 06 50 03 00 32 01 F4 00 t5.500s TX 0x7E0 03 22 F1 A0 00 00 00 00 // 超过S3默认5秒后读同一个DID t5.512s RX 0x7E8 03 7F 22 22 00 00 00 00 // NRC 0x22会话已回到默认这个现象在测试报告里很有价值它证明了ECU的S3超时回默认逻辑是正常工作的。实际量产中S3时间不一定正好是5秒OEM可能设成3秒、10秒甚至更长具体以CDD为准。但原则是一样的非默认会话不能躺平太久必须持续有请求来保活。提示S3计时从收到任意诊断请求包括0x3E保活后重新开始。如果测试中需要长时间停留非默认会话务必周期发送0x3E否则S3超时会让你悄悄掉回默认会话。3.4 主动切回默认会话的正确姿势超时回跳是被动行为工程上更常用主动切换直接发02 10 01让ECU立刻回到默认会话。正响应和切换扩展会话类似子功能回显0x01t0.000s TX 0x7E0 02 10 01 00 00 00 00 00 t0.010s RX 0x7E8 06 50 01 00 32 01 F4 00切回默认后之前开放的写权限和例程权限会立即关闭已解锁的安全等级一般也会被清除。有些ECU在切回默认时会做一次内部自检响应时间会稍长但通常不会超过P2*。如果你发现主动切回去偶尔收不到正响应不要直接判定失败等够P2*时间再看有没有0x78或者迟到的正响应。4. 刷写场景里的会话切换从默认切编程会话前后的隐藏变化刷写Flash Reprogramming是Session切换最有存在感的场景。整车OTA、售后升级、产线下线刷写都离不开那一句02 10 02。这一章我聊聊刷写流程中会话是怎么被编排的以及切进编程会话后ECU身上悄悄发生的那些变化。4.1 一次完整刷写里Session是怎么被编排的我拆过不少OEM的刷写流程各家细节不同但骨架高度一致预编程阶段默认会话切到扩展会话02 10 03做安全访问解锁0x27、读版本号、清DTC等准备工作正式编程阶段从扩展会话切到编程会话02 10 02然后执行例程控制0x31擦除Flash、请求下载0x34、数据传输0x36最后请求传输退出0x37收尾阶段发送0x11 ECU复位让ECU以默认会话重新启动。为什么不是从默认会话直接切编程会话而是先切扩展会话再做预编程检查原因有两个。第一很多ECU的安全解锁逻辑只允许在扩展或编程会话下执行从默认直接进编程会话可能绕不过安全校验第二扩展会话下可以先做预编程检查——电压检测、固件版本确认、DTC读取——全部通过后再切编程会话如果前置检查失败就不入场风险完全可控。4.2 切进编程会话后ECU身上发生的隐藏变化很多人只看到02 10 02的正响应就以为万事大吉其实ECU内部已经翻江倒海应用层任务挂起正常行驶相关的控制报文、状态报文可能停止发送总线明显安静DTC记录暂停编程期间通常不记录新故障防止刷写过程自身干扰误报通信参数切换P2/P2*往往比扩展会话更宽松因为Flash操作确实慢响应超时判断要用新参数安全访问状态可能保留也可能被重置ISO标准里诊断会话切换通常会重置安全等级但不同OEM实现有差异有的切进编程会话后需要重新做0x27解锁有的会保留之前的解锁等级。务必以规格书为准。我在一次台架测试中遇到过比较特殊的现象ECU切到编程会话后应用报文确实停了但DTC状态位里多了一个编程会话已激活的故障码。一开始我以为是异常后来翻厂商协议才知道是故意设计的——用DTC状态位标记刷写过程回头排查问题能看清刷到哪一步。所以编程会话DTC完全不更新这种说法在具体ECU上不一定成立得看OEM实现。4.3 一段典型的刷写切换序列可直接参考下面这段CAPL脚本模拟刷写前段序列API名称以你用的诊断工程为准重点看Session切换的位置// 预编程默认 - 扩展 DiagRequest_DiagnosticSessionControl.SetSubFunction(0x03); DiagSendRequest(DiagRequest_DiagnosticSessionControl); // 安全访问假设seed/key算法是pass-through DiagRequest_SecurityAccess.SetSubFunction(0x01); DiagSendRequest(DiagRequest_SecurityAccess); // 收到seed后用0x02子功能发送计算好的key DiagRequest_SecurityAccess.SetSubFunction(0x02); DiagRequest_SecurityAccess.SetIdent(0x03, key); DiagSendRequest(DiagRequest_SecurityAccess); // 正式编程扩展 - 编程 DiagRequest_DiagnosticSessionControl.SetSubFunction(0x02); DiagSendRequest(DiagRequest_DiagnosticSessionControl); // 后面就是0x31擦除、0x34请求下载、0x36传数据...这段脚本看着不难但我实际调试时栽过跟头切到编程会话后如果某两步请求间隔超过了S3时间ECU会退回默认会话后续的0x34请求下载就会连续报NRC 0x22整个刷写直接崩掉。解决办法是两条路要么在0x34/0x36/0x37之间插入0x3E保活请求要么通过0x10子功能参数如果OEM支持把S3定时器调长确保刷写过程中不掉会话。4.4 刷写完别忘了复位刷写结束后一般会发0x11 ECU复位子功能0x01表示硬复位0x03表示下电再上电让ECU从编程会话回到默认会话。有的ECU也支持直接用0x10 01切回默认但刷完固件后强烈建议复位——因为新版本的应用程序要重启才能生效而且编程会话下有些资源没有释放干净不重启直接切默认可能存在隐患。5. 切了会话却没生效三个我实际遇过的坑会话切换看起来就一帧报文但恰恰是这一帧引出的问题最多。我挑三个自己踩过的坑按现象、原因、解决讲明白。5.1 坑一S3超时悄悄回默认后续操作连环NRC 0x22有一次给客户做标定测试脚本逻辑是先切扩展会话再做0x2E写参数。单独跑一条用例没问题但放到一整晚的长测里第二天一看日志凌晨3点之后全是0x2E被NRC 0x22拒绝。查了挺久才发现问题切完扩展会话后有一处下载标定数据的操作比较耗时超过了几秒——正好踩中ECU的S3超时ECU回到默认会话后续写操作自然全部被拒。解决方法是在长间隔操作前主动发一次02 10 03重新确认会话或者用03 3E 80周期性保活。更稳妥的做法是写自动化脚本时在每次关键操作前加一个检查当前会话的步骤——读一个只有非默认会话才能读的数据如果失败就重新切会话再继续。这个做法比盲目重试可靠得多。5.2 坑二会话切了但安全访问没做照样没权限还有一次同事在台架上给ECU切到扩展会话然后直接发0x31例程控制执行某个自检结果收到NRC 0x33securityAccessDenied。他很奇怪会话都切了怎么还没权限这里要理清一个概念会话切换只解决ECU允许你进入某个诊断模式的问题安全访问0x27解决的是ECU确认你是有权限执行特定动作的操作者的问题。会话是通道安全访问是钥匙。扩展会话下读部分数据可以不解锁但执行例程、写标定数据这类危险操作通常必须先做0x27安全访问。如果CDD里要求扩展会话安全等级某级才算完整权限那会话切换只是第一步。这种坑的隐蔽之处在于有的服务在未解锁时也会返回正响应等真正执行时才在自定义NRC里告诉你权限不足。所以测试用例里的前置条件必须写清楚不仅写SessionExtended还要写SecurityLevelxxx两者缺一不可。5.3 坑三OEM自定义会话子功能把标准流程打乱标准会话只有0x01/0x02/0x03但OEM经常加私货。比如某供应商把0x40定义为工厂模式会话权限模型和标准会话完全不同有的甚至不要求标准的安全访问流程就能进入。问题往往出在测试脚本复用上我原来拿标准UDS用例直接跑脚本里写死了切到0x03就能做0x31但某台ECU的CDD里0x31只在0x40下开放。结果就是切换正响应正常后续服务全部给你NRC 0x12或者0x31莫名其妙。最坑的是这种权限映射不写在ISO标准里全在CDD/ODX文件里不翻文件根本猜不到。所以拿到新ECU的第一件事永远是用诊断工具读一遍CDD把会话-服务权限矩阵整理出来再动脚本。我后来给自己定了个规矩凡是支持自定义会话的ECU测试脚本里不硬编码会话ID全部从配置文件读取。5.4 排查会话问题的通用思路如果遇到会话相关服务不工作我习惯按下面顺序排查看最近一次成功/失败的0x10切换时间戳确认当前会话状态看有没有S3超时相邻两次诊断请求的时间差是否超过了ECU的S3时间看安全访问状态是否需要重新解锁看CDD里的会话-服务权限矩阵当前会话是否真的开放目标服务看P2/P2*参数你的超时判断是否合理。这套思路用了好几年基本没失手过。很多玄学问题到最后都落在会话状态或安全状态这两个点上。6. 一点测试经验会话切换相关的工具配置和脚本套路最后一节说点实际操作层面的东西包括工具的隐藏设置和一个能直接用的保活脚本骨架。6.1 工具配置里容易忽略的三个地方CANoe、CANape、PCAN这类工具发送诊断请求时都有一些贴心功能但用不好反而会掩盖真实问题自动等待正响应很多工具默认发送请求后会等待一段时间如果这个等待时间小于ECU的P2*真正慢的响应会被工具抢先判定为超时造成测试误报。建议把响应等待时间配置成大于ECU最大P2*一般设3秒比较稳自动切换会话有些诊断工具有切换到非默认会话的快捷按钮点一下确实能切但不会提醒你操作完要切回默认有的甚至不在日志里记录这次切换。写报告时没有报文佐证会很被动自动保活部分工具可以周期发送0x3E长时间标定测试时这个功能很实用。但如果保活请求本身没被记录进日志后面查S3超时就会缺少证据。我一般会关掉工具的自动保活改用脚本显式发送让日志完整可追溯。6.2 一个可复用的会话保活脚本骨架下面这段CAPL脚本的逻辑是先切到扩展会话确认成功后进入保活循环直到测试结束。你可以在CANoe里新建一个CAPL节点把这段代码塞进去改改诊断对象名就能跑。variables { msTimer tKeepAlive; int sessionActive 0; } on start { setTimer(tKeepAlive, 50); // 50ms后先发切换请求 } on timer tKeepAlive { if (sessionActive 0) { // 发送 0x10 03 切到扩展会话 DiagRequest_DiagnosticSessionControl.SetSubFunction(0x03); DiagSendRequest(DiagRequest_DiagnosticSessionControl); sessionActive 1; } else { // 周期发送 0x3E 80抑制正响应并保持会话 DiagRequest_TesterPresent.SetSubFunction(0x80); DiagSendRequest(DiagRequest_TesterPresent); } setTimer(tKeepAlive, 1000); // 1秒间隔保活 } on diagResponse DiagResp_DiagnosticSessionControl { // 切换失败时重置状态下个周期会重试 if (diagResp_DiagnosticSessionControl.GetResult() ! 0) { sessionActive 0; } }这段脚本比较糙当脚手架用完全足够。实际工程里我会把保活间隔设成S3时间的一半比如S35秒就每2.5秒发一次0x3E如果S3不可控就每1秒发一次最保险。注意0x3E子功能0x80表示抑制正响应ECU只接收请求不回正响应能有效减少总线报文数量如果你希望每次确认ECU还活着可以发0x3E 00让ECU回应。6.3 写测试用例时的三个习惯最后分享几个工作习惯。第一测试用例的前置条件里永远写清楚两个值Sessionxxxx和SecurityLevelxxxx否则用例在不同ECU之间移植时立刻翻车。第二凡是涉及会话切换的用例断言里必须包含S3超时后回到默认会话这一条这是ECU诊断状态机的基本行为不测等于没测。第三测试报告里附报文时间线时至少截三段切进会话的那一帧、中间操作的一帧、切回默认或者超时后的那一帧。别人审报告能直接看懂你的操作序列不用回头翻原始log。从我自己的体会来说会话切换在UDS诊断体系里的位置远比刚入行时以为的重要。它是一根总闸连着权限、定时器、通信参数、DTC行为和安全等级任何一根线没理清后续操作都可能卡壳。遇到那种明明切成功了一切却没反应的问题我习惯把供电电压、总线状态、CDD权限矩阵三样东西一起拉出来看十有八九答案就藏在这三样里。