做诊断开发,绕不开存储问题。当某个监控Event故障以后,对应DTC的快照信息(Snapshot)、拓展数据(Extended Data)等均需要存储。了解Event内存管理从哪里入手呢?似乎有点老虎吃天。不妨从DEM(Diagnostic Event Manager)的"Event memory management"聊起。本文关注两点:
Event storage处理
Event retention处理
1、Event storage处理
根据项目的需求,会对关注的Event进行监控(Monitor),确保车辆运行过程中,这些Event的可靠性。这些Event是什么呢?eg:电压是否短路、CAN通信是否Busoff、通信报文是否丢失等等。
Autosar提供了故障上报的标准接口Dem_SetEventStatus()或者Dem_ReportErrorStatus()。通过这两个接口可以将Event的状态(PREFAILED | PREPASSED | FAILED | PASSED)上报给DEM。具体的事件故障信息的存储流程如下所示:
(1)检查Event监控使能条件(enable conditions)的有效性,如果无效,则忽略Event的处理,即:不管上报何种Event Status,均不处理。注意:使能条件的检查是指每次Event状态上报给DEM时均需要检查,即每次调用Dem_SetEventStatus()或者Dem_ReportErrorStatus()上报Event状态时均先检查使能条件。这里延伸一下FDC(fault detection counter)的处理问题:如果Event的使能条件不满足,Event对应的FDC是否需要复位?答:看主机厂的要求,FDC复位与否均可,但是个人更倾向FDC复位的处理。
使能条件有哪些呢?eg:诊断电压范围、对应的PNC是否置位、是否busoff等。具体条件需要参考项目需求,不同的Event也可能对应不同的使能条件;
(2)Event监控使能条件满足以后,根据上报的Event Status,进行处理:
如果上报的Event Status == FAILED,则将UDS Status Bit0(Test Failed bit)、Bit1(Test Failed This Operation Cycle)、Bit5(Test Failed Since Last Clear)置位(=1)。Bit4(Test Not Complete Since Last Clear)和Bit6(Test Not Complete This Op Cycle)清零(=0)。
如果上报的Event Status == PASSED,则将UDS Status Bit0(Test Failed bit)复位,Bit4(Test Not Complete Since Last Clear)和Bit6(Test Not Complete This Op Cycle)清零。
如果上报的Event Status == PREFAILED or PREPASSED,则进行去抖处理(debouncing),Event完成去抖以后,需要检测其是否达到对应的成熟度(Qualification),即:FAILED或者PASSED。如果Event没有达到对应的成熟度,则继续监控。
提示:Event Status是指事件状态,即:PREFAILED | PREPASSED | FAILED | PASSED等,而UDS Status是指Event对应DTC的8个bit状态位。一个DTC可以对应多个Event。
(3)当Event Status == FAILED以后,检查Event存储条件的有效性,如果不满足存储条件则跳出剩余流程,如果存储条件有效,则执行Event对应信息的存储动作;
存储条件如何理解呢,与使能条件有什么不同?eg:存储数据是否需要更新就可以作为存储条件的检查。同一个Operation Cycle,如果某个事件故障发生了多次,不同的时间点,对应的快照信息或者拓展数据不同,是否需要更新这些信息可以设置。
14229-1中对DTC Storage Condition的解释:
解释:当DTC status bit再次置位的时候,eg:当前的Operation Cycle,Bit0(Test Failed bit)再次置位,对应的DTC Extended或者Snapshot data已经不同与上次故障发生的数据,同时也满足了Bit3(Confirmed DTC bit)置位,是否需要将此次故障数据存储更新到NVM即可作为存储条件。
(4)Event对应信息存储有效时,则Event对应的UDS Status Bit2(Pending DTC bit)置位。之后进一步判断Event是否满足Confirmed条件,即:事件Failed的次数是否达到confirmation threshold(eg:1),如果满足,则置位Bit3(Confirmed DTC bit),否则,进一步判断Event存储的触发方式;
(5)Event信息存储方式如果是DEM_TRIGGER_ON_CONFIRMED,则需要进一步识别Bit3(Confirmed DTC bit),如果Bit3置位则进一步处理Event信息的相关存储动作,否则,跳出Event存储流程;Event信息存储方式如果是DEM_TRIGGER_ON_PENDING,则需要进一步识别Bit2(Pending DTC bit),如果置位则进一步处理Event信息的相关存储动作,否则,跳出Event存储流程;
(6)Event相关信息进行存储。按照14229-1要求,这些数据主要包含两类:快照数据(snapshot data,也称冻结帧(freeze frames))和拓展数据(extended data);
(7)检查Event的存储结果,即:是否有效地存储到NVM中。Event不满足存储且DemResetConfirmedBitOnOverflow == TRUE,表明事件信息没有被存储。如果存储成功或者DemResetConfirmedBitOnOverflow == FALSE,则进一步检查指示灯的使能条件,如果满足使能条件,则将状态字节Bit7(WarningIndicatorRequest bit)置位。至此,执行完Event的存储流程。
2、Event Retention处理
当Event对应的DTC满足存储条件时,需要对此Event相关的数据(freeze frames, extended data)进行存储,这里的freeze frames是指Snapshot。具体Event数据存储流程如下所示:
(1)检查此Event的对应数据是否已经存储;
(2)如果Event没有存储,检查是否有空用的存储空间,如果有可用的存储空间则存储Event对应数据;如果存储空间已满,则进行替换策略的处理(displacement);
提示:工程中,会设置很多DTC,受限于硬件资源(NVM Size),一般不会将所有Event的故障信息都存储。举例:设置了200个DTC,只存储10个DTC对应Event的故障信息,如果已经存储了10个DTC的故障信息,当有新的Event Failed时,需要按照预先设计的替换策略进行故障信息的替换。即:将已经存储在NVM中的某个DTC对应故障信息清除,存储更重要Event故障信息。
(3)如果Event对应DTC无法替换已存储的DTC,则存储失败。如果Event对应DTC可以替换已存储的DTC,则将已经存储的old DTC替换出来,new DTC存储到内存中。
提示:Autosar中,1表示Event的Priority最高,数值越大,说明Event的Priority越低,如下所示: