CAN诊断基础知识
- 客户端(Client)——诊断请求的提出者– Tester(诊断仪),发送诊断请求
- 服务器端(Server)——诊断响应的提供者– 某个ECU,发送诊断响应
- 远程客户端/服务器(Remote Client /Server)
❖ 与Server (Client) 不在同一“网段” - Physical Address物理通信(1:1)
采用物理寻址方式通信的场景,及客户端与服务器之间一对
一 的诊断通信方式。 - funtctional Address功能通信(1:N)
采用功能寻址方式通信的场景,及客户端向多个服务器发出
同 一功能的诊断请求的通信方式。 - 源地址
发送节点地址 目标地址
接收节点地址协议数据单元(PDU)
协议数据单元是一组信息和数据的集合,表示了发送方和接
收 方对等实体之间传递的信息和数据。协议数据单元包括:
口 协议控制信息(PCI)
口 数据(Data)单帧传输
数据长度<6/7个字节
报文类型
口 单帧(SF)- 多帧传输
数据长度>6/7个字节,最多允许4095个字节
报文类型
口 第一帧(FF):描述传输的起始
口 流控制帧(FC):传输过程中,报文流控制
口 连续帧(CF):传输数据
• Request
诊断仪向ECU发送命令
• Response
ECU向诊断仪发送回复数据
• Negative Response
ECU由于命令不符合标准或没有能力回复正确数据()或命令不能执行等情况
下回复的响应
• Positive Response
ECU回复正确数据或命令正确执行
• Service/SID
标准化的诊断命令/命令标准化编码
• Subfunction
标准化的诊断命令子参数
• SPRMIB
SuppressPosRspMsgIndicatinBit带subfunction的service的subfunction的第七
位(0x80),表明该命令如果被正确执行,则不需要回复正响应
• Sessions
ECU支持default,extended,programing等session,相同service在不同session有可能是支持或不支持
• Security Level
service要在正确Security Level才能被执行,如WriteDataByIdentifier,要解锁才才能被执行
• DTC
故障码,代表某一个组件或元件故障编码
• DID
data identifier 一组数据标识符,如ECU的零件号
• N R C
Negative response codes ECU ECU在负相应时,通知诊断仪出错
的原因编码
DTC status bits
bit# | hex | state | description |
---|---|---|---|
0 | 0x01 | testFailed | DTC failed at the time of the request |
- bit 0 : testFailed
通常来说,ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试,如果在最近的一次测试中,在某个错误路径中发现了故障,则相应DTC的这一个状态位就要被置1,表征出错。此时DTC的testFailed位被置1,但是它不一定被ECU存储到non-volatile memory中,只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时,testFailed会再次被置为0。
- bit 1 :testFailedThisOperationCycle
这个bit用于标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况,即是否出现过错误。operation cycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠,对于没有网络管理的ECU,这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过,比如,当前testFailed = 0, 说明当前这个DTC没有出错,如果testFailedThisOperationCycle = 1的话,就说明这个DTC在当前这个operation cycle中出过错,但是当前错误又消失了。