码迷,mamicode.com
首页 > 其他好文 > 详细

ISO14229系列之二:诊断指令格式和相关概念

时间:2015-04-27 00:17:00      阅读:805      评论:0      收藏:0      [点我收藏+]

标签:

作者:autogeek

原文链接:http://www.cnblogs.com/autogeek/p/4458658.html

1. 简单的通信机制

其实诊断通信的机制很简单,可以类比client-server通信方式,即客户端发送request,服务器收到request之后进行处理,然后向客户端发送response。但是,诊断协议有自己的特色,它规定了在request和response的格式,在收到request的时候要做格式的检查。同时由于寻址方式的不同,有无sub-function的支持等,也会影响request和response的处理方式和结果。下面将我就具体情况分析,尽量做到简介明了。

2. Request

2.1 基本格式

归纳起来,诊断的request格式无非以下2种:

<SID> + <Sub-function> + <Parameter>

<SID> + <Parameter>

即有无sub-function的区别。其中,我把DID也归为Parameter

2.2 有sub-function

在介绍有sub-function情况的request之前,首先要了解一下sub-function的定义方法。下图是从ISO14229中截来的,它是对sub-function的定义。

技术分享

值得注意的是Bit 7,从字面上来看它用来指示是否要抑制Positive Response。的确,它的目的就是这个意思,当Bit 7为1(1 = ‘true’)时,对该request的Positive Response要被抑制,即不发送Positive Response;当Bit7为0(0 = ‘false’)时,对该request的Positive Response不被抑制,正常发送。除了Bit 7,Sub-function有不同的值,具体的值和含义在协议中对每个服务的解释时都会有介绍。

2.3 不带sub-function

根据2.2的说明,不带sub-function的服务,就带parameter。Parameter可以是DID,可以是输入参数,可以是自定义的值,字节数目也是视具体要求而定。一般在协议内都会有表格,当遇到具体问题时,可查表确定。

3. Response

一般来讲,response会在一个服务被request且执行之后发送,成功的话就发positive response,失败的话要发negative response,但是也有例外的时候,比如ECUreset,他要求先发送response,然后再去执行具体的reset,因为如果先reset,那么ECU的通信模块shut down,是无法发送出去response的。一般像这种特殊情况,协议会在描述具体服务时标注出来。

3.1 Positive Response

基本格式:

<SID+0x40> + <Sub-function> + <Parameter>

<SID+0x40> + <Parameter>

其中要注意第一个字节是由SID和0x40的和构成,至于为什么要这样做,只能说协议就是这么规定的,只要是Positive的response,其第一个字节就是要由相应SID的值再加上0x40构成。这里的Parameter项是optional的,具体要看协议规定。

比如session control的service:

Send:10 01(byte1的10是SID,byte2的01是sub-function,且可知Bit 7是false)

Receive:50 01 (byte1是SID+0x40,byte2是sub-funtion)

再举个不带sub-function的例子,比如ReadDataById这个service:

Send:22 F1 86(byte1是SID,byte2和byte3是DID,可视为parameter的一种)

Receive:62 F1 86 01(byte1的62是SID+0x40,byte2和byte3是DID,byte4是读到的数据)

不论是物理寻址还是功能寻址,对于Positive Response来说都没有影响,只需要关注sub-function中的Bit 7 suppressPosRspMsgIndicationBit是0还是1,如果为0即false,那么正常发送即可,如果是1即true,那么就不发送response。如果根本没有subfunction呢,那么什么都不要考虑,肯定是要发送positive response的。

3.2 Negative Response

基本格式:

<0x7F> + <SID> + <NRC>

看起来比较简单,格式比较固定,只要是Negative Response,第一字节就一定是0x7F,第二字节照抄原来的SID,第三个字节是错误响应码,指示具体错误响应的原因,这个NRC可以在协议中查到,并且不同的服务所支持的NRC也有规定。

还是拿session control 这个service来举例:

Send:10 05(现在sun-function变为05了,假定系统不支持这个sub-function)

Receive:7F 10 12(7F即指代错误响应,10为SID,12是NRC,查协议可知其指代sub-function not supported 这个错误)

格式讲完了,来看看在物理寻址和功能寻址情况下,Negative Response分别有什么区别。

首先在物理寻址情况下,只要是Negative Response就应该按照规定格式发送。而在功能寻址情况下,有一点特殊,对于NRC为0x11(service not supported)、0x12(subfunction not supported)、0x31(request out of range)这三种情况,功能寻址是不会发送response的。

4. Request的检查策略

下面用一张流程图来展示收到request之后ECU如何检查他的合法性,并确定是正响应还是负响应,发送还是不发送。这里只是展示最基本的步骤,还有具体的和每个服务相关的条件判断,需要结合具体需求来讨论。

技术分享

ISO14229系列之二:诊断指令格式和相关概念

标签:

原文地址:http://www.cnblogs.com/autogeek/p/4458658.html

(0)
(3)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!