ISO 13209-3-OTX擴展標準及需求

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