基于ODX車輛診斷研究綜述

馬開獻(xiàn)，邱琪雯

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

基于ODX車輛診斷研究綜述

馬開獻(xiàn)，邱琪雯

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

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

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

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

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

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

1 ODX概述

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

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

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

＜DIAG-COMMS＞

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

圖2 ODX-D層服務(wù)描述的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ù)模型的基礎(chǔ)，是診斷數(shù)據(jù)的描述必不可少的兩個(gè)部分。對(duì)于OEM來講，ODX-V也是不可或缺的。本文主要介紹ODX-D與ODX-C層的格式及主要內(nèi)容。

2 ODX-D與ODX-C層介紹

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

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

圖3 ODX-D診斷數(shù)據(jù)層結(jié)構(gòu)

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

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

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

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

ODX-C具有附屬結(jié)構(gòu)ODX-CS，兩種結(jié)構(gòu)的關(guān)系如圖5所示。

圖5 ODX-C與ODX-CS關(guān)系圖（簡(jiǎn)易）

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

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

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

圖6 ODX-D與ODX-C關(guān)系圖（簡(jiǎn)易）

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

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

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

圖7 診斷服務(wù)描述尋址流程（簡(jiǎn)易）

在XML文檔中＜DIAG-COMMS＞、＜FUNCTCLASSS＞、＜REQUESTS＞、＜POS-RESPONSES＞是并列的4個(gè)元素標(biāo)記，即四者平級(jí)，不存在從屬關(guān)系，但是在實(shí)際內(nèi)容上又是相互關(guān)聯(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＞就是用來查找對(duì)應(yīng)的＜REQUEST ID＞和＜POSRESPONSE ID＞的。

例如＜DIAG-COMMS＞結(jié)構(gòu)中存在：

＜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服務(wù)的分類ID為：quot;DLC.UDS_Services.ESD.UDS_Services.FNC.Data_Transmission_genericquot;，則查找＜FUNCT-CLASSS＞中的內(nèi)容，結(jié)果為：

＜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＞

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

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

＜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服務(wù)請(qǐng)求ID為0x22（十進(jìn)制數(shù)34的十六進(jìn)制數(shù)），即為請(qǐng)求信息的第一位。這一位是由協(xié)議標(biāo)準(zhǔn)定義的，不能手動(dòng)更改，而請(qǐng)求的后幾位是根據(jù)應(yīng)用或者由使用者定義的，在該實(shí)例中是由＜TABLE-REFID-REF=quot;DLC.UDS_Services.ESD.UDS_Services.TA.DID_Tablequot;/＞指向的部分定義。而此部分的具體內(nèi)容是存儲(chǔ)在圖7所示的＜DIAG-DATADICTIONARY-SPEC＞結(jié)構(gòu)中的，該結(jié)構(gòu)是用以解碼診斷數(shù)據(jù)的，同樣是通過查找對(duì)應(yīng)的ID值來尋址，該部分代碼在此不贅述。

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

＜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服務(wù)應(yīng)答ID為0x62（十進(jìn)制數(shù)98的十六進(jìn)制數(shù)），即為應(yīng)答信息的第一位。應(yīng)答信息的后面的位由＜DOP-REFIDREF=quot;ODX-RS.DOP.0to0ByteENDOFPDUterminatedID ENTICALBYTEFIELDquot; DOCREF=quot;ODX_RS_DOP_LIB_DLCquot; DOCTYPE=quot;CONTAINERquot;/＞指向的部分定義。

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

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

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

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

［1］ 靳然．ODX應(yīng)用現(xiàn)狀與發(fā)展趨勢(shì)［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 結(jié)語(yǔ)

在國(guó)外尤其是歐美的OEM中，ODX技術(shù)的應(yīng)用

eNow展示太陽(yáng)能驅(qū)動(dòng)的零排放運(yùn)輸制冷單元

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

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

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

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

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

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

（信息來源：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

馬開獻(xiàn)，碩士，從事汽車電子工作10年。