一文搞懂UDS的各种NRC

01NRC介绍

当服务端收到诊断请求时，如果能执行则回复肯定响应，不能执行则回复否定响应；也有不给出响应的情况，就是抑制正响应（Suppress PositiveResponseMessageIndicationBit，简写为SPRMIB），通常来说，如果这个bit被置1，则ECU不会给出正响应（positive response）。

常用的NRC如下：

这里要说一下NRC 0x22，有些客户要求很细，会将温度过高、温度过低、电压过高、电压过低、发动机转速过高等都要报对应的NRC，不在这些情况内的条件不满足就回复NRC 0x22，这样的话NRC 0x22和上面的NRC优先级就是一致的，就看哪个先满足就先回复哪个NRC。

也有些客户需求把温度过高、温度过低、电压过高、电压过低、发动机转速过高等所有的条件不满足都归类为NRC 0x22。

02NRC回复的优先级

不知道你们会不会经常把NRC回复的顺序搞混，总是不知道当有多个NRC可响应的时候，先回复哪个NRC。下面就来分享一下我的经验，当然这里的NRC优先级是参照ISO14229的，大部分车厂是也是参考这个来的，可能有个别NRC是客户定制，这种例外的按照客户需求来就行了。

NRC的优先级从高到低排列：

NRC 0x11 > 0x7F > 0x13 > 0x12 > 0x7E > 0x33 > 0x24 > 0x31 > 0x22 > 0x78

1）NRC 0x11和0x7F的区别：都是服务不支持，但0x11是整个服务不支持，而0x7F是在某个会话不支持，在其他服务下是支持的。举个例子：28服务，只支持在扩展会话下，但在默认会话下执行0x28服务，那此时回复的NRC就是0x7F。

2）NRC 0x11和0x12的区别：0x11是服务不支持，0x12是子功能不支持。这个还是比较好理解的。举个例子：19服务有很多子功能，假设客户不支持0A子功能，那执行19 0A就会回复0x12；假设客户需求不支持23服务，那执行23服务就回复0x11，而且不管你后面传的子功能参数对不对，长度对不对，都是回复0x11，因为0x11优先级最高(看标准0x21总线繁忙的NRC优先级是最高的，但没怎么用过)。

3）NRC 0x12和0x7E的区别：0x12是整个子功能不支持，而0x7E是在当前会话不支持。举个例子：19服务有很多子功能，假设客户需求不支持0A子功能，那执行19 0A就会回复0x12；假设10 02服务只在扩展会话下支持，但在默认会话下执行了，就会回复0x7E。

4）NRC 0x7F和0x7E的区别：0x7F是当前会话下服务不支持，0x7E是当前会话下子功能不支持。这两个没啥好说的，看具体情况，如果这两个都支持，则回复NRC 0x7F，因为0x7F优先级更高。

2.1 通用服务的NRC回复流程

这是ISO14229-1中的规范，这个NRC的回复优先级适用所有没有子功能的服务。从这个可看出回复NRC的顺序为：0x11 > 0x7F > 0x33。

mandatory：强制性的，也就是说这一列的NRC必须是按这个顺序来回复。

optional：可选择的，就是不一定有，可以选择性地由每个请求消息进行评估。例如出现总线繁忙时，就先回复NRC 0x21。

manufacture/supplier specific：车厂或主机厂规范，这是客户要求的，有些客户有特殊的需求，具体的按照客户要求来做就行。

2.2 带sub-function功能参数的服务

带sub-function参数的服务回复NRC的顺序，例如：$10、$11、$27、$28、$31、$85、$14、$19等

2.3 0x22服务回复NRC的顺序

0x22服务回复NRC的顺序如下图：

1）如果请求的DID不是客户支持的，要回复NRC 0x31，就不是0x12了。因为$22服务没有子功能。

2）如果请求的DID在当前会话不支持，也是回复NRC31，不是0x7E了。

总结：22服务里面没有NRC 0x12、0x7E，其他没有子功能的服务也是如此

2.4 0x2E服务回复NRC的顺序

0x2E服务回复NRC的顺序如下图：

基本上和0x22服务一样，最后多一个NRC 0x72，判断最后把数据有没有写到内存中去，写内存失败了就报NRC 0x72。

2.5 0x14服务回复NRC的顺序

$14服务回复NRC的顺序如下图：

2.6 0x31服务回复NRC的顺序

0x31服务的NRC回复顺序如下图：

03物理寻址和功能寻址回复NRC

3.1 物理寻址但带sub-function服务

分成抑制正响应(SPRMIB = 1)，没有抑制正响应(SPRMIB = 0)两种情况。

1）NRC 0x31不管SPRMIB有没有置位，在参数不对或不支持的情况下都回复NRC 0x31；

2）在SID不支持时，SPRMIB没有置位，则回复NRC 0x11或0x7F，看具体情况；但SPRMIB置位了，则一定回复NRC 0x11；

3）在sub-function不支持时，SPRMIB没有置位，则回复NRC 0x12或0x7E，看具体情况；但SPRMIB置位了，则一定回复NRC 0x12。

3.2 功能寻址但带sub-function服务

功能寻址和物理寻址又有点不一样了。

请求的服务是功能寻址时，NRC为：服务不支持(0x11)，当前会话服务不支持(0x7F)，子功能不支持(0x12)，当前会话子功能不支持(0x7E)，请求超出范围(0x31)，不管SPRMIB是否置位，都不会回复NRC。但前提是没有回复NRC 0x78的情况下。括号里面那句话很重要

也就是说，如果请求的是功能寻址，且NRC是上面5个中的任意一个，假设是NRC 0x7F，但是服务端先回复了一个NRC 0x78，那么服务端最后就必须回复NRC 0x7F了。

这里再讲一个NRC 0x78的，原文如下：

当NRC 0x78被使用了，服务端最终都要给一个响应(正响应或否定响应)，和SPRMIB的值是否置位无关，和是否是功能寻址，且NRC为0x11，0x7F，0x12，0x7E，0x31无关。

简单来说就是：

1）当服务端回复了NRC 0x78，即使SPRMIB是置位的也要回复正响应；

2）当服务端回复了NRC 0x78，即使发送的请求是功能寻址，且NRC为0x11，0x7F，0x12，0x7E，0x31，也要回复对应的NRC

举个例子：请求了10 02服务，10 82，且服务端回复了NRC 78，那是要给正响应的。

TX 02 10 82 00 00 00 00 00

RX 03 7F 10 78 AA AA AA AA

RX 06 50 01 00 32 01 F4 AA

3.3 物理寻址但没有sub-function服务

不知道你们一开始看到这个表格一开始是否有个疑问，这里为啥没有SPRMIB是否置位的区分？因为这些是适用没有子功能的服务啊，没有子功能哪来的SPRMIB。

物理寻址没有子功能的服务请求，该回复正响应的就回复正响应，回复NRC就NRC，没有啥特殊情况。

3.4 功能寻址但没有sub-function服务

功能寻址没有子功能的服务请求时，服务不支持，参数不对，都不回复NRC，即无响应。

审核编辑：汤梓红