0、概述

        ISO-14229也称为UDS（统一诊断服务），是一个用于汽车行业诊断通信的需求规范，应用于OSI七层模型的应用层（第7层）。他只规定了与诊断相关的服务需求，并未涉及通信机制；所以，对于ISO-14229的使用是可以架设在各种网络上的，除了我们比较熟悉的CAN外，还可以基于LAN、FlexRay、串口等。在前面的一些文章里，我们也介绍了UDS中常用到的一些诊断服务（如19服务、34/36/37服务、31服务等）的使用；本文则主要介绍下UDS诊断服务的格式及NRC（错误响应码）的定义描述，作为基础补充。
        

1、术语介绍

        为便于后面对UDS诊断服务格式的介绍，我们先来介绍下涉及到的术语。

        （1）、Addressing Type （寻址方式）
        寻址方式指的是诊断消息的传递方式，有以下两种寻址方式：
        物理寻址（Physical），即1对1通信，用于知道确切的被诊断ECU的地址；
        功能寻址（Functional），即1对n通信，或者说广播发送，用于不知道确切的被诊断的ECU的地址，向一组或者全体ECU发送请求。
        例如，在我们ECU的升级过程中，预编程阶段的相关诊断报文（如通过85服务关闭DTC的更新、28服务关闭其他ECU的报文发送功能），一般会通过功能寻址的方式进行发送，广播式地通知车上其他ECU。在正式升级阶段则通过物理寻址方式，进行数据传输刷写。

        （2）、SID（Service Identifier）
        用以指代某个诊断服务的1字节无符号整数。例如会话模式控制的10服务、请求复位的11服务等。

        （3）、DID（Data Identifier）
        用以标识ECU中贮存的某个诊断数据单元的2字节无符号整数。例如请求数据读取的22服务：22 F1 87中的"F1 87"。对于使用者来说DID屏蔽了具体实现细节，而将重点放在了数据本身。例如当我们要读取某个单元的诊断数据时，只要操作（读）对应的DID就可以，而不必通过数据的具体地址去操作。

        （4）、NRC（Negative Response Code）
        即1字节的无符号整数表示的错误响应码。它是诊断协议为每一种执行失败的诊断服务分配的失败原因代号，便于我们对服务请求失败原因的定位分析。

        （5）、Sub-Function（子服务）
        1字节的无符号整数表示的子服务。有些诊断服务可以支持不同的诊断子服务，Sub-Function就是用来定义这种子服务的，通过他将某一个服务细分为更为具体的服务。如10服务中的01、02、03，分别表示请求进入不同的会话模式；19服务中的04、06，分别表示请求的是快照还是扩展信息等。
        其格式如下，注意其最高位(bit7)是肯定响应应答禁止位；即当该位为1时，则该请求的肯定响应不需进行回复。剩余的7个位用于表示子功能的值，具体值对应的含义在各自服务中都有进行介绍的。这里只需注意该字节最高位这个"肯定响应应答禁止位"的作用即可。如10 83是请求进入扩展会话；且如果是肯定响应（50 03）则不需进行回复。

2、诊断服务报文格式

        前面介绍完了涉及到的术语，接下来我们正式来说说UDS诊断服务报文的格式，将分为请求格式、响应格式（肯定响应/否定响应）来进行介绍。

        2.1、请求格式（Request）
        诊断服务请求格式可以分为以下2种：
        [SID] + [Sub-Function] + [Parameter]
        [SID] + [Parameter]
        即有无Sub-Function的区别；这里我们是把DID也归为Parameter了。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数目也是视具体要求而定。

        2.2、肯定响应（Positive Response）
        在请求服务成功执行后，被请求的ECU会返回一个肯定响应；根据通过请求的服务格式是否带有[Sub-Function]，其格式一样可以分为以下的两种：
        [SID + 0x40] + [Sub-Function] + [Parameter]
        [SID + 0x40] + [Parameter]
        这里一样把DID也归为Parameter里。要注意前面ECU收到的服务请求格式是否有带[Sub-Function]，有的话则需注意[Sub-Function]中的Bit 7肯定响应应答禁止位的值。若为1，注意此时是不需发送肯定响应的。我们来看看如下的例子

A、带<Sub-function>的格式：
 Request:   10 03 ------------ 请求进入扩展会话（10是SID，03是Sub-function）
 Response:  50 03 ------------ 请求成功，回复积极响应（50是SID+0x40，03是Sub-function） 

 Request:   10 83 ------------ 请求进入扩展会话（10是SID，83是Sub-function，其中肯定响应应答禁止位有效）
 Response:  无应答，因为肯定响应应答禁止位（Sub-function的Bit7）有效

B、不带<Sub-function>的格式：
 Request:   22 F1 84 --------- 请求进入扩展会话（22是SID，F1 84 是DID，即Parameter）
 Response:  62 F1 84 01 ------ 请求成功，回复积极响应（62是SID+0x40，F1 84 是DID，即Parameter，01是ECU返回的数据，也是归于Parameter）

        2.3、否定响应（Negative Response）
        否定响应的格式比较固定，第一字节固定是0x7F，第二字节是之前请求服务的SID，第三个字节是错误响应码，指示具体错误响应的原因，这个NRC可以在协议中查到，并且不同的服务所支持的NRC也有规定。格式如下：
        [0x7F] + [SID] + [NRC]
        

3、NRC定义描述