从这篇文章开始就要接触14229-1的核心内容--诊断服务的介绍了，在之后的文章中我们会接触到26个服务以及若干个他们的子服务。

我们介绍的顺序也是和14229-1中的顺序相同，不是按照SID从小到大的顺序，而是按照功能单元的分类来一一介绍，首先是诊断与通信管理功能单元。

7 诊断与通信管理功能单元

图1中是诊断与通信管理功能单元中包含的服务：

一共有10个服务，分别是：

0x10(DiagnosticSessionControl诊断会话控制)：客户端请求控制与服务器之间的诊断会话；

0x11(ECUResetECU复位)：客户端强制服务器执行重置；

0x27(SecurityAccess安全访问)：客户端请求解锁一个安全的服务；

0x28(CommunicationControl通信控制)：客户端控制服务器中的通信参数的设置（例如，通信比特率）；

0x3E(TesterPresent测试仪在线)：客户端向服务器指示它仍然存在；

0x83(AccessTimingParameter访问时间参数)：客户端使用此服务来读取/修改活动通信的定时参数；

0x84(SecuredDataTransmission安全数据传输)：客户端使用此服务以扩展的数据链路安全性执行数据传输；

0x85(ControlDTCSetting控制DTC设置)：客户端控制服务器中DTC的设置；

0x86(ResponseOnEvent事件响应)：客户端请求在服务器中设置和/或控制一个事件机制；

0x87(LinkControl链路控制)：客户端请求控制通信波特率。

下面就一个一个来看吧。

7.1 DiagnosticSessionControl（0x10）service

诊断控制控制服务用于在服务器中启用不同的诊断会话。

每个不同的会话都会支持不同的诊断服务和功能，该服务还在肯定响应中报告对启用的诊断会话有效的数据链路层特定参数值（例如定时参数值）。、

服务器中应始终只有一个诊断会话处于活动状态。服务器在上电时应始终启动默认诊断会话。如果未启动其他诊断会话，则只要服务器上电，默认诊断会话将一直运行。

服务器应能够在正常运行条件和车辆制造商规定的其他运行条件下（如跛行回家运行条件，至于什么是跛行回家，请自行百度）提供诊断功能。

如果客户机请求了一个已经在运行的诊断会话，则服务器应发送一个肯定的响应消息，并按照图2所示的方式进行操作，该图描述了服务器在切换会话时的行为。

每当客户端请求新的诊断会话时，服务器应在新会话的定时器生效之前发送肯定响应，也就是先给肯定响应，再切换到新会话，当然也不排除某些情况是先切换到新的会话再给出肯定响应，例如03会话切换到02会话时，就是先切换到02会话再发送肯定响应的。如果服务器无法切换到所请求的诊断会话，则应该发送否定响应消息，并且服务器保持当前的会话模式运行，非默认诊断会话（不包括编程会话）中支持的服务和功能是默认会话中支持的服务和功能的超集，这意味着当切换到任何非默认诊断会话（不包括编程会话）时，默认会话的诊断功能也都支持。然而，那些非默认会话支持的服务和功能在本文档中没有明确的定义，一般都是OEM来定义相关的标准。

要启动一个新的诊断会话，服务器可能会请求满足某些条件。所有这些条件都是由用户定义的。这类情况的例子有：

服务器可以只允许具有特定客户端标识符（客户端诊断地址）的客户端启动特定的新诊断会话（例如，服务器可以要求只有具有客户端标识符0xF4的客户端可以启动扩展诊断会话）。
可能需要满足某些安全条件（例如，车辆不得移动或发动机不得运行）。

在一些系统中，期望在新的诊断会话开始时改变通信定时参数。DiagnosticSessionControl服务实体可以使用适当的服务原语来改变为底层指定的定时参数，以改变本地节点中的通信定时。

图2提供了诊断会话转换的概述，以及当服务器转换到另一个会话时应该做什么。

转换过程说明：

当服务器处于默认会话模式且客户端请求启动默认会话时，服务器应完全重新初始化默认会话--在激活会话期间重置所有的激活/启动/更改的设置/控件，这不包括编程到非易失性存储器中的长期更改。
当服务器从默认会话切换到默认会话以外的任何其他会话时，服务器只能停止在默认会话期间通过ResponseOnEvent(0x86)服务在服务器中配置的事件。
当服务器从除默认会话之外的任何诊断会话转换到除默认会话以外的另一会话（包括当前活动的诊断会话）时，服务器应（重新）初始化诊断会话，这意味着：通过响应事件（0x86）服务在服务器中配置的每个事件都应停止；服务器的安全等级应重新锁定。注意，安全访问的锁定应重置依赖于要解锁的安全访问的任何活动诊断功能（例如DID的活动输入输出控制）；应维护新会话中支持且不依赖于安全访问的所有其他主动诊断功能。例如，当从一个非默认会话转换到另一个或相同的非默认会话时，任何配置的周期性调度程序都应保持活动状态，并且CommunicationControl和ControlDTCSetting服务的状态不应受到影响，这意味着当在会话切换时禁用普通报文通信时，普通报文通信应保持禁用状态。
当服务器从默认会话以外的任何诊断会话切换到默认会话时，服务器应停止通过ResponseOnEvent（0x86）服务在服务器中配置的每个事件，并且安全等级回到未解锁状态。应终止默认会话中不支持的任何其他活动的诊断功能。例如，应禁用任何配置的周期调度程序或输出控制，并重置CommunicationControl和ControlDTCSetting服务的状态，这意味着当会话切换到默认会话时禁用正常通信时，应重新启用正常通信。服务器应在激活会话期间重置所有激活/启动/更改的设置/控件。这不包括编程到非易失性存储器中的长期更改。

图3定义了在defaultSession和非defaultSession期间允许的服务（定时服务）。任何非默认会话都与客户端必须保持活动状态的诊断会话计时器相关联。

关键字：

a：在默认会话期间是否也允许响应事件服务是特定于实现的；

b：安全的数据标识符需要一个安全访问服务，因此还需要一个非默认的诊断会话；

c：安全的内存区域需要一个安全访问服务，因此还需要一个非默认的诊断会话；

d：可以在默认和非默认的诊断会话中动态地定义数据标识符；

e：安全的例程需要一个安全访问服务，因此还需要一个非默认的诊断会话。需要客户端主动停止的例程也需要一个非默认会话。

图中画x的当然就是支持了，右上角的字母就是上面解释的关键字的意思了。

7.1.1 请求消息

图4定义了0x10服务的请求消息：

给出比较好理解的图5，

可以看到，诊断会话控制服务的请求消息比较简单，只有2个部分，2个字节，第一个字节是SID，也就是0x10，第二个字节是子功能参数，也就是要切换到的会话模式，子功能参数具体的定义见图6。

0x10服务的子功能最常用的只有3个，0x01默认会话、0x02编程会话和0x03扩展会话，在这里我们主要介绍这三个，其余的实在是不常用，想了解的可以自行百度。

首先是0x01子服务，默认会话，前面说过，默认会话时ECU在上电后进入的会话模式，默认会话可以理解成是一个网站的用户模式，权限较小，支持基本的诊断服务，并且不需要TesterPresent服务来维持诊断会话模式。

其次是0x02子服务，编程会话，此诊断会话支持支持服务器内存编程所需的所有诊断服务，可以理解为开发这个网站的程序员，权限相当大了，但是默认会话里支持的服务编程会话也不一定都支持，这个还是要看具体的需求。

最后是0x03子服务，扩展会话，这个会话可以理解成网站的管理员账号，他可以管理用户的信息，用户有的功能他基本上都有，但是0x02会话支持的功能他不一定都支持。

另外请注意，此服务的请求消息中不包含数据参数，也就是请求消息只有2个字节而已。

7.1.2 肯定响应消息

图7定义了肯定响应消息的格式：

不好理解？上图，如图8：

那么可以看到，第一个参数毫无意外，是SID+0x40（1个字节），第二个参数就是请求消息中的子服务ID（1个字节），当然，如果请求是10 81的话，肯定响应消息的子功能可就不是81了，那是啥呢？啥也不是，因为肯定响应消息被抑制了，所以服务器不回复肯定响应，也就没有子功能了。后面还有一个数据参数呢，这个代表着什么呢？图8中很明显地标注出来了，这个数据参数一共有4字节，其中前两个字节传递的是P2Server这个时间参数，后两个字节传递的是P2*Server这个时间参数，这里标准也给了这两个时间参数的占用字节数和含义，如图9所示：

P2Server是每当客户端发送一个请求后，如果服务器不能在P2Server这个时间内给出响应，那么就应该发送NRC为78的否定响应消息，那么P2*Server相当于是P2Server的增强版，当服务器发送第一个NRC78的否定响应后，如果在P2*Server的时间内还是给不出响应，那么就应该发送第二个NRC78的否定响应消息，以此类推。

7.1.3 支持的否定响应码

首先来看否定响应消息的格式，如图10所示：

很简单，一共有3个参数，第一个参数是固定的0x78，第二个参数是SID（1个字节），第三个参数是NRC（否定响应码，1个字节），0x10服务支持的NRC如图11所示：

简单说一下这三个NRC的含义：

0x12 sub-functionNotSupported，顾名思义就是不支持这个子功能，比如说服务器不支持0x04这个子服务，但是客户端偏要发送10 04请求，那服务器就会回复7F 10 12，也就是NRC为0x12的否定响应消息；0x13 incorrectMessageLengthOrInvalidFormat，也就是请求消息长度或格式不对，比如客户端发送10 01 00请求消息，但是请求消息的长度要求是2字节，非得要发一个3字节的，那服务器就给你回复7F 10 13呗，也就是NRC为0x13的否定响应消息；0x22 conditionNotCorrect，顾名思义，条件不正确，这个就看具体的需求定义了，比如说我想让服务器切换到编程会话，假如切换到编程会话有条件，例如车速什么的，但是现在条件不满足，那此时客户端发送10 02的话，服务器就会回复7F 10 22，也就是NRC为22的否定响应消息。

7.1.4 诊断会话控制服务的消息流示例

例1：客户端想请求服务器切换到02会话，期待服务器有一个肯定响应，假设服务器的P2Server等于50ms，P2*Server等于5000ms，那么请求消息和肯定响应消息如图12：

是不是一目了然（狗头），当然，官方文档中的图片也奉上，如图13所示：

这两张图结合起来看，再加上前面的知识，理解0x10服务不算困难，但是关键还要实践，0x10服务到此为止，下面来看0x11服务。

7.2 ECUReset（0x11）service

客户端使用ECUReset服务来请求服务器重置，通过参数resetType来控制执行重置的类型，并且在服务器重置前应发送肯定响应（如果需要），成功重置服务器后，服务器应启动默认会话。

ISO 14229的这一部分没有定义从对ECU重置请求的肯定响应消息之后到重置成功完成的时间段内ECU的行为。建议在此期间，ECU不接受任何请求消息并发送任何响应消息。

7.2.1 请求消息定义

0x11服务的请求消息如图14和图15所示，一个是官方给出的格式，一个是我整理出的好理解的格式，大家可以结合着来看：

可以看到，ECUReset服务的请求消息有2部分，第一个部分是SID（1个字节），第二个部分是子功能，即resetType（1个字节）重启类型，用来描述服务器必须如何执行重置，resetType的定义如图16所示：

这里只介绍三个resetType：0x01 hardReset、0x02 keyOffONReset、0x03 softReset。首先是0x01 hardReset，硬重启，顾名思义就是硬件重启，该重启类型相当于服务器掉电再上电的过程，执行的操作没有标准定义，这可能导致易失性存储器和非易失性存储器位置重新初始化为预定值；其次是0x02 keyOffOnReset，相当于重新点火一次，此复位条件应模拟钥匙开关顺序，通常会保留非易失性存储器位置的值，易失性存储器将被初始化；最后是0x03 softReset，软重启，软件重启，重启应用程序软件，而不重新初始化以前学习过的配置数据、自适应因素和其他长期调整。

此外，ECUReset服务的请求消息没有其他的数据参数。

7.2.2肯定响应消息

如图17和图18所示：

ECUReset服务的肯定响应消息分为3个部分，第一个部分是SID+0x40，第二个部分是请求消息中的resetType，第三部分是可选的参数powerDownTime，只在resetType=0x04时才存在，此参数向客户端指示服务器将保持在断电顺序中的备用顺序的最小时间。分辨率为每次一秒，且0x00-0xFE有效，0xFF指示故障或时间不可用。

7.2.3 支持的否定响应码

先看否定响应消息格式，如图19所示：

支持的否定响应码上图中也有，但是还是来看一下比较全面的，如图20所示：

在这里就不细说否定响应码的含义了，大家自行理解。

7.2.4 ECUReset服务消息流示例

例1：客户端请求重启的方式是硬重启，服务器需要在重启之前发送肯定响应消息（如果需要），请求消息和肯定响应消息如图21和图22所示：

ECUReset（0x11）服务就到此介绍完了，下一个服务是SecurityAccess（0x27）服务。

7.3 SecurityAccess（0x27）service

该服务的目的是提供一种访问数据和/或诊断服务的方法，因为安全、排放或安全原因，这些服务的访问受到限制。用于将例程或数据下载/上传到服务器以及从服务器读取特定存储器位置的诊断服务是可能需要安全访问的情况。下载到服务器中的不当例程或数据可能会损坏电子设备或其他车辆部件，或危及车辆符合排放、安全或安保标准。安全概念使用种子和密钥关系。

一个使用此服务的经典例子如下：客户端请求种子，服务器发送种子，客户端计算密钥并发送给服务器，服务器响应说密钥是有效的，服务器将解锁。

请求种子消息的子功能参数值应始终为奇数，同一安全级别对应发送密钥消息的子功能参数值应该等于请求种子的子功能参数值加一。

在任何时候都只能激活一个安全级别，例如，如果服务器已经解锁了0x03相关联的安全级别，但是此时测试仪请求成功解锁与请求种子0x01相关联的安全级别，那么此时只能解锁与请求种子0x01相关联的安全级别所支持的安全功能，以前由与请求种子0x03关联的安全级别解锁的任何附加安全功能都将不再被激活。

客户端请求服务器解锁的过程应该严格按照标准过程来，首先，客户端请求种子，服务器返回种子，然后客户端通过获取到的种子计算密钥并发送，服务器比较密钥，如果匹配则解锁，不匹配则从头开始解锁流程，也就是从获取种子开始重新执行。

如果服务器支持安全性，也就是支持27服务，当服务器收到请求种子的消息时，此时请求的安全级别已经解锁，那么服务器回复的种子值应该为全0，其他情况绝对不可以回复全0，因为客户端要根据此情况来判断服务器是否已解锁。

在服务器通电/重置后以及在一定次数的错误访问尝试之后，在服务器能够积极响应来自客户端的服务SecurityAccess“requestSeed”消息之前，可能需要特定于车辆制造商的时间延迟。如果支持此延迟计时器，则应在达到车辆制造商指定的错误访问尝试次数后，或在服务器通电/重置且先前执行的SecurityAccess服务因一次错误访问尝试而失败时，激活延迟。如果服务器支持此延迟计时器，则在成功解锁服务器后，服务器应清除通电/重置时的延时计时器调用的服务器内部指示信息。如果服务器支持此延迟计时器，并且无法确定在通电/重置之前先前执行的SecurityAccess服务是否失败，则在通电或重置之后，延迟计时器应始终处于活动状态。仅当服务器在通电/重置时被锁定时，才需要延迟。车辆制造商应选择是否支持延迟计时器。

如果客户端在服务器未解锁的情况下请求安全服务，那么服务器应该回复否定响应消息，一般客户端访问安全服务都是这个流程：切换03会话->解锁服务器->请求服务。

7.3.1 请求消息定义

SecurityAccess服务的请求消息有2种，一种是请求种子的请求消息，一种是发送密钥的请求消息，如图23所示：

同样给出易理解的版本，如图24所示：

先看请求种子的请求消息，分为3个部分，第一部分是SID（1个字节），第二部分是子功能参数（1个字节），子功能参数securityAccessType向服务器指示此服务正在进行的步骤、客户端希望访问的安全级别以及种子和密钥的格式。如果服务器支持不同的安全级别，则每个级别应通过requestSeed值来标识，该值与sendKey值的关系是sendKey=requestSeed+0x01，第三部分是安全访问数据记录（字节数由车辆制造商定义，当然也可以为0），这个参数是用户定义的，当请求种子信息时，用户可以选择此参数记录来向服务器传输数据。例如，它可以包含在服务器中验证的客户端的标识。

再看发送密钥的请求消息，同样分为3个部分，第一部分是SID+0x40（1个字节），第二部分是请求种子时的子功能参数加上0x01（1个字节），表示这是和请求种子同样安全等级的密钥，第三部分是计算的密钥（字节数由车辆制造商定义）。

SecurityAccess服务的子功能定义如图25所示：

7.3.2 肯定响应消息

首先给出官方的说法，如图26所示：

那么我们知道，0x27服务的请求消息有2中，第一种是请求种子，第二种是发送密钥，所以肯定响应消息也应该有2种，只看官方给出的格式很容易误导人们认为肯定响应消息只有一种格式，其实不然，这里给出易于理解的格式，如图27所示：

那么这样看起来就很清晰了，返回种子的肯定响应一共有三个部分，第一个部分是固定的0x67（1个字节），第二个部分是子功能参数（1个字节），这和请求种子消息的子功能参数相同，第三个部分就是服务器返回的种子，一般是3个字节或4个字节，这要看OEM的具体要求了。密钥验证成功的肯定响应消息一共有两个部分（2个字节），第一个部分是固定的0x67（1个字节），第二个部分是子功能参数（1个字节），和发送密钥时请求消息中的子功能参数相同。现在回过头来看官方给出的肯定响应消息格式，可以看到securitySeed参数后面有C的字样，哦，原来是有条件的参数啊，只有子功能参数是请求种子时的情况才会存在这个参数，否则是没有的哦。

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

先看否定响应消息的格式，如图28所示：

否定响应消息分为三部分，第一部分是固定的0x7F（1个字节），第二部分是SID 0x11（1个字节），第三部分是支持的NRC，图29中记录了每个NRC发生的情况，如果错误场景适用于服务器，则应使用列出的否定响应。

7.3.4 消息流示例

对于以下给定的消息流示例，如果服务器处于“锁定”状态，则必须满足以下条件才能成功解锁服务器：

⎯ sub-function to request the seed: 0x01 (requestSeed)

⎯ sub-function to send the key: 0x02 (sendKey)

⎯ seed of the server (2 bytes): 0x3657

⎯ key of the server (2 bytes): 0xC9A9 (e.g. 2’s complement of the seed value)

客户端通过将suppressPosRspMsgIndicationBit（子功能参数的第7位）设置为“false”（“0”）

示例1：服务器处于锁定状态

第一步，请求种子，请求消息如图30所示，响应消息如图31所示，

第二步，发送密钥，请求消息如图32所示，肯定响应消息如图33所示，

老样子，在此献上易于理解的格式图，如图34所示：

示例2：服务器处于解锁状态

我们先来理论分析一下，当服务器已经解锁，并且解锁的安全等级刚好是我们要请求解锁的等级时，这个时候我们向服务器请求种子，会发生什么呢？这个时候服务器依然会给出肯定响应，只不过返回的种子是全0的数值，那么我们来看一下具体的消息流，请求消息不必多说，和示例1的相同，不同的是响应消息，这里只给出返回种子的肯定响应消息格式，如图35和图36所示：

到这就是0x27服务的全部内容了，简单回顾一下，SecurityAccess服务是安全访问服务器的服务，客户端需要通过此服务请求解锁服务器来请求需要安全等级解锁的服务，那么解锁步骤一共分为4步，分别是请求种子、返回种子、发送密钥、最终响应。下个服务我们介绍0x28（CommunicationControl）服务，加油！

7.4 CommunicationControl（0x28）service

此服务的目的是打开/关闭服务器的某些消息（例如应用程序通信消息）的发送和/或接收。

服务器和客户端应满足5.5中规定的请求和响应消息行为。

7.4.1 请求消息定义

图37 定义了请求消息的格式：

可以看出CommunicationControl服务的请求消息一共有四个部分，第一部分是SID（1个字节），在这里就是0x28；第二部分是子功能参数controlType（1个字节），子功能参数controlType包含服务器应如何修改communicationType参数中引用的通信类型的信息，如图38所示，一般常用的子功能参数有0x00使能收和发、0x01使能收禁止发、0x02使能发禁止收、0x03禁止收和发，不常用的0x04和0x05都是通过附加的地址信息来控制通信的收发；第三部分是通信类型参数communicationType（1个字节），用于表明要控制的通信类型，具体的格式定义如图39所示，该字节的位编码低位半字节表示communicationType，可通过CommunicationControl（0x28）服务进行控制。例如，位组合（Bits 1-0）为“11b”的communicationType有效，并禁用“normalCommunicationMessages”和“networkManagementCommunicationMessage”消息。communicationType字节值的高半字节定义了当接收到适当的CommunicationControl服务时，应禁用/启用连接到接收节点的子网；第四个部分是节点标识参数（2个字节），此参数只有在子功能参数为0x04或0x05时才会在请求消息中存在，用于识别车辆中某个子网络上的节点，具体值的定义如图40所示，在该网络中，同一节点可以连接到不同车辆线路中的不同网络（例如，具有唯一节点地址的LIN节点连接到一个模型中的网络a，而同一节点连接到不同模型的网络B）。因此，nodeIdentificationNumber提供了一种机制，其中远程节点所连接的相关主节点将相关网络转换到特定诊断模式（例如，禁用LIN网络上的正常通信）。只有检测到由nodeIdentificationNumber标识的相关节点连接的相关主节点才能执行请求的通信控制服务，该节点不能使用较低OSI层1至6的寻址方法来寻址。

OK，那么请求消息的格式以及参数我们都说明了一下，这个时候来看易于理解的请求消息格式，如图41所示：

7.4.2 肯定响应消息

这里给出标准的格式和易于理解的版本，分别如图42和图 43所示：

可以看出CommunicationControl服务的肯定响应消息只有两个部分（2个字节），第一部分是固定的SID+0x40（1个字节），也就是0x68；第二部分是子功能参数controlType（1个字节），和请求消息中的子功能参数相同。

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

先来看一下否定响应消息的格式，如图44所示：

否定响应消息分为三个部分，第一部分是固定的0x7F（1个字节）；第二部分是SID（1个字节），这里就是0x28；第三部分是NRC，图45说明了CommunicationControl服务所支持的NRC：

7.4.4 消息流示例

如图46所示，客户端通过CommunicationControl服务来请求服务器使能收禁止发网络管理报文，那么服务器给出肯定响应，如图47所示：

老样子，给出以上标准格式对应的易理解的格式，如图48所示：

其实14229-1中还有其他两个例子，是关于子功能0x04和0x05的，由于我目前还未接触到这两个子功能的用法，所以这里先不列举了，只给出帮助大家理解的最简单的示例。

到此CommunicationControl服务就介绍完了，做个简单的回顾，CommunicationControl服务功能如其名一样，是控制报文的通信的一个服务，通过子功能参数来设置要对报文操作的类型，比如说是使能收禁止发还是禁止收发之类的，那么还有一个参数是用来选择报文类型的，比如说普通报文和网络管理报文等，下个服务我们介绍0x3E服务TesterPresent，加油！

7.5 TesterPresent（0x3E）service

此服务用于向服务器（或多个服务器）指示客户端仍然连接到车辆，并且先前激活的某些诊断服务和/或通信将保持活动状态。直接的理解就是：客户端给服务器发诊断设备在线请求消息，也就是问候一句“你好吗”，这时候如果服务器接收到此请求，而且此请求消息的都符合服务器的条件并且肯定响应抑制位为0，那么服务端就会向客户端回复肯定响应消息，也就是回复一句“我很好”

该服务还有一个特殊功能：如果服务器在非默认会话模式下，客户端再去请求此服务时，服务器端就可以保留在此非默认会话模式下，其实就是将诊断会话计时器S3server中记录的还没有超过5000ms的时间记录清除，让他再去从0开始计时，这时要想回到默认会话就得再等5000ms或者用10服务。

注意：这个特殊功能其实并不是在我们这个服务里边做的，而是诊断会话服务中本身具有的一项特性，即有除诊断会话服务以外的其他诊断请求指令时，而且服务器当前处于非默认会话模式下，诊断会话计时器就是重新进行计时5000ms，这样我们去诊断设备在线请求时，也就是在这个“其他诊断请求指令”之内。

7.5.1 请求消息定义

先看标准格式，如图49所示：

请求消息一共只有两个部分（2个字节），第一部分是SID（1个字节），在这里是0x3E；第二部分是子功能参数zeroSubFunction（1个字节），TesterPresent服务的子功能只有一个，那就是0x00，也被称为0子功能，如图50所示：

同样的，给出易于理解的请求消息格式如图51所示:

注意：虽然说子功能只有一个，但是别忘了还有个肯定响应抑制位呢，0x80也是可能的，因为他是一个普遍的概念，不是只针对TesterPresent这个服务独有的概念，所以也就没提，但是一定要注意，这个肯定响应抑制位不管什么时候都是有可能被置为1的，这一点一定要注意！

7.5.2 肯定响应消息

TesterPresent服务的请求消息这么简单，相信他的肯定响应消息也一样简单，那么在看图之前请大家现在脑子中想象一下肯定响应消息应该是什么样子的，相信你肯定想到了，标准格式如图52所示，易理解的格式如图53所示：

同样的，肯定响应消息也有两部分，第一部分是SID+0x40（1个字节），在这里就是0x7E；第二部分是子功能参数（1个字节），和请求消息中的一样，是0x00。那么到这可能有人会有这样一个想法：既然子功能参数和请求消息中的一样，那这里的肯定响应消息中的子功能参数也可能是0x80吧，错，大错特错，别忘了，子功能参数的0x80是因为把肯定响应抑制位给置1了，那肯定响应都抑制了，子功能参数怎么可能是0x80呢？所以千万不要有这样的想法，一定要注意。

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

TesterPresent服务的否定响应消息格式如图54所示：

和其他的否定响应消息一样，这里不做解释了，以后的服务也不再对否定响应消息的格式做过多的解释，如果不懂可以看看前面的4个服务中关于否定响应码的解释，那么这里TesterPresent服务支持的NRC如图55所示：

7.5.4 消息流示例

示例1：肯定响应抑制位为0

这里同时给出标准版和易理解的版本，分别如图56和图57所示：

示例2：肯定响应抑制位为1

这里还是同时给出标准版和易理解的版本，分别如图58和图59所示：

那么随着两个示例的结束，TesterPresent服务的介绍也就到此为止了，简单回顾一下，此服务的主要功能就是为了保持当前的会话模式，使服务器不会自动切换到默认会话，实际应用还是很广泛的，下一个服务我们介绍0x83服务AccessTimingParameter，加油！

7.6 AccessTimingParameter（0x83）service

AccessTimingParameter服务用于读取和更改通信链路激活期间的默认定时参数。

此服务的使用非常复杂，取决于服务器的能力和数据链路拓扑。每个诊断会话仅支持一个扩展的定时参数集。建议仅在物理寻址时使用此服务，因为服务器支持不同的扩展定时参数集。

建议使用以下服务顺序：

-DiagnosticSessionControl（diagnosticSessionType）服务；

-AccessTimingParameter（readExtendedTimingParameterSet）服务；

-AccessTimingParameter（setTimingParametersToGivenValues）服务。

对于需要服务器发送响应的情况，客户端和服务器应在服务器发送AccessTimingParameter肯定响应消息后激活新的定时参数设置。如果不允许响应消息，则客户端和服务器应在发送/接收请求消息后激活新的定时参数。

成功切换到另一个或相同的诊断会话后（例如，通过DiagnosticSessionControl、ECUReset服务或会话定时超时），服务器和客户端应将其定时参数重置为默认值。

AccessTimingParameter服务为访问服务器定时参数提供了四种不同的模式：

-读取扩展定时参数集；

-将定时参数设置为默认值；

-读取当前活动的定时参数；

-将定时参数设置为给定值。

7.6.1 请求消息定义

图60给出了请求消息的标准格式，图61给出了请求消息易理解的格式：

很明显，AccessTimingParameter服务的请求消息一共有三个部分，第一部分是SID（1字节），在这里就是0x83；第二部分是子功能参数（1个字节）timingParameterAccessType，子功能参数的定义如图62所示，常用的有4个，都在图里，大家可以自行理解；第三部分是TimingParameterRequestRecord参数（n个字节），这个参数只有在timingParameterAccessType = setTimingParametersToGivenValues时才会存在，也就是只有当客户端想请求服务器将定时参数设为给定值时，请求消息中才会存在该参数，该值的定义可以在ISO14229-3中找到（我也没找过，官方文档里说的）。

7.6.2 肯定响应消息

先来看一下肯定响应消息的格式，标准格式如图63所示，易于理解的格式如图64所示：

AccessTimingParameter服务的肯定响应消息和请求消息一样一共有三个部分，第一部分是SID+0x40（1个字节），在这里就是0xC3；第二部分是子功能参数timingParameterAccessType（1个字节），和请求消息中的子功能参数相同；第三部分是TimingParameterResponseRecord参数，和请求消息中的该参数不同，该参数只有在timingParameterAccessType = readExtendedTimingParameterSet时才会存在，意思就是如果客户端请求读取扩展的定时参数集时，服务器会使该参数来传递返回给客户端的定时参数集。

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

否定响应消息的格式如图65所示：

AccessTimingParameter服务支持的NRC如图66所示：

7.6.4 消息流示例

如图67和图68所示：

到这里AccessTimingParameter服务的介绍就结束了，可以看出来0x83服务的内容不是很多，但是我到现在还没有用过，所以不知道应用起来是简单还是复杂，先来简单回顾一下，0x83服务的主要功能是读取可设置的时间参数以及设置时间参数，这也是个支持子功能的服务，下一个要介绍的服务是SecuredDataTransmission（0x84）服务，加油！

7.7 SecuredDataTransmission（0x84）service

7.7.1 服务描述

此服务的目的是传输防止第三方攻击的数据。

如果客户端打算在安全模式下使用本文档中定义的诊断服务，则SecuredDataTransmission服务适用。它还可以用于在客户端和服务器之间以安全模式传输符合某些其他应用协议的外部数据。在此上下文中的安全模式意味着传输的数据受到加密方法的保护。

图69说明了安全子层。必须在服务器和客户端应用程序中添加安全子层，以便以安全模式执行诊断服务。

那么就有两种数据传输的方式：

不安全的数据传输。这种方式使用其他诊断服务在客户端和服务器间交换数据，安全子层不起作用;
安全的数据传输。使用安全子层以及其他服务来进行数据的交换，安全子层使用SecuredDataTransmission服务来传输安全的数据，因此必须是点对点的通信，只允许物理寻址。

安全子层与应用程序的接口是根据ISO/OSI模型约定进行的，因此提供了以下四个安全子层（SS_）服务原语:

-SS_SecuredMode.req: Security sub-layer Request;

-SS_SecuredMode.ind: Security sub-layer Indication;

-SS_SecuredMode.resp: Security sub-layer Response;

-SS_SecuredMode.conf: Security sub-layer Confirmation.

ISO 14229的这一部分定义了确认和未确认服务。在安全模式下，仅允许确认的服务（suppressPosRspMsgIndicationBit=FALSE）。根据此要求，以下服务不允许在安全模式下执行：

-ResponseOnEvent (0x86);

-ReadDataByPeriodicIdentifier (0x2A);

-TesterPresent (0x3E);

确认的服务（suppressPosRspMsgIndicationBit=FALSE）使用四个应用层服务原语请求、指示、响应和确认。当在安全模式下执行确认的诊断服务时，这些被映射到四个安全子层服务原语上，反之亦然。

在安全模式下执行诊断服务时，安全子层的任务是加密“应用程序”提供的数据，解密“应用程序层”提供的信息，以及添加、检查和删除安全特定数据元素。安全子层使用应用层的SecuredDataTransmission（0x84）服务，根据外部协议（请求和响应）发送和接收整个诊断消息或消息，应在安全模式下进行交换。

安全子层向应用程序提供服务“SecuredServiceExecution”，用于安全执行诊断服务。

“SecuredServiceExecution”服务的安全子层请求和指示原语根据以下通用格式指定：

SecuredServiceExecution服务的安全子层响应和确认原语根据以下通用格式指定：

安全子层服务原语中所示的寻址信息被直接映射到应用层的寻址信息上，反之亦然。

访问安全服务执行的安全子层的概念类似于本文档中描述的应用层接口。安全子层利用应用层服务原语。

以下描述了在安全模式下执行确认的诊断服务：

--客户端应用程序使用安全子层SecuredServiceExecution服务请求以安全模式执行诊断服务。安全子层执行所需的动作以建立与服务器的链接，添加特定的安全相关参数，如果需要，加密将在安全模式下执行的诊断服务的服务数据，并使用应用层SecuredDataTransmission服务请求将安全数据传输到服务器。

--服务器接收由服务器的安全子层处理的应用层SecuredDataTransmission服务指示。服务器的安全子层检查安全特定参数，对加密数据进行解密。应用程序执行服务并使用安全子层SecuredServiceExecution服务响应以安全模式响应服务。服务器的安全子层添加特定的安全相关参数，如果需要，对响应消息数据进行加密，并使用应用层SecuredDataTransmission服务响应将响应数据传输到客户端。

--客户端接收由客户端的安全子层处理的应用层SecuredDataTransmission服务确认原语。客户端的安全子层检查特定于安全的参数，解密加密的响应数据，并通过安全子层SecuredServiceExecution确认将数据呈现给应用程序。

图70以图形方式显示了安全子层、应用程序层和应用程序在安全模式下执行确认的诊断服务时的交互。

7.7.2 请求消息定义

安全子层生成应用层SecuredDataTransmission请求消息参数。

请求消息的标准格式和易理解的格式分别如图71和图72所示：

SecurityDataTransmission服务的请求消息一共有两部分（n个字节），第一部分是SID（1个字节），在这里就是0x84；第二部分是securityDataRequestRecord参数（n个字节），此参数包含由安全子层处理的数据，由于没有使用过这个服务，所以我猜测这个参数就是要使用安全服务来传递的数据。

7.7.3 肯定响应消息

SecurityDataTransmission服务的肯定响应消息的标准格式如图73所示，易理解的格式如图74所示：

肯定响应消息同样分为两个部分，第一部分是SID+0x40（1个字节），在这里就是0xC4；第二部分是securityDataResponseRecord参数（n个字节），和请求消息中的securityDataRequestRecord参数意义相同。

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

否定响应报文的格式如图75所示：

本服务应执行以下NRC。图76记录了每个响应代码发生的情况。响应代码总是不加密发送的，即使根据请求A_PDU中的配置配置文件，响应A_PDU必须被加密。如果错误场景适用于服务器，则应使用所列出的否定响应。

注意：以上所列的响应代码适用于安全数据传输（0x84）服务。如果在安全模式下执行的诊断服务需要否定响应，则该否定响应通过安全数据传输肯定响应消息以安全模式发送到客户端。

那么SecurityDataTransmission服务的介绍就到此为止了，对于0x84服务的理解我也只能借助14229-1来理解，因为我没使用过这个服务，下一个服务是ControlDTCSetting（0x85）服务，这个服务还是挺重要的，实际应用较多，加油！

7.8 ControlDTCSetting（0x85）service

7.8.1 服务描述

客户端应使用ControlDTCSetting服务停止或恢复服务器中DTC状态位的更新。DTC状态位报告在对ReadDTCInformation的某些子功能的肯定响应的DTC参数的statusOfDTC中。

ControlDTCSetting请求消息可用于停止单个服务器或一组服务器中DTC状态位的更新。如果被寻址的服务器无法停止DTC状态位的更新，则应使用ControlDTCSetting否定响应消息进行响应，指出拒绝的原因。

当服务器接受子功能值为DTCSettingType=off的ControlDTCSetting请求时，服务器应暂停对DTC状态位的任何更新（即，冻结当前值），直到再次启用该功能。一旦在子功能设置为“on”的情况下执行了ControlDTCSetting请求，或者发生了到不支持ControlDTCSetting的会话的转换（例如，会话层超时到defaultSession、ECU重置等），DTC状态位信息的更新应继续。如果在请求的活动会话中支持服务，则服务器仍应发送肯定响应子功能设置为“开”或“关”，即使请求的DTC设置状态已激活。

如果客户端发送了ClearDiagnosticInformation（0x14）服务，则ControlDTCSetting不应禁止重置服务器的DTC状态位。

DTC状态位记录了与表示特定故障状态的数字标识符（DTC）相关的某些信息。ControlDTCSetting仅打开/关闭DTC状态位更新。ControlDTCSetting服务不会导致关闭故障监控，也不会导致禁用故障软件策略。不建议故障软或故障安全策略与DTC状态位直接链接或耦合（例如，接受的ClearDiagnosticInformation请求不会直接删除任何激活的故障软件）。

7.8.2 请求报文定义

ControlDTCSetting服务的请求报文的标准格式和易于理解的格式分别如图76和图77所示：

请求报文分为三个部分，第一部分是SID（1个字节），在这里就是0x85；第二部分是子功能参数DTCSettingType（1个字节），关于子功能参数的定义如图78所示，最常用的就是0x01和0x02，0x01子功能就是打开DTC状态位的更新，相对的，0x02子功能就是关闭DTC状态位的更新；第三部分是DTCSettingControlOptionRecord参数，当控制DTC状态位的更新时，用户可以选择此参数记录来向服务器传输数据（例如，它可以包含要打开或关闭的DTC列表）。

7.8.3 肯定响应报文

肯定响应报文的标准格式和易于理解的格式分别如图79和图80所示：

ControlDTCSetting服务的肯定响应报文分两个部分，第一部分是SID+0x40（1个字节），在这里就是0xC5；第二部分是子功能参数DTCSettingType（1个字节），和请求报文中的子功能参数相同。

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

先看否定响应报文的格式，如图81所示：

ControlDTCSetting服务支持的NRC如图82所示：

7.8.5 消息流示例

示例1--DTCSettingType = off：

消息流标准格式和易于理解的格式分别如图83和图84所示：

那么在这里，14229-1给出的是开关DTC状态位更新的两个示例，如上的示例1就是关闭DTC状态位更新的消息流，那么打开也是相同，只是把子功能参数从0x02改成0x01即可，这里就不再给出打开DTC状态位更新的消息流了，但是我这里要稍微修改一下，将第三部分的参数体现出来。

示例2-DTCSettingType = off且DTCGGroup=0xFFFFFF：

这里的DTCGroup就是一组DTC的概念，比如说车身域的DTC啦、底盘域的DTC啦等等，那么这里的0xFFFFFF指的就是全部的DTCGroup，也就是说对全部的DTCGroup都生效，当然，这里的DTCGroup也可以改成某一个DTC来实现针对某个DTC的状态位更新的控制，消息流如图85所示：

这里要注意的一个点是肯定响应报文并没有第三部分，只有两个部分，一定要注意。

那么到这里ControlDTCSetting服务的内容就介绍完了，此服务的功能很明了，看名字就能知道是控制DTC或者DTCGroup的状态位更新的一个服务，下一个服务介绍ResponseOnEvent（0x86）服务，加油！

ISO14229-1专栏（5）--诊断与通信管理功能单元服务介绍相关推荐

汽车UDS诊断详解及Vector相关工具链使用说明——2.1.1 诊断和通讯管理功能单元概述
从本章开始,会为大家详细讲解UDS中常用的诊断服务. 标准中把UDS所有诊断服务分为了以下几个部分: 诊断和通信管理功能单元数据传输功能单元传输储存的数据功能单元输入输出控制功能单元远程激活例 ...
【电气专业知识问答】问：网络计算机监控系统（NCS）的自诊断与冗余管理功能有哪些？
[电气专业知识问答] 问:网络计算机监控系统(NCS)的自诊断与冗余管理功能有哪些? 答:系统能在线诊断监控系统中各设备的故障和软件运行情况,在线诊断出设备故障时自动进行冗余切换并告警,具体如下. ( ...
MES管理系统生产调度管理功能的作用介绍
虽然很多企业在ERP管理系统中制定了生产计划,但ERP管理系统的计划是高层次计划,无法对具体生产工单在各个工序间的生产进行调度. MES管理系统生产调度模块,可用自动和手动排产对生产工单调度,安排每个 ...
【UDS统一诊断服务】四、诊断典型服务（5）— 功能/元件测试功能单元（例行程序功能单元0x31）
文章目录四.诊断典型服务(5)- 功能/元件测试功能单元(例行程序功能单元) "功能/元件测试功能单元(例行程序功能单元)"包括的服务: (1)RoutineControl (0 ...
ISO14229-1专栏--（2）应用层服务介绍
目录 4.1 服务的原语 4.2 应用层服务的格式描述 4.3 服务原语的格式描述 4.3.1 一般定义 4.3.2 服务请求和服务指示原语 4.3.3 服务响应和服务确认原语 4.3.4服务请求确认 ...
工业级交换机的功率和管理功能详解
工业级PoE供电交换机的设备在为一些基于IP的终端传输数据信号的同时,还能为此类设备提供灵活,可靠的电力,最大限度地降低成本.那么,你对工业级交换机的功率和管理功能是否有所了解呢?接下来我们就跟随飞畅 ...
win2003服务器管理功能介绍
Windows Server2003作为一种服务器操作系统应该说是非常成功的,那么它在用户管理方面有哪些功能,下面小编就用iis7远程桌面管理控制我的远端服务器将它常用的用户管理功能给大家介绍一下. ...
ITRON同步和通信管理
ITRON同步和通信管理在多任务的实时系统中,一项工作的完成往往要通过多个任务或多个任务与多个中断处理过程(ISRs)共同完成.它们之间必须协调动作互相配合,甚至需要交换信息进行通信.这些通信和同步 ...
ComM(通信管理)和CanNm(network)
1 网络管理组成部分网络管理部分由通信管理器(简称ComM),通用网络管理器接口(简称NmIf),总线相关的网络管理器(简称NM,包括CanNM,LinNM,FrNM),总线相关的状态管理 ...

ISO14229-1专栏（5）--诊断与通信管理功能单元服务介绍