Negative response codes
The negative response codes (NRC) are divided into 3 ranges:

0x00: positiveResponse parameter value for server internal implementation,
0x01 – 0x7F: communication related negative response codes,
0x80 – 0xFF: negative response codes for specific conditions that are not correct at the point in time the request is received by the server. These response codes may be utilized whenever response code 0x22 (conditionsNotCorrect) is listed as valid in order to report more specifically why the requested action can not be taken.

通用服务响应流程：

带子功能服务响应流程：

&&&&&&&&&&&&&&&&&下面是单帧和多帧&&&&&&&&&&&&&&&&&&&&&

UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构

CAN Message = CAN ID + CAN DATA

CAN ID 分为标准与扩展

在UDS的协议里面 ID 的类型并没有对其进行具体的定义，可以根据自己的需求进行自己定义，在Autosar里面是个两个配置变量，一个配置ID值，一个配置ID类型，大家自己配置一下就可以 ，对于UDS数据流来说，需要重点分析一下CAN DATA. CAN DATA的最终形成是在 网络层实现的，遵循ISO15765-2的规则，在这个层里面吸收应用层的UDS诊断数据，同时增加了这个CAN 信息的控制信息，最终形成一个帧的CAN消息，放入物理层的数据收发器里面。

每一个PDU 包含控制信息PCI,数据信息Data. 具体如下图所示：

综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。其中，SF_DL 代表单帧中数据的个数，FF_DL代表 连续帧中的数据总数，SN代表此帧为连续帧中的第几帧， FS参数控制发送端是否能继续传输数据，BS规定发送端允许持续传输连续帧数目的最大值，STmin限定连续帧相互之间所允许的最小值。

先面用连个例子进行说明，请参考！

例子 1— 单帧的数据传输与接收

数据发送：27 09

数据反馈：7F 27 7E — 负反馈

数据发送： 10 40

数据反馈： 50 40 00 32 01 F4

下图为在Canlyzer里面的数据截图，请参考

由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个数据位，02，03，02，06代表的为此帧数据含有几个数据位，多余的数据位都用 00或者AA行填充。

例子2 — 多帧的数据接收与传输

数据发送：19 04 00 01 00 00

数据反馈：59 04 00 01 00 27 00 0B FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

下图为在Canlyzer里面的数据截图，请参考

数据发送为单帧，所以06代表发送的数据中含有6个字节，回复为正反馈，为连续帧，10 代表连续帧的首帧，1E代表此连续帧含有30个字节，30代表此连续帧的流控制帧，21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。