基于ODX車輛診斷研究綜述

馬開獻，邱琪雯

（維克多汽車技術上海有限公司，上海 200050）

基于ODX車輛診斷研究綜述

馬開獻，邱琪雯

（維克多汽車技術上海有限公司，上海 200050）

介紹ODX的7層數(shù)據(jù)模型，重點闡述ODX-D與ODX-C兩層與診斷數(shù)據(jù)密切相關的信息，最后展望ODX協(xié)議的發(fā)展趨勢。

ODX數(shù)據(jù)模型；ODX應用；診斷服務

ODX（Open Diagnostic Data Exchange）是一種開放式的診斷數(shù)據(jù)格式，基于XML語言，用于車輛全生命周期中診斷數(shù)據(jù)的交互。ODX最初由ASAM（自動化及測量系統(tǒng)標準協(xié)會）提出并形成標準MCD-2D，在2008年以ODX 2.2.0為基礎形成了ISO標準——ISO 22901-1。

ODX提出之前，在診斷開發(fā)的每個階段，應用場景和開發(fā)工具都是不一樣的，所以每個階段所使用的數(shù)據(jù)格式也不一樣。例如在研發(fā)階段，通常采用.doc或.rtf格式來描述診斷需求；在測試驗證階段，以業(yè)界常用的Vector公司的CANoe.DiVa工具為例，采用.cdd格式；同樣，在生產(chǎn)、實現(xiàn)ECU代碼及售后階段，診斷需求所采用的描述格式也不一樣。然而，診斷開發(fā)流程中的各個階段又相互依存，密不可分。如果用以描述診斷需求的數(shù)據(jù)格式不斷轉(zhuǎn)換，數(shù)據(jù)的一致性將很難保證，會出現(xiàn)數(shù)據(jù)遺漏、轉(zhuǎn)換錯誤等問題，既增大了需求管理的復雜度，又使各階段工作銜接困難，增加綜合成本。如果在整個診斷開發(fā)流程中均使用ODX作為診斷需求描述的數(shù)據(jù)格式，因為ODX的開源及標準化的屬性，上述問題都得以解決。

圖1 ODX數(shù)據(jù)模型

1 ODX概述

目前最新版本的ODX為2.2.0，整個ODX數(shù)據(jù)模型分為ODX-D、ODX-C、ODX-V、ODX-F、ODX-E、ODX-FD、ODX-M 7層，如圖1所示。

ODX-D部分主要描述了診斷儀與ECU之間的通信過程，包括診斷服務的請求、響應格式及所用到的參數(shù)類型等；ODX-C部分描述了診斷儀與ECU之間的通信參數(shù)，例如網(wǎng)絡層定時參數(shù)、應用層定時參數(shù)、波特率等；ODX-V部分描述了車輛的信息，例如OEM信息、車型信息、車輛拓撲等；ODX-F部分主要對上傳下載的數(shù)據(jù)進行描述，應用于在線刷新程序；ODX-E部分描述了車輛的配置信息，包括根據(jù)特定的車輛環(huán)境、地點，使能/關閉可選功能，設定特征曲線等，主要應用于ECU生產(chǎn)、售后階段；ODX-FD部分描述了面向功能的診斷信息；ODX-M部分描述了多個ECU共同實現(xiàn)的某些診斷功能信息。ODX數(shù)據(jù)模型是通過UML模型定義的，圖2所示為ODX-D中的診斷服務描述的UML模型。

而在實際應用中，需要將UML模型映射成相應的XML代碼，圖2模型所映射的部分代碼如下。

＜DIAG-COMMS＞

＜DIAG-SERVICE ID=quot;ExampleServiceIDquot;ADDRESSING=quot;FUNCTIONAL-OR-PHYSICALquot;＞

圖2 ODX-D層服務描述的UML模型

＜SHORT-NAME＞ExampleService＜/SHORTNAME＞

……

＜REQUEST-REF ID

REF=quot;ExampleRequestIDquot;/＞

＜POS-RESPONSE-REFS＞

＜POS-RESPONSE-REF ID

REF=quot;ExampleResponseIDquot;/＞

＜/POS-RESPONSE-REFS＞

……

＜/DIAG-SERVICE＞

＜/DIAG-COMMS＞

＜REQUESTS＞

＜REQUEST ID=quot;ExampleRequestIDquot;＞

……

＜PARAMS＞

＜PARAM xsi：type=quot;CODED-CONSTquot;＞

……

＜/PARAM＞

……

＜/REQUEST＞

＜/REQUESTS＞

ODX-D與ODX-C是ODX數(shù)據(jù)模型的基礎，是診斷數(shù)據(jù)的描述必不可少的兩個部分。對于OEM來講，ODX-V也是不可或缺的。本文主要介紹ODX-D與ODX-C層的格式及主要內(nèi)容。

2 ODX-D與ODX-C層介紹

2.1 ODX-D診斷數(shù)據(jù)層

ODX數(shù)據(jù)模型構造的診斷數(shù)據(jù)分布在5個所謂的診斷層中，這5層分別是協(xié)議層（Protocol Layer）、功能組層（Functional-Group Layer）、基礎變量層（Base Variant Layer）、ECU變量（ECU Variant Layer）以及ECU共享數(shù)據(jù)層（ECU-Shared-Data Layer），如圖3所示。這5層存在著值繼承（Value Inheritance）的關系，如圖4所示。

圖3 ODX-D診斷數(shù)據(jù)層結構

圖4 ODX-D診斷數(shù)據(jù)層值繼承圖

圖4中箭頭所指方向，即為值繼承方向。ECU變量層繼承基礎變量層，基礎變量繼承層功能組層以及協(xié)議層，功能組層繼承協(xié)議層，與此同時，ECU共享數(shù)據(jù)層被其余4層共同繼承。因此，ECU共享數(shù)據(jù)層的數(shù)據(jù)是診斷數(shù)據(jù)層的主要結構。

ECU共享數(shù)據(jù)層包含了汽車診斷中所需要的協(xié)議服務分類，協(xié)議服務列表以及診斷通信過程中的測試端向ECU發(fā)出的請求信息與ECU回應給測試端的應答信息。

2.2 ODX-C通信參數(shù)層

ODX-C具有附屬結構ODX-CS，兩種結構的關系如圖5所示。

圖5 ODX-C與ODX-CS關系圖（簡易）

＜COMPARAM-SPEC＞（ODX-C）結構中包含有一個或多個＜PROT-STACK＞，＜PROT-STACK＞定義了通信參數(shù)的設置，并被分成多個＜COMPARAM-SUBSET＞（ODX-CS）結構，這些結構分別對應于＜PROTSTACK＞中所定義的應用層、傳輸層以及物理層的協(xié)議內(nèi)容。

2.3 ODX-D與ODX-C的關聯(lián)

ODX-D與ODX-C兩層，作為ODX數(shù)據(jù)模型中診斷數(shù)據(jù)描述必不可少的兩個部分，必然是具有一定關聯(lián)的，圖6顯示了ODX-D與ODX-C以及ODX-CS之間的關系。

圖6 ODX-D與ODX-C關系圖（簡易）

ODX-C繼承了ODX-CS結構中關于協(xié)議內(nèi)容詳細具體的描述信息，而ODX-D層的Protocol協(xié)議層繼承了ODX-C的值與信息，所以ODX-D與ODX-C層在汽車診斷中都是必不可少的。

3 診斷服務數(shù)據(jù)尋址方式描述

ODX具有多個數(shù)據(jù)層，而幾乎每層中又都包含有多個層次，而每個數(shù)據(jù)層以及每一層的內(nèi)部層次都具有關聯(lián)性，不同層次都具有類似的尋址方式。ODX數(shù)據(jù)模型的實際應用是通過XML代碼生成的一系列文檔進行的，本章節(jié)將以ODX-D層的服務描述為例，介紹XML代碼是如何實現(xiàn)尋址的。診斷服務描述尋址流程如圖7所示。

圖7 診斷服務描述尋址流程（簡易）

在XML文檔中＜DIAG-COMMS＞、＜FUNCTCLASSS＞、＜REQUESTS＞、＜POS-RESPONSES＞是并列的4個元素標記，即四者平級，不存在從屬關系，但是在實際內(nèi)容上又是相互關聯(lián)的。例如＜FUNCT-CLASS＞是用來分類＜DIAG-COMM＞的，因此兩者之間是通過在＜FUNCT-CLASSS＞中查找與＜DIAG-COMM＞下屬的＜DIAG-SERVICES＞中的＜FUNCT-CLASS-REF IDREF＞值相同的＜FUNCT-CLASS ID＞的值。以此類推，＜REQUEST-REF ID-REF＞和＜POS-RESPONSE-REF ID-REF＞就是用來查找對應的＜REQUEST ID＞和＜POSRESPONSE ID＞的。

例如＜DIAG-COMMS＞結構中存在：

＜DIAG-SERVICE ID=quot;DLC.UDS_Services.ESD.UDS_Services.DC.Read_Data_By_Identifierquot;SEMANTIC=quot;DATA-READquot;＞

＜SHORT-NAME＞Read_Data_By_Identifier＜/SHORT-NAME＞

……

＜FUNCT-CLASS-REFS＞

＜FUNCT-CLASS-REF ID-REF=quot;DLC.UDS_Services.ESD.UDS_Services.FNC.Data_Transmission_genericquot; /＞

＜/FUNCT-CLASS-REFS＞

＜REQUEST-REF ID-REF=quot;DLC.UDS_Services.ESD.UDS_Services.RQ.Read_Data_By_Identifier_Requestquot;/＞

＜POS-RESPONSE-REFS＞

＜POS-RESPONSE-REF ID-REF=quot;DLC.UDS_Services.ESD.UDS_Services.PR.Read_Data_By_Identifier_Responsequot;/＞

＜/POS-RESPONSE-REFS＞

＜/DIAG-SERVICE＞

1）ReadDataByIdentifier服務的分類ID為：quot;DLC.UDS_Services.ESD.UDS_Services.FNC.Data_Transmission_genericquot;，則查找＜FUNCT-CLASSS＞中的內(nèi)容，結果為：

＜FUNCT-CLASS ID=quot;DLC.UDS_Services.ESD.UDS_Services.FNC.Data_Transmission_genericquot;＞

＜SHORT-NAME＞Data_Transmission_generic＜/SHORT-NAME＞

……

＜DESC＞

＜p＞UDS functional unit Data Transmission （generic services）＜/p＞

＜/DESC＞

＜/FUNCT-CLASS＞

該語句表示ReadDataByIdentifier服務在ODX文件所存儲的該協(xié)議中，被分類為DataTransmission（generic），即數(shù)據(jù)轉(zhuǎn)換（通用）。

2）ReadDataByIdentifier服務的請求ID為：quot;DLC.UDS_Services.ESD.UDS_Services.RQ.Read_Data_By_Identifier_Requestquot;，則查找＜REQUESTS＞中的內(nèi)容，部分結果為：

＜REQUEST ID=quot;DLC.UDS_Services.ESD.UDS_Services.RQ.Read_Data_By_Identifier_Requestquot;＞

＜SHORT-NAME＞Read_Data_By_Identifier_Request＜/SHORT-NAME＞

……

＜PARAMS＞

＜PARAM SEMANTIC=quot;SERVICE-IDquot; xsi：type=quot;CODED-CONSTquot;＞

＜SHORT-NAME＞Service_Id＜/SHORT-NAME＞

……

＜CODED-VALUE＞34＜/CODED-VALUE＞

……

＜/PARAM＞

＜PARAM ID=quot;DLC.UDS_Services.ESD.UDS_Services.RQ.Read_Data_By_Identifier_Request.PA.Data_Id_1quot; xsi：type=quot;TABLE-KEYquot;＞

＜SHORT-NAME＞Data_Id＜/SHORT-NAME＞

……

＜TABLE-REF ID-REF=quot;DLC.UDS_Services.ESD.UDS_Services.TA.DID_Tablequot;/＞

＜/PARAM＞

＜/PARAMS＞

＜/REQUEST＞

由＜CODED-VALUE＞34＜/CODED-VALUE＞可知，ReadDataByIdentifier服務請求ID為0x22（十進制數(shù)34的十六進制數(shù)），即為請求信息的第一位。這一位是由協(xié)議標準定義的，不能手動更改，而請求的后幾位是根據(jù)應用或者由使用者定義的，在該實例中是由＜TABLE-REFID-REF=quot;DLC.UDS_Services.ESD.UDS_Services.TA.DID_Tablequot;/＞指向的部分定義。而此部分的具體內(nèi)容是存儲在圖7所示的＜DIAG-DATADICTIONARY-SPEC＞結構中的，該結構是用以解碼診斷數(shù)據(jù)的，同樣是通過查找對應的ID值來尋址，該部分代碼在此不贅述。

3）從＜D I A G-C O M M S＞的語句中可得，ReadDataByIdentifier服務的肯定應答ID為：quot;DLC.UDS_Services.ESD.UDS_Services.PR.Read_Data_By_Identifier_Responsequot;則查找＜POS-RESPONSES＞中的語句，結果為：

＜POS-RESPONSE ID=quot;DLC.UDS_Services.ESD.UDS_Services.PR.Read_Data_By_Identifier_Responsequot;＞

＜SHORT-NAME＞Read_Data_By_Identifier_Response＜/SHORT-NAME＞

……

＜PARAMS＞

＜PARAM xsi：type=quot;CODED-CONSTquot;＞

＜SHORT-NAME＞Service_Id＜/SHORT-NAME＞

……

＜CODED-VALUE＞98＜/CODED-VALUE＞

……

＜/PARAM＞

＜PARAM xsi：type=quot;VALUEquot;＞

＜SHORT-NAME＞Data＜/SHORT-NAME＞

……

＜DOP-REF ID-REF=quot;ODX-RS.DOP.0to0ByteENDOF PDUterminatedIDENTICALBYTEFIELDquot;

D O C R E F=quot;O D X_R S_D O P_L I B_D L Cquot;DOCTYPE=quot;CONTAINERquot;/＞

＜/PARAM＞

＜/PARAMS＞

＜/POS-RESPONSE＞

由此可得，ReadDataByIdentifier服務應答ID為0x62（十進制數(shù)98的十六進制數(shù)），即為應答信息的第一位。應答信息的后面的位由＜DOP-REFIDREF=quot;ODX-RS.DOP.0to0ByteENDOFPDUterminatedID ENTICALBYTEFIELDquot; DOCREF=quot;ODX_RS_DOP_LIB_DLCquot; DOCTYPE=quot;CONTAINERquot;/＞指向的部分定義。

由于ODX是一個用以存儲大量數(shù)據(jù)的數(shù)據(jù)庫，所以每一個ODX項目都會包含多個ODX文件，在尋址過程中，往往也會從一個文件跳轉(zhuǎn)到另一個文件，也是通過查找ID的方式來實現(xiàn)的。例如上文的＜DOPREFID-REF=quot;ODX-RS.DOP.0to0ByteENDOFPDUterm inatedIDENTICALBYTEFIELDquot; DOCREF=quot;ODX_RS_DOP_LIB_DLCquot; DOCTYPE=quot;CONTAINERquot;/＞則是跳轉(zhuǎn)到了另一個ODX文件，該文件名為quot;ODX_RS_DOP_LIB_DLCquot;，所對應的具體內(nèi)容ID為quot;ODX-RS.DOP.0to0 ByteENDOFPDUterminatedIDENTICALBYTEFIELDquot;。

ODX文件的尋址方式比較簡單，主要就是通過查找相同的ID與存儲文件名來實現(xiàn)的。相對比較成熟，但是隨著研究與應用的深入，涌現(xiàn)出不同的需求，這也是標準不斷完善和新工具誕生的源動力。例如在2011年，ASAM發(fā)布的ODX Authoring Guidelines，為建立ODX文件時的命名（比如文件名稱、ODX-Link、DOP）、SDG的描述、服務的描述（SEMANTIC、Service-Id、否定響應碼）、DTC的描述、數(shù)據(jù)交互過程給出了統(tǒng)一的建議及相關示例，這就進一步推進了診斷數(shù)據(jù)格式ODX在OEM和供應商之間的交互應用。標準化組織、OEM和工具供應商的共同努力將繼續(xù)推動ODX的應用和發(fā)展。

國內(nèi)OEM的診斷技術和診斷開發(fā)流程都在不斷積累和完善，ODX能夠減少診斷數(shù)據(jù)以及工具管理的成本，這必將使得ODX在國內(nèi)汽車診斷行業(yè)中被更廣泛地應用。國內(nèi)OEM將逐步統(tǒng)一診斷數(shù)據(jù)格式，同時和工具供應商一起合作研究開發(fā)適用于自己的診斷工具鏈。

由于ODX是一種開源化的診斷數(shù)據(jù)格式，OEM及供應商將共同面臨其安全保密性的問題，因此，基于這種開源的數(shù)據(jù)格式，數(shù)據(jù)的加密、保護必定也會有相應的研究與發(fā)展。

［1］ 靳然．ODX應用現(xiàn)狀與發(fā)展趨勢［EB/OL］.http：//auto.vogel. com.cn/news_view.html?id=358026.

［2］ ISO22901-1，Road vehicles-Open diagnostic data exchange-Part1：Data model specification ［S］．

（編輯 心 翔）

4 結語

在國外尤其是歐美的OEM中，ODX技術的應用

eNow展示太陽能驅(qū)動的零排放運輸制冷單元

eNow公司已經(jīng)在一輛于城市環(huán)境中送貨的卡車上展示了一款太陽能零排放商業(yè)用途運輸制冷單元（TRU），新的TRU品牌“Rayf Refrigeration”在五個月的測試期間實現(xiàn)了98%的N2O和97%的PM減排，傳統(tǒng)上，TRU由高污染的小型柴油發(fā)動機提供動力。

該Rayf Refrigeration系統(tǒng)采用eNow太陽能與Johnson Truck Bodies制冷機組以及Enerson的高效壓縮機技術相結合，該單元的冷板和電池最初是從公用電源充電一夜，但在送貨路線上，由安裝在卡車車頂上的eNow太陽能光伏（PV）面板提供電源。

該1800瓦的eNow太陽能系統(tǒng)提供超過足夠的能源通過典型的一天中開啟和關閉車門來保持最佳溫度，同時，該冷藏卡車在加州夏季的高溫中提供新鮮的乳制品。

eNow團隊計算，CO2的平均排放量從2525磅/周下降到159磅/周；N2O排放量從7162克減少到1克。這是在調(diào)整供電電網(wǎng)的電力過夜之后實現(xiàn)的（太陽能的任務為0）。

除了消除有害排放物之外，預計Rayf Refrigeration裝置將運營成本降低達90%，該節(jié)省是通過消除柴油燃料和維護成本以及由于eNow太陽能的一致電量維護而延長了電池壽命來實現(xiàn)的。

圣華金谷空氣污染管制區(qū)通過技術進步計劃資助了該Rayf Refrigeration計劃。

（信息來源：2017.10.12 Green Car Congress） 戴朝典??編譯

Vehicle Diagnostic Research Based on ODX

MA Kai-xian，QIU Qi-wen
（Vector Automotive Technology （Shanghai） Co.，Ltd.，Shanghai 200050，China）

This paper introduces ODX data model for seven layers，and focuses onODX-D and ODX-C layers，because they are the most important layers related to diagnostic data. At last，the development trend of ODX protocol is mentioned.

ODX data model；ODX application；diagnostic services

U463.6

A

1003-8639（2017）11-0028-05

2017-02-13

馬開獻，碩士，從事汽車電子工作10年。