AutoSar之诊断事件管理①

​最近一段时间，整理下Dem的知识和大家分享。

本文宏观上介绍下Dem在AutoSar架构中的角色和位置。

Dem(Diagnostic Event Manager)诊断事件管理，属于Autosar BSW(Basic Software)中的系统服务，在整个架构中所处的位置如下图。

阐述下图中的概念：

功能抑制管理(Function inhibitor Manager, FiM)

代表对软件组件所需动作(例如抑制特定监视器)的事件进行评估和分配。当监测状态发生变化时，Dem通知并更新功能抑制管理器(FiM)，以便根据分配的依赖关系抑制或释放功能实体。

诊断通信管理器(Diagnostic Communication Manager, Dcm)

负责UDS和SAEJ1979通信路径和诊断服务的执行，从而处理来自外部测试人员或OBD系统的诊断请求。它转发来自外部扫描工具的请求，并进一步负责封装响应消息(DTC、状态信息等)，这些消息随后将被传输到外部诊断扫描工具。

J1939 (J1939 Dcm)诊断通信管理器，负责SAE J1939-73诊断通信协议。

软件组件(SW-C)和底层软件(BSW)模块，可以访问Dem来更新和检索当前监控状态、UDS状态等信息。SW-Cs和BSW模块可以从Dem中检索数据，例如打开或关闭指示灯。底层监控是SW-C/ BSW模块的子组件。

数据提供：SW-Cs和BSW模块将提供Dem所需的数据(即事件相关数据)，例如，能够创建事件存储。

NVRAM管理器(NvM)提供了在NVRAM中存储数据块的机制。NVRAM(最大大小取决于配置)被分配给Dem, Dem使用NVRAM块实现UDS状态信息和相关数据的永久存储(例如过电复位)。

RTE为BSW实现调度机制，例如为ECU中使用的每个BSW模块分配优先级和内存保护。

为什么需要诊断呢？可能学校里的同学不太理解。诊断的功能在ECU设置中不可或缺，尤其在日益严格的法规面前。大家可能不太相信，目前我们做的国六项目中，有40%以上的代码是在为满足功能安全和法规要求而存在。我以前在学校做控制器的时候，也是非常随意，什么诊断，什么功能安全，什么ASIL等级，什么失效模式，统统不care。但是企业做产品时，这些问题必须要考虑，有些问题权利机关担心我们不考虑，通过写入法规来严格要求我们的产品。

上面提到的Dem，其实主要有两方面的作用：需要关闭适当的功能和给错误处理提供有用的信息。你想象一下，如果感觉不舒服去医院，通过多项检查得出肝不太好的结论。把上面的一系列过程比作软件诊断，Dem在其中就是通过化验数据的处理得出这个人的病症（故障）在肝，并将这个病症存储，例如存写在病历中。有了病症（故障）信息，医生就可以建议患者不要喝酒(这如同（Fim功能抑制，将喝酒功能禁用），也可以将病症（故障）信息告诉家属（这如同Dcm诊断通讯管理），诊断系统是类似的。

使用AutoSar 官方文件中描述来总结一下：
Dem服务组件，负责处理和存储诊断事件(故障)和相关数据。此外，Dem向Dcm提供故障信息(例如，从事件内存中读取所有存储的DTD)。Dem提供了与应用层和其他BSW模块的接口。

有关AUTOSAR的材料，可以关注微信公众号“汽车控制与人工智能”后，回复“AUTOSAR”获取。