CANdelaStudio工具与DEM（AUTOSAR模块）关于Event交互汇总

背景信息
CANdelaStudio是Vector公司编辑诊断数据库CDD以及导出ODX文件的编辑工具，使用时工程师基于ECU这段需求规范编辑诊断数据库，具体工具介绍和编辑方式见下（干货分享，参看公众号：车载诊断技术）：
《车载诊断技术》2021年CANdelaStudio操作指南集
DEM是AUTOSAR关于诊断的一个具体模块，主要处理负责故障事件的处理、故障数据的存储和管理。简单说其功能是故障事件确认前的故障debounce，故障事件确认时的故障数据存储，故障发生后的故障老化、故障替代（覆盖策略）。

本文分享内容是在诊断数据库CDD文件中，编辑诊断事件（Dignostic Event）相对应的介绍，主要用于在数据库中编辑完整后，导入配置工具自动生成相对应的代码。


诊断模块介绍
在车载控制器（ECU）做车载诊断功能实现时，现在业界主要策略是通过将诊断数据库加载到相应的代码配置工具中：
->通过配置工具配置BSW代码，配置工具各家都有相应的解决方案，主要是在UI交互界面对加载的诊断数据库做属性配置；
->通过对BSW和SWC交互配置（通过类似于RTE实现），当BSW需要上层应用层数据支撑，可以通过C/S、S/R、Server Call Point等接口方式，获取所需数据。
而对应ECU的诊断故障存储策略、DTC数据和属性的定义、实现是ECU实现诊断功能中非常重要的Specific内容。软件框架AUTOSAR中与诊断功能相关的基础软件BSW模块有：
->DCM(Diagnostic Communication Manager)；
->DEM(Diagnostic Event Manager)；
->FIM(Function Inhibition Manager)。

其中DCM模块负责从底层接收并处理Tester发送的诊断数据，其中DCM模块具体分DSL、DSD、DSP，详细定义可参看如下文章（公众号：车载诊断技术，里面有文章简介）：


基于实例探究车载诊断功能实现全流程（干货版）

而DEM模块主要负责处理和存储诊断故障及相应数据（主要是跟DTC相关服务Service 19/Service 14）。当DCM模块接受到Tester发送的诊断请求是关于DTC相关的服务，这个时候由DEM提供故障信息给DCM,当然当应用层和其他BSW模块也需要这方面的信息时，DEM同样提供相应接口供使用。
引申思考：
伴随着车载电子电器架构从分布式转换为中央处理器和域控制器融合架构，特别是ADAS在车身应用越来越深层次，对应的诊断故障策略也会带来新的变化，比如在DEM模块检测出相应的故障信息，对于该具体故障可以关联相应的事件出发，比如可以关联提醒事件，发送提醒信息给驾驶员（显示在人机交互界面），也可以作为功能降级的判断输入信息。
Return to today's topic!
本文中通过CANdelaStudio，工程师可以生成CDD文件，并将该文件导入配置工具DaVinci Configurator生成配置参数代码（仅以此为例）。编辑工具CANdelaStudio作为数据交互平台，还支持将CDD文件导出成ARXML（Diagnostic Extract Template）文件，作为DaVinci Configurator的配置参数代码生成的输入。

编辑工具CANdelaStudio在Version 12.0版本后，对其AUTOSAR 4.4  ARXNL格式的定义，增加了关于Event数据的配置界面。目的是为了解决使用者将CDD或DEXT文件导入配置工具DaVinci Configurator后，其中一些关于Event的DEM配置参数需要工程师手动配置的痛点。诊断工程师在开发阶段初期，编辑CDD文件的时候，基于需求规范：
->ECU诊断需求规范，定义ECU所需的诊断服务、DID、DTC及相应服务执行权限等；
->DTC属性参数文件，定义DTC触发条件、存储条件、维修策略、DTC覆盖策略等，比如可在FailSafe文件中定义。
诊断工程师基于规范在编辑工具CANdelaStudio中建立DTC和对应的Event的关系，从而减少手动配置配置代码工具带来的错误，提高开发效率，有效保证数据的一致性和有效性。

具体参数详解
在CANdelaStudio工具中，事件（Events）的配置界面在Diagnostic Instance ”Fault Memory”按钮下，配置界面具体如下图所示：

主要分为三个部分：
1、Events；
2、DTC Event Mapping；
3、Event Master Data。

Events
在车辆ECU运行过程中，Monitor单元负责监测硬件、通信或者算法等的错误（原则上伴随整个生命周期都在运行），如果Monitor单元监测到定义的具体错误（故障信号信息），需要报告一个诊断Event，DEM模块接收并处理来自SWC(开发工程师基于企业自身需求定义的检测策略)或其他BSW(如CanSM模块）报告的Event。因此需要定义Event的相关属性（在CANdelaStudio工具中）。

具体操作方式，新建Event定义属性如：

选择Event来源种类：故障Events源自上层SWC定义的事件触发或是BSW具体相关错误信息；

Operation Cycle：定义了监测Event开始和结束的条件，运行周期定义也有不同，可以是从ECU唤醒到休眠为一个周期，也可以是车辆Ignition On-Off为一个周期，各有不同，就看自身定义即可。

Debounce Algorithm：CANdelaStudio工具现阶段支持DEM去抖的方式，DEM去抖策略按照AUTOSAR定义有基于时间去抖和基于计数器去抖两种去抖策略，主要是为了防止故障误报。

Failure Cycle Counter Threshold：在诊断协议ISO 14229-1中称作“Trip Counter”，当Counter计数器达到阈值后，DTC Status字节中的bit3 ConfirmedDTC置1 ，这个阈值定义出现错误的Operation Cycle的数量。

Enable Conditions：DEM模块处理Event时的前提条件(e.g.车速>0km/h)。当DEM模块运行过程中接收到具体Event的状态(pre)Passed或(pre)Failed的结果时，DEM应先检查Enable Conditions。通过校验条件是否满足，DEM来决定是否执行改变DTCStatus字节，DEM去抖相关的计数器被冻结或复位等操作。

Storage Conditions：在检测过程中，DEM模块对Event的状态进行监控，当判断为Failed时， DEM应检查Storage Condition来判断是否应该存储该Event事件。

Freeze Frame Prestored：故障Event发生时，为了方便获取发生故障时的环境信息，规范中会定义快照信息来存储故障发生时的环境信息（一般通过DID来反馈故障发生时信息）。Freeze Frame相应数据是否预存储在这里做设置。



…In Memory: 定义存储策略，具体指Freeze Frame预存储的地方是在ECU掉电非易失内存中存储还是掉电易失内存存储。

Clear Allowed：定义清楚故障DTC及相应数据的清除策略。

1) 配置always，当收到清除故障信息的请求（比如说Service 14 FF FF FF），DEM模块会清除相关的快照数据、扩展数据，并且复位DTC Status字节等操作；

2) 配置requires callback execution，清除故障信息的请求需要调用回调函数来触发执行。

Indicator Connection：该配置项定义提醒驾驶员的指示设备，如故障指示灯、蜂鸣器等，原则上与DTC Status bit 7相关。



DTC Events Mapping
该配置界面主要是为了实现DTC与已定义的Event的映射关系，DTC与Event的对应关系可以有如下方式：
-> DTC与Event一一对应，一个Event事件触发具体一个故障DTC；
->DTC对应多个Event，该方式可能是后续发展趋势，因为车身越发复杂，考虑到DTC资源，会考虑该方式作为故障触发策略（个人之见）。
特别是在自动驾驶逐渐向高Level实现，车载控制器（域控制器、中央处理器）需要处理的诊断事件event会超级多，这个时候将多个类同event事件做归一性设置，会极大促使功能落地，也可以降低DTC资源。
该方式具体操作界面如下图所示：


Event Master Data
在CANdelaStudio工具中，工程师基于项目需求（Specific 规范），在工具交互界面手动编辑Event相关数据（Operation Cycles、Debounce Algorithm（Counter-Based、Time-Based）、Indicators），工具编辑界面如下图所示：


其中关于Operation Cycle（运行周期）类型，AUTOSAR规范中定义的以下几种：Undefined（自定义）、Ignition（车钥匙开关）、Warmup（暖机周期以发送机温度上下值）、Time、OBD Driving Cycle等，具体参看项目需求来实现即可；
Counter-Based算法包括AUTOSAR定义的Increment/Decrement Step Size、Failed/Passed Threshold等参数，通过计数来完成对Event的去抖动，具体内容后续有专文做分析；

Time-Based算法包括AUTOSAR定义的Failed/Passed Threshold、FDC Storage Threshold等参数，如下图纵坐标表示Event上报的状态类型（FAILED、PREFAILED、PREPASSED、PASSED）。该状态通过DEM提供的函数接口来体现。
在该区域中，每上报一次不同的event状态，如下图区域2中的FDC（Fault Detection Counter）都会发生相应的变化；
在区域3中，纵坐标是event经过去抖动算法之后的最终评估结果，亦称为故障成熟结果，分为PASS,FAIL两种结果：
当FDC == 127（Failed）时，Event Status == FAIL;
当FDC == -128（Passed）时，Event Status == PASS;



总结
车载诊断作为车身必要一个功能，扮演着重要作用，在后续智能驾驶领域不断推进过程中，也带来新的应用场景和更大的挑战，作为一个终身学习者，持续不断学习，不断提升自己！

另：疫情反反复复，这里祝各位多注意身体，各自身体各自负责！