关于AUTOSAR-DEM模块的简要介绍和几点思考-电子发烧友网

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

诊断故障管理模块主要涉及到故障事件监控，故障信息上报、故障信息处理以及故障信息存储等四个基本环节，它们之间的基本关系如下图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状态来决定系统作出相应的反应。