搞诊断开发的小伙伴,对于事件(Event)状态应该并不陌生。在Event状态的讨论中,很多时候我们是在讨论Autosar DEM(Diagnostic Event Manager)规范中的事件状态。但是,有些小伙伴有时会与UDS(U...
搞诊断开发的小伙伴,对于事件(Event)状态应该并不陌生。在Event状态的讨论中,很多时候我们是在讨论Autosar DEM(Diagnostic Event Manager)规范中的事件状态。但是,有些小伙伴有时会与UDS(Unified diagnostic services)的DTC(Diagnostic Trouble Code)状态(Status)混淆。所以,本文聊一聊Event状态、DTC状态到底是怎么一回事,Event状态又是如何影响DTC状态变化的?
1、事件(Event)状态
在DEM规范中,事件状态包含五种状态:DEM_EVENT_STATUS_PASSED、
DEM_EVENT_STATUS_FAILED、DEM_EVENT_STATUS_PREPASSED、DEM_EVENT_STATUS_PREPASSED、DEM_EVENT_STATUS_FDC_THRESHOLD_REACHED。具体描述如下所示:
图片
如上图,还是有些信息量的,值得我们细细的“咀嚼”一下:1、Event的五种状态是监控(Monitor)后的结果(Result),至于如何监控每一个事件(Event),依赖于事件的需求输入;2、对于DEM_EVENT_STATUS_FDC_THRESHOLD_REACHED,工程上似乎很少用,如何理解呢?这个状态的存在,主要是为了采样(Sample)数据(eg:拓展数据、冻结帧)设置的。更多信息,可以参考前文《诊断基础:你还见过怎样的快照数据(Snapshot Data)采样和存储策略?》;3、在Auotosar的软件架构中,事件状态最终由DEM模块处理,因此,事件状态可以通过Dem_SetEventStatus()上报。该接口可以由SW-Cs(上层应用组件)通过RTE(Runtime Environment)调用,也可以由BSW(Basic Software,基础软件)中的软件模块直接调用。有意思的是:规范中提到,BSW调用该接口时,不用判断返回值,也可认为是安全的。BSW和SW-Cs调用该接口的关系示意如下:图片
提示:在Autosar 4.2(包含)之前的版本中,BSW模块中的事件状态还可以通过Dem_ReportErrorStatus()接口通知DEM,而且可以将事件状态异步(asynchronous)、队列(Queue)存储。在Autosar 4.2之后的软件版本中,Dem_ReportErrorStatus()接口不再使用,大家基于Autosar软件架构开发时,注意两个接口的使用。(一)DEM可以存储初始化或者Shutdown过程中的事件状态吗DEM可以存储初始化或者Shutdown过程中的事件状态吗?答案是肯定的,Autosar DEM中给出的解释如下所示(1):图片
如上图,在软件初始过程中,某些模块(主要指BSW)初始化错误(eg:某驱动模块),但是DEM还没有正常工作,不能处理上报的事件状态。此时,故障模块可以将对应事件状态缓存(Buffer)起来,等到DEM被正常调度后,处理缓存的事件状态。
2、DTC状态
按照UDS规范的解释,DTC状态由一个字节(1 byte)的8个bit位表征故障状态。关于每个bit的具体含义,可以参考前文《Autosar DEM诊断事件管理(一)》。
DTC不同状态bit的变化又因Event状态变化而触发,两者更详细的变化规律可以参考前文《Uds诊断:不同Operation Cycle下的DTC状态位变化》。
本文着重聊一下UDS故障状态的bit0和bit3关系。
DTC bit0(test Failed):侧重描述当前驾驶循环中,被监控事件(Event)是否成熟(matured)。也就是说:被监控事件(eg:蓄电池欠压事件)经过去抖(debunce)处理后,确认故障真实发生(eg:蓄电池电压<6V,持续1s),该bit状态由0->1变化。在一个驾驶循环内,被监控事件可以多次成熟,所以,DTC bit0可以多次由0->1变化,示意如下:
图片
DTC bit3(confirmed DTC):侧重描述故障是否确认。而故障的确认需要满足故障的确认阈值(Confirmation Threshold),对于Confirmation Threshold,UDS的规范中用Trip Counter表征。也就是说,Trip Counter≥指定阈值(用户自定义)以后,DTC bit3由0->1变化。而Trip Counter与驾驶循环关联,即:一个操作循环内,Event多次成熟,即使DTC bit0多次由0->1,Trip Counter也只累加一次,示意如下:
图片
一般来说,对于non-OBD场景,Trip Counter一般设置为1,即:一个驾驶循环内,Event成熟,DTC bit0由0->1变化,Trip Counter = 1,进而DTC bit3由0->1变化;对于OBD场景,Trip Counter一般设置>1(eg:3),即:每个驾驶循环内,DTC bit0均至少经历一次0->1变化,Trip Counter累加1,当Trip Counter = 3后,DTC bit3由0->1变化。
对于OBD场景,Trip Counter、DTC bit0、DTC bit3变化,示意如下:
图片
如上图,每个驾驶循环结束后,Trip Counter需要存储非易失内存(NVM,
Non volatile Memory),以便于下一个驾驶循环可以基于上次的计数进行操作。
参考资料
(1)Specification of Diagnostic Event Manager AUTOSAR CP Release 4.4.0
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报。