在UDS学习1中学习的4.基于CAN总线的UDS诊断通信的网络传输层协议、5.UDS报文的四种帧型的区分和格式、6.基于 CAN 总线的 UDS 报文的多帧通信的网络层的 6 个时间参数都是关于ISO 15765-2规定的网络传输层的协议UDS协议是ISO 14229系列协议规定的协议内容即14229即为UDSUDS即为14229其中14229-1是最核心的应用层规定在工作中如果要用到很少见的UDS服务可以从【ISO 14229-1】pdf文档中去学习它的详细用法我们此阶段将学习最常用、最重要的其中的8个服务0x10、0x3E、0x11、0x27、0x22、0x2E、0x19、0x14UDS服务的请求报文的一般格式【格式一】服务ID 子功能SID SubFunction例如10 03 —— 使用10服务开启扩展会话进入扩展会话、不抑制肯定响应10 83 —— 使用10服务开启扩展会话进入扩展会话、要抑制肯定响应3E 00 —— 使用3E服务保持Tester在线不抑制肯定响应3E 80 —— 使用3E服务保持Tester在线要抑制肯定响应格式上子功能紧跟在 SID 之后占用1个字节。子功能这个字节的最高位bit如果为0代表不抑制肯定响应反之如果最高位为1代表要抑制肯定响应如果响应成功的话不返回肯定响应的报文。最高位bit这个特点称之为SuppressPosRspMessageIndicationBit这是对所有拥有子功能的UDS服务都有效的特点。【格式二】服务ID 数据IDSID DID (2字节)例如22 F1 8C —— 使用22服务读取DID为 F1 8C 代表ECU的序列号的数据值0x10服务————诊断会话控制0x10服务是用来切换当前Tester和ECU之间诊断会话的状态的Tester和ECU在不同通信会话状态下能够做的事情不一样。UDS中定义的三种会话session1.默认会话 (default session) —— 子功能的编号为 01ECU上电后就处于“默认会话状态”当ECU处于“非默认会话状态”时如果Tester超过了一个 ECU规定的时间还未给ECU发送任何诊断请求则ECU会跳转回“默认会话状态”。这个超时的时间协议中推荐为5000ms2.扩展会话 (extended session) —— 子功能的编号为 03只有进入到扩展会话状态很多高级的操作才可以进行解锁ECU、读取权限要求的数据、 写入数据、进入编程会话、……3.编程会话 (programming session) —— 子功能的编号为 02当我们要刷写ECU的程序时需要处于这个编程会话状态要想进入编程会话状态必须先进去扩展会话状态使用0x10进行会话控制的格式和实例肯定响应中的P2server和P2*server的含义P2server——后续的诊断服务请求响应的过程中ServerECU最大的响应超时时间就是P2server的值上例子00 32就是P2server代表50msP2server——后续的诊断服务请求响应的过程中如果上一个响应给了一个NRC否定响应码为78的否定响应后ServerECU会在P2server的值报文值 × 10的这个时间之内返回真正的响应数据。上例子01 F4就是P2*server代表5000ms01 F4 -- 500 -- 500 * 10 -- 5000以下是CANoe中的仿真ECU的诊断实例截图0x3E服务————诊断仪在线3E服务的请求报文一般是由Tester设备自动地、连续地不断发送UDS协议推荐Tester如果要长时间跟ECU保持会话每4000ms发送一次3E服务的请求报文S3 Client 时间参数和 S3 Server 时间参数S3 Client Time —— 客户端每隔多长时间向ECU发送一次3E服务的请求报文推荐4000ms。S3 Server Time—— ECU在持续没有收到Tester请求报文后多长时间会中断会话退回到默认会话状态。0x11服务————重置的ECU当刷写ECU更新ECU中的固件程序时按照规范刷写的最后步骤一定要用11服务进行重置ECU。硬重置和软重置的区别硬重置是模拟ECU完全掉电KL30电【蓄电池的电】、KL15电【发动机点火的电】后再上电的这个重置过程软重置是让ECU的软件程序重新启动。0x11服务的请求和响应的报文格式及示例以下是0x11服务的报文实例0x27服务————安全访问ECU解锁因为部分的诊断功能需要在ECU解锁状态下才能访问而0x27服务就是用于解锁ECU的例如写入一些敏感的数据、刷写ECU更新ECU固件程序/对ECU编程了的情况下就必须要先解锁ECU要使用0x27服务必须先进入扩展会话使用0x27服务解锁ECU的核心步骤先请求种子再发送Key根据种子计算Key由ECU研发提供的计算Key的安全算法程序来进行计算Key的工作在企业中ECU研发工程师会设计计算Key的安全算法程序这个算法绝密不能泄露、涉及违法在我们工作过程中由于测试需求会将算法程序文件给到我们我们才能使用27服务进行ECU解锁的测试解锁ECU成功后如果没有保持在扩展会话跳回到默认会话后解锁状态也就结束了也就是ECU又处于锁定状态UDS协议规范要求ECU制造商一般也是这样实现的在Tester尝试解锁ECU发送Key失败一定数次后比如3次再次尝试解锁ECU那么ECU从安全的角度考虑不会进行比较Key的验证了而且短时间内也不会再接收27服务了但不影响其它服务。0x27服务支持多种不同级别的解锁ECU可以让自己处于不同级别的解锁状态处于不同级别的解锁状态下才能完成对应的一些安全任务。企业中ECU是否有多个不同级别的解锁状态以及不同级别的解锁状态下能完成哪些任务这些都是取决于ECU的需求定义。可以使用0x27服务的不同子功能代表要解锁不同的安全级别。某一个安全级别的解锁的步骤都是2个步骤先请求种子再发送Key某一个安全级别的请求种子的子功能必须是奇数01、03、05、07、09、……某一个安全级别的发送Key的子功能必须是偶数而且是对应这个安全级别请求种子的子功能号1例如使用01子功能表示请求01安全级别的种子那么算出来的Key必须用0211子功能发送用于解锁01安全级别。使用03子功能表示请求03安全级别的种子那么算出来的Key必须用0431子功能发送用于解锁03安全级别。使用11子功能表示请求11安全级别的种子那么算出来的Key必须用12111子功能发送用于解锁11安全级别。解锁ECU的过程理解和示例数据以下是CANoe中的仿真ECU的解锁ECU的实例截图CANoe中可以非常方便的为诊断面板配置ECU研发提供的安全算法程序文件从而CANoe的诊断工具可以在请求种子后自动调用安全算法程序计算出Key以便于下一步发送Key。0x22服务————根据DID读取数据Tester可以从ECU中读取存储的、工作时的一些数据ECU的序列号、标识名、硬件版本号、软件版本号、软件的最后更新日期、……引擎ECU中还会存储车架号VIN、车门ECU中还会存储当前车窗升降的比例、……还有ECU工作时的实时数据如电压、当前汽车行驶里程、车轮转速、……读取这些数据时必须要用一个指代这些数据的标识名Data Identifier也就是DIDUDS协议中规定DID固定用2个字节表示ECU的各项数据DID有些是UDS协议中规定的有些是ECU制造商自定义的ECU制造商不一定能实现UDS协议中所规定的全部DID其实大多数ECU只实现了很少的一部分列举如下ECU的一般通用信息F1 8CECU的序列号、F1 89ECU的标识名ECU运行的实时数据01 07电压、01 0A转速、01 08汽车行驶总里程信息不同ECU中各自的数据发动机ECU中F1 90VIN、车门ECU中02 01车窗升降比例ECU的诊断相关需求规格定义中会明确定义其所实现的全部DID以及每个DID的详细规范0x22服务的请求响应的报文格式、示例以下是CANoe中的仿真ECU的使用0x22服务读取指定DID数据值的实例截图Trace中的报文结果Diagnostic Console 中 的 分 析 结 果每一项DID的数据值的详细解释报文和其所表征的物理值的关系一定会定义诊断的需求规格说明中可以定义在Word文档中如果公司使用的是Vector系列的工具链可以使用CANDelaStudio制作UDS诊断的数据库文件CDD文件也就是需求规格定义该文件是定义了某个ECU所能实现的UDS诊断服务、子功能和所支持的全部DID。针对DID而言该文件中分门别类的列出了所有的DID和每个DID的参数的名字、数据类型字节长度、转换关系例如下图是对车门仿真ECU的DID为F1 89ECU标识名详细的定义信息例如下图是对车门仿真ECU的DID为01 07电压信息详细的定义信息0x2E服务————向ECU中写入指定DID数据0x2E服务用于向ECU中写入指定DID的数据写入数据是许多的数据由于敏感性和安全要求需要先解锁ECU才能写入写入指定DID数据时参数的设置填写如果没有CANoe或者有CANoe但没有CDD诊断的数据库文件如果有CANoe和该ECU的诊断数据库文件CDD文件那么只需要在诊断控制台上直接填写参数的物理值会自动转换成报文那么需要根据该DID的需求规格定义自己进行物理量和报文直接的转换然后发送0x2E服务的请求格式和示例以下是CANoe中的仿真ECU的使用2E服务写入数据ECU的序列号的实例截图0x19服务————读取诊断故障码信息诊断故障码详解诊断故障码diagnostic Trouble code是用于记录ECU检查到设备故障信息的代号可以理解为故障信息的“身份证”DTC故障内码Root DTC的表示信息的理解协议规定故障码内码是两个字节必须理解这2个字节16个bit是怎么对应到5位故障码表现形式的。最好全都背下来有助于开发理解第一位字符值Description第二位字符值Description00Powertrain (P)00ISO/SAE controlled01Chassis (C)01Manufacturer controlled10Body (B)10ISO/SAE controlled11Network (U)11ISO/SAE controlled第三位字符值描述的故障子系统或范围P00 - P02燃油和空气计量系统(Fuel and air metering)P03点火系统或发动机间歇性熄火(Ignition system or misfire)P04辅助排放控制系统(Auxiliary emission controls)P05车速控制、怠速控制系统和辅助输入(Vehicle speed, idle control, and auxiliary inputs)P06计算机ECU和辅助输出元件(Computer and auxiliary outputs)P07 - P09变速器控制系统(Transmission)P0A - P0E混合动力推进系统(Hybrid Propulsion)故障码描述P0251喷油泵燃油计量控制的 A” 凸轮 /转子 /注射器P0252喷油泵燃油计量控制的 A” 范围/性能凸轮 /转子 /注射器P0253喷油泵燃油计量控制的 A” 低凸轮 /转子 /注射器P0254喷油泵燃油计量控制的 A” 高凸轮 /转子 /注射器P0255喷油泵燃油计量控制的 A” 间歇凸轮 /转子 /注射器P0256喷油泵燃油计量控制的 B” 凸轮 /转子 /注射器P0257喷油泵燃油计量控制的 B” 范围/性能凸轮 /转子 /注射器P0258喷油泵燃油计量控制的 B” 低凸轮 /转子 /注射器P0259喷油泵燃油计量控制的 B” 高凸轮 /转子 /注射器P0260喷油泵燃油计量控制的 B” 间歇凸轮 /转子 /注射器P0320点火 /分销发动机转速输入电路P0321点火 /分销发动机转速输入电路范围 /性能P0322点火 /分销发动机转速无信号输入电路P0323点火 /分销发动机转速输入电路间歇P0324爆震控制系统错误P0325爆震传感器 1 电路P0326爆震传感器 1 电路范围 /性能诊断故障码的FTB故障类型字节————Fault Type ByteFTB代表着故障发生的原因占一个字节故障码的状态完整的故障码信息有4个字节【3个字节故障码2个字节的故障码内码 1个字节的FTB 1个字节的状态】FTB 类别故障类型字节FTB 类别FTB类别描述00-0F一般故障信息此范围包括所有其他类别当故障类别中的故障是唯一的通过分配新的子类型不符合标准时使用或者当检测到的故障在该故障类别中被两个或更多子类型最好地描述时。10-1F一般电气故障此范围指定标准接线故障模式即短路和打开以及与欧姆定律相关的直流(DC) 量。20-2F一般信号故障此范围指定与振幅、频率或变化率以及波形相关的量。30-3FFM (频率调制)/PWM (脉冲宽度调制) 故障该范围规定了与控制模块的调频 (FM) 和脉冲宽度调制 (PWM) 输入和输出相关的故障。此类别还包括位置由计数决定的故障。40-4F系统内部故障该范围规定了与内存、软件和内部电路相关的故障需要更换组件 (控制模块、传感器等)。50-5F系统程序设计故障该范围规定了与操作软件、校准和选项相关的故障通过配置/编程系统的一部分(控制模块、传感器等) 来补救。60-6F算法故障此范围基于比较两个或多个输入参数的合理性来指定故障将单个参数与自身相对于时间进行比较。70-7F机械故障该范围指定了通过不适当的运动检测到的故障以响应与控制模块相关的输入/控制输出。80-8F总线信号故障此范围指定与总线硬件和信号完整性相关的故障。当信号的物理输入位于一个控制模块中而另一个控制模块诊断电路时也使用此类别。90-9F元件故障该范围指定了与连接到控制模块或由控制模块监控的组件相关的故障这些组件本身并没有通过数据链路连接器与扫描工具通信。该范围还规定了与连接到控制模块或由控制模块监控的组件相关的非电气故障。A0-AF一般电气故障-2此范围指定标准接线故障模式即短路和打开以及与欧姆定律相关的直流(DC) 量。B0-BFISO/SAE 保留此值由文档保留以便将来扩展。C0-CFISO/SAE 保留此值由文档保留以便将来扩展。D0-DFISO/SAE 保留此值由文档保留以便将来扩展。E0-EFISO/SAE 保留此值由文档保留以便将来扩展。F0-FF车辆制造商/系统供应商专用此范围保留给车辆制造商/系统供应商使用。0x19 01————读取诊断故障码数量子功能的参数名【ReportDTCNumberByStatusMask】CANoe中仿真ECU子功能0x19 01实例0x19 02————读取指定状态掩码DTC列表0x19服务02子功能的参数名为ReportDTCByStatusMask02子功能是19服务中的非常重要和基础的子功能ECU都应该实现它CANoe中的仿真ECU实例————0x19 020x19 04————根据DTC及快照编号读取DTC的快照记录当ECU检测到某一个故障码所代表的故障发生时可以存储当时ECU或汽车的一些重要实时数据例如电压、引擎转速、实行总里程等。这些就是故障发生时的“快照记录Snapshot”每次发生故障时都可以记录一次快照信息开发可以为每个快照指定一个快照编号。高品质的ECU才有记录故障发生时的快照记录的能力很多ECU不具备这样的能力因为也就不提供19 04子功能这项服务。使用19 04子功能时指定一个DTC和一个想要读取的快照编号就可以让ECU返回某个DTC发送时的某一次故障的快照记录信息。19 04子功能的参数名reportDTCSnapshotRecordByDTCNumberUDS协议规定如果“快照号”的字节为“FF”表示要求ECU返回该DTC的所有快照CANoe中的仿真ECU实例————0x19 040x19 0A————读取ECU支持的所有 DTC 及其当前状态子功能名称reportSupportedDTC0A服务用于读取服务器中所有已配置/支持的 DTC并返回每个 DTC 的编号和当前状态。请求中不带任何数据参数只指定子功能。0A 子功能和 02 子功能很像但是不同点在于0A 请求无参数直接读取所有支持的DTC包括当前无故障的02 需要状态掩码读取符合掩码过滤条件的DTC请求格式字节参数值/说明#1Request SID0x19#2sub-function0x0A即19 0A如果需要抑制肯定响应可将子功能字节 bit7 置 1即请求0x8A肯定响应格式字节参数值/说明#1Response SID0x59#2sub-function0x0A#3DTCStatusAvailabilityMask服务器支持的 DTC 状态位掩码#4*nDTCAndStatusRecord[]每个记录 4 字节DTC 高字节、DTC 中字节、DTC 低字节、statusOfDTC即59 0A 【DTCStatusAvailabilityMask】 【DTC_HB DTC_MB DTC_LB statusOfDTC】* N肯定响应示例假设服务器支持 2 个 DTC状态掩码支持0xFFDTC 分别为P0101假设三字节0x01 0x01 0x01状态0x24P02020x02 0x02 0x02状态0x08。请求19 0A肯定响应59 0A FF 【01 01 01 24】 【02 02 02 08】ECU 支持的 DTC 列表是静态的此时他们的故障状态都是默认状态例如0x50运行一段时间后故障状态会发生各种的变化例如情况statusOfDTC 可能的值测试还没跑0x50测试未完成测试跑了通过0x00或0x40本循环测试未完成位可能还在测试失败未确认0x01或0x05testFailed pending测试失败已确认0x04或0x07或0x24等故障恢复等待老化0x04或0x0C等清码后回到0x50或0x00类似以上这种而0A子功能和02子功能的区别可以通过以下例子来学习假设 ECU 支持 4 个 DTCDTC含义P0101空气流量计P0102空气流量计低P0300随机失火P03011 缸失火刚复位时0x0A可能返回59 0A FF 01 01 01 50 01 02 02 50 03 00 00 50 03 01 01 50 //四个 DTC 状态都是 0x50表示测试未完成。运行一段时间后0x0A可能返回59 0A FF 01 01 01 00 // 测试通过 01 02 02 04 // 已确认故障 03 00 00 50 // 还没跑到 03 01 01 07 // 测试失败 挂起 已确认 //每个 DTC 状态都不一样。0x14服务————清楚故障信息清除故障码14服务用于清除诊断信息清除故障码—— Clear Diagnostic Information14服务没有子功能也没有DID只有一个代表要清除那一类/组的诊断故障信息的参数“GroupOfDTC”这个参数用三个字节表示实际上大多数ECU只实现了FFFF这一种参数代表清除所有的故障码CANoe中基于仿真ECU的实例————0x14服务
企业数字化 ERP 产品动态
相关推荐
机器学习目标定义:AI安全落地的关键与实战框架 1. 从一次模型上线事故说起:目标定义不清到底有多致命去年帮一个做工业质检的团队看他们线上模型的问题。模型在离线测试集上准确率97%,F1也在0.95以上,指标漂亮得可以拿去写论文。但上线跑了不到两周,产线那边就炸了——漏检率突… · 2026/9/25 16:27:43
基于SpringBoot的社区团购管理系统设计与实现:技术栈、背景意义与核心代码 温馨提示:本人主页置顶文章(点我)开头有 CSDN 平台官方提供的学长联系方式的名片!
1. 项目背景与意义
随着移动互联网和社区电商的快速发展,社区团购已成为连接社区居民与本地供应商的重要零售模式。传统社区团购多依赖微信群接龙、手工记账… · 2026/9/25 16:27:12
LLM Wiki 亮点深挖:知识图谱、MCP、深度研究、两步摄入是怎么实现的(TaoToken 配置骨架) /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 17:00:02
Hunk 测试体系全解:跨模块、跨进程与终端边界的分层测试布局与命令指南 开发工具代码评审CLIAI 应用 【免费下载链接】hunk Review-first terminal diff viewer for agentic coders 项目地址: https://gitcode.com/gh_mirrors/hu/hunk 点击查看 免费下载 本篇技术指南围绕 Hunk(Review-first 终端 diff 查看器)仓… · 2026/9/25 16:59:56
MCP 实战:TaoToken 统一 Key 下的服务配置与工具调用 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 16:59:56
RTX 5090复现Openvla,部署,推理,微调、评估和结果分析全流程记录 精简版项目总结、实验结果和演示视频:GitHub记录
一、环境配置
OpenVLA 官方测试栈:Python 3.10、torch 2.2.0、torchvision 0.17.0、transformers 4.40.1、tokenizers 0.19.1、timm 0.9.10、flash-attn 2.5.5。OpenVLA LoRA:官方写明至少要… · 2026/9/25 16:59:49
EMAformer:改进Transformer嵌入层,提升时间序列预测精度 时间序列预测这个方向,做的人多,但真正把Transformer用出效果的案例其实没想象中那么多。我最早接触这类模型是在做电力负荷预测的时候,当时用LSTM跑了个基线,MAE卡在某个数值上怎么都下不去,后来换成Transformer&… · 2026/9/25 16:59:49
Day 08 · AI 视频摘要:10 分钟视频 30 秒看完 作者:梅雅达编程笔记收藏了一个 1 小时的 Python 教学视频,想着"周末好好看"。结果周末到了,打开视频,看了 5 分钟觉得太慢,拖了一下进度条,又觉得跳太多了怕漏掉关键内容……反反复复折腾了 20 … · 2026/9/25 16:59:49
创维E900V22D刷机全攻略:S905L3SB芯片兼容性解析与救砖实战 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:31
MQTT协议原理与Broker服务器搭建实战:从Mosquitto到EMQX /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:37