01

$22讀服務

$22讀服務通常在默認會話下即可執行，特殊情況下，某些信息做了讀取保密設計，需要在擴展會話和安全控制下才能讀取該DID（Data ID）信息。

DID長度通常為16進制2個字節，范圍從0x00 00至0xFF FF，每個DID代表一條對應的消息，這樣我們需要知道該信息的內容時，只需要使用$22+DID既可以獲取該信息內容。如：我們用DID 0xF1 90標識車輛VIN，需要知道車輛VIN具體號碼信息時，向ECU發送$22 F1 90進行信息查詢，即可得到內容反饋。

之前我們一直在強調UDS診斷的自定義空間比較大，在極個別項目中，我們遇到過DID長度為3個字節的情況，我們需要以實際項目研發測試過程設計為準。

1.1 DID的分類

通過上面的描述我們可以理解，車輛上很多信息可以通過DID進行設計定義，通常主機廠根據信息屬性不同將DID進行設計分類：

1）物流數據

物流數據中一般包含的是跟車輛和設備生產相關的固定信息。在生產過程中，零部件供應商不會一個批次完成所有零部件的生產和交付，這個過程一般是以月份或者季度為單位分批次執行，伴隨著這個過程的通常還有主機產要求的VAVE等活動，因此同一個零部件也會因生產批次不同，對應的軟硬件和配置信息有所不同。物流數據通常有：零部件硬件批次號、軟件批次號、本設備的串號、部件號、出廠時間、制造時間、供應商硬件號、供應商軟件號、ECU部件數量、ECU應用軟件數量、ECU配置文件數量、車型信息、車輛VIN碼等等。

2）內部屬性數據

內部屬性數據一般包含了ECU本身的軟硬件配置相關信息，如：軟件版本號、設備溫度、ICCID號、IMEI號、GNSS天線狀態、GNSS定位信息、NAD基本信息、NAD天線信息等等。

3）配置屬性數據

配置屬性數據顧名思義包含了ECU中需要進行配置的相關數據，這些數據一般情況下都可以做成模板進行復用，根據要求不一樣進行模板選擇，如：當前車輛的車型（同一型號的車具體有高中低等不同配置，具體到當前車輛可能發動機等配置都是有區別的）、移動通信運營商國家代碼、運營商網絡編碼、APN撥號配置等。

4）Bitmapped I/O parameter DID和Non-Bitmapped I/O parameter DID

ECU通常會收到網絡上其他設備發送的周期信號，這些信號通?？梢栽谙鄳木W絡上實時獲取，也可以通過診斷讀取，這類信號一般包含在Bitmapped和Non-Bitmapped屬性數據中，區別是一個通常包含的是開關與否、報警與否的狀態信號，另一個通常包含的對應的數值，如：機油過低報警狀態、機油量、油量過低報警狀態、當前油量等等。

1.2 $22服務請求報文

$22服務的請求報文格式總體與第三篇文檔的描述一致。但是$22服務沒有子功能，在服務ID后直接跟DID。發送報文幀結構如下圖：

圖 1

舉例$22服務請求VIN碼對應的DID，報文為：03 22 F1 90，當然根據項目實際情況車輛VIN可能是其他DID。

$22服務支持多個DID一次讀取，報文格式如下圖：

圖 2

舉例$22服務一次請求多個DID，$22 F1 80 F1 81。

1.3 $22服務響應報文

$22服務的響應報文格式總體與第三篇文檔的描述一致。正響應報文的服務號為$62，第二、三字節對應請求報文的DID。從第四字節至最后為對應DID的實際數據。響應報文幀的結構圖如下所示：

圖 3

舉例$22服務的響應報文通常為：

ECU：  10 14 62 F1 90 01 02 03

Tester：30 00（流控制幀）

ECU：  21 04 05 06 07 08 09 0A

ECU：  22 0B 0C 0D 0E 0F 10 11

$22服務一次讀取多個DID的響應報文格式如下圖：

圖 4

$22服務一次讀取多個DID的響應報文，如：

ECU：  10 0C 62 F1 80 01 02 03

Tester：30 00（流控制幀）

ECU：  21 04 F1 81 0A 0B 0C AA

$22服務的否定響應格式，可以參考第三篇文章服務響應總體中負響應部分介紹，所有UDS服務的負響應故障代碼表在項目中均是通用的。

02

$2E寫服務