ISO 13209-3-OTX擴(kuò)展標(biāo)準(zhǔn)及需求

道路車輛--開放測(cè)試序列交換格式（OTX）—3部分：標(biāo)準(zhǔn)的擴(kuò)展和要求目錄前言 8介紹 91范圍 102規(guī)范性參考文獻(xiàn) 113術(shù)語(yǔ)，定義和術(shù)語(yǔ)縮寫 123.1術(shù)語(yǔ)和定義 123.1.1自定義屏幕 123.1.2對(duì)話框 123.1.3ECOS的測(cè)量裝置 123.1.4模式對(duì)話框 123.1.5非模式的屏幕 123.1.6測(cè)試儀 123.1.7文本ID 123.2術(shù)語(yǔ)縮寫 134要求 144.1需求定義的基本原則 144.2需求優(yōu)先級(jí) 144.3需求列表 145擴(kuò)展的概述 185.1概述 185.2依賴性 185.3OTX擴(kuò)展的基本特征 196OTX時(shí)間日期擴(kuò)展 226.1介紹 226.2術(shù)語(yǔ) 226.2.1概述 226.2.2語(yǔ)法 226.2.3語(yǔ)義 227OTXDiagCom擴(kuò)展 267.1介紹 267.2總體考慮 277.2.1通信通道 277.2.2Diagnosticservices 277.2.3診斷通信模式 287.2.4專用診斷數(shù)據(jù)類型 337.3數(shù)據(jù)類型 347.3.1概述 347.3.2語(yǔ)法 347.3.3語(yǔ)義 357.4異常 387.4.1概述 387.4.2語(yǔ)法 387.4.3變更請(qǐng)求的語(yǔ)義 387.5訪問變量 397.5.1概述 397.5.2語(yǔ)法 407.5.3語(yǔ)義 407.6操作 407.6.1概述 407.6.2comchannel有關(guān)的操作 417.6.3comparameter有關(guān)的操作 437.6.4diagservice有關(guān)的操作 447.7術(shù)語(yǔ) 567.7.1概述 567.7.2comchannel相關(guān)術(shù)語(yǔ) 577.7.3diagservice相關(guān)術(shù)語(yǔ) 617.7.4請(qǐng)求相關(guān)的術(shù)語(yǔ) 657.7.5結(jié)果相關(guān)的術(shù)語(yǔ) 667.7.6響應(yīng)相關(guān)的術(shù)語(yǔ) 697.7.7參數(shù)相關(guān)的術(shù)語(yǔ) 727.7.8comparam相關(guān)術(shù)語(yǔ) 777.7.9事件相關(guān)的術(shù)語(yǔ) 818OTX診斷數(shù)據(jù)瀏覽擴(kuò)展 838.1介紹 838.2數(shù)據(jù)類型 838.2.1概述 838.2.2語(yǔ)法 838.2.3語(yǔ)義 848.3變量訪問 858.3.1概述 858.3.2語(yǔ)法 858.3.3語(yǔ)義 858.4術(shù)語(yǔ) 868.4.1概述 868.4.2語(yǔ)法 868.4.3語(yǔ)義 869OTX事件處理擴(kuò)展 919.1介紹 919.2數(shù)據(jù)類型 919.2.1概述 919.2.2語(yǔ)法 929.2.3語(yǔ)義 929.3變量訪問 939.3.1概述 939.3.2語(yǔ)法 939.3.3語(yǔ)義 939.4操作 949.4.1概述 949.4.2語(yǔ)法 949.4.3語(yǔ)義 949.4.4例子 959.5術(shù)語(yǔ) 969.5.1概述 969.5.2事件 979.5.3事件源項(xiàng) 989.5.4事件屬性術(shù)語(yǔ) 10110OTXFLASH擴(kuò)展 10410.1介紹 10410.2數(shù)據(jù)類型 10510.2.1概述 10510.2.2語(yǔ)法 10510.2.3語(yǔ)義 10610.3異常 10710.3.1概述 10710.3.2語(yǔ)法 10810.3.3語(yǔ)義 10810.4變量訪問 10810.4.1概述 10810.4.2語(yǔ)法 10910.4.3語(yǔ)義 10910.5操作 10910.5.1概述 10910.5.2語(yǔ)法 10910.5.3語(yǔ)義 11010.5.4的例子 11210.6術(shù)語(yǔ) 11210.6.1概述 11210.6.2Flash工作相關(guān)的術(shù)語(yǔ) 11310.6.3Flash會(huì)話相關(guān)的術(shù)語(yǔ) 11610.6.4刷寫塊相關(guān)的術(shù)語(yǔ) 11910.6.5刷寫塊段相關(guān)的術(shù)語(yǔ) 12410.6.6安全相關(guān)術(shù)語(yǔ) 12610.6.7自己識(shí)別相關(guān)術(shù)語(yǔ) 12910.6.8枚舉相關(guān)術(shù)語(yǔ) 13111OTXHMI擴(kuò)展 13311.1介紹 13311.1.1概述 13311.1.2對(duì)話框 13311.1.3自定義屏幕 13411.1.4自定義屏幕使用的例子 13511.2數(shù)據(jù)類型 13611.2.1概述 13611.2.2句法 13611.2.3語(yǔ)義 13611.3異常 13811.3.1概述 13811.3.2語(yǔ)法 13811.3.3語(yǔ)義 13911.4變量訪問 13911.4.1概述 13911.4.2語(yǔ)法 14011.4.3語(yǔ)義 14011.5操作 14011.5.1概述 14011.5.2對(duì)話框相關(guān)的行動(dòng) 14111.5.3自定義屏幕相關(guān)的行動(dòng) 14711.6術(shù)語(yǔ) 15111.6.1概述 15111.6.2語(yǔ)法 15211.6.3語(yǔ)義 15311.7特征 15611.7.1概述 15611.7.3語(yǔ)義 15612OTXi18n擴(kuò)展 15912.1介紹 15912.2數(shù)據(jù)類型 15912.2.1概述 15912.2.2語(yǔ)法 15912.2.3語(yǔ)義 15912.3異常 16012.3.1概述 16012.3.3語(yǔ)義 16012.4變量訪問 16112.4.1概述 16112.4.2語(yǔ)法 16112.4.3語(yǔ)義 16212.5術(shù)語(yǔ) 16212.5.1概述 16212.5.2區(qū)域設(shè)置相關(guān)的術(shù)語(yǔ) 16312.5.3翻譯相關(guān)術(shù)語(yǔ) 16412.5.4量相關(guān)的術(shù)語(yǔ) 16813OTXJob擴(kuò)展 17113.1介紹 17113.2異常 17113.2.1概述 17113.2.2句法 17113.2.3語(yǔ)義 17213.3操作 17213.3.1概述 17213.3.2語(yǔ)法 17313.3.3語(yǔ)義 17313.3.4例子 17713.4術(shù)語(yǔ) 17813.4.1概述 17813.4.2語(yǔ)法 17813.4.3語(yǔ)義 17913.4.4例子 18113.5標(biāo)準(zhǔn)特征定義 18213.5.1概述 18213.5.2singleecujob 18213.5.3flashjob 18313.5.4securityaccessjob 18414OTXLogging擴(kuò)展 18514.1介紹 18514.2數(shù)據(jù)類型 18614.2.1概述 18614.2.2語(yǔ)法 18614.3變量訪問 18814.3.1概述 18814.3.2語(yǔ)法 18814.3.3語(yǔ)義 18814.4操作 18814.4.1概述 18814.4.2語(yǔ)法 18914.4.3語(yǔ)義 18914.4.4例子 19014.5術(shù)語(yǔ) 19114.5.1概述 19114.5.2語(yǔ)法 19114.5.3語(yǔ)義 19115OTX數(shù)學(xué)擴(kuò)展 19315.1介紹 19315.2術(shù)語(yǔ) 19315.2.1概述 19315.2.2語(yǔ)法 19315.2.3語(yǔ)義 19316OTX測(cè)量擴(kuò)展 19616.1介紹 19616.2數(shù)據(jù)類型 19616.2.1概述 19616.2.2語(yǔ)法 19616.2.3語(yǔ)義 19616.3異常 19716.3.1概述 19716.3.3語(yǔ)義 19716.4變量訪問 19816.4.1概述 19816.4.2語(yǔ)法 19816.4.3語(yǔ)義 19916.5特征 19916.5.1概述 19916.5.2語(yǔ)法 19916.5.3語(yǔ)義 20016.6操作 20116.6.1概述 20116.6.2語(yǔ)法 20116.6.3語(yǔ)義 20216.7術(shù)語(yǔ) 20416.7.1概述 20416.7.2測(cè)量相關(guān)的術(shù)語(yǔ) 20516.7.3事件相關(guān)的術(shù)語(yǔ) 20817OTX數(shù)量擴(kuò)展 21017.1介紹 21017.2數(shù)據(jù)類型 21217.2.1概述 21217.2.2語(yǔ)法 21217.2.3語(yǔ)義 21317.3異常 21417.3.1概述 21417.3.2語(yǔ)法 21417.3.3語(yǔ)義 21517.4變量訪問 21517.4.1概述 21517.4.2語(yǔ)法 21517.4.3語(yǔ)義 21617.5術(shù)語(yǔ) 21617.5.1概述 21617.5.2數(shù)量和單位相關(guān)術(shù)語(yǔ) 21718OTXStringUtil擴(kuò)展 22418.1介紹 22418.2數(shù)據(jù)類型 22418.2.1概述 22418.2.2語(yǔ)法 22418.2.3語(yǔ)義 22418.3異常 22518.3.1概述 22518.3.2語(yǔ)法 22518.3.3語(yǔ)義 22618.4變量訪問 22618.4.1概述 22618.4.2語(yǔ)法 22618.4.3語(yǔ)義 22718.5術(shù)語(yǔ) 22718.5.1概述 22718.5.2語(yǔ)法 22718.5.3語(yǔ)義 228前言ISO（國(guó)際標(biāo)準(zhǔn)化組織）是一個(gè)世界性的國(guó)家標(biāo)準(zhǔn)機(jī)構(gòu)聯(lián)合會(huì)（ISO成員機(jī)構(gòu)）。制定國(guó)際標(biāo)準(zhǔn)的工作通常由ISO的進(jìn)行技術(shù)委員會(huì)來準(zhǔn)備。對(duì)建立技術(shù)委員會(huì)的主題感興趣的每個(gè)成員團(tuán)體均有權(quán)參加該委員會(huì)的代表。國(guó)際組織、政府和機(jī)構(gòu)與ISO聯(lián)系的非政府組織也參與了這項(xiàng)工作。ISO與國(guó)際電工委員會(huì)（IEC）就電工標(biāo)準(zhǔn)化的所有事宜密切合作。國(guó)際標(biāo)準(zhǔn)是根據(jù)ISO/IEC指令第2部分給出的規(guī)則起草的。技術(shù)委員會(huì)的主要任務(wù)是制定國(guó)際標(biāo)準(zhǔn)。國(guó)際標(biāo)準(zhǔn)草案由技術(shù)委員會(huì)通過的發(fā)給各成員團(tuán)體投票表決。作為國(guó)際標(biāo)準(zhǔn)發(fā)布需要至少75％的成員機(jī)構(gòu)投票批準(zhǔn)。注意：本文件中的某些內(nèi)容可能涉及到一些專利權(quán)問題。ISO不負(fù)責(zé)識(shí)別任何這樣的專利權(quán)問題。ISO13209-1由技術(shù)委員會(huì)ISO/TC22，道路車輛，小組委員會(huì)SC3，電氣和電子設(shè)備制定。ISO13209由以下幾部分組成，標(biāo)題為道路車輛-開放測(cè)試序列交換格式（OTX）：--1部分：一般信息和使用案例--2部分：核心數(shù)據(jù)模型的規(guī)范和要求--3部分：標(biāo)準(zhǔn)的擴(kuò)展規(guī)范和要求介紹無論何時(shí)，正在被診斷、測(cè)試、編程或下線的測(cè)試設(shè)備或具有診斷性質(zhì)的功能都會(huì)使用診斷測(cè)試序列號(hào)。測(cè)試序列定義了用戶（即車間或裝配線的工作人員）、診斷應(yīng)用（測(cè)試設(shè)備）和車輛通信接口以及任何計(jì)算必須執(zhí)行的決定之間的相互作用的關(guān)系。測(cè)試序列提供了一種手段來定義互動(dòng)，引導(dǎo)診斷或類似的測(cè)試邏輯。如今，汽車行業(yè)主要依賴于紙質(zhì)文件或?qū)Ｓ械膭?chuàng)作環(huán)境來記錄和實(shí)施特定測(cè)試應(yīng)用程序的測(cè)試序列。建立工程、裝配線或服務(wù)的診斷測(cè)試應(yīng)用程序的作者需要實(shí)現(xiàn)所需的手動(dòng)測(cè)試序列，它由非均勻的測(cè)試序列文件支持，最有可能為每個(gè)具體的測(cè)試應(yīng)用程序創(chuàng)作用例和格式。如果過程和工具支持OTX概念，這多余的努力可以大大減少。ISO13209為人類和機(jī)器的可讀的診斷測(cè)試序列描述提出一個(gè)開放的、標(biāo)準(zhǔn)化的格式。該格式支持在電子系統(tǒng)供應(yīng)商、車輛制造商和服務(wù)經(jīng)銷商或維修商之間傳輸診斷測(cè)試序列的要求邏輯。ISO13209-2的這一部分代表了OTX格式基礎(chǔ)的要求和技術(shù)規(guī)范，即“OTX核心”。該核心描述了每個(gè)OTX文檔的基本結(jié)構(gòu)。這包括描述測(cè)試序列邏輯所需的所有控制結(jié)構(gòu)的詳細(xì)數(shù)據(jù)模型定義，還包括測(cè)試序列邏輯嵌入其中的外部包絡(luò)文檔結(jié)構(gòu)的定義。為了實(shí)現(xiàn)可擴(kuò)展性，核心還包含定義明確的擴(kuò)展點(diǎn)，允許單獨(dú)定義其他OTX功能-無需更改核心數(shù)據(jù)模型。ISO13209的這一部分使用ISO13209-2中描述的擴(kuò)展機(jī)制規(guī)則擴(kuò)展了Core的一些附加功能。本文定義的擴(kuò)展包括允許與車輛的診斷接口進(jìn)行診斷通信、刷寫、執(zhí)行診斷任務(wù)、控制測(cè)量設(shè)備、國(guó)際化、使用物理單元、訪問環(huán)境、通過人機(jī)界面（HMI）和其他實(shí)用擴(kuò)展。1范圍ISO13209的這一部分定義了開放測(cè)試序列交換（OTX）擴(kuò)展要求和數(shù)據(jù)模型規(guī)范。這些要求源自ISO13209-1中描述的用例。它們?cè)诘?章中列出。數(shù)據(jù)模型規(guī)范旨在對(duì)OTX擴(kuò)展的所有功能進(jìn)行詳盡的定義，這些擴(kuò)展已經(jīng)實(shí)現(xiàn)以滿足要求。ISO13209的這一部分為每個(gè)擴(kuò)展的語(yǔ)法實(shí)體建立了規(guī)則。每個(gè)這些語(yǔ)法實(shí)體都附帶有語(yǔ)義規(guī)則，這些語(yǔ)義規(guī)則決定如何解釋包含擴(kuò)展功能的OTX文檔。語(yǔ)法規(guī)則由UML類圖和XML模式提供，而語(yǔ)義由UML活動(dòng)圖和散文定義給出。2規(guī)范性參考文獻(xiàn)以下參考文件對(duì)于本文件的應(yīng)用是必不可少的。凡是注日期的引用文件，僅注明引用的版本。凡是不注日期的引用文件，其最新版本（包括所有修改單）適用于本文件。ISO／IEC646:1991，信息技術(shù)-用于信息交換的ISO7位編碼字符集ISO8601:2004，數(shù)據(jù)元素和交換格式-信息交換-日期和時(shí)間表示ISO／IEC8859-1:1998，信息技術(shù)-8位單字節(jié)編碼圖形字符集-第1部分：拉丁字母編號(hào)1ISO/IEC10646，信息技術(shù)-通用多字節(jié)編碼字符集（UCS）ISO／IEC13209-1，道路車輛-開放測(cè)試序列交換格式（OTX）-第1部分：一般信息和用例ISO／IEC13209-2，道路車輛-開放測(cè)試序列交換格式（OTX）-第2部分：核心數(shù)據(jù)模型規(guī)范和要求ISO／IEC19501:2005，信息技術(shù)-開放分布式處理的統(tǒng)一建模語(yǔ)言（UML）版本1.4.2ISO14229（所有部分），道路車輛-統(tǒng)一診斷服務(wù)（UDS）ISO22900（所有部分），道路車輛-模塊化車輛通信接口（MVCI）ISO22901（所有部分），道路車輛-開放診斷數(shù)據(jù)交換（ODX）RFC1866，超文本標(biāo)記語(yǔ)言-2.0SAEJ1979，E/E的診斷測(cè)試模式W3Cxptr：2003，W3C推薦：XPointer框架（所有部分）W3C和2001，W3C推薦標(biāo)準(zhǔn)：XML鏈接語(yǔ)言（XLink）版本1W3C的XML：2008，W3C推薦標(biāo)準(zhǔn)：可擴(kuò)展標(biāo)記語(yǔ)言（XML）1（第五版）W3Cxmlns：2009，W3C推薦標(biāo)準(zhǔn)：XML命名空間中的1（第三版）W3C的XSD：2004，W3C推薦標(biāo)準(zhǔn)：XML模式（所有部分）3術(shù)語(yǔ)，定義和術(shù)語(yǔ)縮寫3.1術(shù)語(yǔ)和定義就本文件而言，ISO13209-1，ISO13209-2及以下條款中給出的術(shù)語(yǔ)和定義適用。3.1.1自定義屏幕屏幕上顯示由測(cè)試序列作者定義的屬性和字段3.1.2對(duì)話框屏幕上帶有可以從OTX序列中設(shè)置或讀取的預(yù)定義屬性和字段3.1.3ECOS的測(cè)量裝置廣泛使用的嵌入式系統(tǒng)用于測(cè)試消費(fèi)者的電流和電壓曲線3.1.4模式對(duì)話框?qū)υ捒蜃柚沽鞒虉?zhí)行，直到用戶將其解除為止3.1.5非模式的屏幕異步，非阻塞屏幕，在測(cè)試序列執(zhí)行繼續(xù)時(shí)仍然顯示3.1.6測(cè)試儀通過車輛通信接口連接到車輛的計(jì)算機(jī)系統(tǒng)，運(yùn)行診斷應(yīng)用程序用3.1.7文本ID一個(gè)包含本地化字符串翻譯詞典數(shù)據(jù)庫(kù)輸入的字符串引用3.2術(shù)語(yǔ)縮寫API應(yīng)用編程接口DTC診斷故障代碼ECOS電氣檢查系統(tǒng)ECU電子控制單元GUI圖形用戶界面HMI人機(jī)接口IFD通用接口定義（OTX擴(kuò)展）NOP無操作指令執(zhí)行OEM原始設(shè)備制造商OTX開放測(cè)試序列交換PDU協(xié)議數(shù)據(jù)單元UI用戶界面UML統(tǒng)一建模語(yǔ)言VCI車輛通信接口XML可擴(kuò)展標(biāo)記語(yǔ)言XSDXML架構(gòu)定義4要求4.1需求定義的基本原則確定基本原則作為定義OTX要求的指導(dǎo)原則：a）OTX要求規(guī)定了OTX數(shù)據(jù)模型和格式應(yīng)滿足的條件。b）提供診斷測(cè)試程序的所有利益相關(guān)者（系統(tǒng)供應(yīng)商，原始設(shè)備制造商，工具供應(yīng)商）均應(yīng)執(zhí)行并遵守本標(biāo)準(zhǔn)的要求。OTX文件的內(nèi)容和信息的質(zhì)量是發(fā)件人的責(zé)任。4.2需求優(yōu)先級(jí)以下每項(xiàng)要求都包含一個(gè)可以設(shè)置為SHALL或SHOULD的優(yōu)先級(jí)屬性。--SHALL：該要求代表了利益相關(guān)方定義的特征，缺少這些特征會(huì)導(dǎo)致缺乏其他方式無法補(bǔ)償?shù)娜毕荨?-SHOULD：如果需求定義特征在數(shù)據(jù)模型中沒有或者沒有完全實(shí)現(xiàn)，它不會(huì)導(dǎo)致缺陷，因?yàn)榭梢允褂脭?shù)據(jù)模型中的其他功能來規(guī)避這一點(diǎn)。4.3需求列表Extensions_R01–讀取當(dāng)前的日期和時(shí)間優(yōu)先級(jí)：SHALL原理：它可以檢索當(dāng)前的日期和時(shí)間。描述：前的日期和時(shí)間應(yīng)該以適合于計(jì)算兩個(gè)日期之間的持續(xù)時(shí)間的方式來訪問，但也可以用于生成人類可讀的日期形式。Extensions_R02–支持但不需要ODX優(yōu)先級(jí)：SHALL原理：為了與車輛ECU通信，應(yīng)支持但不強(qiáng)制使用ODX。描述：任何車輛通信相關(guān)的擴(kuò)展數(shù)據(jù)模型都應(yīng)與ODX功能的有用子集相匹配。Extensions_R03–刷寫會(huì)話處理優(yōu)先級(jí)：SHALL原理：應(yīng)提供功能來瀏覽和選擇刷寫會(huì)話。描述：刷寫擴(kuò)展應(yīng)提供按方向和名稱選擇的可能性。Extensions_R04–低水平的flash數(shù)據(jù)訪問優(yōu)先級(jí)：SHALL原理：應(yīng)提供用于瀏覽和從刷寫環(huán)境（下載容器）中選擇數(shù)據(jù)的功能。描述：數(shù)據(jù)應(yīng)聚集在塊和段中。應(yīng)該支持像ODXFlash這樣的現(xiàn)代數(shù)據(jù)格式所使用的安全功能。Extensions_R05–刷寫數(shù)據(jù)存儲(chǔ)優(yōu)先級(jí)：SHALL原理：上傳的Flash數(shù)據(jù)應(yīng)存儲(chǔ)在本地存儲(chǔ)器中。描述：對(duì)于刷寫數(shù)據(jù)上傳，用于刷寫的OTX擴(kuò)展應(yīng)提供以選定格式存儲(chǔ)的功能。Extensions_R06–使開發(fā)人員能夠使用OTX代替ODXJava作業(yè)優(yōu)先級(jí)：SHALL原理：應(yīng)提供功能來模擬OTX序列的ODXJava作業(yè)描述：一作業(yè)擴(kuò)展應(yīng)使開發(fā)人員能夠?qū)TX序列作為ODXJava作業(yè)運(yùn)行。應(yīng)支持SingelEcuJob，SecurityAccessJob和FlashJob。Extensions_R07–提供與汽車ECU通信診斷手段優(yōu)先級(jí)：SHALL原理：應(yīng)提供與車輛ECU系統(tǒng)進(jìn)行診斷通信的功能。描述：應(yīng)該有一個(gè)OTX擴(kuò)展，它允許配置和執(zhí)行車輛ECU的診斷服務(wù)。應(yīng)該可以建立到特定ECU的通信通道，配置發(fā)送到ECU的診斷服務(wù)的請(qǐng)求參數(shù)并分析ECU的響應(yīng)參數(shù)。溝通渠道，診斷服務(wù)和參數(shù)的描述應(yīng)以人類可讀和符號(hào)的方式進(jìn)行;任何現(xiàn)有的診斷符號(hào)到二進(jìn)制映射（例如ODX）都應(yīng)該被支持。發(fā)送診斷服務(wù)和接收的實(shí)際功能應(yīng)通過測(cè)試序列和車輛之間的接口（例如MCD3DAPI和MVCI）提供。Extensions_R08–提供瀏覽診斷數(shù)據(jù)的方法優(yōu)先級(jí)：SHALL原理：應(yīng)提供功能來從診斷應(yīng)用程序的靜態(tài)診斷數(shù)據(jù)庫(kù)中讀取信息。描述：應(yīng)提供OTX擴(kuò)展，它允許從診斷數(shù)據(jù)庫(kù)中讀取靜態(tài)信息，例如，可用的通信信道，用于通信信道的診斷服務(wù)或用于診斷服務(wù)的參數(shù)。Extensions_R09–使開發(fā)人員處理事件優(yōu)先級(jí)：SHALL原理：應(yīng)提供功能性，允許OTX測(cè)試序列對(duì)明確定義的事件作出反應(yīng)。描述：OTX擴(kuò)展應(yīng)允許開發(fā)人員配置測(cè)試序列，以便它可以等待某些事件發(fā)生（例如，當(dāng)定時(shí)器到期，變量值發(fā)生變化或從用戶界面接收用戶輸入時(shí)等）。應(yīng)該有辦法獲得關(guān)于事件的進(jìn)一步信息，例如它是什么類型的事件，以及關(guān)于特定事件的附加信息。Extensions_R10–提供人機(jī)界面功能的手段優(yōu)先級(jí)：SHALL原理：應(yīng)提供功能，允許OTX測(cè)試序列以雙向方式與用戶進(jìn)行通信。描述：需要一個(gè)OTX擴(kuò)展，允許從用戶界面發(fā)送和接收信息（例如，帶有輸入控件的GUI窗口）。該擴(kuò)展不應(yīng)提供明確配置信息的圖形布局的手段;相反，它只能為通信數(shù)據(jù)本身提供一個(gè)雙向接口。Extensions_R11–使開發(fā)人員能夠配置本地化測(cè)試序列優(yōu)先級(jí)：SHALL原理：在配置OTX測(cè)試序列時(shí)，應(yīng)支持測(cè)試序列開發(fā)人員，這些測(cè)試序列準(zhǔn)備好翻譯成不同的語(yǔ)言。描述：需要OTX擴(kuò)展，允許開發(fā)人員通過文本ID概念訪問同義詞庫(kù)數(shù)據(jù)庫(kù)。開發(fā)人員應(yīng)支持將文本ID轉(zhuǎn)換為為運(yùn)行時(shí)系統(tǒng)或其他語(yǔ)言配置的語(yǔ)言（就運(yùn)行系統(tǒng)而言）的功能。同義詞庫(kù)數(shù)據(jù)庫(kù)本身不應(yīng)該是標(biāo)準(zhǔn)的一部分。通用方法應(yīng)支持不同類型的敘詞表數(shù)據(jù)庫(kù)。Extensions_R12–提供記錄日志優(yōu)先級(jí)：SHALL原理：應(yīng)該可以將日志消息寫入日志記錄資源。描述：需要OTX擴(kuò)展，允許將日志消息寫入日志記錄資源;消息應(yīng)根據(jù)嚴(yán)重程度進(jìn)行過濾。Extensions_R13–支持測(cè)量設(shè)備優(yōu)先級(jí)：SHALL原理：制造和售后車間中的測(cè)量設(shè)備應(yīng)可通過適當(dāng)?shù)墓δ苓M(jìn)行訪問。描述：需要OTX擴(kuò)展，允許從測(cè)量設(shè)備接收測(cè)量值。應(yīng)該有一個(gè)抽象層允許使用任何種類的測(cè)量設(shè)備。Extensions_R14–支持物理單元優(yōu)先級(jí)：SHALL原理：需要功能性，允許用單位處理物理值描述：需要一個(gè)OTX擴(kuò)展來描述物理量。該擴(kuò)展應(yīng)便于在這些物理量上進(jìn)行常用計(jì)算，例如，物理值從一個(gè)單位系統(tǒng)到另一單位系統(tǒng)的轉(zhuǎn)換（例如，以千米或英里表示距離等）。它還應(yīng)允許對(duì)數(shù)量進(jìn)行基本的數(shù)學(xué)運(yùn)算，而不要求開發(fā)人員明確關(guān)心該單元（例如，應(yīng)該可以直接計(jì)算10m+2km）。Extensions_R15–支持增強(qiáng)的字符串操作優(yōu)先級(jí)：SHALL原理：OTX核心字符串操作應(yīng)通過額外的常用字符串操作進(jìn)行擴(kuò)展。描述：需要一個(gè)OTX擴(kuò)展來描述附加的字符串操作，這將有助于計(jì)算字符串值。Extensions_R16–支持基本的數(shù)學(xué)函數(shù)優(yōu)先級(jí)：SHALL原理：OTX核心的算術(shù)運(yùn)算應(yīng)該通過附加的數(shù)學(xué)函數(shù)來擴(kuò)展。描述：需要一個(gè)OTX擴(kuò)展，它描述了一些附加的數(shù)學(xué)函數(shù)，這些函數(shù)在某些診斷應(yīng)用中是需要的（例如三角函數(shù)和對(duì)數(shù)函數(shù)等）。5擴(kuò)展的概述5.1概述本文件描述了數(shù)據(jù)模型版本“1.0.0”5.2依賴性圖1顯示了一個(gè)UML包圖[ISO/IEC19501]，描述了全套OTX擴(kuò)展（以及OTXCore）以及它們之間的導(dǎo)入依賴關(guān)系。OTX擴(kuò)展使用或擴(kuò)展OTXCore中定義的類型。因此，所有擴(kuò)展都基于ISO13209第2部分規(guī)定的OTX核心數(shù)據(jù)模型（直接或間接）。除了OTX核心，OTX事件處理，OTXDiagCom和OTX數(shù)量擴(kuò)展也起著核心作用;此處定義的類型由其他OTX擴(kuò)展使用或擴(kuò)展。 圖1-概述：OTX架構(gòu)的依賴關(guān)系重要-OTXCore是任何OTX應(yīng)用程序的先決條件，應(yīng)始終得到全面支持。相比之下，OTX應(yīng)用程序無需支持本標(biāo)準(zhǔn)中規(guī)定的所有擴(kuò)展。受支持的擴(kuò)展集可能因應(yīng)用領(lǐng)域而異。但是，支持導(dǎo)入其他擴(kuò)展的擴(kuò)展的OTX應(yīng)用程序也應(yīng)支持這些擴(kuò)展。這保證了支持的擴(kuò)展集與依賴關(guān)系一致。圖1還顯示了輔助軟件包OTXDiagMetaData以及OTXAppInfo。這些軟件包不是OTX擴(kuò)展;它們支持OTX創(chuàng)作系統(tǒng)，只有在創(chuàng)作時(shí)才會(huì)使用附加數(shù)據(jù)。OTX測(cè)試序列運(yùn)行時(shí)不需要這些信息。有關(guān)DiagMetaData的輔助信息，請(qǐng)參閱附錄C.有關(guān)AppInfo的輔助信息，請(qǐng)參閱ISO13209的第2部分。5.3OTX擴(kuò)展的基本特征表1提供了有關(guān)所有OTX擴(kuò)展及其基本特性的概述。擴(kuò)展（模式文件）摘要依賴關(guān)系DateTime(otxIFD_DateTime.xsd)提供對(duì)系統(tǒng)時(shí)間的訪問CoreDiagCom(otxIFD_DiagCom.xsd)連接到ECU，創(chuàng)建和執(zhí)行診斷服務(wù)，分析通信數(shù)據(jù)EventHandling,Quantities,CoreDiagComRaw(otxIFD_DiagComRaw.xsd)直接在非符號(hào)（二進(jìn)制）級(jí)別進(jìn)行診斷通信DiagComDiagDataBrowsing(otxIFD_DiagDataBrosing.xsd)用于從診斷數(shù)據(jù)庫(kù)讀取數(shù)據(jù)的瀏覽功能DiagCom,CoreEventHandling(otxIFD_Event.xsd)支持OTX事件處理機(jī)制CoreFlash(otxIFD_Flash.xsd)功能，用于下載和上傳來自ECU的刷寫數(shù)據(jù)DiagCom,CoreHMI(otxIFD_HMI.xsd)通過對(duì)話框和屏幕與UI（用戶界面）進(jìn)行通信的功能EventHandling,Corei18n(otxIFD_I18n.xsd)國(guó)際化功能，多語(yǔ)言支持和翻譯機(jī)制Quantities,CoreJob(otxIFD_Job.xsd)OTX測(cè)試序列模擬ODXJava作業(yè)的功能DiagCom,Quantities,CoreLogging(otxIFD_Logging.xsd)支持（Log4J風(fēng)格）日志記錄CoreMath(otxIFD_Math.xsd)擴(kuò)展的數(shù)學(xué)函數(shù)CoreMeasure(otxIFD_Measure.xsd)執(zhí)行測(cè)量設(shè)備服務(wù)，測(cè)量物理值，分析測(cè)量值EventHandlingQuantities,CoreQuantities(otxIFD_Quantities.xsd)處理數(shù)量數(shù)據(jù)，wrt。國(guó)際單位制，單位間轉(zhuǎn)換等CoreStringUtil(otxIFD_StringUtil.xsd)擴(kuò)展的字符串處理功能Core表1—OTX擴(kuò)展特性表2顯示了所有OTX擴(kuò)展[W3CXSD][W3CXMLNS]的XSD名稱空間關(guān)聯(lián)。每個(gè)名稱空間都有一個(gè)分配給它的前綴。這也適用于OTXCore名稱空間，該名稱空間具有otx：前綴（表中未顯示）。在本文檔的其余部分，這里定義的前綴用于標(biāo)記屬于除當(dāng)前描述的擴(kuò)展之外的擴(kuò)展的類型。相反，由當(dāng)前描述的擴(kuò)展定義的類型不加前綴。表2—OTX擴(kuò)展命名空間關(guān)聯(lián)思考圖2中的示例。它顯示了OTXDiagCom擴(kuò)展的IsDiagServiceEvent術(shù)語(yǔ)。該術(shù)語(yǔ)接受在OTXEventHandling擴(kuò)展中定義的參數(shù)，因此元素的類型標(biāo)記為event：prefix（event：EventValue）。這同樣適用于為圖定義的布爾型返回類型，該類型在OTXCore中定義，并用otx：前綴（otx：BooleanTerm）相應(yīng)標(biāo)記。因?yàn)槭钱?dāng)前描述的OTXDiagCom擴(kuò)展的成員，所以IsDiagServiceEvent類型本身不是前綴。圖2-例如：擴(kuò)展前綴的使用6OTX時(shí)間日期擴(kuò)展6.1介紹OTXDateTime擴(kuò)展的用途是檢索有關(guān)診斷應(yīng)用程序提供的當(dāng)前日期和時(shí)間的信息。6.2術(shù)語(yǔ)6.2.1概述OTXDateTime擴(kuò)展中的術(shù)語(yǔ)應(yīng)用于檢索有關(guān)當(dāng)前系統(tǒng)時(shí)間的信息。6.2.2語(yǔ)法圖3顯示了OTXDateTime擴(kuò)展中所有術(shù)語(yǔ)的語(yǔ)法。圖3-數(shù)據(jù)模型視圖：TimeDate術(shù)語(yǔ)6.2.3語(yǔ)義gettimestampGetTimestamp應(yīng)返回一個(gè)時(shí)間戳，以1970年01月00:00:00UTC以來的毫秒數(shù)表示。GetTimestamp的語(yǔ)義應(yīng)該根據(jù)Java2平臺(tái)標(biāo)準(zhǔn)所指定的Java.util.date.gettime()方法。GetDate是一個(gè)otx整數(shù)術(shù)語(yǔ)。它沒有成員。formatDateFormatDate項(xiàng)應(yīng)將時(shí)間戳（請(qǐng)參閱上面的GetTimestamp術(shù)語(yǔ)）轉(zhuǎn)換為日期表示形式，其格式如下：a）如果沒有指定自定義格式，則返回的字符串應(yīng)根據(jù)ISO8601標(biāo)準(zhǔn)[ISO8601：2004]給出的規(guī)則進(jìn)行格式化。b）如果給定了自定義格式（由<format>元素），則字符串應(yīng)根據(jù)下面指定的Cusom格式規(guī)則進(jìn)行格式化。自定義格式模式可由OTX作者配置;它控制日期的文本顯示。格式模式包含一個(gè)或多個(gè)預(yù)定義的日期和時(shí)間格式說明符（請(qǐng)參閱表3）以及必須用引號(hào)（'）轉(zhuǎn)義的用戶定義的字符串序列。非數(shù)字輸出（例如一個(gè)月的名稱）應(yīng)自動(dòng)翻譯成當(dāng)前設(shè)置的語(yǔ)言環(huán)境（參見第12條OTXi18n擴(kuò)展）表3日期格式說明符格式模式規(guī)則類似于Java?2??PlatformStandardEd所指定的類java.text.SimpleDateFormat的規(guī)則。FormatDate的整體語(yǔ)義應(yīng)根據(jù)方法SimpleDateFormat.format（日期日期）的語(yǔ)義。示例1在中歐時(shí)區(qū)（CET）的2011-03-1011:23:56給定日期和時(shí)間并且當(dāng)前語(yǔ)言環(huán)境設(shè)置為en-US時(shí)，“hh'o''clock'a，zzzz”會(huì)產(chǎn)生以下格式輸出：“中歐時(shí)間上午11點(diǎn)。。如果沒有給出自定義格式，則ISO8601符合日期輸出格式應(yīng)與自定義格式“yyyy-MM-dd'T'HH：mm：ss'。'SSSZ”相等格式化，其中“T”是時(shí)間指示符，“.”是以下毫秒部分的分隔符。這種模式是獨(dú)立于語(yǔ)言的;當(dāng)前設(shè)置的語(yǔ)言環(huán)境不會(huì)影響輸出。示例2在中歐時(shí)區(qū)（CET）2011-03-1011:23:56的給定日期和時(shí)間，將生成以下標(biāo)準(zhǔn)格式輸出：“2011-0310T11：23：56.123+0100”FormatDate是一個(gè)otx：StringTerm。其成員具有以下語(yǔ)義：--<timestamp>：OTX：numericterm[1]該元素表示日期，時(shí)間戳記應(yīng)被解釋為自1970年1月1日00:00:00UTC以來經(jīng)過的毫秒數(shù)。根據(jù)上面給出的規(guī)則，相應(yīng)的日期應(yīng)格式化為字符串輸出。浮動(dòng)值應(yīng)被截?cái)唷?-<pattern>：OTX：stringterm[0..1]這個(gè)可選元素表示應(yīng)該用于生成自定義日期輸出字符串的自定義格式模式。拋出：--OTX：outofboundsexception如果時(shí)間戳值為負(fù)數(shù)。formatdurationFormatDuration項(xiàng)應(yīng)以字符串表示形式返回給定的毫秒持續(xù)時(shí)間。格式化應(yīng)該類似于FormatDate術(shù)語(yǔ)來完成，區(qū)別在于傳遞給術(shù)語(yǔ)的毫秒數(shù)被解釋為持續(xù)時(shí)間，而不是日期。由于表3中給出的一些格式說明符在持續(xù)時(shí)間方面（例如時(shí)區(qū)，星期幾名稱，時(shí)代等）沒有意義，因此只應(yīng)使用表4中定義的說明符。表4時(shí)間格式說明符示例1對(duì)于給定的203443毫秒的持續(xù)時(shí)間（這是3分23秒和443毫秒），例如像“'這花了'米'分鐘和'秒'”會(huì)產(chǎn)生以下格式輸出：“這花了大約3分23秒。”如果沒有給出自定義格式，那么符合ISO8601要求的日期輸出格式應(yīng)與自定義格式“'P'yyyy-MM-dd'T'HH：mm：ss'。'SSS”相同，其中“P”是時(shí)間指示符，“T”是時(shí)間指示符。示例2對(duì)于給定的持續(xù)時(shí)間203443毫秒（這是3分23秒和443毫秒），將生成以下標(biāo)準(zhǔn)格式輸出：“P000000-00T00：03：23.443”FormatDuration是一個(gè)otx：StringTerm。其成員具有以下語(yǔ)義：--<Duration>：OTX：numericterm[1]該元素表示以毫秒為單位的持續(xù)時(shí)間，該持續(xù)時(shí)間將被轉(zhuǎn)換為根據(jù)上述規(guī)則格式化的字符串。浮動(dòng)值應(yīng)被截?cái)唷?-<pattern>：OTX：stringterm[0..1]這個(gè)可選元素表示為了生成自定義持續(xù)時(shí)間輸出字符串而應(yīng)用的自定義格式模式。拋出：--OTX：outofboundsexception如果持續(xù)時(shí)間值是負(fù)值。7OTXDiagCom擴(kuò)展7.1介紹OTXDiagCom擴(kuò)展的目的是為執(zhí)行診斷車輛通信提供必要的OTX元素。具體而言，已經(jīng)考慮了以下診斷用例：--處理ECU通信通道--執(zhí)行診斷服務(wù)--設(shè)置服務(wù)請(qǐng)求參數(shù)并評(píng)估服務(wù)響應(yīng)參數(shù)--處理診斷服務(wù)的積極或各種消極反應(yīng)--處理通信通道協(xié)議參數(shù)--執(zhí)行ECU的變體識(shí)別--功能性診斷服務(wù)：多個(gè)ECU將響應(yīng)請(qǐng)求--重復(fù)/循環(huán)執(zhí)行診斷服務(wù)：?jiǎn)蝹€(gè)請(qǐng)求將導(dǎo)致來自同一ECU的多個(gè)響應(yīng)--functional功能尋址和循環(huán)服務(wù)執(zhí)行的潛在組合：多個(gè)ECU響應(yīng)多次請(qǐng)求--diagnostic診斷服務(wù)的請(qǐng)求和響應(yīng)中的復(fù)雜數(shù)據(jù)結(jié)構(gòu)：參數(shù)結(jié)構(gòu)，參數(shù)列表，包含參數(shù)結(jié)構(gòu)的列表下面的考慮引入了由DiagCom擴(kuò)展的設(shè)計(jì)解決的問題域。雖然這些功能不太可能會(huì)被所有運(yùn)行OTX序列的運(yùn)行環(huán)境所支持，但OTXDiagCom擴(kuò)展必須提供處理這些概念的方法，因?yàn)樗荚诔蔀槎x車輛診斷的通用方法。注1：這是DiagCom擴(kuò)展的明確設(shè)計(jì)目標(biāo)，可用于任何診斷通信內(nèi)核。作為設(shè)計(jì)指南，考慮了基于ODX/MVCI[ISO22901][ISO22900]的系統(tǒng)-由于ODX/MVCI正在解決高度通用的車輛通信問題領(lǐng)域，因此DiagCom采用的設(shè)計(jì)概念對(duì)于正在實(shí)施車輛通信問題解決方案的任何系統(tǒng)，擴(kuò)展應(yīng)該是可用的抽象。注2：DiagCom擴(kuò)展的明確設(shè)計(jì)目標(biāo)是僅為診斷車輛通信提供運(yùn)行時(shí)間接口。瀏覽診斷數(shù)據(jù)庫(kù)（例如ASAMMCD3API的數(shù)據(jù)庫(kù)部分）不是DiagCom擴(kuò)展的設(shè)計(jì)目標(biāo)。對(duì)于這種使用情況，應(yīng)創(chuàng)建專門提供數(shù)據(jù)訪問功能的單獨(dú)OTX擴(kuò)展。7.2總體考慮7.2.1通信通道執(zhí)行任何診斷通信的先決條件是診斷應(yīng)用程序與車輛的電子控制單元之間的通信通道。在OTX中，這個(gè)實(shí)例稱為ComChannel，指定測(cè)試序列和預(yù)期通信目標(biāo)之間的邏輯連接。ComChannel不關(guān)心與所需端點(diǎn)進(jìn)行通信所需的協(xié)議，布線，連接器或釘扎的任何細(xì)節(jié);相反，這些方面將由底層車輛通信層來處理。ComChannel在符號(hào)級(jí)別上工作，因?yàn)樗鼞?yīng)該通過名稱來處理ECU，并通過運(yùn)行時(shí)存在的ECU的特定變體來了解ECU的診斷功能。因此，OTX中有一個(gè)ComChannel上ECU變量識(shí)別的概念，以及創(chuàng)建指向特定ECU變體的通道或檢索ComChannel的當(dāng)前活動(dòng)ECU變體名稱的功能。注意這是OTXDiagCom擴(kuò)展的明確設(shè)計(jì)目標(biāo)，可用于任何診斷通信內(nèi)核。然而，ComChannel和ECU變體的概念是基于邏輯鏈路和ECU變體識(shí)別的MVCI定義，因?yàn)樗鼈兇砹藦V泛適用的設(shè)計(jì)問題的通用高級(jí)方法。7.2.2Diagnosticservices圖4給出了診斷服務(wù)的請(qǐng)求和結(jié)果數(shù)據(jù)結(jié)構(gòu)的高級(jí)概述。該服務(wù)包含一個(gè)請(qǐng)求。該請(qǐng)求包括一個(gè)或多個(gè)參數(shù)。診斷服務(wù)可以有任意數(shù)量的結(jié)果。在這個(gè)例子中，顯示了一個(gè)結(jié)果。服務(wù)結(jié)果可以包含任意數(shù)量的ECU響應(yīng)。響應(yīng)包含一個(gè)或多個(gè)參數(shù)。參數(shù)可以是簡(jiǎn)單數(shù)據(jù)類型，也可以是包含參數(shù)列表或結(jié)構(gòu)參數(shù)的復(fù)雜類型構(gòu)。圖4-診斷服務(wù)請(qǐng)求的結(jié)果結(jié)構(gòu)圖5所示的請(qǐng)求由一個(gè)簡(jiǎn)單的參數(shù)，一個(gè)包含兩個(gè)低級(jí)參數(shù)的struct參數(shù)和一個(gè)包含兩個(gè)item的list參數(shù)組成，每個(gè)item又包含三個(gè)簡(jiǎn)單的數(shù)據(jù)類型參數(shù)。它還顯示了如何使用由<path>元素定義的<stepByIndex>和<stepByName>方法，通過DiagCom擴(kuò)展中的術(shù)語(yǔ)和動(dòng)作訪問不同的參數(shù)（請(qǐng)參考本節(jié)的其余部分，以及更多信息，請(qǐng)參閱ISO13209的第2部分）。如示例請(qǐng)求中所示，通過路徑訪問參數(shù)的方式也適用于ECU響應(yīng)，這些響應(yīng)也可以包含復(fù)雜的參數(shù)結(jié)構(gòu)。為了處理重復(fù)的服務(wù)執(zhí)行模式（請(qǐng)參閱7.2.3），診斷服務(wù)使用結(jié)果隊(duì)列的概念。每次向ECU發(fā)送請(qǐng)求時(shí)，都會(huì)將新的結(jié)果元素添加到包含ECU對(duì)該請(qǐng)求的響應(yīng)的隊(duì)列中。OTXDiagCom擴(kuò)展提供了三種與結(jié)果隊(duì)列交互的方法：a）可以使用GetFirstResult項(xiàng)來訪問隊(duì)列的第一個(gè)結(jié)果b）通過使用GetAllResults術(shù)語(yǔ)，可以將當(dāng)前隊(duì)列中的所有結(jié)果作為OTX列表進(jìn)行檢索c）GetAllResultsAndClear操作檢索隊(duì)列中的所有結(jié)果并清除隊(duì)列診斷服務(wù)隊(duì)列中結(jié)果的生命周期由服務(wù)執(zhí)行請(qǐng)求分隔：每次在該DiagService對(duì)象上調(diào)用ExecuteDiagService或StartRepetition時(shí)，都會(huì)清除診斷服務(wù)的隊(duì)列。圖5-復(fù)雜要求的結(jié)構(gòu)與<stepbyname>和<stepbyindex>7.2.3診斷通信模式概述除了診斷服務(wù)請(qǐng)求和響應(yīng)具有任意的結(jié)構(gòu)復(fù)雜性之外，診斷應(yīng)用與車輛內(nèi)的ECU之間的交互模型也為診斷應(yīng)用提供了挑戰(zhàn)：發(fā)送給車輛的診斷服務(wù)請(qǐng)求可能導(dǎo)致多個(gè)ECU應(yīng)答該請(qǐng)求，或者在由通信后端重復(fù)執(zhí)行診斷服務(wù)的情況下導(dǎo)致多個(gè)請(qǐng)求和響應(yīng)幀。當(dāng)ECU的回應(yīng)以多個(gè)部分發(fā)送時(shí)，會(huì)出現(xiàn)更多復(fù)雜情況。下面舉例說明了物理和功能尋址，一次性和重復(fù)執(zhí)行以及單部分和多部分響應(yīng)以及由此產(chǎn)生的結(jié)果結(jié)構(gòu)的可能置換。一次性服務(wù)，物理尋址，單部分的響應(yīng)圖6顯示了一個(gè)測(cè)試和一個(gè)電控單元之間的通信流。圖6一次服務(wù)，物理尋址，單部分的響應(yīng)ECU接收物理地址服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向測(cè)試儀系統(tǒng)發(fā)送單部件響應(yīng)。發(fā)送到ECU的請(qǐng)求導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1）。ECU的響應(yīng)包含在結(jié)果對(duì)象（Response_1）中。一次性服務(wù)，物理尋址，多部分的反應(yīng)圖7顯示了一個(gè)測(cè)試和一個(gè)電控單元之間的通信流。圖7一次服務(wù)，物理尋址，多部分的反應(yīng)ECU接收物理地址服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向測(cè)試儀系統(tǒng)發(fā)送多部分響應(yīng)。發(fā)送到ECU的請(qǐng)求導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1）。ECU的響應(yīng)包含在結(jié)果對(duì)象（Response_1和Response_2）中。一次性服務(wù)，功能尋址，單部分的響應(yīng)圖8顯示了一個(gè)診斷的應(yīng)用及一套電控單元之間的通信流。圖8-一次服務(wù)，功能尋址，單部分的響應(yīng)ECU接收功能性地址的服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向應(yīng)用程序發(fā)送單部分響應(yīng)。發(fā)送給ECU的請(qǐng)求導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1）。ECU的響應(yīng)包含在結(jié)果對(duì)象（Response_1和Response_2）中。請(qǐng)注意，OTXDiagCom術(shù)語(yǔ)GetComChannelIdentifierFromResponse可用于識(shí)別與響應(yīng)相關(guān)的ECU（ComChannel）。一次性服務(wù)，功能尋址，多部分的反應(yīng)圖9顯示了一個(gè)診斷的應(yīng)用及一套電控單元之間的通信流。圖9一次服務(wù)，功能尋址，多部分的反應(yīng)ECU接收功能性地址的服務(wù)請(qǐng)求，這導(dǎo)致ECU向測(cè)試儀系統(tǒng)發(fā)送多部分響應(yīng)。發(fā)送給ECU的請(qǐng)求導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1）。ECU的響應(yīng)包含在該結(jié)果對(duì)象中（Response_1至Response_4）。重復(fù)服務(wù)，物理尋址，單部分的響應(yīng)圖10顯示了一個(gè)診斷應(yīng)用程序和一個(gè)電控單元之間的通信流。圖10重復(fù)的服務(wù)，物理尋址，單部分的響應(yīng)ECU接收重復(fù)的物理地址服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向每個(gè)請(qǐng)求的診斷應(yīng)用程序發(fā)送一個(gè)單一部分的響應(yīng)。發(fā)送給ECU的請(qǐng)求會(huì)導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1和Result_2）。ECU對(duì)重復(fù)請(qǐng)求的響應(yīng)包含在與引發(fā)響應(yīng)的執(zhí)行周期相對(duì)應(yīng)的結(jié)果對(duì)象中（第一個(gè)循環(huán)的Result_1，第二個(gè)循環(huán)的Result_2等等）。重復(fù)使用，功能尋址，單部分的響應(yīng)圖11顯示了一個(gè)診斷的應(yīng)用及一套電控單元之間的通信流。圖11重復(fù)的服務(wù)，功能尋址，單部分的響應(yīng)ECU接收到重復(fù)的功能編址服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向每個(gè)請(qǐng)求的診斷應(yīng)用程序發(fā)送一個(gè)單一部分的響應(yīng)。發(fā)送給ECU的請(qǐng)求導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1和Result_2）。ECU對(duì)重復(fù)請(qǐng)求的響應(yīng)包含在與引發(fā)響應(yīng)的執(zhí)行周期相對(duì)應(yīng)的結(jié)果對(duì)象中（第一個(gè)循環(huán)的Result_1，第二個(gè)循環(huán)的Result_2等等）。重復(fù)服務(wù)，物理尋址，多部分的反應(yīng)圖12顯示了一個(gè)診斷應(yīng)用程序和一個(gè)電控單元之間的通信流。圖12重復(fù)的服務(wù)，物理尋址，多部分的反應(yīng)ECU接收到重復(fù)的物理地址服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向每個(gè)請(qǐng)求的診斷應(yīng)用程序發(fā)送一個(gè)多部分響應(yīng)。發(fā)送給ECU的請(qǐng)求會(huì)導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1和Result_2）。ECU對(duì)重復(fù)請(qǐng)求的響應(yīng)包含在與引發(fā)響應(yīng)的執(zhí)行周期相對(duì)應(yīng)的結(jié)果對(duì)象中（第一個(gè)循環(huán)的Result_1，第二個(gè)循環(huán)的Result_2等等）。重復(fù)使用，功能尋址，多部分的反應(yīng)圖13顯示了一個(gè)診斷的應(yīng)用及一套電控單元之間的通信流。圖13重復(fù)的服務(wù)，功能尋址，多部分的反應(yīng)ECU接收重復(fù)的功能編址服務(wù)請(qǐng)求，這會(huì)導(dǎo)致ECU向每個(gè)請(qǐng)求的診斷應(yīng)用程序發(fā)送多部分響應(yīng)。發(fā)送給ECU的請(qǐng)求導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象（Result_1和Result_2）。ECU對(duì)重復(fù)請(qǐng)求的響應(yīng)包含在與引發(fā)響應(yīng)的執(zhí)行周期相對(duì)應(yīng)的結(jié)果對(duì)象中（第一個(gè)周期的Result_1，第二個(gè)周期的Result_2等等）。其他模式請(qǐng)注意，OTXDiagCom擴(kuò)展沒有明確支持周期性執(zhí)行診斷服務(wù)的功能，即向ECU提出一個(gè)請(qǐng)求導(dǎo)致ECU在沒有相應(yīng)請(qǐng)求的情況下循環(huán)發(fā)送對(duì)測(cè)試儀系統(tǒng)的響應(yīng)的服務(wù)。如果此類行為必須由OTXDiagCom運(yùn)行時(shí)系統(tǒng)進(jìn)行映射，則基本規(guī)則是OTX結(jié)果對(duì)象始終對(duì)應(yīng)于測(cè)試儀系統(tǒng)發(fā)出的一個(gè)請(qǐng)求。圖14顯示了一組ECU周期性向診斷應(yīng)用程序發(fā)送多部分響應(yīng)的理論情況。在OTX中，應(yīng)用程序發(fā)送的初始請(qǐng)求將導(dǎo)致創(chuàng)建相應(yīng)的結(jié)果對(duì)象，其中包含隨后收到的任何響應(yīng)。請(qǐng)注意，OTX不支持任何用于停止循環(huán)診斷服務(wù)的便利功能。需要ECU停止發(fā)送循環(huán)響應(yīng)的OTX作者必須手動(dòng)選擇并執(zhí)行相應(yīng)的診斷服務(wù)，以告知ECU停止。圖14一次服務(wù)，功能尋址，周期性的多部分的反應(yīng)7.2.4專用診斷數(shù)據(jù)類型由于OTX不支持結(jié)構(gòu)化數(shù)據(jù)類型的明確定義，因此需要提及DiagCom擴(kuò)展如何處理無處不在的診斷數(shù)據(jù)類型，如故障碼或凍結(jié)幀數(shù)據(jù)。看一下故障碼，通常來說，它只不過是一種結(jié)構(gòu)化數(shù)據(jù)類型，具有由SAEJ1979標(biāo)準(zhǔn)[SAEJ1979]定義的一組結(jié)構(gòu)參數(shù)，其他是OEM特定的參數(shù)。因此，OTX中的故障碼與其他任何結(jié)構(gòu)化參數(shù)一樣：當(dāng)從診斷服務(wù)的響應(yīng)中檢索代表故障碼的參數(shù)時(shí)，可以通過在故障碼參數(shù)上使用DiagCom術(shù)語(yǔ)GetParameterByPath來加入DTC的字段，并將名稱<path>元素中所需的子參數(shù)。例如，如果在診斷系統(tǒng)中，DTC的PID值被命名為“TroubleCode”以訪問該信息，則OTX序列看起來將如OTX示例中所示。樣品的OTX文件的例子”dtcexample.otx”7.3數(shù)據(jù)類型7.3.1概述由OTXDiagCom擴(kuò)展引入的所有數(shù)據(jù)類型都來自O(shè)TXCoreComplexType，這意味著它們定義了ISO13209第2部分定義的復(fù)雜數(shù)據(jù)類型。此處描述的元素是底層通信系統(tǒng)相應(yīng)對(duì)象的句柄。7.3.2語(yǔ)法所有的OTXdiagcom異常類型聲明的語(yǔ)法，如圖15所示。圖15-數(shù)據(jù)模型視圖：diagcom數(shù)據(jù)類型7.3.3語(yǔ)義概述OTXDiagCom數(shù)據(jù)類型沒有初始化部分（枚舉類型ResponseState和ResultState除外）;因此，這些不能被聲明為常量。comchannelComChannel是通信通道的句柄。它表示鏈接到一個(gè)特定通信端點(diǎn)的概念，例如，一個(gè)ECU模塊（物理尋址）或一組ECU模塊（功能尋址）。注：在基于MVCI/ODX的系統(tǒng)中，ComChannel句柄指向MCDDLogicalLink對(duì)象。diagserviceDiagService是表示診斷服務(wù)的對(duì)象的句柄，例如，一個(gè)閱讀錯(cuò)誤代碼的服務(wù)。DiagService句柄可用于使用ExecuteDiagService操作執(zhí)行診斷服務(wù)執(zhí)行（請(qǐng)參閱.1）。注：在基于MVCI/ODX的系統(tǒng)中，DiagService句柄代表MCDDiagComPrimitive對(duì)象。ResultResult是診斷服務(wù)對(duì)象結(jié)果的句柄。請(qǐng)參閱圖4，了解診斷服務(wù)的請(qǐng)求，結(jié)果，響應(yīng)和參數(shù)實(shí)例的結(jié)構(gòu)。注：對(duì)于基于MVCI/ODX的系統(tǒng)，結(jié)果句柄代表MCDResult對(duì)象。parametercontainerParameterContainer是一個(gè)抽象數(shù)據(jù)類型，它包含所有包含參數(shù)的數(shù)據(jù)類型，即Parameter和Message句柄。參數(shù)參數(shù)是診斷服務(wù)請(qǐng)求或響應(yīng)的參數(shù)對(duì)象的句柄。它可以表示一個(gè)簡(jiǎn)單或復(fù)雜的類型參數(shù)，即參數(shù)句柄可能指向一個(gè)簡(jiǎn)單的Integer或String參數(shù)，或者它可能對(duì)應(yīng)于參數(shù)結(jié)構(gòu)或參數(shù)列表，具體取決于底層通信系統(tǒng)的定義。請(qǐng)參閱圖4，了解診斷服務(wù)的請(qǐng)求，結(jié)果，響應(yīng)和參數(shù)實(shí)例的結(jié)構(gòu)。注：對(duì)于基于MVCI/ODX的系統(tǒng)，參數(shù)句柄代表MCDParameter對(duì)象（或其專門化的MCDRequestParameter和MCDResponseParameter）。消息Message元素是封裝實(shí)際ECU消息的抽象數(shù)據(jù)類型。響應(yīng)響應(yīng)是診斷服務(wù)結(jié)果的響應(yīng)對(duì)象的句柄。請(qǐng)參閱圖4，了解診斷服務(wù)的請(qǐng)求，結(jié)果，響應(yīng)和參數(shù)實(shí)例的結(jié)構(gòu)。注：對(duì)于基于MVCI/ODX的系統(tǒng)，響應(yīng)句柄表示MCDResponse對(duì)象。請(qǐng)求請(qǐng)求是診斷服務(wù)請(qǐng)求的句柄。請(qǐng)參閱圖4，了解診斷服務(wù)的請(qǐng)求，結(jié)果，響應(yīng)和參數(shù)實(shí)例的結(jié)構(gòu)。注：如果是基于MVCI/ODX的系統(tǒng)，請(qǐng)求句柄表示MCDRequest對(duì)象。resultstateResultState是描述結(jié)果狀態(tài)的枚舉類型。允許枚舉值列表定義如下：--all_failed：在物理尋址的情況下，功能組中的所有ECU（收聽同一功能地址）都無法應(yīng)答：請(qǐng)求的ECU未能應(yīng)答--all_invalid：在物理尋址的情況下，功能組中的所有ECU（監(jiān)聽相同的功能地址）返回了無效的答案：一個(gè)請(qǐng)求的ECU返回?zé)o效響應(yīng)--all_negative：在物理尋址的情況下，功能組中的所有ECU（監(jiān)聽相同的功能地址）返回否定響應(yīng)：一個(gè)請(qǐng)求的ECU返回否定響應(yīng)--all_positive：一個(gè)功能組中的所有ECU（監(jiān)聽相同的功能地址）在物理尋址的情況下返回肯定響應(yīng)：所請(qǐng)求的一個(gè)ECU返回肯定響應(yīng)--失?。汗δ芙M中的某些ECU（收聽同一功能地址）未能應(yīng)答--無效：功能組中的一些ECU（監(jiān)聽同一功能地址）返回?zé)o效響應(yīng)--負(fù)：某個(gè)功能組中的某些ECU（聽取相同的功能地址）返回否定響應(yīng)--陽(yáng)性：一個(gè)功能組中的一些ECU（監(jiān)聽相同的功能地址）返回了肯定的響應(yīng)重要-ResultState值可能作為比較操作數(shù)出現(xiàn)（參見ISO13209的第2部分關(guān)系操作）。對(duì)于這種情況，應(yīng)使用以下順序關(guān)系：ALL_FAILED<ALL_INVALID<ALL_NEGATIVE<ALL_POSITIVE<FAILED<INVALID<NEGATIVE<POSITIVE。重要-在ResultState值上應(yīng)用otx：ToString時(shí)，結(jié)果字符串應(yīng)該是枚舉值的名稱，例如OTX：的ToString（正）=“陽(yáng)性”。此外，應(yīng)用otx：ToInteger應(yīng)返回ResultStates枚舉中值的索引（最小索引為0）。其他轉(zhuǎn)換術(shù)語(yǔ)的行為未定義（參見ISO13209的第2部分）。ResultState是一個(gè)otx：SimpleType。其成員具有以下語(yǔ)義：<init>：resultstateliteral[0..1]此可選元素表示聲明時(shí)標(biāo)識(shí)符的硬編碼初始化值。--value：resultstates={all_failed|all_invalid|all_negative|all_positive|失敗的|無效|負(fù)|積極}[1]該屬性應(yīng)包含ResultStates枚舉中定義的值之一。重要提示-如果ResultState聲明未明確初始化（省略<init>元素），則默認(rèn)值為ALL_FAILED。responsestateResponseState是描述響應(yīng)狀態(tài)的枚舉類型。允許枚舉值列表定義如下：--失?。篍CU未能回答--無效：ECU返回了一個(gè)無效的響應(yīng)--負(fù)：返回的ECU的負(fù)面反應(yīng)--正：ECU返回一個(gè)積極的響應(yīng)重要-ResponseState值可能作為比較操作數(shù)出現(xiàn)（參見ISO13209的第2部分，關(guān)系操作）。對(duì)于這種情況，應(yīng)使用以下順序關(guān)系：FAILED<INVALID<NEGATIVE<POSITIVE重要-當(dāng)對(duì)ResponseState值應(yīng)用otx：ToString時(shí)，結(jié)果字符串應(yīng)該是枚舉值的名稱，例如OTX：的ToString（正）=“陽(yáng)性”。此外，應(yīng)用otx：ToInteger應(yīng)返回ResponseStates枚舉中的值的索引（最小索引為0）。其他轉(zhuǎn)換術(shù)語(yǔ)的行為未定義（參見ISO13209的第2部分）。ResponseState是一個(gè)otx：SimpleType。其成員具有以下語(yǔ)義：<init>：responsestateliteral[0..1]此可選元素表示聲明時(shí)標(biāo)識(shí)符的硬編碼初始化值。--value：responsestates={FALIED|INVALID|NEGATIVE|POSITIVE}[1]該屬性應(yīng)包含ResponseStates枚舉中定義的值之一。重要-如果ResponseState聲明沒有明確地初始化（省略<init>元素），默認(rèn)值應(yīng)該是FAILED。7.4異常7.4.1概述本節(jié)中引用的所有元素均來自ISO13209第2部分定義的OTX核心異常類型。它們表示由OTXDiagCom擴(kuò)展添加的全套例外。7.4.2語(yǔ)法所有的OTXdiagcom異常類型聲明的語(yǔ)法，如圖16所示。圖16-數(shù)據(jù)模型視圖：diagcom異常7.4.3變更請(qǐng)求的語(yǔ)義概述由于所有OTXDiagCom異常類型都是沒有初始化部分的隱式異常，因此不能將其聲明為常量。diagcomexceptionDiagComException是DiagCom擴(kuò)展中所有異常的超類。如果本節(jié)其余部分描述的更具體的異常類型不適用于手頭的問題，則應(yīng)使用DiagComException。ambiguoussemanticexception如果有多個(gè)對(duì)象具有與DiagCom活動(dòng)相匹配的相同語(yǔ)義屬性，則會(huì)引發(fā)AmbiguousSemanticException。這個(gè)異常可以通過以下操作/術(shù)語(yǔ)拋出：--creatediagservicebysemantic--getparameterbysemantic--setparametervaluebysemanticunknowntargetexception如果DiagCom操作或術(shù)語(yǔ)引用底層通信系統(tǒng)中不可用或未定義的對(duì)象，則會(huì)拋出UnknownTargetException。lossofcomexception如果在服務(wù)執(zhí)行過程中出現(xiàn)通信故障，則拋出LossOfComException。以防連接車輛的電纜被拔下。unknownresponseexception如果執(zhí)行診斷服務(wù)時(shí)返回了未由ExecuteDiagService操作映射的響應(yīng)（請(qǐng)參閱.1），則會(huì)引發(fā)此異常。unknowncomchannelexception如果在使用GetComChannelNameFromResponse項(xiàng)（見.4）時(shí)響應(yīng)句柄無法鏈接到通信通道，則會(huì)拋出此異常。invalidstateexception如果在重復(fù)執(zhí)行的DiagService上使用StartRepeatedExecution操作，并且在重復(fù)執(zhí)行的DiagService上使用StopRepeatedExecution操作，或者在當(dāng)前正在重復(fù)執(zhí)行的DiagService上使用SetRepetitionTime操作的情況下，將拋出此異常。incompleteparameterizationexception如果執(zhí)行的DiagService不是所有的請(qǐng)求參數(shù)都沒有設(shè)置默認(rèn)值，那么就會(huì)拋出這個(gè)異常。7.5訪問變量7.5.1概述按照ISO13209第2部分的規(guī)定，OTX擴(kuò)展應(yīng)為它們定義的每種數(shù)據(jù)類型定義一個(gè)變量訪問類型（包含的異常類型）。所有變量訪問類型都來自O(shè)TX核心變量擴(kuò)展接口。以下指定為DiagCom擴(kuò)展定義的所有變量訪問類型。7.5.2語(yǔ)法圖17顯示的diagcom擴(kuò)展的變量訪問類型的語(yǔ)法。圖17-數(shù)據(jù)模型視圖：diagcom變量訪問類型7.5.3語(yǔ)義所有的變量訪問類型的一般語(yǔ)義適用。詳情請(qǐng)參閱2部分ISO13209。7.6操作7.6.1概述圖18所示的所有元素?cái)U(kuò)展了ISO13209第2部分定義的otx：ActionRealisation擴(kuò)展接口。圖18-數(shù)據(jù)模型視圖：diagcom行為概述7.6.2comchannel有關(guān)的操作描述本節(jié)中描述的所有操作都會(huì)影響ComChannel句柄上的更改。語(yǔ)法圖19顯示了DiagCom擴(kuò)展的所有與ComChannel相關(guān)的ActionRealisation類型的語(yǔ)法。圖19-數(shù)據(jù)模型視圖：comchannel有關(guān)的操作語(yǔ)義.1identifyandselectvariantIdentifyAndSelectVariant操作應(yīng)用于告知通信后端，以識(shí)別在特定通信通道運(yùn)行時(shí)存在的ECU變體。如果可以識(shí)別ECU變量，則通信通道將切換為指向該特定變量。本標(biāo)準(zhǔn)不能對(duì)OTX運(yùn)行時(shí)使用的車輛通信組件是否支持ECU變體識(shí)別的概念或有關(guān)通信組件行為的假設(shè)進(jìn)行假設(shè)。DiagCom擴(kuò)展的相關(guān)部分基于以下假設(shè)：--ECU的通信通道與描述該ECU的特定變體的診斷行為的數(shù)據(jù)集相關(guān)聯(lián)。--車輛通信組件能夠明確地執(zhí)行到ECU的通信信道上的ECU變體識(shí)別操作。--執(zhí)行變型識(shí)別所需的邏輯和數(shù)據(jù)是車輛通信組件固有的，即通信組件不需要額外的外部信息來執(zhí)行ECU變型識(shí)別。--識(shí)別出ECU變體后，車輛通信組件能夠明確將通信通道與具有針對(duì)該ECU變體的特定數(shù)據(jù)集的ECU相關(guān)聯(lián)，從而有效地將通信通道從舊變體數(shù)據(jù)集切換到新變體數(shù)據(jù)集。IdentifyAndSelectVariant操作通知運(yùn)行時(shí)系統(tǒng)在提供的通信通道上執(zhí)行變量識(shí)別操作，然后將與該通道關(guān)聯(lián)的數(shù)據(jù)集切換到適合新識(shí)別變體（如果有的話）的數(shù)據(jù)集。請(qǐng)參考GetComChannel術(shù)語(yǔ)（見.3），它告訴運(yùn)行系統(tǒng)創(chuàng)建一個(gè)新的通信通道，立即在新的通信通道上執(zhí)行變量識(shí)別操作，然后將與該通道相關(guān)的數(shù)據(jù)集切換到一個(gè)適合新確定的變體（如果有的話）。注：如果使用ODX/MVCI系統(tǒng)，變型識(shí)別和選擇的確切語(yǔ)義由ISOODX和MVCI標(biāo)準(zhǔn)規(guī)定。以下的語(yǔ)義identifyandselectvariant行動(dòng)的成員：--<comchannel>：comchannelvalue[1]該元素包含通信通道，該通道應(yīng)用于識(shí)別通信通道連接的ECU的實(shí)際變體。拋出：--lossofcomexception如果在變型識(shí)別過程中與ECU的通信中斷。.2closecomchannel操作CloseComChannel告訴OTX運(yùn)行系統(tǒng)，可以關(guān)閉到ECU的通信信道并關(guān)閉相關(guān)的資源。請(qǐng)注意，通過OTX序列使用CloseComChannel操作僅表明不再需要該通道-這取決于特定運(yùn)行時(shí)系統(tǒng)的實(shí)現(xiàn)，無論它實(shí)際上是否釋放所有資源并在此時(shí)關(guān)閉通道。如果診斷序列在通過CloseComChannel動(dòng)作釋放后使用ComChannel句柄，則運(yùn)行時(shí)系統(tǒng)應(yīng)拋出otx：InvalidReferenceException。closecomchannel行動(dòng)的成員有以下的語(yǔ)義：--<comchannel>：comchannelvariable[1]該元件包括應(yīng)關(guān)閉的通信信道。7.6.3comparameter有關(guān)的操作描述本節(jié)中描述的所有操作都會(huì)更改ComChannel句柄的通信參數(shù)設(shè)置。例如，CAN超時(shí)或波特率設(shè)置通常被建模為通信參數(shù)。語(yǔ)法圖20顯示了DiagCom擴(kuò)展的所有與參數(shù)處理相關(guān)的ActionRealisation類型的語(yǔ)法。圖20-數(shù)據(jù)模型視圖：通信參數(shù)處理語(yǔ)義.1setcomparameterSetComParameter操作將用于更改通信后端使用的通信參數(shù)的值。例如，可以使用SetComParameter節(jié)點(diǎn)設(shè)置總線超時(shí)或波特率。注：如果使用ODX/MVCI系統(tǒng)進(jìn)行車輛通信，可以設(shè)置的通信參數(shù)名稱和數(shù)據(jù)類型由DPDUAPI/ODX通信參數(shù)規(guī)范定義。setcomparameter行動(dòng)的成員有以下的語(yǔ)義：--<comchannel>：comchannelvalue[1]該元素包含通信參數(shù)應(yīng)修改的通信信道。--<name>：OTX：stringterm[1]該元素指定了應(yīng)該改變的通信參數(shù)的名稱。--<value>：OTX：term[1]該元素指定了應(yīng)設(shè)置的新通信參數(shù)值。拋出：--unknowntargetexception如果不存在具有指定名稱的通信參數(shù)。--OTX：typemismatchexception如果指定的數(shù)量類型與要設(shè)置的通訊參數(shù)的數(shù)據(jù)類型不匹配。.2setcomplexcomparameterSetComplexComParameter操作是SetComParameter的增強(qiáng)變體。這些操作之間的區(qū)別在于，在這種情況下可以使用復(fù)雜的數(shù)據(jù)類型。注意例如，在基于ODX/MVCI的系統(tǒng)中，復(fù)雜的通信參數(shù)數(shù)據(jù)類型用于定義功能尋址用例的響應(yīng)ID列表。setcomplexcomparameter行動(dòng)的成員有以下的語(yǔ)義：--<comchannel>：comchannelvalue[1]該元素包含通信參數(shù)應(yīng)修改的通信信道。--<parameter>：parameterterm[1]該元素包含應(yīng)設(shè)置的參數(shù)結(jié)構(gòu)。拋出：--OTX：typemismatchexception如果指定的<parameter>元素與要設(shè)置的通信參數(shù)不匹配。7.6.4diagservice有關(guān)的操作描述本節(jié)中描述的操作用于設(shè)置和執(zhí)行實(shí)際的ECU通信。語(yǔ)法圖21顯示了與診斷服務(wù)配置和執(zhí)行相關(guān)的DiagCom擴(kuò)展的所有ActionRealisation類型的語(yǔ)法。圖21-數(shù)據(jù)模型視圖：diagservice有關(guān)的行動(dòng)語(yǔ)義.1executediagserviceExecuteDiagService操作應(yīng)用于執(zhí)行診斷車輛通信。OTX序列中的ExecuteDiagService節(jié)點(diǎn)向運(yùn)行系統(tǒng)指出，此時(shí)服務(wù)請(qǐng)求應(yīng)發(fā)送給一個(gè)或多個(gè)ECU，并且可能必須向OTX序列提供任何相關(guān)的響應(yīng)。為了做到這一點(diǎn)，ExecuteDiagService操作需要兩組信息：A）要使用的DiagServiceB）將OTX值映射到服務(wù)請(qǐng)求參數(shù)的定義以及服務(wù)響應(yīng)參數(shù)的值返回到OTX變量。根據(jù)服務(wù)的參數(shù)結(jié)構(gòu)在OTX創(chuàng)作時(shí)是已知還是必須在運(yùn)行時(shí)動(dòng)態(tài)評(píng)估，可以通過兩種方式向/從服務(wù)參數(shù)寫入/讀取值。--內(nèi)聯(lián)映射：如果服務(wù)的參數(shù)結(jié)構(gòu)是靜態(tài)的（在創(chuàng)作時(shí)已知），則ExecuteDiagService操作可用于通過其<RequestParameters>和<ResponseParameters>成員內(nèi)聯(lián)定義請(qǐng)求和響應(yīng)參數(shù)映射。將在本條的其余部分給出詳細(xì)的解釋。請(qǐng)注意，內(nèi)聯(lián)映射方法僅適用于一個(gè)ECU對(duì)診斷服務(wù)有一個(gè)響應(yīng)的情況。如果多個(gè)ECU響應(yīng)服務(wù)請(qǐng)求和/或ECU響應(yīng)不止一次，內(nèi)聯(lián)映射將只與第一個(gè)結(jié)果中的第一個(gè)響應(yīng)有關(guān)。--動(dòng)態(tài)響應(yīng)：如果服務(wù)的參數(shù)結(jié)構(gòu)在運(yùn)行時(shí)是動(dòng)態(tài)的（在創(chuàng)作時(shí)未知），則可以使用由DiagCom擴(kuò)展定義的術(shù)語(yǔ)來通過明確的OTX語(yǔ)句評(píng)估請(qǐng)求和響應(yīng)參數(shù)結(jié)構(gòu)。這樣，有可能例如通過包含結(jié)構(gòu)列表的服務(wù)響應(yīng)進(jìn)行循環(huán)。響應(yīng)參數(shù)結(jié)構(gòu)在運(yùn)行時(shí)以這種方式變化的診斷服務(wù)的示例是由UDS協(xié)議[ISO14229]定義的讀取DTC服務(wù)。由于它在服務(wù)執(zhí)行時(shí)返回了ECU中存在的DTC的數(shù)量，因此在創(chuàng)作時(shí)無法確切知道在運(yùn)行時(shí)服務(wù)的響應(yīng)中將包含多少或哪些DTC。如果診斷服務(wù)產(chǎn)生復(fù)雜的結(jié)果結(jié)構(gòu)，則還需要手動(dòng)評(píng)估結(jié)果。這可能發(fā)生在兩種情況下，第一種是診斷服務(wù)，其中一項(xiàng)服務(wù)執(zhí)行導(dǎo)致來自ECU的多個(gè)循環(huán)響應(yīng)。在這種情況下，診斷服務(wù)將有多個(gè)與之相關(guān)的結(jié)果-每個(gè)ECU在時(shí)間線上的響應(yīng)都有一個(gè)。單個(gè)結(jié)果必須通過中定義的術(shù)語(yǔ)進(jìn)行訪問和評(píng)估。第二種情況是當(dāng)一個(gè)診斷請(qǐng)求導(dǎo)致來自不同ECU的多個(gè)響應(yīng)時(shí)，即當(dāng)使用功能性尋址時(shí)。在這種情況下，有一個(gè)與診斷服務(wù)相關(guān)的結(jié)果，其中包含多個(gè)響應(yīng)-每個(gè)響應(yīng)功能請(qǐng)求的ECU都有一個(gè)響應(yīng)。必須使用中定義的術(shù)語(yǔ)來訪問和評(píng)估個(gè)人響應(yīng)。請(qǐng)注意，從理論上講，這兩種情況也可以合并-可以想象使用功能性尋址的重復(fù)發(fā)送的診斷服務(wù)，產(chǎn)生包括多個(gè)響應(yīng)的多個(gè)結(jié)果。更多細(xì)節(jié)請(qǐng)參考。下列規(guī)則適用于在executediagservice元素內(nèi)聯(lián)映射參數(shù)：--允許的OTX數(shù)據(jù)類型用于參數(shù)映射：RequestParameter和ResponseParameter映射僅允許引用OTX簡(jiǎn)單類型，OTXByteField，列表和映射類型以及OTX數(shù)量類型。--ExecuteDiagService的響應(yīng)映射和異常行為：通常，ExecuteDiagService操作可以包含多個(gè)響應(yīng)參數(shù)序列-一個(gè)用于OTX序列感興趣的每個(gè)響應(yīng)。如果在運(yùn)行時(shí)遇到一個(gè)未由ExecuteDiagService節(jié)點(diǎn)中的<responseParameters>元素表示的ECU響應(yīng)，則會(huì)導(dǎo)致UnknownResponseException。為了能夠確定問題的性質(zhì)，在這種情況下，可以使用術(shù)語(yǔ)GetDiagServiceFromException（請(qǐng)參閱.7）檢索已從UnknownResponseException執(zhí)行的DiagService對(duì)象，然后通過查找來分析它的響應(yīng)結(jié)構(gòu)在響應(yīng)的PDU中（參見.4中的術(shù)語(yǔ)GetPdu），或者使用適當(dāng)?shù)腄iagCom術(shù)語(yǔ)通常的遍歷方法。--如前面段落中所述，ExecuteDiagService節(jié)點(diǎn)可以通過提供具有適當(dāng)響應(yīng)名稱的<responseParameters>元素來自由定義它感興趣的服務(wù)的哪些響應(yīng)。請(qǐng)注意，<responseParameters>元素可以為空，但不要求定義實(shí)際響應(yīng)參數(shù)的任何映射。這允許診斷序列作者對(duì)ExecuteDiagService操作的行為進(jìn)行細(xì)粒度控制：在遇到意外/不需要的響應(yīng)時(shí)，ExecuteDiagService操作是否應(yīng)該拋出異常僅僅是提供可能的空響應(yīng)參數(shù)針對(duì)有問題的答案進(jìn)行映射。例如，如果診斷序列作者只對(duì)正面回答感興趣并且認(rèn)為發(fā)生否定回答是錯(cuò)誤，則他應(yīng)該只提供正面回答名稱的映射。如果負(fù)面響應(yīng)的發(fā)生不被認(rèn)為是錯(cuò)誤，并且不會(huì)導(dǎo)致UnknownResponseException，他也可以簡(jiǎn)單地為負(fù)面響應(yīng)提供映射，如果他不關(guān)心實(shí)際響應(yīng)參數(shù)，則可以為空。原則適用于響應(yīng)的任何組合（正面，負(fù)面，全局負(fù)面等）-只需提供適當(dāng)?shù)?lt;responseParameters>元素，作者就可以控制響應(yīng)的發(fā)生是否應(yīng)被視為UnknownResponseException（無映射）或不（映射存在）。注：如果OTXDiagCom擴(kuò)展功能與ODX/MVCI系統(tǒng)一起使用，<responseParameters>元素的名稱是相應(yīng)ODX數(shù)據(jù)中響應(yīng)的SHORT-NAME（正數(shù)，局部負(fù)數(shù)，全局負(fù)數(shù)）。如果DiagCom擴(kuò)展與不同的通信后端一起使用，該通信后端沒有服務(wù)的多個(gè)響應(yīng)概念/沒有響應(yīng)名稱，則可以使用類似的內(nèi)部命名約定將OTX響應(yīng)參數(shù)映射為正面或負(fù)面響應(yīng)。ExecuteDiagService操作還可以配置為告訴通信后端，如果通信后端和要執(zhí)行的特定診斷服務(wù)支持該概念，則尋址的ECU應(yīng)禁止發(fā)送肯定響應(yīng)。如果屬性suppressPositiveResponse的值設(shè)置為true，則會(huì)發(fā)生這種情況。如果從ExecuteDiagService中省略該屬性，則默認(rèn)值為false。executediagservice行動(dòng)的成員有以下的語(yǔ)義：--executeasync：XSD：boolean={false|true}[0..1]該選項(xiàng)告訴通信后端使此診斷服務(wù)執(zhí)行非阻塞。這意味著如果executeAsync設(shè)置為true，則OTX執(zhí)行流將立即轉(zhuǎn)到下一個(gè)Action，而不等待ExecuteDiagService操作的結(jié)果。因此，由此ExecuteDiagService操作定義的任何響應(yīng)參數(shù)映射都將被忽略：由于執(zhí)行ExecuteDiagService節(jié)點(diǎn)時(shí)診斷服務(wù)執(zhí)行不一定完成，因此在這點(diǎn)上，靜態(tài)映射以包含服務(wù)響應(yīng)的OTX變量不能包含值。executeAsync功能的使用始終要求OTX序列執(zhí)行動(dòng)態(tài)響應(yīng)解釋。OTX序列可以使用DiagServiceEventSource術(shù)語(yǔ)（請(qǐng)參閱.1）在異步執(zhí)行的診斷服務(wù)的新結(jié)果到達(dá)時(shí)收到通知。--suppresspositiveres