车载通信——诊断刷写

一.诊断刷写基础知识

UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是在汽车电子ECU环境下的一种诊断通信协议。

诊断工具与车内的所有控制单元连接启用了UDS服务,使用OSI模型的第五层和第七层(会话层和应用层)。

Diagnostic Trouble Code(DTC): 诊断故障代码

发请求时的格式1:SID+DID;

发请求时的格式2:SID(特指例程控制服务)+子类型+RID

SID(Service ID:服务类ID,

DID(Data ID:数据类ID,一般都是与产品系统相关的信息和一些配置信息,

RID(RoutineControl ID:例程控制的ID,一般都是些与标定、烧写相关的耗时耗资源操作

诊断协议: 

UDS本质上是一系列服务的集合。UDS是一种定向的通信,是一种交互协议(Request/Response),即诊断方(Tester)给ECU发送指定的请求数据(Request)。服务ID(SID:Service Identifier,诊断服务ID)和与服务相关的参数包含在CAN数据帧的8个数据字节中,这些数据帧是从诊断工具发出的。

诊断服务应用 

UDS-诊断服务功能 :

报文:03 7F 27 35 AA AA AA AA, 其中:

            A). 0表示这个是一个SF,即单帧;

            B). 第二位非0,表示这是一个长度为8字节的报文;3表示,playload负载长度是3个字节;

            C). 7F,是诊断负响应码标识;

            D). 27表示的是诊断安全访问服务(SecuritySession);

            E). 35为具体的负响应码,“非法密钥”;

            F). AA 是位填充符;

否定响应码——NRC 

通信过程

寻址信息包含了源地址(Source Address)和目标地址(Target Address)。

UDS的寻址模式分两种:

物理寻址(点对点、一对一),根据物理地址的不同进行访问,但只能访问单个ECU节点,Tester为SA源地址,ECU作为TA目标地址。

功能寻址(广播、一对多),根据功能的不同进行访问,它能访问多个ECU节点,对于标准帧来说,通常是0x7DF。

 二.基于UDS刷写功能

(1)预编程步骤

10 03  为了禁止ECU间的正常通信和控制DTC设置,预编程需要启动非默认(诊断)会话模式, 诊断仪应持续周期性(S3client)发送诊断仪在线服务请求(3E 80),以维持所有ECU的非默认会话模式(功能寻址)

31 01 02 03  检查ECU编程条件,从而确保系统安全

85 02  诊断仪发送DTC设置类型设为关闭的控制DTC设置服务请求(功能寻址)

28 03 03  诊断仪通过通信控制(28h)服务请求,禁止非诊断报文的发送和接收(功能寻址)

22 xx yy  禁止正常通信后,读取被编程的ECU的状态(如:编程的应用软件和数据)

 (2)主编程步骤

10 02  收到一个寻址方式为物理寻址,子功能为编程会话的诊断会话控制(10h)服务后,ECU启动Bootloader,并分配编程所需的所有资源(物理寻址)

27 09/0A  编程事件必须通过安全访问

27 01  安全校验

27 02 47 11  物理请求

31 01 FF 00  物理响应

2E F1 5A  在擦除内存例程之前,将指纹写到ECU内存中是强制的(哪个诊断仪对ECU内存做了修改)

31 01 FF 00  为了允许应用软件和数据下载,ECU的内存将被擦除

34  请求下载

36  传输数据

37  请求传输退出

31 01 02 02  检查编程完整性例程,检查所有的字节都正确传输

31 01 FF 01  一旦完成所有的应用软件或数据块/模块的下载,诊断仪将开始一个例程来触发ECU检查重编程的依赖性

11 01  诊断仪使用物理寻址,发送一个复位类型为硬复位的ECU复位11h)服务请求报文到CAN网络(物理寻址)

 (3)后编程步骤

10 03  诊断仪发送一个会话类型为扩展会话的诊断会话控制服务请求报文到CAN网络上,使所有ECU(包括刷写执行完毕已复位的ECU)切换至扩展会话模式(功能寻址)

28 00 03  诊断仪通过通信控制(28h)服务请求,开启非诊断报文的发送和接收(功能寻址)

85 01  诊断仪发送DTC设置类型设为开启的控制DTC设置服务请求(功能寻址)

10 01  诊断仪发送一个会话类型为默认会话的诊断会话控制(10h)服务请求报文到CAN网络, 诊断仪应停止发送周期性的诊断仪在线请求 3E 80(功能寻址)

14 FF FF FF  通过物理寻址的清除诊断信息服务来清除

附:

三、诊断请求报文格式

(1)诊断Request格式:

格式1:[SID] + [Sub-function]

格式2:[SID] + [DID]

格式3:[SID] + [Sub-function] + [DID]

(2)Positive Response:肯定响应

格式1:[SID + 0x40] + [Sub-function]

格式2:[SID + 0x40] + [DID]

格式3:[SID + 0x40] + [Sub-function] + [DID]

(3)Negative Response:否定响应

[0x7F] + [SID] + [NRC]

案例:

单帧数据传输:

(1)肯定响应

发送请求:10 02

响应请求:50 02 00 32 00 C8

(2)否定响应

发送请求:10 01

响应请求:7F 10 12 (NRC:sub-functionNotSupported)

报文:03 7F 27 35 AA AA AA AA, 其中:

            A). 0表示这个是一个SF,即单帧;

            B). 第二位非0,表示长度为8字节的报文;3表示,playload负载长度是3个字节;

            C). 7F,是诊断负响应码标识;

            D). 27表示的是诊断安全访问服务(SecuritySession);

            E). 35为具体的负响应码,“非法密钥”;

            F). AA 是位填充符;

多帧数据传输:

(1)发送数据为单帧,06开头代表有发送的数据中含有6个字节

(2)响应为肯定响应,连续帧

· 10中的1代表连续帧的首帧,0A代表此连续帧中含有10个字节

· 30代表流控帧

· 21代表连续帧里的第一帧

Step1:

                0:表示单帧(SF);

                6:表示一个长度为6字节的报文,后面的负载长度是6个字节;

                04:服务;

                91 D6 15 10:指定的DID值

Step2:

                1:表示首帧(FF);

                A:表示整个数据包的长度为10个字节;即:59 04 91 D6 15 10 11 22 33 44

Step3:

                3:表示流控帧(FC);

                0:表示流状态是继续发送帧(FlowStatus=0);

                00:表示buffer size为0个字节;

                00:表示连续帧的时间间隔为00ms;

Step4:

                2:表示连续帧;

                1:序列号值为1(SequenceNumber=1),因为此帧是紧接首帧的连续帧;

                11 22 33 44:报文数据;

                00填充位;

  • 14
    点赞
  • 132
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 4
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车人——EEA

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值