与DEM的初次见面
先来一份缩略词的全称解释
Abbreviation | Description: |
BSW | Basic software |
ECUM | ECU state manager |
DCM | Diagnostic communication manager |
DEM | Dianostic event manager |
FIM | Function inhibition manager |
NVM | NVRAM manager |
SWC | Software componen |
两份DEM相关文档连接:
AUTOSAR_EXP_LayeredSoftwareArchitecture:
https://download.csdn.net/download/Sure_gengjia/12363653
AUTOSAR_SWS_DiagnosticEventManager.pdf:
https://download.csdn.net/download/Sure_gengjia/12363541
DEM全称diagnostic event manager,主要是用于处理诊断事件(如检测12伏电压是否异常)和存储相关数据(如扩展数据、冻结帧等)。同时也给其他模块通过标准接口提供信息,如DCM可以通过
Dem_ReturnGetStatusOfDTCType Dem_DcmGetStatusOfDTC(
uint32 DTC,
Dem_DTCOriginType DTCOrigin,
uint8* DTCStatus)
这个标准接口同步或异步的读取到指定的DTC的故障状态。
下面将从以下几个方面,感性地分享一下DEM在AUTOSAR中的规定:
- DEM与不同模块之间的联系;
- DEM包括哪些子功能,这些功能又是怎么实现的呢?
首先从架构的角度看DEM,DEM处于BSW的服务层,见图一,与之交互的模块有SWC、BSW、ECUM、FIM、DCM、NVM,见图二。
图一:mapping of basic software modules to AUTOSAR layers
图二:dependencies of the Diagnostic Event Manager to other software modules
DEM与其他模块间的关系:
SWC:
其中应用层SWC会周期调用故障监控函数,并周期调用标准接口Std_ReturnType Dem_SetEventStatus(
Dem_EventIdType EventId,
Dem_EventStatusType EventStatus)
把故障及状态报给DEM,DEM会根据预先配置的debounce方式调用相对应的函数。然后根据debounce的结果决定是否把当前故障加入到fault memory中和触发FIM。该内容的详细介绍在DEM与其他模块的联系章节的SWC部分和DEM内部模块的debounce部分会涉及到。
BSW:
BSW也会给DEM报故障,根据AUTOSAR规定,BSW通过调用
void Dem_ReportErrorStatus(
Dem_EventIdType EventId,
Dem_EventStatusType EventStatus)
标准接口给DEM报故障,故障内容如NVM写入失败或者排队任务数溢出或者校验错误。该类故障在DEM中的debounce方式是no debounce,不需要debounce,所以故障状态只有DEM_EVENT_STATUS_FAILED或者DEM_EVENT_STATUS_PASSED。
ECUM:
ECUM主要负责在不同时序调用DEM的初始化工作,
DEM初始化应包括
- 对每个故障的debounce status做处理;
- 初始化fault memory相关数据;
- 初始化DEM中存储的BSW的故障数据。
FIM:
FIM全称function inhibition manager,主要负责给SWC提供一个控制机制,可以使能或者失能SWC的功能,如SWC中电压检测功能,此时由于其该功能被抑制,SWC此时使用Dem_SetEventStatus报给DEM的故障状态是no condition。
另外在SWC调用Dem_SetEventStatus时,如果故障状态发生变化,DEM会通过调用
void FiM_DemTriggerOnEventStatus(
Dem_EventIdType EventId,
Dem_UdsStatusByteType EventStatusByteOld,
Dem_UdsStatusByteType EventStatusByteNew )
来抑制SWC本身的功能和与之相关的事件的功能。详细内容请期待FIM模块的分享。
DCM:
DCM和DEM之前有着密切关系,因为DCM中有ReadDTCInformation和ClearDiagnosticInformation这两个服务都是都是要从DEM中读取信息或者传递命令,还有PID01请求当前动力诊断数据等服务。比如根据DTC读冻结帧(也叫快照)(19 04 xx xx xx yy),在19服务的自服务的处理函数里面,首先就要调用
Dem_ReturnGetStatusOfDTCType Dem_DcmGetStatusOfDTC(
uint32 DTC,
Dem_DTCOriginType DTCOrigin,
uint8* DTCStatus)
给DEM传递DTC和该DTC所属的memory类型,来获得DTCStatus;然后调用
Dem_ReturnGetSizeOfDataByDTCType Dem_DcmGetSizeOfFreezeFrameByDTC(
uint32 DTC,
Dem_DTCOriginType DTCOrigin,
uint8 RecordNumber,
uint16* SizeOfFreezeFrame)
获得冻结帧(快照)的数据大小,因为数据大小和数据内容是提前配置好的,也可标定。最后调用
Dem_ReturnGetFreezeFrameDataByDTCType Dem_DcmGetFreezeFrameDataByDTC(
uint32 DTC,
Dem_DTCOriginType DTCOrigin,
uint8 RecordNumber,
uint8* DestBuffer,
uint16* BufSize)
获取冻结帧。但是DCM和DEM是两个不同的任务,所以以上几个函数一般是异步执行,DCM只负责把请求命令和写入目标给到DEM,在DEM任务中轮询DCM的任务请求,并实现数据的填充,后通知DCM任务完成。DCM再通过肯定相应回复数据。
NVM
NVM之于DEM主要在于存储啦,NVM也就是NVRAM manager,司职于非易失性数据的存储和维护。而DEM中又有大量数据需要存储在非易失性存储模块(如Dflash、EEPROM)中,但两者的交互关系都发生在上电初始化(startup)和下电(shutdown)过程中,当然,如果没有NvM_WriteAll的过程,也可以在运行过程中写入。
DEM需要存储在非易失性存储模块的数据包括19服务中会用的相关数据(如第一次出现的故障,第一个confirm的故障、最新的故障等等)、primary fault memory中的数据、mirror memory中的故障、OBD相关的数据、冻结帧、预存的数据、Debounce的状态(甚至是debounce counter)等,这些数据会在NVM_Readall的时候读取到DEM的RAM中,下电的时候会在NVM的writeall时从DEM的target RAM写入非易失性存储区(non-volatile memory)。
DEM内部分很多子模块,每个子模块分工不同,任务明确。INIT负责对DEM内部变量根据配置内容进行初始化。debounce负责对事件发生故障的有效性和事件表现正常的有效性的做滤波判断,如KL30电电压超过16伏100ms,该事件才会报KL30过压故障;primary fault memory负责存储当前发生的故障的DTC及相关数据,如冻结帧、扩展数据等。operational cycle management负责管理各种操作循环的判断,如对于OBD-related ECU中OBD drving cycle开启时才能故障状态才能进入confirm的状态,这也和项目配置有关;其它子模块及以上模块详细内容,敬请期待下一次的分享——DEM子模块详细分析。
更多内容,可关注公众号“激活未来”。