ISO14229-1专栏（4）--服务消息的格式约定

上一篇文章介绍了应用层的协议，其中的重点是PDU的介绍以及服务器对于不同请求类型消息的响应行为，其中不要忘记NRC78这个特殊情况哦，那么随着学习的不断深入，我们也离14229-1最核心的部分--诊断服务越来越近了，那么这章我们来看看14229-1中的第八章，服务描述约定。打好基础，以后理解诊断服务才会事半功倍，加油！

6 服务描述约定

6.1 服务描述

本子条款定义了本规范中如何描述每项诊断服务。它定义了每个诊断服务的一般服务描述格式。

本小节简要概述了服务的功能。每个诊断服务规范都以客户机和服务器执行的特定于每个服务的操作的描述开始。每个服务的描述包括一个表，其中列出了其原语的参数：请求/指示、响应/确认肯定或否定结果。它们都具有相同的结构：

对于给定的请求/指示和响应/确认a_PDU定义，每个参数的存在由以下约定（Cvt）值之一描述：

 

这张图是14229-1中的原图，来简单解答一下：M代表Mandatory，表示该参数必须在A_PDU中出现；C代表Conditional，表示根据某些标准，参数可以出现在A_PDU中，例如子功能参数；S代表Selection，表示参数是必需的，除非另有规定，并且是从参数列表中选择的；U代表User option，表示该参数是用户可选的参数，用户可以对该参数做出规定，例如是否使用该参数。

注意：标记为“M”（强制）的“＜服务名称＞请求SID”不意味着服务器必须支持此服务。“M”仅表示在服务器支持服务的情况下，请求A_PDU中必须存在此参数。

6.2 请求消息

6.2.1 请求消息-定义

本小节包括一个或多个表，用于定义服务请求/指示的A_PDU（应用层协议数据单元）参数。如果不同子功能参数的请求消息在A_Data参数的结构上不同，并且无法在单个表中明确说明，则每个子功能参数可能有一个单独的表。

下图定义了包含子功能的请求A_PDU的定义：

 

我认为这个表并不包含数据段的组合顺序，也就是实际发出的请求消息可能并不是按照这个顺序发出的，当然这只是我的猜想，是否是这个顺序还需要以后再调查，但是从这个表中确实是能看出来哪些参数是必须要有的，哪些参数是可选的，上面的那些参数在上一章已经说明了，不知道是什么意思的可以再翻一翻上一章的内容。

下图描述了不包含子功能的请求A_PDU的定义：

 

大家自行理解哈。

在所有请求/指示中，寻址信息MType、TA、SA、TAtype和Length是强制性的。寻址信息RA可选地存在。

6.2.2 请求消息-子功能参数等级定义

下图中说明了子功能参数字节分为2部分：

 

子功能参数值是7位值（子功能参数字节的位6-0），其可以具有多个值以进一步指定服务行为。除了肯定响应抑制位之外，支持子功能参数值的服务还应支持子功能值表中定义的子功能参数。

如果SPRMIB对于具有大量数据的响应为TRUE，需要使用分页缓冲区处理，这可能会导致第一批数据的传输仍然可以在响应定时窗口内开始，但服务执行的终止超出响应定时窗口的限制。如果在这种情况下响应被抑制，则无法向客户端通知延迟，但服务器仍处于繁忙状态，尚未准备好接收另一个请求。对于客户端，建议不要请求大量数据并在同一请求中设置SPRMIB（例如，SID 0x19 SF 0x0A），因为这会破坏SPRMIB的目的。对于服务器实现，建议发送NRC 0x78（RCRRP），然后也发送肯定响应，以防SPRMIB为TRUE时使用分页缓冲处理。

简单地来说如果服务支持子功能，那么第二个字节就分为2部分，第7位是肯定响应抑制位，其余7个为子功能参数，那么显然子功能参数的最大值为0x7F喽，同时请注意，肯定响应抑制位抑制的是肯定响应，不关否定响应的事。

下图描述了子功能参数的定义以及数据格式：

 这里没什么好说的，大家自己看图就能理解。

6.2.3 请求消息-数据参数定义

数据参数部分可以包含多个字节。本小节提供了每个数据参数的一般描述。如果所描述的服务不使用任何数据参数，则该子条款不包含任何定义。

 6.3 肯定响应消息

6.3.1 肯定响应消息定义

诊断服务执行后，应发送诊断服务的肯定响应消息（如果需要）。如果诊断服务需要不同的处理（例如ECUReset服务），则可以在诊断服务的服务描述中找到何时发送肯定响应消息的适当描述。

下图定义了肯定响应的A_PDU：

 6.3.2 肯定响应消息-数据参数定义

如果所描述的服务不使用任何数据参数，则该子条款不包含任何定义。数据参数部分可以包含多个字节。

下图定义了响应的数据参数：

 这里也没有什么好说的，如果服务不支持数据参数，那么就没有，如果支持，那么就需要注意回复什么样的参数，需要根据具体的服务来看。

6.4 支持的否定响应码（NRC）

除每个服务说明中规定的否定响应代码（如适用）外，还应使用附录A.1中列出的否定响应码。详情见附录A.1（14229-1的2013版）。

这里14229-1也给了一张图，但是我觉得没什么用，否定响应码还是看附录或者学习服务的时候一起理解比较好。

6.5 消息流示例

那么这里14229-1也给出了一个消息流的示例，来先简单看一看服务的请求消息和响应消息的格式吧。

 上图是一条不包含寻址信息的请求报文，消息的传递方向是客户端发送给服务器，消息类型是一条请求消息，第一个字节是请求的SID（就是正常的SID，例如0x10DiagnosticSessionControl等），接下来是子功能参数和数据参数。那么服务器的响应消息有2种，对了，就是肯定响应和否定响应，下图就是肯定响应消息的示例：

 那么消息的传递方向是服务器发送给客户端，消息类型是响应消息，第一个字节是响应SID（响应SID = 请求SID + 40，例如0x10服务的响应SID就是0x50），接下来是子功能参数和数据参数，肯定响应消息就是这样，下图是否定响应消息的格式：

 

消息的传递方向是服务器发送给客户端，消息类型是响应消息，第一个字节是固定的数据0x7F，第二个字节是请求SID，第三个字节就是响应错误的否定响应码啦（例如，如果请求消息的长度不对，否定响应码就是0x13）。

可能以上的消息格式不是那么的明确哈，下面就拿出我从前辈那里得到的方法，来把消息格式形象地展示出来，上图：

 我个人感觉还是这样比较直观一点，比较好理解，所以以后的文章我尽量都会以这种方式呈现，当然有的时候还是14229-1中的表达方式好一些，能描述更多细节，我会在尊重标准的基础上尽量以这种好理解的方式呈现出来。

小结

这篇内容总体来说还是比较简单，主要是为了介绍接下来的26个UDS诊断服务开了个小头，介绍了诊断请求报文和响应报文的格式，知道了响应消息有肯定响应和否定响应2种，那么从下篇文章开始我们就要接触UDS诊断的第一个服务了，估计这26个服务也会用比较长的时间来介绍，这期的内容到此为止，我们下期见！