ISO14229-1道路車輛-統(tǒng)一診斷服務（UDS）-1

前言：

基于ISO14229-1，整理了一些車載控制器軟件開發(fā)中常用的診斷服務，并補充了自己的理解與心得體會。

術語：

統(tǒng)一診斷服務：Unified diagnostic services（UDS）

ISO 14229-1規(guī)定了診斷服務數(shù)據(jù)鏈路的獨立要求， 以使診斷測試儀（客戶端）可控制車載電子控制單元（ ECU、服務器）的診斷功能。

常用術語及通俗解釋：

功能尋址（Fun）:廣播式信息，總線上凡是支持該功能尋址服務的ECU節(jié)點都要響應Tester的請求。例如老師（Tester）詢問全班學生（ECUs）：“今天誰沒帶課本？”這是功能尋址請求。

物理尋址（Phy）：點對點式信息，即只有特定節(jié)點響應Tester的請求。例如老師（Tester）詢問學生（ECU_x）：“張三你帶課本了嗎？”這是物理尋址請求。

禁止肯定響應：若某服務支持該功能，則當禁止肯定響應位為1時，該服務若是肯定響應，則不回消息；反之若是否定響應，則回復否定響應。例如老師（Tester）告知全班學生（ECUs）：“開始默寫課文！”，學生不用回應老師，只需要有問題的學生回應老師。比如張三說沒帶筆，李四說沒帶紙等等。該功能一般針對那些并不關心肯定響應而只需執(zhí)行指令的場景，另外若所有ECU都回復正響應，也可能會導致總線上不必要的瞬時高負載。后文的3E服務就是禁止肯定響應的一個典型應用場景。

（常用）否定響應碼：Negative Response Codes（NRC）

否定響應代碼范圍 0x00 – 0xFF。

0x00:肯定響應（Positive Response）

0x01-0x7F:通信有關的否定響應代碼

0x80-0xFF:指示規(guī)定條件不正確的否定響應代碼。

圖表 1 否定響應碼值與定義

字節(jié)值	否定響應代碼（NRC）定義	助記符
0x00	positiveResponse 肯定響應	PR
0x10	generalReject 全部拒絕	GR
0x11	serviceNotSupported 服務不受支持	SNS
0x12	sub-functionNotSupported 子功能不受支持	SFNS
0x13	incorrectMessageLengthOrInvalidFormat 消息長度錯誤或格式無效	IMLOIF
0x14	responseTooLong 響應過長	RTL
0x22	conditionsNotCorrect 條件不正確	CNC
0x24	requestSequenceError 請求序列錯誤	RSE
0x31	requestOutOfRange 請求超過限值	ROOR
0x33	securityAccessDenied 安全訪問被拒絕	SAD
0x35	invalidKey 無效密鑰	IK
0x36	exceedNumberOfAttempts 超出最大嘗試次數(shù)	ENOA
0x37	requiredTimeDelayNotExpired 要求的延時未到時間	RTDNE
0x78	requestCorrectlyReceived-ResponsePending 請求正確接收的響應暫停	RCRRP
0x7E	sub-functionNotSupportedInActiveSession 活動會話不支持子功能	SFNSIAS
0x7F	serviceNotSupportedInActiveSession 服務在活動會話中不受支持	SNSIAS

0x10h:DiagnosticSessionControl(診斷會話控制)服務

通用描述:

診斷服務器中應始終只有一個有效診斷會話。服務器上電時應始終啟動默認診斷會話。

非默認診斷會話（programmingSession（編程會話）除外）中的診斷服務和診斷功能集是 defaultSession（默認會話）中提供的功能超集，這意味著切換到任何非默認診斷會話時還可以使用 defaultSession（默認會話）的診斷功能。

圖例

圖例1：包括10 01;11 xx;會話超時；上電；

停止基于事件響應（0x86）服務；

應終止 defaultSession（默認會話）中不支持的任何其他活動的診斷功能；

這不包括已編程入非易失性存儲器中的長期更改。

圖例2：可能需要滿足特定安全條件：比如車輛靜止或發(fā)動機停止；服務器可以僅允許一個帶特定客戶端標識符（客戶端診斷地址） 的客戶端啟動一個新的具體診斷會話（例如，服務器可以要求僅帶有客戶端標識符 0xF4 的客戶端啟動 extendedDiagnosticSession（擴展診斷會話））：即可以通過物理尋址或者功能尋址。

圖例3：每次執(zhí)行3都會初始化診斷會話，意味著：

停止（0x86h）事件；

應重新鎖定安全性。注意，鎖定安全訪問應重置依存于待解鎖的安全訪問的任何有效診斷功能（舉例：某個inputOutputControl（輸入輸出控制）需要安全訪問權限，當執(zhí)行1003后，由于安全性被重新鎖定，那么該安全性所衍生服務與狀態(tài)也要被初始化，即此時應該將IO的控制權需交還ECU）；

應維護好新會話中支持的且不依存于安全訪問的所有其他有效診斷功能。例如：維持通信控制（28h）和控制 DTC 設置（85h）的狀態(tài)。

默認會話模式可以直接切換到擴展會話模式，但是不能直接切換到編程會話模式，如果想進入編程會話模式，則必須先進入擴展會話模式。同樣，編程會話模式不能直接進入擴展會話模式，只能進入默認會話模式。 ECU 復位以及 S3 定時器超時將導致 ECU 進入默認會話模式

圖 1 診斷會話切換

默認會話（01）

只要服務器上電，就應始終進行默認診斷會話；

該會話模式不需要任何診斷應用程序的超時處理；

默認模式再一次被啟動（上電或切換），則ECU 須復位所有此前會話模式下被激活的狀態(tài)和控制服務：

安全訪問（27h）：重新鎖定ECU，恢復至默認安全等級；

基于事件的響應（86h）；

通信控制（28h）：使能收發(fā)；

控制 DTC 設置（85h）：使能DTC上報

輸入輸出控制（2Fh）：交還控制權至ECU

編程會話（02）

如果 ECU 在引導程序中運行編程會話，只能通過如下退出02會話:

診斷工具發(fā)起的“ECU 復位”（11h） 服務

會話類型為默認會話的“診斷會話控制”（10h） 服務（重啟APP）

或ECU 會話層超時退出（重啟APP）。

擴展診斷會話（03）

該 diagnosticSession（診斷會話）可用于啟用支持服務器內存中功能（如， “怠速、 CO 值等”）調整所需的所有診斷服務。該會話還可以用于啟用與功能調整無特別相關性的診斷服務。

安全系統(tǒng)診斷會話（04）

該 diagnosticSession（診斷會話）可以用于啟用支持安全系統(tǒng)相關功能所需的所有診斷服務（例如，氣囊布置）

請求與應答：

圖 2 請求消息定義

圖 3 肯定響應消息定義

圖 4 會話參數(shù)記錄定義

圖 5 會話參數(shù)釋義

注：

定時器 P2server 的精度為 1ms

定時器 P2*server 的精度為 10ms

小結

若因S3Timer超時需退至默認會話，并重置以下內容：

27服務：重新鎖定ECU恢復默認安全級別

31服務：重置歷程控制

85h服務：開啟DTC狀態(tài)更新

28h服務：使能報文收發(fā)

2Fh服務：IO控制權交還至ECU。

若已在03會話，再次受到10 03請求，則只需重置如下內容：

27服務：重新鎖定ECU恢復默認安全級別

27服務設計的安全性權限的衍生服務：

2Fh服務：IO控制權交還至ECU（因其一般需要解鎖ECU）。

其他需要安全性解鎖的服務。

0x11h: ECUReset（ ECU 重置）服務

通用描述：

本服務請求服務器根據(jù)嵌入 ECUReset（ECU 重置）請求消息中的 resetType（重置類型）參數(shù)值的內容有效地執(zhí)行服務器重置。應于在服務器中執(zhí)行重置之前發(fā)送 ECUReset（ECU 重置）肯定響應消息（如需要）。服務器成功重置后，服務器應激活 defaultSession（默認會話）。

圖 6 請求消息定義

請求消息子功能參數(shù)定義描述：

0x01 hardReset（硬件復位）：

該條件模擬了服務器斷開其電源（即電池）之后通常會執(zhí)行的上電／啟動序列。

0x02 keyOffOnReset（點火鑰匙重置）：

該重置條件應模擬鑰匙關—開序列。

0x03 softReset（軟重置）

使服務器立即重啟應用程序。

0x04 enableRapidPowerShutDown（啟用快速斷電）

可強制進入休眠模式，并非單純地關閉電源。休眠意味著關閉電源，但仍時刻準備著被喚醒（電池供電型）。子功能的目的是縮短點火開關轉至關閉位置之后 ECU的待機時間。

0x05 disableRapidPowerShutDown（禁用快速斷電）

該值要求服務器禁用此前已啟用的“快速斷電”功能。

圖 7 肯定響應消息定義

圖 8 響應消息數(shù)據(jù)參數(shù)定義

小結：

無。

0x27h: SecurityAccess（安全訪問）服務

通用描述：

本服務旨在提供一種訪問因安全、排放或安全因素而被限制訪問的數(shù)據(jù)和／或診斷服務的方式。用于下載／上傳例程或數(shù)據(jù)到服務器及從服務器讀取具體內存位置的診斷服務可能需要進行安全訪問。

任何時間都僅可有一個安全級別處于活動狀態(tài)。例如，如果與 requestSeed（請求種子） 0x03 相關的安全級別處于活動狀態(tài)，且測試儀請求成功地解鎖了與 requestSeed（請求種子） 0x01 相關的安全級別，則此時僅應解鎖與 requestSeed（請求種子） 0x01 相關的安全級別所支持的受保護功能。此前已由與 requestSeed（請求種子） 0x03 相關的的安全級別解鎖的任何其他受保護功能應不再處于活動狀態(tài)。

服務流程：

客戶端請求“種子”：

子功能參數(shù)值應始終為奇數(shù)（比如0x27 01），且同一安全級別的相應“sendKey（發(fā)送密鑰） ”子功能參數(shù)值應等于“requestSeed（請求種子） ”子功能參數(shù)值加一。

種子為隨機數(shù)，且種子不能是如下兩種數(shù)值：

00000000h:如果服務器支持安全性，但是接收 SecurityAccess（安全訪問） “requestSeed（請求種子） ”消息時所請求的安全級別已經(jīng)解鎖，則該服務器應通過種子值等于零（0）的 SecurityAccess（安全訪問）“requestSeed（請求種子） ”肯定響應消息服務做出響應。無論何時，服務器均不得就當前已鎖定的指定安全級別發(fā)送全為零的種子。客戶端應檢查非零種子，通過這種方式確定服務器是否鎖定為特定的安全級別。

服務器發(fā)送“種子”

此種子是診斷工具及 ECU 計算密鑰的輸入?yún)?shù)；

客戶端發(fā)送“密鑰”（適用于已接收到的種子）

服務器做出響應

確認“密鑰”有效，并自行解鎖

如果兩個數(shù)字不匹配，則這將被視作一次錯誤的訪問嘗試。ECU 拒絕請求并發(fā)送否定響應碼 35h“密鑰無效”（InvalidKey）， 安全訪問失敗計數(shù)加 1。當錯誤計數(shù)器數(shù)值達到 N 時， ECU 需要等待 T 秒方可接受下次“請求種子”（Request Seed） 報文并返回 36h（請求次數(shù)超出限制） 否定響應。 在這 T秒內， 任何“SecurityAccess- RequestSeed”都將不被處理， 且ECU 返回 37h（延時時間未到）否定響應。當 T秒等待時間結束，安全訪問錯誤計數(shù)減 1 并允許另一次嘗試。如果在這次嘗試期間安全訪問失敗計數(shù)再次增加（由于密鑰無效）， 要求 ECU 在接受下次“請求種子”（Request Seed） 報文前再次等待 T 秒。

任何一次 ECU 被成功解鎖（密鑰有效），失敗計數(shù)器都將被重置為零，ECU 上電或復位后默認處于閉鎖狀態(tài)， 失敗計數(shù)器不能被重置

種子及密鑰的請求和響應流程是強制性的，但以下情況發(fā)生時，該流程將被重置：

ECU 發(fā)送了“SecurityAccess- SendKey”的肯定或否定響應

ECU 發(fā)送了“SecurityAccess-RequestSeed”的否定響應

由于回到默認會話模式或被重啟， ECU 回到閉鎖狀態(tài)

圖 9 安全訪問流程

圖 10 安全訪問策略

圖 11 安全訪問狀態(tài)轉換圖

請求與響應示例：

圖 12 請求消息定義-請求種子

圖 13請求消息定義-發(fā)送密鑰

圖 14肯定響應消息定義

小結：

無。

0x28h CommunicationControl（通信控制）服務

通用描述：

本服務旨在開啟／關閉服務器一些消息的傳輸和／或接收（例如，應用程序通信消息）。

圖 15請求消息定義

圖 16請求消息子功能參數(shù)定義（截取部分）

圖 17請求消息數(shù)據(jù)參數(shù)定義

圖 18肯定響應消息定義

小結：

無。

0x3Eh: TesterPresent（測試儀?；?#xff09;服務

通用描述：

本服務用于在服務器內顯示，客戶端仍與車輛連接，且此前已激活的診斷服務和／或通信仍將保持活動狀態(tài)。該服務用于將一個或多個服務器保持在非 defaultSession（默認會話）的診斷會話狀態(tài)。通過周期性地傳輸 TesterPresent（測試儀?；?#xff09;請求消息或者在無其他診斷服務時啟用該服務，可防止服務器（因S3計數(shù)器超時）自動返回 defaultSession（默認會話）。

圖 19請求消息定義

圖 20請求消息子功能參數(shù)定義

圖 21肯定響應消息定義

小結：

本服務僅用于維持會話與控制狀態(tài)，無其他特殊執(zhí)行規(guī)定，且一般推薦測試儀使用功能尋址方式發(fā)送3Eh 80h (SPRMIB = TRUE)，即Tester告知ECU診斷設備保持在線，無需ECU回復肯定響應。

0x85h: ControlDTCSetting（控制 DTC 設置）服務

通用描述：

本服務客戶端應使用 ControlDTCSetting（控制 DTC 設置）服務來停止或繼續(xù)服務器中 DTC 狀態(tài)位的更新。

服務器接受子功能值為 DTCSettingType = off 的 ControlDTCSetting（控制 DTC 設置）請求時，服務器應暫停任何至 DTC 狀態(tài)位的更新（即，凍結當前值），直到再次啟用該功能。子功能設置為“開”時執(zhí)行 ControlDTCSetting（控制 DTC 設置）請求后，或者轉換到不支持 ControlDTCSetting（控制DTC 設置）的會話后（即，會話層超時轉至 defaultSession（默認會話）、 ECU 重置等）應繼續(xù)更新DTC 狀態(tài)位信息。

如 果 客 戶 端 發(fā) 送 ClearDiagnosticInformation （ 清 除 診 斷 信 息 ） （ 0x14 ） 服 務 ， 則ControlDTCSetting（控制 DTC 設置）不得禁止重置服務器的 DTC 狀態(tài)位。

ControlDTCSetting（控制 DTC 設置）僅打開／關閉 DTC 狀態(tài)位更新。 ControlDTCSetting（控制 DTC設置）服務的目的并非是關閉故障監(jiān)控，也并非是禁用故障弱化策略。

圖 22請求消息定義

圖 23請求消息子功能參數(shù)定義

圖 24請求消息數(shù)據(jù)參數(shù)定義

圖 25肯定響應消息定義

小結：

本服務客戶端用來使能或禁止DTC狀態(tài)位更新，比如bootloader更新前會發(fā)送85 02禁止DTC狀態(tài)位更新。

0x22h: ReadDataByIdentifier（按標識符讀取數(shù)據(jù)）服務

通用描述：

ReadDataByIdentifier（按標識符讀取數(shù)據(jù)）服務允許客戶端請求讀取服務器中通過一個或多個dataIdentifiers（數(shù)據(jù)標識符）所識別的數(shù)據(jù)記錄值。

圖 26請求消息定義

圖 27請求消息數(shù)據(jù)參數(shù)的定義

圖 28肯定響應消息定義

圖 29響應消息數(shù)據(jù)參數(shù)定義

小結：

一般項目每次只讀取一個DID。

0x2Eh: WriteDataByIdentifier（按標識符寫數(shù)據(jù)）服務

通用描述：

WriteDataByIdentifier（按標識符寫數(shù)據(jù)）服務允許客戶端向服務器中給定數(shù)據(jù)標識符指定的內部位。如：將配置信息編入服務器中（如 VIN），清除非易失性存儲器， 重置所得的值，設置選項內容等。

圖 30請求消息的定義

圖 31請求消息數(shù)據(jù)參數(shù)的定義

圖 32肯定響應消息的定義

小結

無。

0x14h: ClearDiagnosticInformation（清除診斷信息）服務

通用描述：

此服務用于清除一個或多個 ECU 存儲器中的診斷信息。

圖 33請求消息的定義

圖 34肯定響應消息的定義

小結：

清除所有DTC相關信息。

0x19h: ReadDTCInformation（讀取DTC信息）服務

通用描述：

此服務允許診斷工具讀取車輛內任意一個或一組 ECU 中存儲的診斷故障代碼（DTC）及其相關信息。ECU 應可返回包含排放相關及非排放相關在內的所有 DTC 信息。子功能較多，典型如下：

診斷工具可獲取與診斷工具定義的 DTC 狀態(tài)掩碼相匹配的 DTC 數(shù)目（19h 01h）；

圖 35請求消息的定義

圖 36肯定響應消息的定義

診斷工具可獲取與診斷工具定義的 DTC 狀態(tài)掩碼相匹配的所有 DTC 列表和狀態(tài)信息（19h 02h）；

圖 37請求消息的定義

圖 38肯定響應消息的定義

診斷工具可獲取與診斷工具定義的 DTC 碼和 DTCsnapshot 記錄號碼（FFh 代表所有記錄）相關的DTCSnapshot 記錄信息（19h 04h）；

圖 39請求消息的定義

圖 40肯定響應消息的定義

診斷工具可獲取與診斷工具定義的 DTC 碼和 DTCExtendedDatarecord 號碼（FFh 代表所有記錄）相關的 DTCExtendedData 記錄信息。 擴展數(shù)據(jù)的典型應用是存儲與 DTC 相關的動態(tài)信息，如故障發(fā)生次數(shù)及最近一個故障的發(fā)生時間（19h 06h）；

圖 41請求消息的定義

圖 42肯定響應消息的定義

診斷工具可獲取 ECU 支持的所有 DTC 列表和狀態(tài)信息（19h 0Ah）。

圖 43請求消息的定義

圖 44肯定響應消息的定義

小結

無。

0x2Fh: InputOutputControlByIdentifier（輸入輸出控制）服務

通用描述：

客戶端使用 InputOutputControlByIdentifier（按標識符的輸入輸出控制）服務代替輸入信號值，以及電子系統(tǒng)輸出（執(zhí)行機構）的內部服務器功能和/或力控制值?？傊?#xff0c;該服務用于相對簡單的（如靜態(tài)）輸入替換/輸出控制，但若必須使用較為復雜的輸入替換/輸出控制時，則使用 routineControl（例程控制）。

圖 45請求消息的定義

圖 46肯定響應消息的定義

圖 47復合數(shù)據(jù)塊定義（示例）

圖 48控制啟用掩碼記錄（示例）

圖 49請求消息的定義（控制踏板位置A和EGR工作周期示例）

圖 50肯定響應消息的定義（控制踏板位置A和EGR工作周期示例）

圖 51請求消息的定義（將所有參數(shù)控制權返回給ECU示例）

圖 52肯定響應消息的定義（將所有參數(shù)控制權返回給ECU示例）

小結：

通常需要特殊規(guī)定的條件限制（車速，發(fā)動機狀態(tài)等）；

保持激活狀態(tài)直至ECU任何原因下恢復默認會話，或ECU重啟或軟件復位。

總結

以上是生活随笔為你收集整理的ISO14229-1道路车辆-统一诊断服务（UDS）-1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。