作者 | 李偉 上海控安安全測評中心安全測評部總監

來源 |鑒源實驗室

引言：第四篇中我們介紹了UDS服務中的會話和安全控制，主要講了不同模式會話間的切換邏輯，問答報文結構，安全控制的作用和等級、安全控制的解鎖過程，以及這兩個服務的測試注意要點等等。本篇講述UDS中的讀和寫服務，讀寫服務幾乎是工程師日常使用最為頻繁的服務，特別是讀服務。

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.1DID的分類

通過上面的描述我們可以理解，車輛上很多信息可以通過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通常會收到網絡上其他設備發送的周期信號，這些信號通常可以在相應的網絡上實時獲取，也可以通過診斷讀取，這類信號一般包含在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寫服務

$2E寫服務跟$22是對應的關系，完成了DID對應的數據寫入后，我們才能通過$22服務讀取出相應DID寫入的內容。所以$2E服務的請求應答過程跟$22的請求應答格式上看是相互翻轉的。

$2E服務成功寫入的前提條件，通常要求服務在擴展會話和安全等級1的模式下執行。另外要注意的，并不是所有支持$22服務的DID都能夠在$2E服務下寫入，通常物流數據DID、配置信息DID等可以反復寫入，Bitmapped和Non-Bitmapped屬性數據一般不支持$2E手動寫入，具體情況還需要查看項目的相關設計文檔。

2.1 $2E服務請求報文

$2E服務請求報文寫入DID對應的數據格式總體上跟上篇中UDS請求報文介紹一致，發送報文幀結構如下圖：

圖 6

舉例$2E的正響應報文通常格式為：03 6E F1 90

負響應的報文格式可以參考第三篇的相關章節，負響應NRC代碼表一般在項目中是通用的。

03 總結

$22服務和$2E服務測試過程中通常是配合一起執行的。但是支持$22服務的DID，不一定支持$2E服務。DID對應的信息含義和格式一定要查閱和依據診斷規范。

04 測試要點

$22和$2E服務跟其他服務測試相同的地方是，大家都要依照針對規范執行相關測試；不同點在于$22和$2E涉及到的物流數據DID，對于這些信息零部件每個生產批次的數值可能都不一樣，最新的數值表一般在排產前，由DRE在系統中申請生成，并向供應商釋放，因此測試的時間和對應釋放的軟件版本號需要特別注意。

審核編輯：湯梓紅