ISO 13209-3-OTX扩展标准及需求

道路车辆--开放测试序列交换格式（OTX）—3部分：标准的扩展和要求目录前言 8介绍 91范围 102规范性参考文献 113术语，定义和术语缩写 123.1术语和定义 123.1.1自定义屏幕 123.1.2对话框 123.1.3ECOS的测量装置 123.1.4模式对话框 123.1.5非模式的屏幕 123.1.6测试仪 123.1.7文本ID 123.2术语缩写 134要求 144.1需求定义的基本原则 144.2需求优先级 144.3需求列表 145扩展的概述 185.1概述 185.2依赖性 185.3OTX扩展的基本特征 196OTX时间日期扩展 226.1介绍 226.2术语 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专用诊断数据类型 337.3数据类型 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术语 567.7.1概述 567.7.2comchannel相关术语 577.7.3diagservice相关术语 617.7.4请求相关的术语 657.7.5结果相关的术语 667.7.6响应相关的术语 697.7.7参数相关的术语 727.7.8comparam相关术语 777.7.9事件相关的术语 818OTX诊断数据浏览扩展 838.1介绍 838.2数据类型 838.2.1概述 838.2.2语法 838.2.3语义 848.3变量访问 858.3.1概述 858.3.2语法 858.3.3语义 858.4术语 868.4.1概述 868.4.2语法 868.4.3语义 869OTX事件处理扩展 919.1介绍 919.2数据类型 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术语 969.5.1概述 969.5.2事件 979.5.3事件源项 989.5.4事件属性术语 10110OTXFLASH扩展 10410.1介绍 10410.2数据类型 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术语 11210.6.1概述 11210.6.2Flash工作相关的术语 11310.6.3Flash会话相关的术语 11610.6.4刷写块相关的术语 11910.6.5刷写块段相关的术语 12410.6.6安全相关术语 12610.6.7自己识别相关术语 12910.6.8枚举相关术语 13111OTXHMI扩展 13311.1介绍 13311.1.1概述 13311.1.2对话框 13311.1.3自定义屏幕 13411.1.4自定义屏幕使用的例子 13511.2数据类型 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术语 15111.6.1概述 15111.6.2语法 15211.6.3语义 15311.7特征 15611.7.1概述 15611.7.3语义 15612OTXi18n扩展 15912.1介绍 15912.2数据类型 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术语 16212.5.1概述 16212.5.2区域设置相关的术语 16312.5.3翻译相关术语 16412.5.4量相关的术语 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术语 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数据类型 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术语 19114.5.1概述 19114.5.2语法 19114.5.3语义 19115OTX数学扩展 19315.1介绍 19315.2术语 19315.2.1概述 19315.2.2语法 19315.2.3语义 19316OTX测量扩展 19616.1介绍 19616.2数据类型 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术语 20416.7.1概述 20416.7.2测量相关的术语 20516.7.3事件相关的术语 20817OTX数量扩展 21017.1介绍 21017.2数据类型 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术语 21617.5.1概述 21617.5.2数量和单位相关术语 21718OTXStringUtil扩展 22418.1介绍 22418.2数据类型 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术语 22718.5.1概述 22718.5.2语法 22718.5.3语义 228前言ISO（国际标准化组织）是一个世界性的国家标准机构联合会（ISO成员机构）。制定国际标准的工作通常由ISO的进行技术委员会来准备。对建立技术委员会的主题感兴趣的每个成员团体均有权参加该委员会的代表。国际组织、政府和机构与ISO联系的非政府组织也参与了这项工作。ISO与国际电工委员会（IEC）就电工标准化的所有事宜密切合作。国际标准是根据ISO/IEC指令第2部分给出的规则起草的。技术委员会的主要任务是制定国际标准。国际标准草案由技术委员会通过的发给各成员团体投票表决。作为国际标准发布需要至少75％的成员机构投票批准。注意：本文件中的某些内容可能涉及到一些专利权问题。ISO不负责识别任何这样的专利权问题。ISO13209-1由技术委员会ISO/TC22，道路车辆，小组委员会SC3，电气和电子设备制定。ISO13209由以下几部分组成，标题为道路车辆-开放测试序列交换格式（OTX）：--1部分：一般信息和使用案例--2部分：核心数据模型的规范和要求--3部分：标准的扩展规范和要求介绍无论何时，正在被诊断、测试、编程或下线的测试设备或具有诊断性质的功能都会使用诊断测试序列号。测试序列定义了用户（即车间或装配线的工作人员）、诊断应用（测试设备）和车辆通信接口以及任何计算必须执行的决定之间的相互作用的关系。测试序列提供了一种手段来定义互动，引导诊断或类似的测试逻辑。如今，汽车行业主要依赖于纸质文件或专有的创作环境来记录和实施特定测试应用程序的测试序列。建立工程、装配线或服务的诊断测试应用程序的作者需要实现所需的手动测试序列，它由非均匀的测试序列文件支持，最有可能为每个具体的测试应用程序创作用例和格式。如果过程和工具支持OTX概念，这多余的努力可以大大减少。ISO13209为人类和机器的可读的诊断测试序列描述提出一个开放的、标准化的格式。该格式支持在电子系统供应商、车辆制造商和服务经销商或维修商之间传输诊断测试序列的要求逻辑。ISO13209-2的这一部分代表了OTX格式基础的要求和技术规范，即“OTX核心”。该核心描述了每个OTX文档的基本结构。这包括描述测试序列逻辑所需的所有控制结构的详细数据模型定义，还包括测试序列逻辑嵌入其中的外部包络文档结构的定义。为了实现可扩展性，核心还包含定义明确的扩展点，允许单独定义其他OTX功能-无需更改核心数据模型。ISO13209的这一部分使用ISO13209-2中描述的扩展机制规则扩展了Core的一些附加功能。本文定义的扩展包括允许与车辆的诊断接口进行诊断通信、刷写、执行诊断任务、控制测量设备、国际化、使用物理单元、访问环境、通过人机界面（HMI）和其他实用扩展。1范围ISO13209的这一部分定义了开放测试序列交换（OTX）扩展要求和数据模型规范。这些要求源自ISO13209-1中描述的用例。它们在第4章中列出。数据模型规范旨在对OTX扩展的所有功能进行详尽的定义，这些扩展已经实现以满足要求。ISO13209的这一部分为每个扩展的语法实体建立了规则。每个这些语法实体都附带有语义规则，这些语义规则决定如何解释包含扩展功能的OTX文档。语法规则由UML类图和XML模式提供，而语义由UML活动图和散文定义给出。2规范性参考文献以下参考文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注明引用的版本。凡是不注日期的引用文件，其最新版本（包括所有修改单）适用于本文件。ISO／IEC646:1991，信息技术-用于信息交换的ISO7位编码字符集ISO8601:2004，数据元素和交换格式-信息交换-日期和时间表示ISO／IEC8859-1:1998，信息技术-8位单字节编码图形字符集-第1部分：拉丁字母编号1ISO/IEC10646，信息技术-通用多字节编码字符集（UCS）ISO／IEC13209-1，道路车辆-开放测试序列交换格式（OTX）-第1部分：一般信息和用例ISO／IEC13209-2，道路车辆-开放测试序列交换格式（OTX）-第2部分：核心数据模型规范和要求ISO／IEC19501:2005，信息技术-开放分布式处理的统一建模语言（UML）版本1.4.2ISO14229（所有部分），道路车辆-统一诊断服务（UDS）ISO22900（所有部分），道路车辆-模块化车辆通信接口（MVCI）ISO22901（所有部分），道路车辆-开放诊断数据交换（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术语，定义和术语缩写3.1术语和定义就本文件而言，ISO13209-1，ISO13209-2及以下条款中给出的术语和定义适用。3.1.1自定义屏幕屏幕上显示由测试序列作者定义的属性和字段3.1.2对话框屏幕上带有可以从OTX序列中设置或读取的预定义属性和字段3.1.3ECOS的测量装置广泛使用的嵌入式系统用于测试消费者的电流和电压曲线3.1.4模式对话框对话框阻止流程执行，直到用户将其解除为止3.1.5非模式的屏幕异步，非阻塞屏幕，在测试序列执行继续时仍然显示3.1.6测试仪通过车辆通信接口连接到车辆的计算机系统，运行诊断应用程序用3.1.7文本ID一个包含本地化字符串翻译词典数据库输入的字符串引用3.2术语缩写API应用编程接口DTC诊断故障代码ECOS电气检查系统ECU电子控制单元GUI图形用户界面HMI人机接口IFD通用接口定义（OTX扩展）NOP无操作指令执行OEM原始设备制造商OTX开放测试序列交换PDU协议数据单元UI用户界面UML统一建模语言VCI车辆通信接口XML可扩展标记语言XSDXML架构定义4要求4.1需求定义的基本原则确定基本原则作为定义OTX要求的指导原则：a）OTX要求规定了OTX数据模型和格式应满足的条件。b）提供诊断测试程序的所有利益相关者（系统供应商，原始设备制造商，工具供应商）均应执行并遵守本标准的要求。OTX文件的内容和信息的质量是发件人的责任。4.2需求优先级以下每项要求都包含一个可以设置为SHALL或SHOULD的优先级属性。--SHALL：该要求代表了利益相关方定义的特征，缺少这些特征会导致缺乏其他方式无法补偿的缺陷。--SHOULD：如果需求定义特征在数据模型中没有或者没有完全实现，它不会导致缺陷，因为可以使用数据模型中的其他功能来规避这一点。4.3需求列表Extensions_R01–读取当前的日期和时间优先级：SHALL原理：它可以检索当前的日期和时间。描述：前的日期和时间应该以适合于计算两个日期之间的持续时间的方式来访问，但也可以用于生成人类可读的日期形式。Extensions_R02–支持但不需要ODX优先级：SHALL原理：为了与车辆ECU通信，应支持但不强制使用ODX。描述：任何车辆通信相关的扩展数据模型都应与ODX功能的有用子集相匹配。Extensions_R03–刷写会话处理优先级：SHALL原理：应提供功能来浏览和选择刷写会话。描述：刷写扩展应提供按方向和名称选择的可能性。Extensions_R04–低水平的flash数据访问优先级：SHALL原理：应提供用于浏览和从刷写环境（下载容器）中选择数据的功能。描述：数据应聚集在块和段中。应该支持像ODXFlash这样的现代数据格式所使用的安全功能。Extensions_R05–刷写数据存储优先级：SHALL原理：上传的Flash数据应存储在本地存储器中。描述：对于刷写数据上传，用于刷写的OTX扩展应提供以选定格式存储的功能。Extensions_R06–使开发人员能够使用OTX代替ODXJava作业优先级：SHALL原理：应提供功能来模拟OTX序列的ODXJava作业描述：一作业扩展应使开发人员能够将OTX序列作为ODXJava作业运行。应支持SingelEcuJob，SecurityAccessJob和FlashJob。Extensions_R07–提供与汽车ECU通信诊断手段优先级：SHALL原理：应提供与车辆ECU系统进行诊断通信的功能。描述：应该有一个OTX扩展，它允许配置和执行车辆ECU的诊断服务。应该可以建立到特定ECU的通信通道，配置发送到ECU的诊断服务的请求参数并分析ECU的响应参数。沟通渠道，诊断服务和参数的描述应以人类可读和符号的方式进行;任何现有的诊断符号到二进制映射（例如ODX）都应该被支持。发送诊断服务和接收的实际功能应通过测试序列和车辆之间的接口（例如MCD3DAPI和MVCI）提供。Extensions_R08–提供浏览诊断数据的方法优先级：SHALL原理：应提供功能来从诊断应用程序的静态诊断数据库中读取信息。描述：应提供OTX扩展，它允许从诊断数据库中读取静态信息，例如，可用的通信信道，用于通信信道的诊断服务或用于诊断服务的参数。Extensions_R09–使开发人员处理事件优先级：SHALL原理：应提供功能性，允许OTX测试序列对明确定义的事件作出反应。描述：OTX扩展应允许开发人员配置测试序列，以便它可以等待某些事件发生（例如，当定时器到期，变量值发生变化或从用户界面接收用户输入时等）。应该有办法获得关于事件的进一步信息，例如它是什么类型的事件，以及关于特定事件的附加信息。Extensions_R10–提供人机界面功能的手段优先级：SHALL原理：应提供功能，允许OTX测试序列以双向方式与用户进行通信。描述：需要一个OTX扩展，允许从用户界面发送和接收信息（例如，带有输入控件的GUI窗口）。该扩展不应提供明确配置信息的图形布局的手段;相反，它只能为通信数据本身提供一个双向接口。Extensions_R11–使开发人员能够配置本地化测试序列优先级：SHALL原理：在配置OTX测试序列时，应支持测试序列开发人员，这些测试序列准备好翻译成不同的语言。描述：需要OTX扩展，允许开发人员通过文本ID概念访问同义词库数据库。开发人员应支持将文本ID转换为为运行时系统或其他语言配置的语言（就运行系统而言）的功能。同义词库数据库本身不应该是标准的一部分。通用方法应支持不同类型的叙词表数据库。Extensions_R12–提供记录日志优先级：SHALL原理：应该可以将日志消息写入日志记录资源。描述：需要OTX扩展，允许将日志消息写入日志记录资源;消息应根据严重程度进行过滤。Extensions_R13–支持测量设备优先级：SHALL原理：制造和售后车间中的测量设备应可通过适当的功能进行访问。描述：需要OTX扩展，允许从测量设备接收测量值。应该有一个抽象层允许使用任何种类的测量设备。Extensions_R14–支持物理单元优先级：SHALL原理：需要功能性，允许用单位处理物理值描述：需要一个OTX扩展来描述物理量。该扩展应便于在这些物理量上进行常用计算，例如，物理值从一个单位系统到另一单位系统的转换（例如，以千米或英里表示距离等）。它还应允许对数量进行基本的数学运算，而不要求开发人员明确关心该单元（例如，应该可以直接计算10m+2km）。Extensions_R15–支持增强的字符串操作优先级：SHALL原理：OTX核心字符串操作应通过额外的常用字符串操作进行扩展。描述：需要一个OTX扩展来描述附加的字符串操作，这将有助于计算字符串值。Extensions_R16–支持基本的数学函数优先级：SHALL原理：OTX核心的算术运算应该通过附加的数学函数来扩展。描述：需要一个OTX扩展，它描述了一些附加的数学函数，这些函数在某些诊断应用中是需要的（例如三角函数和对数函数等）。5扩展的概述5.1概述本文件描述了数据模型版本“1.0.0”5.2依赖性图1显示了一个UML包图[ISO/IEC19501]，描述了全套OTX扩展（以及OTXCore）以及它们之间的导入依赖关系。OTX扩展使用或扩展OTXCore中定义的类型。因此，所有扩展都基于ISO13209第2部分规定的OTX核心数据模型（直接或间接）。除了OTX核心，OTX事件处理，OTXDiagCom和OTX数量扩展也起着核心作用;此处定义的类型由其他OTX扩展使用或扩展。 图1-概述：OTX架构的依赖关系重要-OTXCore是任何OTX应用程序的先决条件，应始终得到全面支持。相比之下，OTX应用程序无需支持本标准中规定的所有扩展。受支持的扩展集可能因应用领域而异。但是，支持导入其他扩展的扩展的OTX应用程序也应支持这些扩展。这保证了支持的扩展集与依赖关系一致。图1还显示了辅助软件包OTXDiagMetaData以及OTXAppInfo。这些软件包不是OTX扩展;它们支持OTX创作系统，只有在创作时才会使用附加数据。OTX测试序列运行时不需要这些信息。有关DiagMetaData的辅助信息，请参阅附录C.有关AppInfo的辅助信息，请参阅ISO13209的第2部分。5.3OTX扩展的基本特征表1提供了有关所有OTX扩展及其基本特性的概述。扩展（模式文件）摘要依赖关系DateTime(otxIFD_DateTime.xsd)提供对系统时间的访问CoreDiagCom(otxIFD_DiagCom.xsd)连接到ECU，创建和执行诊断服务，分析通信数据EventHandling,Quantities,CoreDiagComRaw(otxIFD_DiagComRaw.xsd)直接在非符号（二进制）级别进行诊断通信DiagComDiagDataBrowsing(otxIFD_DiagDataBrosing.xsd)用于从诊断数据库读取数据的浏览功能DiagCom,CoreEventHandling(otxIFD_Event.xsd)支持OTX事件处理机制CoreFlash(otxIFD_Flash.xsd)功能，用于下载和上传来自ECU的刷写数据DiagCom,CoreHMI(otxIFD_HMI.xsd)通过对话框和屏幕与UI（用户界面）进行通信的功能EventHandling,Corei18n(otxIFD_I18n.xsd)国际化功能，多语言支持和翻译机制Quantities,CoreJob(otxIFD_Job.xsd)OTX测试序列模拟ODXJava作业的功能DiagCom,Quantities,CoreLogging(otxIFD_Logging.xsd)支持（Log4J风格）日志记录CoreMath(otxIFD_Math.xsd)扩展的数学函数CoreMeasure(otxIFD_Measure.xsd)执行测量设备服务，测量物理值，分析测量值EventHandlingQuantities,CoreQuantities(otxIFD_Quantities.xsd)处理数量数据，wrt。国际单位制，单位间转换等CoreStringUtil(otxIFD_StringUtil.xsd)扩展的字符串处理功能Core表1—OTX扩展特性表2显示了所有OTX扩展[W3CXSD][W3CXMLNS]的XSD名称空间关联。每个名称空间都有一个分配给它的前缀。这也适用于OTXCore名称空间，该名称空间具有otx：前缀（表中未显示）。在本文档的其余部分，这里定义的前缀用于标记属于除当前描述的扩展之外的扩展的类型。相反，由当前描述的扩展定义的类型不加前缀。表2—OTX扩展命名空间关联思考图2中的示例。它显示了OTXDiagCom扩展的IsDiagServiceEvent术语。该术语接受在OTXEventHandling扩展中定义的参数，因此元素的类型标记为event：prefix（event：EventValue）。这同样适用于为图定义的布尔型返回类型，该类型在OTXCore中定义，并用otx：前缀（otx：BooleanTerm）相应标记。因为是当前描述的OTXDiagCom扩展的成员，所以IsDiagServiceEvent类型本身不是前缀。图2-例如：扩展前缀的使用6OTX时间日期扩展6.1介绍OTXDateTime扩展的用途是检索有关诊断应用程序提供的当前日期和时间的信息。6.2术语6.2.1概述OTXDateTime扩展中的术语应用于检索有关当前系统时间的信息。6.2.2语法图3显示了OTXDateTime扩展中所有术语的语法。图3-数据模型视图：TimeDate术语6.2.3语义gettimestampGetTimestamp应返回一个时间戳，以1970年01月00:00:00UTC以来的毫秒数表示。GetTimestamp的语义应该根据Java2平台标准所指定的Java.util.date.gettime()方法。GetDate是一个otx整数术语。它没有成员。formatDateFormatDate项应将时间戳（请参阅上面的GetTimestamp术语）转换为日期表示形式，其格式如下：a）如果没有指定自定义格式，则返回的字符串应根据ISO8601标准[ISO8601：2004]给出的规则进行格式化。b）如果给定了自定义格式（由<format>元素），则字符串应根据下面指定的Cusom格式规则进行格式化。自定义格式模式可由OTX作者配置;它控制日期的文本显示。格式模式包含一个或多个预定义的日期和时间格式说明符（请参阅表3）以及必须用引号（'）转义的用户定义的字符串序列。非数字输出（例如一个月的名称）应自动翻译成当前设置的语言环境（参见第12条OTXi18n扩展）表3日期格式说明符格式模式规则类似于Java™2​​PlatformStandardEd所指定的类java.text.SimpleDateFormat的规则。FormatDate的整体语义应根据方法SimpleDateFormat.format（日期日期）的语义。示例1在中欧时区（CET）的2011-03-1011:23:56给定日期和时间并且当前语言环境设置为en-US时，“hh'o''clock'a，zzzz”会产生以下格式输出：“中欧时间上午11点。。如果没有给出自定义格式，则ISO8601符合日期输出格式应与自定义格式“yyyy-MM-dd'T'HH：mm：ss'。'SSSZ”相等格式化，其中“T”是时间指示符，“.”是以下毫秒部分的分隔符。这种模式是独立于语言的;当前设置的语言环境不会影响输出。示例2在中欧时区（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以来经过的毫秒数。根据上面给出的规则，相应的日期应格式化为字符串输出。浮动值应被截断。--<pattern>：OTX：stringterm[0..1]这个可选元素表示应该用于生成自定义日期输出字符串的自定义格式模式。抛出：--OTX：outofboundsexception如果时间戳值为负数。formatdurationFormatDuration项应以字符串表示形式返回给定的毫秒持续时间。格式化应该类似于FormatDate术语来完成，区别在于传递给术语的毫秒数被解释为持续时间，而不是日期。由于表3中给出的一些格式说明符在持续时间方面（例如时区，星期几名称，时代等）没有意义，因此只应使用表4中定义的说明符。表4时间格式说明符示例1对于给定的203443毫秒的持续时间（这是3分23秒和443毫秒），例如像“'这花了'米'分钟和'秒'”会产生以下格式输出：“这花了大约3分23秒。”如果没有给出自定义格式，那么符合ISO8601要求的日期输出格式应与自定义格式“'P'yyyy-MM-dd'T'HH：mm：ss'。'SSS”相同，其中“P”是时间指示符，“T”是时间指示符。示例2对于给定的持续时间203443毫秒（这是3分23秒和443毫秒），将生成以下标准格式输出：“P000000-00T00：03：23.443”FormatDuration是一个otx：StringTerm。其成员具有以下语义：--<Duration>：OTX：numericterm[1]该元素表示以毫秒为单位的持续时间，该持续时间将被转换为根据上述规则格式化的字符串。浮动值应被截断。--<pattern>：OTX：stringterm[0..1]这个可选元素表示为了生成自定义持续时间输出字符串而应用的自定义格式模式。抛出：--OTX：outofboundsexception如果持续时间值是负值。7OTXDiagCom扩展7.1介绍OTXDiagCom扩展的目的是为执行诊断车辆通信提供必要的OTX元素。具体而言，已经考虑了以下诊断用例：--处理ECU通信通道--执行诊断服务--设置服务请求参数并评估服务响应参数--处理诊断服务的积极或各种消极反应--处理通信通道协议参数--执行ECU的变体识别--功能性诊断服务：多个ECU将响应请求--重复/循环执行诊断服务：单个请求将导致来自同一ECU的多个响应--functional功能寻址和循环服务执行的潜在组合：多个ECU响应多次请求--diagnostic诊断服务的请求和响应中的复杂数据结构：参数结构，参数列表，包含参数结构的列表下面的考虑引入了由DiagCom扩展的设计解决的问题域。虽然这些功能不太可能会被所有运行OTX序列的运行环境所支持，但OTXDiagCom扩展必须提供处理这些概念的方法，因为它旨在成为定义车辆诊断的通用方法。注1：这是DiagCom扩展的明确设计目标，可用于任何诊断通信内核。作为设计指南，考虑了基于ODX/MVCI[ISO22901][ISO22900]的系统-由于ODX/MVCI正在解决高度通用的车辆通信问题领域，因此DiagCom采用的设计概念对于正在实施车辆通信问题解决方案的任何系统，扩展应该是可用的抽象。注2：DiagCom扩展的明确设计目标是仅为诊断车辆通信提供运行时间接口。浏览诊断数据库（例如ASAMMCD3API的数据库部分）不是DiagCom扩展的设计目标。对于这种使用情况，应创建专门提供数据访问功能的单独OTX扩展。7.2总体考虑7.2.1通信通道执行任何诊断通信的先决条件是诊断应用程序与车辆的电子控制单元之间的通信通道。在OTX中，这个实例称为ComChannel，指定测试序列和预期通信目标之间的逻辑连接。ComChannel不关心与所需端点进行通信所需的协议，布线，连接器或钉扎的任何细节;相反，这些方面将由底层车辆通信层来处理。ComChannel在符号级别上工作，因为它应该通过名称来处理ECU，并通过运行时存在的ECU的特定变体来了解ECU的诊断功能。因此，OTX中有一个ComChannel上ECU变量识别的概念，以及创建指向特定ECU变体的通道或检索ComChannel的当前活动ECU变体名称的功能。注意这是OTXDiagCom扩展的明确设计目标，可用于任何诊断通信内核。然而，ComChannel和ECU变体的概念是基于逻辑链路和ECU变体识别的MVCI定义，因为它们代表了广泛适用的设计问题的通用高级方法。7.2.2Diagnosticservices图4给出了诊断服务的请求和结果数据结构的高级概述。该服务包含一个请求。该请求包括一个或多个参数。诊断服务可以有任意数量的结果。在这个例子中，显示了一个结果。服务结果可以包含任意数量的ECU响应。响应包含一个或多个参数。参数可以是简单数据类型，也可以是包含参数列表或结构参数的复杂类型构。图4-诊断服务请求的结果结构图5所示的请求由一个简单的参数，一个包含两个低级参数的struct参数和一个包含两个item的list参数组成，每个item又包含三个简单的数据类型参数。它还显示了如何使用由<path>元素定义的<stepByIndex>和<stepByName>方法，通过DiagCom扩展中的术语和动作访问不同的参数（请参考本节的其余部分，以及更多信息，请参阅ISO13209的第2部分）。如示例请求中所示，通过路径访问参数的方式也适用于ECU响应，这些响应也可以包含复杂的参数结构。为了处理重复的服务执行模式（请参阅7.2.3），诊断服务使用结果队列的概念。每次向ECU发送请求时，都会将新的结果元素添加到包含ECU对该请求的响应的队列中。OTXDiagCom扩展提供了三种与结果队列交互的方法：a）可以使用GetFirstResult项来访问队列的第一个结果b）通过使用GetAllResults术语，可以将当前队列中的所有结果作为OTX列表进行检索c）GetAllResultsAndClear操作检索队列中的所有结果并清除队列诊断服务队列中结果的生命周期由服务执行请求分隔：每次在该DiagService对象上调用ExecuteDiagService或StartRepetition时，都会清除诊断服务的队列。图5-复杂要求的结构与<stepbyname>和<stepbyindex>7.2.3诊断通信模式概述除了诊断服务请求和响应具有任意的结构复杂性之外，诊断应用与车辆内的ECU之间的交互模型也为诊断应用提供了挑战：发送给车辆的诊断服务请求可能导致多个ECU应答该请求，或者在由通信后端重复执行诊断服务的情况下导致多个请求和响应帧。当ECU的回应以多个部分发送时，会出现更多复杂情况。下面举例说明了物理和功能寻址，一次性和重复执行以及单部分和多部分响应以及由此产生的结果结构的可能置换。一次性服务，物理寻址，单部分的响应图6显示了一个测试和一个电控单元之间的通信流。图6一次服务，物理寻址，单部分的响应ECU接收物理地址服务请求，这会导致ECU向测试仪系统发送单部件响应。发送到ECU的请求导致创建相应的结果对象（Result_1）。ECU的响应包含在结果对象（Response_1）中。一次性服务，物理寻址，多部分的反应图7显示了一个测试和一个电控单元之间的通信流。图7一次服务，物理寻址，多部分的反应ECU接收物理地址服务请求，这会导致ECU向测试仪系统发送多部分响应。发送到ECU的请求导致创建相应的结果对象（Result_1）。ECU的响应包含在结果对象（Response_1和Response_2）中。一次性服务，功能寻址，单部分的响应图8显示了一个诊断的应用及一套电控单元之间的通信流。图8-一次服务，功能寻址，单部分的响应ECU接收功能性地址的服务请求，这会导致ECU向应用程序发送单部分响应。发送给ECU的请求导致创建相应的结果对象（Result_1）。ECU的响应包含在结果对象（Response_1和Response_2）中。请注意，OTXDiagCom术语GetComChannelIdentifierFromResponse可用于识别与响应相关的ECU（ComChannel）。一次性服务，功能寻址，多部分的反应图9显示了一个诊断的应用及一套电控单元之间的通信流。图9一次服务，功能寻址，多部分的反应ECU接收功能性地址的服务请求，这导致ECU向测试仪系统发送多部分响应。发送给ECU的请求导致创建相应的结果对象（Result_1）。ECU的响应包含在该结果对象中（Response_1至Response_4）。重复服务，物理寻址，单部分的响应图10显示了一个诊断应用程序和一个电控单元之间的通信流。图10重复的服务，物理寻址，单部分的响应ECU接收重复的物理地址服务请求，这会导致ECU向每个请求的诊断应用程序发送一个单一部分的响应。发送给ECU的请求会导致创建相应的结果对象（Result_1和Result_2）。ECU对重复请求的响应包含在与引发响应的执行周期相对应的结果对象中（第一个循环的Result_1，第二个循环的Result_2等等）。重复使用，功能寻址，单部分的响应图11显示了一个诊断的应用及一套电控单元之间的通信流。图11重复的服务，功能寻址，单部分的响应ECU接收到重复的功能编址服务请求，这会导致ECU向每个请求的诊断应用程序发送一个单一部分的响应。发送给ECU的请求导致创建相应的结果对象（Result_1和Result_2）。ECU对重复请求的响应包含在与引发响应的执行周期相对应的结果对象中（第一个循环的Result_1，第二个循环的Result_2等等）。重复服务，物理寻址，多部分的反应图12显示了一个诊断应用程序和一个电控单元之间的通信流。图12重复的服务，物理寻址，多部分的反应ECU接收到重复的物理地址服务请求，这会导致ECU向每个请求的诊断应用程序发送一个多部分响应。发送给ECU的请求会导致创建相应的结果对象（Result_1和Result_2）。ECU对重复请求的响应包含在与引发响应的执行周期相对应的结果对象中（第一个循环的Result_1，第二个循环的Result_2等等）。重复使用，功能寻址，多部分的反应图13显示了一个诊断的应用及一套电控单元之间的通信流。图13重复的服务，功能寻址，多部分的反应ECU接收重复的功能编址服务请求，这会导致ECU向每个请求的诊断应用程序发送多部分响应。发送给ECU的请求导致创建相应的结果对象（Result_1和Result_2）。ECU对重复请求的响应包含在与引发响应的执行周期相对应的结果对象中（第一个周期的Result_1，第二个周期的Result_2等等）。其他模式请注意，OTXDiagCom扩展没有明确支持周期性执行诊断服务的功能，即向ECU提出一个请求导致ECU在没有相应请求的情况下循环发送对测试仪系统的响应的服务。如果此类行为必须由OTXDiagCom运行时系统进行映射，则基本规则是OTX结果对象始终对应于测试仪系统发出的一个请求。图14显示了一组ECU周期性向诊断应用程序发送多部分响应的理论情况。在OTX中，应用程序发送的初始请求将导致创建相应的结果对象，其中包含随后收到的任何响应。请注意，OTX不支持任何用于停止循环诊断服务的便利功能。需要ECU停止发送循环响应的OTX作者必须手动选择并执行相应的诊断服务，以告知ECU停止。图14一次服务，功能寻址，周期性的多部分的反应7.2.4专用诊断数据类型由于OTX不支持结构化数据类型的明确定义，因此需要提及DiagCom扩展如何处理无处不在的诊断数据类型，如故障码或冻结帧数据。看一下故障码，通常来说，它只不过是一种结构化数据类型，具有由SAEJ1979标准[SAEJ1979]定义的一组结构参数，其他是OEM特定的参数。因此，OTX中的故障码与其他任何结构化参数一样：当从诊断服务的响应中检索代表故障码的参数时，可以通过在故障码参数上使用DiagCom术语GetParameterByPath来加入DTC的字段，并将名称<path>元素中所需的子参数。例如，如果在诊断系统中，DTC的PID值被命名为“TroubleCode”以访问该信息，则OTX序列看起来将如OTX示例中所示。样品的OTX文件的例子”dtcexample.otx”7.3数据类型7.3.1概述由OTXDiagCom扩展引入的所有数据类型都来自OTXCoreComplexType，这意味着它们定义了ISO13209第2部分定义的复杂数据类型。此处描述的元素是底层通信系统相应对象的句柄。7.3.2语法所有的OTXdiagcom异常类型声明的语法，如图15所示。图15-数据模型视图：diagcom数据类型7.3.3语义概述OTXDiagCom数据类型没有初始化部分（枚举类型ResponseState和ResultState除外）;因此，这些不能被声明为常量。comchannelComChannel是通信通道的句柄。它表示链接到一个特定通信端点的概念，例如，一个ECU模块（物理寻址）或一组ECU模块（功能寻址）。注：在基于MVCI/ODX的系统中，ComChannel句柄指向MCDDLogicalLink对象。diagserviceDiagService是表示诊断服务的对象的句柄，例如，一个阅读错误代码的服务。DiagService句柄可用于使用ExecuteDiagService操作执行诊断服务执行（请参阅.1）。注：在基于MVCI/ODX的系统中，DiagService句柄代表MCDDiagComPrimitive对象。ResultResult是诊断服务对象结果的句柄。请参阅图4，了解诊断服务的请求，结果，响应和参数实例的结构。注：对于基于MVCI/ODX的系统，结果句柄代表MCDResult对象。parametercontainerParameterContainer是一个抽象数据类型，它包含所有包含参数的数据类型，即Parameter和Message句柄。参数参数是诊断服务请求或响应的参数对象的句柄。它可以表示一个简单或复杂的类型参数，即参数句柄可能指向一个简单的Integer或String参数，或者它可能对应于参数结构或参数列表，具体取决于底层通信系统的定义。请参阅图4，了解诊断服务的请求，结果，响应和参数实例的结构。注：对于基于MVCI/ODX的系统，参数句柄代表MCDParameter对象（或其专门化的MCDRequestParameter和MCDResponseParameter）。消息Message元素是封装实际ECU消息的抽象数据类型。响应响应是诊断服务结果的响应对象的句柄。请参阅图4，了解诊断服务的请求，结果，响应和参数实例的结构。注：对于基于MVCI/ODX的系统，响应句柄表示MCDResponse对象。请求请求是诊断服务请求的句柄。请参阅图4，了解诊断服务的请求，结果，响应和参数实例的结构。注：如果是基于MVCI/ODX的系统，请求句柄表示MCDRequest对象。resultstateResultState是描述结果状态的枚举类型。允许枚举值列表定义如下：--all_failed：在物理寻址的情况下，功能组中的所有ECU（收听同一功能地址）都无法应答：请求的ECU未能应答--all_invalid：在物理寻址的情况下，功能组中的所有ECU（监听相同的功能地址）返回了无效的答案：一个请求的ECU返回无效响应--all_negative：在物理寻址的情况下，功能组中的所有ECU（监听相同的功能地址）返回否定响应：一个请求的ECU返回否定响应--all_positive：一个功能组中的所有ECU（监听相同的功能地址）在物理寻址的情况下返回肯定响应：所请求的一个ECU返回肯定响应--失败：功能组中的某些ECU（收听同一功能地址）未能应答--无效：功能组中的一些ECU（监听同一功能地址）返回无效响应--负：某个功能组中的某些ECU（听取相同的功能地址）返回否定响应--阳性：一个功能组中的一些ECU（监听相同的功能地址）返回了肯定的响应重要-ResultState值可能作为比较操作数出现（参见ISO13209的第2部分关系操作）。对于这种情况，应使用以下顺序关系：ALL_FAILED<ALL_INVALID<ALL_NEGATIVE<ALL_POSITIVE<FAILED<INVALID<NEGATIVE<POSITIVE。重要-在ResultState值上应用otx：ToString时，结果字符串应该是枚举值的名称，例如OTX：的ToString（正）=“阳性”。此外，应用otx：ToInteger应返回ResultStates枚举中值的索引（最小索引为0）。其他转换术语的行为未定义（参见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是描述响应状态的枚举类型。允许枚举值列表定义如下：--失败：ECU未能回答--无效：ECU返回了一个无效的响应--负：返回的ECU的负面反应--正：ECU返回一个积极的响应重要-ResponseState值可能作为比较操作数出现（参见ISO13209的第2部分，关系操作）。对于这种情况，应使用以下顺序关系：FAILED<INVALID<NEGATIVE<POSITIVE重要-当对ResponseState值应用otx：ToString时，结果字符串应该是枚举值的名称，例如OTX：的ToString（正）=“阳性”。此外，应用otx：ToInteger应返回ResponseStates枚举中的值的索引（最小索引为0）。其他转换术语的行为未定义（参见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概述本节中引用的所有元素均来自ISO13209第2部分定义的OTX核心异常类型。它们表示由OTXDiagCom扩展添加的全套例外。7.4.2语法所有的OTXdiagcom异常类型声明的语法，如图16所示。图16-数据模型视图：diagcom异常7.4.3变更请求的语义概述由于所有OTXDiagCom异常类型都是没有初始化部分的隐式异常，因此不能将其声明为常量。diagcomexceptionDiagComException是DiagCom扩展中所有异常的超类。如果本节其余部分描述的更具体的异常类型不适用于手头的问题，则应使用DiagComException。ambiguoussemanticexception如果有多个对象具有与DiagCom活动相匹配的相同语义属性，则会引发AmbiguousSemanticException。这个异常可以通过以下操作/术语抛出：--creatediagservicebysemantic--getparameterbysemantic--setparametervaluebysemanticunknowntargetexception如果DiagCom操作或术语引用底层通信系统中不可用或未定义的对象，则会抛出UnknownTargetException。lossofcomexception如果在服务执行过程中出现通信故障，则抛出LossOfComException。以防连接车辆的电缆被拔下。unknownresponseexception如果执行诊断服务时返回了未由ExecuteDiagService操作映射的响应（请参阅.1），则会引发此异常。unknowncomchannelexception如果在使用GetComChannelNameFromResponse项（见.4）时响应句柄无法链接到通信通道，则会抛出此异常。invalidstateexception如果在重复执行的DiagService上使用StartRepeatedExecution操作，并且在重复执行的DiagService上使用StopRepeatedExecution操作，或者在当前正在重复执行的DiagService上使用SetRepetitionTime操作的情况下，将抛出此异常。incompleteparameterizationexception如果执行的DiagService不是所有的请求参数都没有设置默认值，那么就会抛出这个异常。7.5访问变量7.5.1概述按照ISO13209第2部分的规定，OTX扩展应为它们定义的每种数据类型定义一个变量访问类型（包含的异常类型）。所有变量访问类型都来自OTX核心变量扩展接口。以下指定为DiagCom扩展定义的所有变量访问类型。7.5.2语法图17显示的diagcom扩展的变量访问类型的语法。图17-数据模型视图：diagcom变量访问类型7.5.3语义所有的变量访问类型的一般语义适用。详情请参阅2部分ISO13209。7.6操作7.6.1概述图18所示的所有元素扩展了ISO13209第2部分定义的otx：ActionRealisation扩展接口。图18-数据模型视图：diagcom行为概述7.6.2comchannel有关的操作描述本节中描述的所有操作都会影响ComChannel句柄上的更改。语法图19显示了DiagCom扩展的所有与ComChannel相关的ActionRealisation类型的语法。图19-数据模型视图：comchannel有关的操作语义.1identifyandselectvariantIdentifyAndSelectVariant操作应用于告知通信后端，以识别在特定通信通道运行时存在的ECU变体。如果可以识别ECU变量，则通信通道将切换为指向该特定变量。本标准不能对OTX运行时使用的车辆通信组件是否支持ECU变体识别的概念或有关通信组件行为的假设进行假设。DiagCom扩展的相关部分基于以下假设：--ECU的通信通道与描述该ECU的特定变体的诊断行为的数据集相关联。--车辆通信组件能够明确地执行到ECU的通信信道上的ECU变体识别操作。--执行变型识别所需的逻辑和数据是车辆通信组件固有的，即通信组件不需要额外的外部信息来执行ECU变型识别。--识别出ECU变体后，车辆通信组件能够明确将通信通道与具有针对该ECU变体的特定数据集的ECU相关联，从而有效地将通信通道从旧变体数据集切换到新变体数据集。IdentifyAndSelectVariant操作通知运行时系统在提供的通信通道上执行变量识别操作，然后将与该通道关联的数据集切换到适合新识别变体（如果有的话）的数据集。请参考GetComChannel术语（见.3），它告诉运行系统创建一个新的通信通道，立即在新的通信通道上执行变量识别操作，然后将与该通道相关的数据集切换到一个适合新确定的变体（如果有的话）。注：如果使用ODX/MVCI系统，变型识别和选择的确切语义由ISOODX和MVCI标准规定。以下的语义identifyandselectvariant行动的成员：--<comchannel>：comchannelvalue[1]该元素包含通信通道，该通道应用于识别通信通道连接的ECU的实际变体。抛出：--lossofcomexception如果在变型识别过程中与ECU的通信中断。.2closecomchannel操作CloseComChannel告诉OTX运行系统，可以关闭到ECU的通信信道并关闭相关的资源。请注意，通过OTX序列使用CloseComChannel操作仅表明不再需要该通道-这取决于特定运行时系统的实现，无论它实际上是否释放所有资源并在此时关闭通道。如果诊断序列在通过CloseComChannel动作释放后使用ComChannel句柄，则运行时系统应抛出otx：InvalidReferenceException。closecomchannel行动的成员有以下的语义：--<comchannel>：comchannelvariable[1]该元件包括应关闭的通信信道。7.6.3comparameter有关的操作描述本节中描述的所有操作都会更改ComChannel句柄的通信参数设置。例如，CAN超时或波特率设置通常被建模为通信参数。语法图20显示了DiagCom扩展的所有与参数处理相关的ActionRealisation类型的语法。图20-数据模型视图：通信参数处理语义.1setcomparameterSetComParameter操作将用于更改通信后端使用的通信参数的值。例如，可以使用SetComParameter节点设置总线超时或波特率。注：如果使用ODX/MVCI系统进行车辆通信，可以设置的通信参数名称和数据类型由DPDUAPI/ODX通信参数规范定义。setcomparameter行动的成员有以下的语义：--<comchannel>：comchannelvalue[1]该元素包含通信参数应修改的通信信道。--<name>：OTX：stringterm[1]该元素指定了应该改变的通信参数的名称。--<value>：OTX：term[1]该元素指定了应设置的新通信参数值。抛出：--unknowntargetexception如果不存在具有指定名称的通信参数。--OTX：typemismatchexception如果指定的数量类型与要设置的通讯参数的数据类型不匹配。.2setcomplexcomparameterSetComplexComParameter操作是SetComParameter的增强变体。这些操作之间的区别在于，在这种情况下可以使用复杂的数据类型。注意例如，在基于ODX/MVCI的系统中，复杂的通信参数数据类型用于定义功能寻址用例的响应ID列表。setcomplexcomparameter行动的成员有以下的语义：--<comchannel>：comchannelvalue[1]该元素包含通信参数应修改的通信信道。--<parameter>：parameterterm[1]该元素包含应设置的参数结构。抛出：--OTX：typemismatchexception如果指定的<parameter>元素与要设置的通信参数不匹配。7.6.4diagservice有关的操作描述本节中描述的操作用于设置和执行实际的ECU通信。语法图21显示了与诊断服务配置和执行相关的DiagCom扩展的所有ActionRealisation类型的语法。图21-数据模型视图：diagservice有关的行动语义.1executediagserviceExecuteDiagService操作应用于执行诊断车辆通信。OTX序列中的ExecuteDiagService节点向运行系统指出，此时服务请求应发送给一个或多个ECU，并且可能必须向OTX序列提供任何相关的响应。为了做到这一点，ExecuteDiagService操作需要两组信息：A）要使用的DiagServiceB）将OTX值映射到服务请求参数的定义以及服务响应参数的值返回到OTX变量。根据服务的参数结构在OTX创作时是已知还是必须在运行时动态评估，可以通过两种方式向/从服务参数写入/读取值。--内联映射：如果服务的参数结构是静态的（在创作时已知），则ExecuteDiagService操作可用于通过其<RequestParameters>和<ResponseParameters>成员内联定义请求和响应参数映射。将在本条的其余部分给出详细的解释。请注意，内联映射方法仅适用于一个ECU对诊断服务有一个响应的情况。如果多个ECU响应服务请求和/或ECU响应不止一次，内联映射将只与第一个结果中的第一个响应有关。--动态响应：如果服务的参数结构在运行时是动态的（在创作时未知），则可以使用由DiagCom扩展定义的术语来通过明确的OTX语句评估请求和响应参数结构。这样，有可能例如通过包含结构列表的服务响应进行循环。响应参数结构在运行时以这种方式变化的诊断服务的示例是由UDS协议[ISO14229]定义的读取DTC服务。由于它在服务执行时返回了ECU中存在的DTC的数量，因此在创作时无法确切知道在运行时服务的响应中将包含多少或哪些DTC。如果诊断服务产生复杂的结果结构，则还需要手动评估结果。这可能发生在两种情况下，第一种是诊断服务，其中一项服务执行导致来自ECU的多个循环响应。在这种情况下，诊断服务将有多个与之相关的结果-每个ECU在时间线上的响应都有一个。单个结果必须通过中定义的术语进行访问和评估。第二种情况是当一个诊断请求导致来自不同ECU的多个响应时，即当使用功能性寻址时。在这种情况下，有一个与诊断服务相关的结果，其中包含多个响应-每个响应功能请求的ECU都有一个响应。必须使用中定义的术语来访问和评估个人响应。请注意，从理论上讲，这两种情况也可以合并-可以想象使用功能性寻址的重复发送的诊断服务，产生包括多个响应的多个结果。更多细节请参考。下列规则适用于在executediagservice元素内联映射参数：--允许的OTX数据类型用于参数映射：RequestParameter和ResponseParameter映射仅允许引用OTX简单类型，OTXByteField，列表和映射类型以及OTX数量类型。--ExecuteDiagService的响应映射和异常行为：通常，ExecuteDiagService操作可以包含多个响应参数序列-一个用于OTX序列感兴趣的每个响应。如果在运行时遇到一个未由ExecuteDiagService节点中的<responseParameters>元素表示的ECU响应，则会导致UnknownResponseException。为了能够确定问题的性质，在这种情况下，可以使用术语GetDiagServiceFromException（请参阅.7）检索已从UnknownResponseException执行的DiagService对象，然后通过查找来分析它的响应结构在响应的PDU中（参见.4中的术语GetPdu），或者使用适当的DiagCom术语通常的遍历方法。--如前面段落中所述，ExecuteDiagService节点可以通过提供具有适当响应名称的<responseParameters>元素来自由定义它感兴趣的服务的哪些响应。请注意，<responseParameters>元素可以为空，但不要求定义实际响应参数的任何映射。这允许诊断序列作者对ExecuteDiagService操作的行为进行细粒度控制：在遇到意外/不需要的响应时，ExecuteDiagService操作是否应该抛出异常仅仅是提供可能的空响应参数针对有问题的答案进行映射。例如，如果诊断序列作者只对正面回答感兴趣并且认为发生否定回答是错误，则他应该只提供正面回答名称的映射。如果负面响应的发生不被认为是错误，并且不会导致UnknownResponseException，他也可以简单地为负面响应提供映射，如果他不关心实际响应参数，则可以为空。原则适用于响应的任何组合（正面，负面，全局负面等）-只需提供适当的<responseParameters>元素，作者就可以控制响应的发生是否应被视为UnknownResponseException（无映射）或不（映射存在）。注：如果OTXDiagCom扩展功能与ODX/MVCI系统一起使用，<responseParameters>元素的名称是相应ODX数据中响应的SHORT-NAME（正数，局部负数，全局负数）。如果DiagCom扩展与不同的通信后端一起使用，该通信后端没有服务的多个响应概念/没有响应名称，则可以使用类似的内部命名约定将OTX响应参数映射为正面或负面响应。ExecuteDiagService操作还可以配置为告诉通信后端，如果通信后端和要执行的特定诊断服务支持该概念，则寻址的ECU应禁止发送肯定响应。如果属性suppressPositiveResponse的值设置为true，则会发生这种情况。如果从ExecuteDiagService中省略该属性，则默认值为false。executediagservice行动的成员有以下的语义：--executeasync：XSD：boolean={false|true}[0..1]该选项告诉通信后端使此诊断服务执行非阻塞。这意味着如果executeAsync设置为true，则OTX执行流将立即转到下一个Action，而不等待ExecuteDiagService操作的结果。因此，由此ExecuteDiagService操作定义的任何响应参数映射都将被忽略：由于执行ExecuteDiagService节点时诊断服务执行不一定完成，因此在这点上，静态映射以包含服务响应的OTX变量不能包含值。executeAsync功能的使用始终要求OTX序列执行动态响应解释。OTX序列可以使用DiagServiceEventSource术语（请参阅.1）在异步执行的诊断服务的新结果到达时收到通知。--suppresspositiveres