| DEXT、DCM、DEM和FIM的概述
DEXT(Diagnostic Extract Template)是AUTOSAR定义的诊断提取模板,用于DCM(Diagnostics Communication Manager)、DEM(Diagnostics Event Manager)以及FIM(Function Inhibition Manager)的需求及配置定义。
DCM的配置包括诊断服务的设置和由一个或多个软件组件(例如:Composition 1、Composition 2)提供的数据对象的分配。
DEM的配置包括故障存储数据(DTCs和环境数据)以及由一个或多个SwComponentTypes分配的相应数据(如Composition 1、Composition 2)。
FIM作为功能抑制管理主要描述对软件组件及其功能的控制机制。它可以在运行时显著地修改应用软件的行为。
例如:响应传感器故障,如果一个与硬件传感器相关的诊断事件被报告为“失败”,那么FIM可以修改应用软件的行为,使其不再依赖已经不可靠的传感器信息。它决定抑制的条件来自DEM中定义的诊断事件,因此可以说FIM和DEM模型的配置是紧密相关的。
在DEXT中,DCM大致对应AUTOSAR协议中的诊断服务描述,DEM大致对应AUTOSAR协议中的诊断事件处理的描述。综上,DEXT涵盖AUTOSAR支持的用于诊断的所有基础软件模块的配置,主要内容包括:
- UDS/OBD/WWH-OBD/SAE J1939等协议定义的诊断服务和相关子服务在AUTOSAR架构中的配置数据;
- 诊断数据元素和相关数据类型;
- 故障路径和故障存储器(Fault Memory);
- 将诊断数据元素映射到应用软件;
- 功能抑制(FIM)。
| 用例分析
使用DEXT,不仅可以描述相应协议传输的数据,还可以描述ECU应用软件中数据的来源。当且仅当两种类型的信息均可用时,才可以完全配置基础诊断软件。
AUTOSAR协议中定义了两种通用用例的诊断的配置过程。此过程涉及以下三方:
- OEM或Diagnostic Requester;
- Application Developer或Application Developer;
- ECU-Supplier或Integrator。
在用例1中,一些软件组件由OEM(或OEM的供应商)实现,并且Diagnostic Extract数据的首次合并由OEM执行。
在用例2中,OEM通过Diagnostic Extract提供诊断需求,多个Application Developer提供与其实施相关的信息,合并完全由ECU-Supplier执行。
此外,用例1和用例2也可以结合使用。ECU供应商也可以实施软件的某些部分,包括其相应的Diagnostic Extract。
对OEM而言,OEM或diagnostic requester使用Diagnostic Extract来定义一个或多个ECU诊断接口。它还可能会将一些Internal Behavior定义为ECU-Supplier或Application Developer的需求,例如:
- 定义DTCs的值;
- 定义ECU支持的UDS服务或子服务;
- 定义Application Developer实现的特定组合所需的事件。
| DEXT的应用
DEXT可以满足AUTOSAR诊断模块的需求,主要应用于开发阶段的代码设计,支持AUTOSAR Classic以及Adaptive平台。
目前市场上,为了减少AUTOSAR配置的复杂性,会选择使用ODX或者CDD文件导出DEXT做AUTOSAR实现,虽然CDD (*.cdd) 、ODX (*.odx或*.pdx) 以及DEXT (*.arxml) 都是描述诊断相关信息的数据库,但是它们并不能互相替代,侧重覆盖的应用场景也不一样。如果使用ODX或者CDD做AUTOSAR实现,必然是需要补充ODX/CDD转DEXT所缺失的数据才能满足需求。
| VisualODX 3.0 版本
VisualODX 3.0版本通过EXCEL诊断问卷调查表扩展了DEXT定义所需支持的内容,新增了对服务及DID的Access Permission定义和对事件(Event)数据的支持。
该版本可以直接通过用户的诊断问卷调查表导出ODX/DEXT文件,不仅可以满足客户AUTOSAR架构中诊断模块软件实现的DEXT数据,而且能保证数据同源,方便统一维护。
| 往期回顾
▶ 实现Excel到ODX/PDX数据文件的自动转换工具:VisualODX—ODX