AUTOSAR-DEM模块几点思考！

DEM全称“Diagnostic Event Management”，该模块作为AUTOSAR架构中的BSW模块之一，对于ECU软件开发也是必需的软件模块，了解该模块自身属性以及与其他模块的关系也显得尤为重要。结合自身开发经验，我将从以下六个方面对该模块进行简要介绍和几点思考。

诊断故障管理模块主要涉及到故障事件监控，故障信息上报、故障信息处理以及故障信息存储等四个基本环节，它们之间的基本关系如下图1所示：

图1 故障上报流程图

1. 故障事件触发

故障监控的基本单元是事件（event), 上报事件可以来自于BSW模块，也可以来自SW-C模块，事件的监控策略方式由各个上报故障事件的模块自行决定，但故障事件定义需满足图2.1以下几条基本原则：

图2.1 事件定义基本原则

如果未能按照上述基本原则去定义事件或者触发方式，可能会出现故障事件重复上报、事件多报或者误报等问题，甚至很难快速定位到问题所在，没有真正起到事件监控应具备的基本特点：准确性、合理性、独立性等。良好的故障事件定义将会为整个故障管理打下坚实的基础，为故障分析提供一种强有力的手段。

  2. 故障信息上报

经由BSW模块或者SW-C模块上报的故障事件，有多种上报方式，如通过RTE接口、DEM模块标准接口来上报，一般是同属于BSW的模块直接调用RTE或者DEM标准接口均可，对于SW-C模块则需要通过RTE来上报故障事件。其中，调用DEM标准接口时，也存在四种调用方式，如下图2.2所示：

图2.2 故障上报五种方式

由图中所示，上述5种上报方式的选择，一般根据是否位于BSW模块，是否需要上报相关环境数据、是否需要在诊断监控开启之前监控等因素来决定。

3. 故障信息处理

当Dem模块收到来自BSW或者SW-C模块的故障事件及状态会进行相应的处理，上报故障事件状态可分为四种：PreFail、PrePass、Passed、Failed。其中前两者需要经过TimeBased 或者CounterBased 的debouncing 策略来进一步判定故障是否成熟，而后二者则可以直接判别故障是否成熟。如下图3所示：

图3 故障信息处理流程图

4. 故障信息存储

经过上述诊断信息处理后，为了便于故障发生后能够保留现场，因此需要将相关故障信息存储至Flash或者EEPROM中，此文中先不过多讨论故障信息如何在内存中存储，若以何种方式存储故障信息来区分，常规存储故障信息方式一般有两种，循环故障信息存储与休眠时存储；若以存储区域划分，可以分为内部故障信息存储区（IFM）与客户故障信息存储区（CFM）；通过分析优缺点、应用场合等维度来对故障信息存储分析如下：

存储方式	优缺点	应用对象	存储区域	应用场合
循环存储	能够实时存储故障信息，信息频繁更新存储，大量占用RAM	KL15 ECU	IFM	详细故障信息存储，内部可见，客户不可见。
休眠存储	仅在ECU休眠时存储，不会占用大量RAM，适用于大量故障信息的存储。	KL30 ECU	CFM	常规故障信息存储，内部及客户均可见。

5. 故障系统降级

当ECU系统检测到任何故障时，按照功能安全的要求，系统将会作出相应的系统降级行为，以保证整车行车安全。按照AUTOSAR标准规范，图4是从故障信息上报到系统降级的数据流程图，故障上报给到DEM模块，DEM模块会先进行前期故障信息处理，后期将故障评估结果映射到FIM模块，各模块无论是BSW还是SW-C就会识别相应的FIM ID状态来决定系统作出相应的反应。

图4 系统故障降级数据流

6. 故障监控存储基本原则

在设计系统故障监控、故障信息预处理、故障存储、故障降级等环节时，务必本着设计先行、故障依赖性明确、故障信息获取全面、降级方式合理等原则来设计故障监控存储系统，将能够最大程度上来保证ECU系统的稳定性与鲁棒性且大大提供故障分析效率并最终准确定位到问题所在。

标签：AUTOSAR,存储,信息,故障,DEM,模块,上报,事件
来源： https://blog.csdn.net/king110108/article/details/119273813