网站首页 > 技术文章 正文
UDS bootloader刷写报文实例解析
最近有同事问起UDS的事情,为了熟悉14229当时还写过简易的tester上位机,录了报文。
UDS的全称叫通用诊断规范,主要的功能分为故障诊断和刷写两个部分,14229就是通用诊断规范的具体协议,规定了tester和ECU之间的通讯方式方法。对于协议中的内容是也就是子功能的内容是由主机厂自行规定,所以每个主机厂都有自己的诊断规范。
主机厂会根据自己的车型分配CAN网络的ID给UDS使用,故障定义分配DTC故障码给UDS使用,定义冻结帧列表给UDS使用,定义数据流的DID,识别UDS的子功能,
文章的最后有一个刷写的报文数据流,用于展示UDS的刷写过程框架,对于UDS数据流的具体细节会在以后的文章中体现,
1,UDS地址
- UDS地址分为持物理寻址和功能寻址,物理地址像是广播帧,暂时假设功能寻址请求ID= KillBug,ECU回复ID=godKnow,物理寻址请求ID=Fixdall,
2,DTC故障码
- DTC故障码有一个编写规则,该数字码代表了一个故障,详细见图
3,冻结帧列表
- 冻结帧是对应的故障发生时刻需要锁定的标量数据,存储到ECU中,为故障排查过程提供数据支持,但是冻结帧受到存储空间大小和存储过程对CPU消耗的影响不能存储过多,另外单个上电周期同一故障的存储次数同样需要谨慎处理,
4,DID列表
- DID是两个字节的数字,UDS通讯传输过程中具体的传输的数据代表的实际意义,比如:F183表示bootloader版本,F184表示硬件版本,
5,刷写的报文数据流实例
- 先要介绍下UDS的服务
- 基本每个UDS服务又有子服务详细的可以参考14229,比如:10服务下就有01,02,03三个子服务,01代表常规会话,02代表刷写会话,03代表扩展会话,每个会话有对应的权限,有些服务只能在指定的会话下执行,参见 ‘UDS服务列表’图,
- UDS 的服务包括:
- 10服务:诊断会话的控制,
- 11服务:ECU复位控制
- 27服务:密钥密匙的安全控制
- 28服务:通讯功能控制
- 3E服务:tester 在线控制
- 85服务:DTC设置的控制
- 22服务:根据DID读取数据
- 2E服务:根据DID写入数据
- 2F服务:一些输入输出口的控制,一些外设比如IO等的控制等
- 14服务:清空诊断信息
- 19服务:读取DTC的信息
- 31服务:刷写的控制,开始,停止以及检查是否满足刷写状态等
- 34服务:请求下载
- 36服务:开始传输数据
- 37服务:请求传输退出
- UDS报文刷写实例及解析
- 每一帧CAN报文都是8个字节
- KillBug 8 02 10 01 00 00 00 00 00
- //与上位机连接,请求CANID:KillBug,CAN报文的字节长度:8,UDS服务有效字节数:02,UDS服务:10,子服务:01,
- godKnow 8 06 50 01 00 32 00 C8 AA
- //上面请求的回复,回复CANID:godKnow,CAN报文的字节长度:8,UDS服务有效字节数:06,UDS服务:10+40,子服务:01,
- Fixdall 8 02 10 03 00 00 00 00 00
- //进入扩展会话,请求CANID:KillBug,CAN报文的字节长度:8,UDS服务有效字节数:02,UDS服务:10,子服务:03,
- KillBug 8 04 31 01 02 03 00 00 00
- godKnow 8 03 7F 31 33 AA AA AA AA
- //刷写的控制,请求CANID:KillBug,CAN报文的字节长度:8,UDS服务有效字节数:04,UDS服务:31,子服务:01,DID:0203 ,其中 子服务:01=开始刷写,使能刷写,DID:0203=检测刷写条件是否满足,
- Fixdall 8 02 85 02 00 00 00 00 00
- godKnow 8 02 C5 02 AA AA AA AA AA
- //DTC控制,请求CANID:Fixdall,CAN报文的字节长度:8,UDS服务有效字节数:02,UDS服务:85,子服务:02,其中 子服务02:停止DTC的记录,
- Fixdall 8 03 28 03 01 00 00 00 00
- godKnow 8 02 68 03 AA AA AA AA AA
- //DTC控制,请求CANID:Fixdall,CAN报文的字节长度:8,UDS服务有效字节数:03,UDS服务:28,子服务:03,01,其中 子服务03:禁止CAN报文的发送和接受, 子服务03后的01表示:禁止的CAN报文类型是普通报文,不包括UDS自身的报文,
- KillBug 8 03 22 F1 83 00 00 00 00
- godKnow 8 10 0D 62 F1 83 42 43 55
- KillBug 8 30 00 00 00 00 00 00 00
- godKnow 8 21 20 15 04 21 32 30 30
- //UDS服务有效字节数:03,UDS服务:22,DID:F183,其中DID F183: 表示读取bootloader版本,该DID由主机厂定义,
- KillBug 8 02 10 02 00 00 00 00 00
- godKnow 8 06 50 02 00 32 00 C8 AA
- //UDS服务有效字节数:02,UDS服务:10,子服务:02,其中子服务02:表示ECU进入刷写会话,
- KillBug 8 02 27 11 00 00 00 00 00
- godKnow 8 06 67 11 04 01 0B 65 AA
- //UDS服务有效字节数:02,UDS服务:27,子服务:11,其中子服务11:表示请求密钥,
- KillBug 8 06 27 12 92 91 11 6E 00
- godKnow 8 02 67 12 AA AA AA AA AA
- //UDS服务有效字节数:02,UDS服务:27,子服务:12,其中子服务12:表示请接收计算好的密匙,
- KillBug 8 10 0C 2E F1 84 00 00 00
- godKnow 8 30 00 01 AA AA AA AA AA
- KillBug 8 21 00 00 00 00 00 00 AA
- godKnow 8 03 6E F1 84 AA AA AA AA
- //UDS服务有效字节数:0C,UDS服务:2E,DID:F184,其中0C前面的10表示传输的是多帧数据,流控帧稍后整理资料介绍,DID F184:表示硬件版本 这又主机厂自行定义,
- KillBug 8 10 0B 34 00 44 D4 00 00
- godKnow 8 30 00 01 AA AA AA AA AA
- KillBug 8 21 00 00 00 05 00 AA AA
- godKnow 8 04 74 20 01 02 AA AA AA
- //write=34 写入的其实地址和数据量的大小,UDS服务有效字节数:0B,UDS服务:34,其中服务34表示请求下载,0C前面的10表示传输的是多帧数据,流控帧稍后整理资料介绍,
- KillBug 8 11 02 36 01 82 12 82 00
- godKnow 8 30 00 01 AA AA AA AA AA
- //UDS服务有效字节数:02,UDS服务:36,其中服务36表示请求传输,36后面的01是有意义的,表示数据块的计数器,34服务后的第一个36的数据块是01,之后累加,直到FF,这之后变成00继续累加,
- //..........此处省略被刷写的数据..........
- KillBug 8 01 37 00 00 00 00 00 00
- godKnow 8 01 77 AA AA AA AA AA AA
- //UDS服务有效字节数:01,UDS服务:37,其中服务37请求传输退出,
- KillBug 8 10 08 31 01 02 02 3B 2B
- godKnow 8 30 00 01 AA AA AA AA AA
- KillBug 8 21 61 06 AA AA AA AA AA
- godKnow 8 05 71 01 02 02 01 AA AA
- //当刷写完成后,需要恢复之前的状态,UDS服务有效字节数:08,UDS服务:31,子服务:01,服务31:表示刷写控制,子服务01:表示使能使能服务,0202:表示检查数据CRC结果,
- KillBug 8 04 31 01 FF 01 00 00 00
- godKnow 8 05 71 01 FF 01 00 AA AA
- //UDS服务有效字节数:04,UDS服务:31,子服务:01,服务31:表示刷写控制,子服务01:表示使能使能服务,FF01:有主机厂定义,表示检查APP的刷写完成标志,
- KillBug 8 10 09 2E F1 99 16 02 17
- godKnow 8 30 00 01 AA AA AA AA AA
- KillBug 8 21 09 40 21 AA AA AA AA
- godKnow 8 03 6E F1 99 AA AA AA AA
- //刷写完成后,写入当下时间戳,
- KillBug 8 02 11 01 00 00 00 00 00
- godKnow 8 02 51 01 AA AA AA AA AA
- //ECU复位
- Fixdall 8 02 10 03 00 00 00 00 00
- //退出了02的刷写会话,进入扩展会话,
- Fixdall 8 03 28 00 01 00 00 00 00
- godKnow 8 02 68 00 AA AA AA AA AA
- //恢复CAN通讯
- Fixdall 8 02 85 01 00 00 00 00 00
- godKnow 8 02 C5 01 AA AA AA AA AA
- //重新使能DTC的记录,
- Fixdall 8 02 10 01 00 00 00 00 00
- godKnow 8 06 50 01 00 32 00 C8 AA
- //进入默认会话,
- done,
- 上一篇: AP AUTOSAR硬核技术(5):诊断管理
- 下一篇: UDS之19服务中04子服务:读取快照数据
猜你喜欢
- 2024-12-14 鉴源实验室:车载ECU嵌入式设备的诊断测试 - 会话和安全控制
- 2024-12-14 AUTOSAR学习笔记之服务层介绍
- 2024-12-14 大众汽车为所有ID.系列引入OTA无线更新
- 2024-12-14 纯电动汽车整车控制器软件设计
- 2024-12-14 AUTOSAR BSW介绍
- 2024-12-14 AUTOSAR概述
- 2024-12-14 什么是AUTOSAR(一)——AUTOSAR概述
- 2024-12-14 UDS网络层介绍
- 2024-12-14 CAN编程介绍
- 2024-12-14 想要快速进阶车载测试!这些基础问题你一定要知道
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)