基于UDS協議的OBD診斷服務標準SAE J1979-2研究

俞林炯

(上汽大眾汽車有限公司，上海 201805)

車載診斷(OBD)功能隨著排放法規的引入，從20世紀80年代至今，已經歷了多輪迭代和更新。2007年7月執行的GB 18352.3—2005《輕型汽車污染物排放限值及測量方法(中國Ⅲ、Ⅳ階段)》引入了OBD系統及其功能要求。隨著環保要求的提升，2020年7月實施的GB 18352.6—2016《輕型汽車污染物排放限值及測量方法(中國第六階段)》對OBD功能的要求已達到了世界前列。到2020年，全國機動車保有量達3.72億輛，四項污染物排放總量為1 593萬t，而汽車是其主要貢獻者，其中汽油車的CO排放超過汽車排放總量的80%、HC超過70%，柴油車的NOx排放超過汽車排放總量的80%。2021年10月國務院印發的《2030年前碳達峰行動方案》提出了關于碳達峰碳中和的重大戰略決策，可以預見，機動車污染物排放監管在未來一段時間內會進一步加強，對OBD的要求[包括診斷服務/測試模式(以下統稱OBD診斷服務)標準]也應同步升級。

1 當前的OBD診斷服務

從GB 18352.3—2005到GB 18352.5—2013《輕型汽車污染物排放限值及測量方法(中國第五階段)》，汽車排放法規中OBD診斷服務采用的標準是ISO 15031-5：2001《道路車輛-車輛與排放有關診斷用的外部試驗裝置之間的通訊-第5部分：排放有關的診斷服務》，并通過滿足ISO 15031-4要求的診斷工具輸出信息。從GB 18352.6—2016開始，OBD診斷服務的標準換成了SAE J1979_201202《電子/電氣診斷測試模式》(下稱J1979)，通過滿足SAE J1978規定的掃描工具輸出信息，明確規定了相應信息，包括準備就緒狀態(J6.4.1)、數據流(J6.4.2)、凍結幀(J6.4.3)、故障代碼(J6.4.4)、測試結果(J6.4.5)、軟件標定識別碼(J6.4.6)、軟件標定驗證碼(J6.4.7)、車輛識別碼(J6.4.8)、ECU名稱(J6.4.9)、IUPR率跟蹤(J6.5)要求。其他與GB 18352.6—2016配套的需監測OBD功能的法規(如GB 18285—2018《汽油車污染物排放限值及測量方法(雙怠速法及簡易工況法)》和HJ 1237—2021《機動車排放定期檢驗規范》)也規定按照J1979提供標準化輸出。

從技術上講，ISO 15031-5和J1979是等效的，不同時期的應用是由排放法規中OBD部分要求的引用/參考源不同所致。J1979是為滿足美國OBD法規而開發的標準，用于1996年以后車型；ISO 15031-5是基于J1979開發的標準，它結合了美國的要求和歐洲OBD的要求，適用于2000年以后車型。GB 18352.3—2005～GB 18352.5—2013中的OBD標準參考歐洲法規，即EOBD，相應標準為ISO 15031-5；而GB 18352.6—2016的OBD采用美國標準，即OBD Ⅱ，相應標準為J1979。

J1979作為當前輕型車主流的OBD診斷服務標準，能滿足絕大部分情況的需求，但從實際應用情況來看，還是存在一些局限，因而有行業代表建議CARB(California Air Resources Board)在OBD法規中采用SAE J1979-2_202104(下稱J1979-2)，因為J1979-2標準能有效消除J1979中的局限。例如：1)隨著插電式混合動力汽車(PHEV)的不斷投產，當前基于J1979標準的2 B標準故障碼即將用盡。而J1979-2可提供3 B標準故障碼，能大大增加可用故障碼數量。2)當前基于J1979標準的每個故障碼ECU只輸出一個凍結幀，且有優先級的區別，不利于維修和監管。而J1979-2可提供更多的凍結幀信息。3)當前基于J1979標準的就緒狀態組數量有限，且無法詳細到故障碼級別。而J1979-2可拓展更多的就緒狀態組，且可實現精確到DTC的就緒狀態輸出。4)當前基于J1979標準的測試結果標準化程度不夠。而J1979-2可實現精確到DTC的測試結果輸出，方便監管和維修。5)當前基于J1979標準的在用車檢測頻率指標(IUMPR)只能按組輸出。而J1979-2可實現精確到DTC的IUMPR結果輸出。

為此，CARB批準自MY23開始HD/MD車型以逐步過渡的方式采用J1979-2標準，到MY27要求100% 的產品采用J1979-2。盡管J1979-2標準正式發布時間不長，但已受到行業的高度關注。中國同樣關注到了J1979-2的應用趨勢。

2 J1979-2介紹

J1979-2《E/E diagnostic test modes:OBD-onUDS》可以理解為基于UDS協議的OBD診斷測試模式，正式版于2021年4月發布。J1979-2并非對J1979推翻重來，也不是簡單地將J1979中的Service$01～$0A映射成UDS服務，而是基于UDS協議針對J1979支持的診斷服務(Mode$1～$A)進行升級和擴充。

UDS協議(ISO 14229)在汽車行業其實不是新技術，OBD也不是新功能，但兩者的結合目前還是較新的要求。相比于排放OBD專用診斷服務(只針對與排放相關的控制器)，UDS協議的最大特點在于U即Unified。UDS面向整車所有ECU，且支持多種總線技術。目前的主要排放控制器如ECU、TCU等實際上已支持UDS標準，但為滿足排放法規還要開發一組功能用于滿足J1979。

無論是J1979-2還是J1979，定義的都是車載OBD系統與外部通用設備之間的通信，故可將其通信架構映射到開放系統互連(OSI)模型(ISO/IEC 7498-1和ISO/IEC 10731)進行介紹，進而清晰地展示J1979-2與J1979在通信方面的差異(見圖1)。

圖1 基于OSI架構的通信方式對比

以目前汽車行業內最常見的CAN總線為例，從物理層(Layer1)到傳輸層(Layer4)都是基于ISO 15765-4標準(功能上J1979/15031-5還支持SAE J1850、ISO 9141-2、ISO 14230-1/2等數據鏈路層和物理層，但技術較老，當今汽車行業已不再開發，故未在圖1中列出)。兩標準中會話層(Layer5)都是基于ISO 14229-2標準，表示層(Layer6)除J1979-2新增了SAE J1939-DA外，其他3種通信方式都一樣。J1979-2相對于J1979的主要變化在于應用層(Layer7)，J1979-2的通信方式從J1979的ISO 15031-5/SAE J1979切換為ISO 14229-1/SAE J1979-2。此外，J1979-2還可以拓展到以太網總線技術，以適應更新更快的通信需求。綜上，OBD診斷服務標準的更新其實只是對通信架構應用層的更新，基礎通信層Layer1～Layer4保持不變，因而能大大降低技術升級的成本，可以將軟硬件開發解耦，通過軟件升級即可實現新標準。J1979與J1979-2的OBD診斷服務對比見表1。

從表1可以看出：J1979-2采用UDS協議ISO 14229-1中的4種服務實現了J1979的9種服務，其中J1979不具備的3種服務就是J1979-2的典型升級內容。

表1 J1979與J1979-2的診斷服務映射關系

3 OBD診斷服務實現方式對比

為便于閱讀，基于J1979的診斷服務順序(Service$01～Service$0A)進行診斷服務對比，最后補充J1979-2新增的3種診斷服務。研究內容基于J1979-2和對應的SAE J1979-DA，以CAN總線通信方式為基礎，Layer1～Layer4基于ISO 15765-4協議。

3.1 Service$01請求動力總成診斷數據

J1979、J1979-2中Service$01對比見表2。

表2 Service$01對比

J1979中動力總成診斷數據通過Service$01和PID(Parameter identification)獲取，PID數據長度為1 B，范圍為$00～$FF。其中$00、$20、$40等并不表征實際的物理量，而是用來表征ECU對后面連續32個PID的支持情況。這種邏輯同樣適用于下文中Service$06的MID/TID、Service$09的Infotype。

J1979-2動力總成診斷數據通過UDS協議的Service$22和DID獲取，DID數據長度為2 B，范圍為$F400～$F5FF。其中$F400、$F420、$F440等并不表征實際參數，而是用來表征ECU對后面連續32個DID的支持情況。這種邏輯同樣適用于下文中MID/TID/ITID。ISO 14229-1附錄C.1中預留了$F700～$F7FF的區間給OBD，但目前SAE J1979-DA中暫未使用。

DID其實是UDS協議中一個通用概念，與J1979的區別是，DID的區間在ISO 14229-1附錄C.1中作了詳盡分類，預留了專用區間給OBD法規使用。因此，在J1979-2中，MID/TID/ITID都屬于DID，但其值不會重復，可直觀地理解為J1979-2中High byte=F4/F5/F7的DID都用于Service$01。關于PID/DID的支持數量，兩標準對ECU的響應要求一樣，J1979要求ECU至少響應6個PID，J1979-2根據請求類型進行分類，要求物理請求的ECU至少響應6個DID、功能請求的ECU至少響應3個DID。PID/DID的定義參考SAE J1979-DA、Annex B-Parameter IDs。

3.2 Service$02請求動力總成的凍結幀數據

凍結幀信息的功能是提供出現排放故障時刻的必要數據信息，OBD標準中稱為Freeze frame，UDS協議中稱為Snapshot。凍結幀信息是J1979-2相比于J1979升級比較明顯的服務，其主要變化見表3。

表3 J1979-2關于凍結幀功能的升級

凍結幀的信息需要結合排放法規來設置，以GB 18352.6—2016為例，失火和燃油系統具有更高的凍結幀優先級，若下一階段從J1979切換成J1979-2，則企業無需再給失火和燃油系統的故障設置優先級。同樣，原法規中針對失火和燃油系統專門設置的相似工況等要求也要酌情考慮調整。兩標準中Service$02對比見表4。

表4 Service$02對比

J1979中凍結幀通過Service$02讀取。J1979-2中凍結幀通過UDS的Service$19～SF$04讀取，DTC snapshot record number為凍結幀序號，長度為1 B，UDS協議對其進行劃分，其中$00、$F0用于OBD，與J1979-2對應：$00為首次出現的凍結幀，$F0為最近一次出現的凍結幀。

3.3 Service$03/$07請求排放相關的DTC

基于UDS協議的J1979-2在讀取排放故障碼服務方面相比J1979有進一步提升，但實現方式接近。考慮到Service$07和Service$03在功能上完全一致，合并在一起介紹。

J1979-2要求乘用車/輕型車使用SAE J2012-DA_DTC format_04格式的故障碼，DTC format identifier=0x04，該格式的故障碼為3 B DTC，具體信息參考SAE J2012-DA/ISO 15031-6。J1979要求的故障碼為2 B格式的故障碼。這是J1979-2中一個典型的故障碼格式升級。

除故障碼格式差異外，J1979-2可利用UDS協議的優勢，根據故障碼的狀態和屬性即DTC severity mask record對故障碼進行精確篩選。J1979中未決故障碼(Pending DTC)通過Service$07讀取，確認故障碼(Confirmed DTC)通過Service$03讀取。J1979-2中未決故障碼和確認故障碼都是通過UDS的Service$19～SF$42讀取，除保留原先的故障碼讀取功能外，還通過DTC status mask和DTC severity mask增加了篩選的功能。兩標準中Service$03/$07對比見表5。

表5 Service$03/$07對比

FGID：功能組ID，按照UDS協議的定義，排放組為33。

DTC status mask：ISO 14229-1中詳細定義了每一位的意思，其中bit2表示未決故障碼，bit3表示確認故障碼，DTC status mask =0x04表示可以請求未決故障碼，DTC status mask =0x08表示可以請求確認故障碼。

DTC severity mask：ISO 14229-1中詳細定義了每一位的意思，高3位用來定義DTC severity information，低5位用來定義DTC class information，其中bit1表示故障等級是DTC class_1，這個是必須支持的故障等級，故Byte#5可以直接定義成0x02。

除完成常規的Pending DTC和Confirmed DTC獲取外，測試員還可通過DTC status mask和DTC severity mask篩選其他屬性的故障碼。

3.4 Service$04清除排放相關診斷信息

故障清除功能在J1979-2中沒有明顯變化(見表6)。

表6 Service$04對比

J1979中清除排放相關故障碼通過Service$04實現。J1979-2中清除排放相關故障碼通過Service$14實現。盡管UDS協議中Service$14支持多種清除功能(包括清除特定的DTC)，但J1979-2只要求其中兩種，分別為刪除排放組(0x33)的故障碼和刪除所有(0xFF)的故障碼。

3.5 Service$06請求監測系統診斷結果

J1979和J1979-2通過MID讀取診斷結果的功能沒有明顯差異，都使用OBDMID(On-board diagnostic monitor ID)和相應的TID(Manufacturer defined test IDs)，兩者的對比見表7。J1979-2新增的測試結果讀取功能見3.9節。

表7 Service$06對比

J1979中通過Service$06讀取診斷結果，MID數據長度為1 B，范圍為$00～$FF。J1979-2中通過UDS的Service$22讀取診斷結果，定義的MID(DID)數據長度為2 B，范圍為$F600～$F6FF，可以直觀地理解為High byte=F6的DID都用于Service$06。MID和TID的定義參考SAE J1979-DA、Annex D-Monitor IDs和Annex C-Test IDs。

3.6 Service$08請求控制OBD系統

對于OBD系統的控制請求，J1979和J1979-2定義較少，更多的功能都是原始設備制造商(OEM)開發和定義的，通過UDS協議的Service$31實現。兩者的對比見表8。

表8 Service$08對比

J1979中控制OBD系統通過Service$08實現，定義的TID數據長度為1 B，范圍為$00～$FF。J1979-2中控制OBD系統通過UDS協議的Service$31～SF$01實現，定義的RID數據長度為2 B，范圍為$E001～$E1FF。RID的定義參考SAE J1979-DA、Annex F-Test-Routine IDs。

3.7 Service$09請求車輛信息

J1979、J1979-2中車輛信息都使用ITID(Infotype IDs)，常規的車輛信息讀取功能沒有明顯差異，兩者的對比見表9。J1979-2新增的IUMPR讀取功能見3.9節。

表9 Service$09對比

J1979中車輛信息通過Service$09讀取，定義的ITID數據長度為1 B，范圍為$00～$FF。J1979-2中車輛信息通過UDS的Service$22(Read data by identifier)讀取，定義的ITID(DID)數據長度為2 B，范圍為$F800～$F8FF，可以直觀地理解為High byte=F8的DID都用于Service$09。

對于外部測試設備，需測試排放控制器支持的標準，連接后需測試支持的協議，使用Service$22搭配ITID$F810。如果車輛上與排放相關的ECU支持J1979-2中至少一種UDS協議，就應在$F810輸出0x01。ITID的定義參考SAE J1979-DA、Annex G-Infotype IDs。

3.8 Service$0A請求永久故障碼

兩標準中Service$0A的對比見表10。J1979中永久故障碼的讀取通過Service$0A實現，其功能與Service$03和Service$07類似。J1979-2中永久故障碼通過基于UDS協議的Service$19～SF$55讀取。

表10 Service$0A對比

3.9 J1979-2新增的OBD診斷服務

基于J1979的OBD診斷服務存在以下問題：1)Service$06按照MID和TID輸出測試結果，由于很多TID是企業自定義的，在缺少相關資料的情況下監管部門和維修人員很難確認測試結果與監測項之間的關系。另外，測試結果展示的具體數值還能用來衡量其與故障閾值的距離，具有故障預判、維修驗證等功能，如果能有針對性地獲得排放相關故障碼的測試結果，將大大提高車輛檢查和維修效率。2)Service$09按照組的形式報告IUMPR結果，輸出的Ratio是該組中最小的值，無法有針對性地讀取排放相關故障碼的IUMPR結果，且法規定義為跟蹤需求的一些診斷并不會輸出到GST。例如在進行OBD演示試驗時，會出現演示項的Ratio并非該IUMPR組最小值的情況，導致分子增長無法體現在Service$09中。按照C6 OBD實施細則的要求，出現這類情況需要企業截圖證明分子增長。如果能有針對性地讀取每個有IUMPR要求的監測項的結果，則能大大提高監管效率。3)最近一次清除存儲的故障代碼后的診斷就緒狀態(Readiness)按照組的形式通過PID$01展示，如果小組顯示未完成，很難發現具體是哪些診斷未完成，給排放檢驗與維護帶來困難。如GB 18285—2018第7.3節規定，在用車檢查時若就緒狀態未完成項超過2項，則要求車主在對車輛充分行駛后進行復檢，而當前基于J1979的就緒狀態展示的是組的就緒狀態而非單個診斷的就緒狀態，導致車主無法高效地對車輛進行行駛以滿足就緒狀態要求。

J1979-2能有效解決以上問題。基于UDS協議的Service$19的下屬子功能SF$1A和SF$06可有效解決上述問題1和問題2，而且存在進一步擴展功能的可能；Service$19的下屬子功能SF$56可按照就緒狀態組獲得該組所有故障碼相應的診斷狀態，確認單個診斷的就緒狀態，有效解決上述問題3。

請求支持的DTC擴展記錄信息(Request supported DTC extended record information)功能通過基于UDS協議的Service$19～SF$1A(Report DTC extended data record identification)實現，可基于檢驗員指定的DTC extended data record number返回支持該拓展信息的故障碼列表和對應狀態(Status of DTC)，為SF$06提供基礎信息。實現方式如下：

Byte#1:0x19

Byte#2:0x1A

Byte#3:0x90～0x9F(DTC extended data record number)

DTC extended data record number指定的擴展信息序號長度為1 B，范圍為$00～$FF。ISO 14229-1附錄D.8中對其有詳細定義，其中0x90～0x9F段留給OBD，與SAE J1979-DA的Annex I-extended data items對應。典型的DTC extended data record number如下：

0x91:DTC based IUMPR

0x92:DTC based test result

3.9.2 請求支持的DTC擴展數據記錄

請求支持的DTC擴展數據記錄(Request DTC extended data record)功能通過基于UDS協議的Service$19～SF$06(Report DTC extended data record by DTC number)實現，除可基于檢驗員指定的DTC extended data record number返回支持該信息的故障碼列表和故障狀態外，還能返回其對應的數據記錄(DTC extended data record)，這個功能很重要。在使用SF$06之前，先要通過SF$1A確認哪些DTC支持指定的DTC extended data record number。實現方式如下：

首先，應當制定促進科技發展方面的立法。比如，我國制定《科技促進法》、《科技人才促進法》等促進科技發展的法律，為科技發展提供制度環境。其次，應當完善已有的科技相關法律。比如，應當從促進科技發展的角度出發，完善《著作權法》、《專利法》、《商標法》、《網絡安全法》等，為科技創新保駕護航，同時維護科研人員的智慧成果，激發其創新的積極性。最后，制定和完善規范科技運行的法律。比如，我國可以制定《科技倫理法》，對科技工作者和科學研究活動提出倫理性要求，禁止他們從事有違社會倫理道德的科研活動。另外，還可以制定法律禁止科學研究用于違法的行為。

Byte#1:0x19

Byte#2:0x06

Byte#3:DTC high byte

Byte#4:DTC middle byte

Byte#5:DTC low byte

Byte#6:0x90～0x9F

通過該子功能，可按照故障碼獲取相應的IUMPR信息和測試結果，從而大大拓展獲取信息的渠道，作為Service$06和Service$09的補充。如確認某個DTC P1234-56支持0x91/0x92，即可通過SF$06請求P1234-56的DTC extended data record，獲取該診斷的IUMPR信息和測試結果。

3.9.3 請求某就緒狀態組的故障信息

請求某就緒狀態組的故障信息(Request DTCs for a readiness group)功能通過基于UDS協議的Service$19～SF$56(Report DTC extended data record by DTC number)實現，可基于檢驗員指定的Readiness group identifier返回一個支持該信息的故障碼列表及其故障狀態(Status of DTC)。實現方式如下：

Byte#1:0x19

Byte#2:0x56

Byte#3:0x00～0xFE(RGID)

RGID(Readiness group identifier)參考SAE J1979-DA。通過該子功能，可按照就緒狀態組獲取組內每個DTC的診斷狀態。如發現RGID$07顯示未完成，可通過SF$56查看是由該組哪些診斷未完成導致的。

4 展望

新標準的實施除政策引導外，還需要原始設備制造商和相關配套標準一起推進。如Vector公司在2021年底宣布完成可滿足J1979-2標準的ECU開發工具和測試設備。此外，與J1979-2配套的技術標準如SAE J2012、SAE J1699-3等都需作相應調整。

J1979-2相比于J1979的變化主要是對傳統動力車輛OBD診斷服務的升級，從技術角度也能對純電動汽車(BEV)的監管產生啟示作用。盡管傳統意義上的OBD只是針對車載污染物排放的控制，而BEV本身并不包含污染物排放源，但BEV由于性能下降/惡化間接導致的污染物影響不應被忽視，無論是從“實際表現偏離設計意圖”等原則性角度定義BEV的OBD功能，還是從具象的BEV性能相關綜合零部件診斷，相關的功能均不應被放棄，也需以與時俱進的標準化診斷服務作為保障。而OBDonUDS可很好地兼容內燃機車和BEV控制器應用層的數據標準化要求，且支持多種目前主流總線通信技術，可以為提出BEV的OBD監管需求提供技術基礎。

5 結語

隨著排放法規的不斷更新，OBD診斷服務標準因不同市場、不同車型導致診斷工具和控制器軟件不同的情況有望在引入J1979-2后得到統一。從當前OBD診斷服務/測試模式標準的局限性、J1979-2的功能和優勢及實現方式三方面進行研究，J1979-2標準在保留J1979標準功能的基礎上進行升級，具有提供更多OBD信息的拓展性，且原始設備制造商針對J1979-2的軟件技術升級的成本較低，具有較高的應用價值。隨著J1979-2的升級，預計基于UDS協議的OBD診斷服務還會拓展出更多功能，同時可為實現BEV的OBD服務提供技術基礎。相信J1979-2的應用能為污染物排放監管帶來更高的環保收益，并提高車輛維修效率，建議將它作為中國下一階段排放法規OBD部分的應用標準。