UDS诊断系列之三 ISO14229协议介绍（下）

上篇主要分享了一些基本概念和响应规则，里面提到了否定响应码，也提到了ISO14229-1的附录A是一张否定响应码的表格，里面详细介绍了否定响应码的具体含义。那么在什么时候给出什么样的否定响应码，这篇里会详细说一说。

对于所有的诊断请求，处理流程会分为两部分，第一部分是通用规则，第二部分是每个服务自身特有的规则。当然有些服务是没有第二部分的，比如10会话模式控制服务。

要注意的是，上篇文章提到的带子功能和不带子功能，在否定响应的规则里，这个也会产生影响，即其所应用的规则也会有部分不同。

下面分章节对响应的处理流程进行说明。

1.所有服务通用响应规则

这幅流程图的起始位置是收到诊断请求，左中右分成三类，分别是强制的、可选的和自定义的，含义很好理解，但是强制的部分也会因为某些功能不具备而不需要检查，例如NRC34，如果不支持认证的功能，就不需要检查，所以也不需要支持响应这个NRC，开发的时候这段逻辑直接默认OK就好。可选的NRC表示可以根据实际情况支持或者不支持，而OEM或者supplier定义的部分则是OEM或supplier根据自己的需求定义一些NRC规则，这些NRC可以是自定义的也可以是附录A的清单里的。

可选的里面特别注意的有38和39这两个，如果支持安全子层，那么就需要这两个NRC。至于安全子层是什么，后续会在84服务的分享里进行说明（开始挖坑）。

其他的下面简单解释一下：

①NRC21：当接受到请求时，有其他设备在之前请求的服务还没执行完，那么需要给出这个否定响应，代表服务端在忙，无法处理，直接拒绝的当前的请求。

②NRC11：如果服务端不支持请求里面包含的服务，需要给出这个否定响应。

③NRC7F：如果在当前会话模式不支持请求里包含的服务，注意是当前的会话模式，需要给出这个否定响应。例如在默认会话模式是不支持27服务的，如果收到了27服务的请求，则回复此NRC。

④NRC33：如果请求的服务需要先通过安全访问认证（27服务）才可以执行，但是当前的状态是没有经过安全访问的，这时候服务端就需要给出这个否定响应来表明客户端需要先经过安全访问认证才可以执行。

流程走到最后，分成了两个分支，一个是带子功能的，一个是不带子功能的。带子功能的，后面还有一部分通用的规则，而不带子功能的则直接进入到对应服务里的响应规则，针对不带子功能的，会在后续每个服务里进行详细说明。这里需要注意一个特殊的说明，就是带子功能的这个分支是不包含31服务的，为什么呢，因为31服务格式的特殊性，需要检查的内容和检查顺序与普通带子功能的服务是不一样的，后续31服务分享的时候会有专门的否定响应规则说明。

2.带子功能的服务通用响应规则

带子功能的服务，在执行完所有服务的通用规则后，会执行上图所示的响应规则。

下面，按照图示的顺序，对每个NRC所对应的情况进行简单说明：

①NRC13：当检查到请求的数据长度和所请求服务所要求的长度不一致时，需要给出这个NRC，这一步的长度指的是最小长度，仅包含服务ID和子功能两个字节，即长度小于两个字节，报错。当然不要误会NRC13仅对最小长度有效，在每个服务的检查内容里，也会有标准长度的检查要求，过长也是会响应NRC13的，具体看后面服务的介绍吧，这里不单独距离说明了。

②NRC12：如果服务端不支持请求里面包含服务的子功能，需要给出这个否定响应。

③NRC34：这里的NRC34的情况同上一节，不同点在于这里是检查子功能的时候触发的，而非服务。

④NRC7E：如果在当前会话模式不支持请求里包含服务的子功能，注意是当前的会话模式，需要给出这个否定响应。例如在扩展会话模式下不支持27服务的03子功能，收到该请求时就需要响应NRC7E。

⑤NRC33：如果请求服务的子功能需要先通过安全访问认证（27服务）才可以执行，但是当前的状态是没有经过安全访问的，这时候服务端就需要给出这个否定响应来表明客户端需要先经过安全访问认证才可以执行。

⑥NRC24：有些服务的子功能有顺序要求，例如27服务需要先请求种子然后才能发送密钥，请求种子和发送密钥是通过子功能来进行区分的，这时候如果没有先发送请求种子而直接发送了密钥，就会响应NRC24。

以上就是诊断的一些通用NRC响应规则，到这里诊断的响应规则分享完毕，欢迎大家关注后续的分享。

UDS诊断系列链接汇总_ChenglimK的博客-CSDN博客