根据流程定义id获取流程实例_基于AUTOSAR方法的诊断开发流程

OEM和供应商在车辆诊断功能的开发中要使用多种不同的流程，并采用不同的数据交互格式和工具。问题往往出现在多个开发者和工具之间交互诊断描述文件时。数据交互是一项耗时的工作，需要保证交互信息的完整性和正确性。AUTOSAR诊断数据文件(DEXT)为诊断开发提供一种新的可能。诊断相关的基础软件(BSW)模块根据企业规范统一配置，模块集成可以通过DEXT来实现。

1

DEXT与其他诊断数据格式

DEXT最初发布在AUTOSAR 4.2.1中。AUTOSAR 4.3.0在标准UDS协议之外，增加了OBD-II、WWH-OBD、FIM和SAE J1939的相关扩展内容。DEXT不仅描述通过各自协议传输的数据，还包括ECU应用层软件中初始数据。当上述两种数据的描述完整正确时，即可通过DEXT配置AUTOSAR诊断相关BSW。AUTOSAR标准没有定义诊断协议、诊断服务和数据，而是直接使用了UDS和OBD-II的定义。

另一方面，ODX文件可作为通用诊断仪的数据格式，描述诊断协议、ECU和诊断仪间的数据传输，以及诊断仪解析数据的方法。对于诊断仪来说，ECU数据的来源并不重要，因此在ODX中并未定义。此外ODX可被用作配置的初始输入，主要描述诊断数据及其结构，但是必须通过手动方式将诊断数据与ECU应用层关联。当ODX描述故障存储数据时，与ECU软件之间存在较大差异，例如用于故障检测的消抖或置换算法是BSW的重要组成，但是ODX中完全没有这部分信息。加之不同整车厂的ODX编写指南存在很大不同，因此使得ECUC(ECU配置信息)的交互更复杂。

ECUC作为嵌入式软件代码生成工具的输入文件，格式频繁变更，从而适应每个新版本的标准。与此同时，ECUC允许自定义的扩展，因此ECUC不适合作为一种中性的交互格式。

AUTOSAR DEXT是专为满足BSW输入数据的需求而设计，其主要元素见图1：

UDS、OBD、WWH-OBD、J1939诊断服务和相关子服务的选择；

故障路径和故障存储；

诊断数据元素和相关的数据包；

诊断数据元素与应用层软件的映射；

功能禁用模块(FIM)；

图1 AUTOSAR DEXT的元素

AUTOSAR元模型正式定义如何对DID建模。不同于ODX文件，AUTOSAR DEXT文件不能自由定义，从而避免了工具间数据交互时出现歧义的风险。诊断DID实例包含16-bit的DID，一个或多个数据元素，DID数据的名字和类型。为了进行数据类型建模，AUTOSAR可复用已存在的系统模板模型。通过UDS诊断服务0x22、0x2E或0x2F引用DID，DID被用于诊断服务。这是在诊断相关BSW中定义DID的配置所需的全部信息。

为了读、写或者重写DID，BSW需要与应用层软件交互，这是为什么DEXT中包含另外的元素——诊断映射。诊断映射描述了BSW中诊断元素之间的关系，例如Routine、DID数据、事件和应用层的软件组件(SWC)。为此，SWC的接口必须遵循AUTOSAR定义的建模方法，例如通过不同通信模式调用客户端/服务器的接口，或者通过收/发接口来读/写数据。过去，工程师不得不手动配置BSW和应用层软件间端口的关联；当使用DEXT时，这一操作可以自动执行。采用DEXT可以减少错误，并在提高质量的同时缩短开发时间。

2

分布式诊断开发中的场景和角色

除了工具和数据交互格式外，诊断开发流程的不同主要体现在OEM和Tier1的分工。实际上，存在多种不同的诊断开发流程(见表1)：

• 由OEM完成设计；

• 由OEM和Tier 1联合进行诊断开发；

• 由Tier 1独立完成开发。

场景1 OEM完成诊断设计	场景2 Tier1扩展OEM诊断规范	场景3 Tier1创建诊断规范
OEM创建系统设计(包括SWC的诊断接口)	OEM创建系统设计(包括SWC的诊断接口)	Tier1创建SWC的诊断接口
OEM提供ECU诊断规范	OEM提供ECU诊断规范	Tier1创建适用于SWC的诊断规范
Tier1接手OEM的诊断规范	Tier1扩展ECU诊断设计	OEM接手Tier1的诊断规范
	OEM更新Tier1修改的诊断规范

表1 诊断开发流程

DEXT支持以上三种流程。AUTOSAR arxml文件中的元素在DEXT都是可选的。在不同的流程中，可以创建DEXT并丰富其内容，或在流程的末期扩展其内容。创建的数据是合法的且可交互的。数据可在应用过程中被定义，所以在哪个步骤中添加哪些数据并不重要。

3

工具链相关的需求

诊断开发流程需要工具链的支撑。在流程开始阶段，需要用需求管理系统(RMS)定义诊断需求。由诊断需求获取应用层软件与诊断服务相关的需求。通常这两类需求要SWC和对应的BSW配置来实现。工程师在ECU集成期间将两者关联，这就是之前提到的DEXT在诊断映射中的作用，如图2所示。

图2 OEM和Tier1供应商之间的诊断流程

在自顶向下的开发流程中，诊断应用层软件最先被开发，或者复用已有的软件。诊断数据源自需求和应用层软件的接口描述。与许多现有流程相比，这一流程主要优势是诊断数据适用于需求和应用层软件。这通常是一项耗时的手工整合任务。

DEXT文件被创建的同时，也需要创建ODX数据。从同一源头生成ODX和DEXT数据，可以确保诊断仪与ECU的诊断软件相匹配。

4

基于工具链的实例

图3展示了Vector诊断开发工具链的实例，其中PREEvision用于需求和系统设计，CANdelaStudio作为诊断需求编辑工具，DaVinci Configurator Pro是BSW配置工具。

开发初期用PREEvision定义诊断需求。例如，某个需求要求提供一个油温传感器，这个传感器应包含读取油温的诊断服务，I/O Control重写传感器的数值，支持一个或多个DTC表示温度传感器的故障。

SYS-EX的SWC接口定义来自arxml文件。SWC接口也定义诊断对象的参数。在油温传感器的例子中，一个SWC的端口提供当前的温度值，接口定义测量值数据类型为16-bit或32-bit，以及转换公式和单位。出于支持该工作流程的需要，在CANdelaStudio中新增SWC同步功能，从而为以下诊断元素自动生成合适的诊断数据：

• 读、写、I/O-Control使用的DID；

• RID(Routine Control ID)；

• 事件和DTC。

在实例中，诊断专家在CANdelaStudio中创建“ReadData-ByIdentifier”服务，包含无符号16-bit的“温度”数据和0.1摄氏度的分辨率，带有相同数据元素的I/O-Control服务，以及DTC对应的传感器故障。诊断专家定义一个ID在诊断通信中用来获取油温。

此外，CANdelaStudio存储SWC提供温度的端口，以及从该端口读取数据的诊断服务。利用这一信息，CANdelaStudio能导出用于诊断映射的DEXT文件。DaVinci Configurator Pro读取DEXT文件，并且从中获取诊断相关BSW的配置信息。DaVinci Configurator Pro还负责生成诊断相关BSW的SWC接口，并且将其连接到SWC的端口——这是一种与AUTOSAR DEXT诊断映射兼容的方法。

图3 基于Vector工具链的诊断工作流实例

5

总结和展望

AUTOSAR DEXT提供了诊断开发领域的新可能，包括数据的精确描述(包括BSW配置信息的获取)，OEM和Tier1之间的分布式诊断开发，以及自顶向下自动集成ECU的诊断功能。Vector的诊断工具链支持这些功能，同时确保ODX和DEXT数据的同步。

AUTOSAR DEXT可以用于AUTOSAR Classic Platform和AUTOSAR Adaptive Platform。