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為填充位。