故障码有以下两点意义:
1)产线下线检测:一辆车的零部件的开发,系统集成,整车组装,其中涉及的流程之长,零部件数量之多,可以说是相当复杂。为了产线生产的车能正常下线,安全上路,就需要确保在车辆下线前,各零部件本身以及零部件相互配合是没有问题的。因此在产线电检流程中,会读取整车故障码,通过故障码说明车辆是否正常。
2)车辆维修:当车辆出故障时,维修工程师是如何快速定位到故障零部件呢?车辆是由上万个零部件组成,如果依赖于维修工程根据经验慢慢排查,效率会极其低下。因此,维修工程师会使用诊断仪读取整车故障码,并将故障码与故障现象对照,快速得出维修策略。
以非排放相关的ECU为例,可以将DTC故障类型分为以下几个部分:
通讯相关故障:如报文丢失、信号无效,Checksum/Rolling 障等
status Of DTC: bit field name | Bit | Bit state | Description |
testFailed | 0 | 0 | DTC is not failed at the time of the request |
testFailedThisOperationCycle | 1 | 0 | DTC failed during the current operation cycle |
pendingDTC | 2 | 0 | DTC was not failed on the current or previous operation cycle |
confirmedDTC | 3 | 0 | DTC is not confirmed at the time of the request |
testNotCompletedSinceLastClear | 4 | 0 | DTC test was completed since the last code clear |
testFailedSinceLastClear | 5 | 0 | DTC test never failed since last code clear |
testNotCompletedThisOperationCycle | 6 | 0 | DTC test completed this operation cycle |
warningIndicatorRequested | 7 | 0 | Server is not requesting warningIndicator to beactive |
类型 | 组成 | 内容 |
冻结帧 | 由一系列DID组成,用户可以自定义DID内容 | 描述车速,温度,油量,等信息 |
扩展信息 | 由一系列DID组成,DID内容由BSW规定 | 描述故障码的额外信息,比如老化周期数量。 |
3. 故障确认后:故障的老化,替代,实现故障修复后,故障能被清除的功能。例如,仪表上的发动机故障灯,在发动机修好后一段时间后就会熄灭。
Dem位于AUTOSAR架构系统服务层,系统服务层提供了以下服务:
1.操作系统调度与监控服务、
2.通信与网络管理服务
AUTOSAR架构图
Dem与其他模块关系链路图
在介绍DEM的具体功能前,先引入概念“Diagnostic event”,“Diagnostic event”也是DEM模块中最重要的元素。对于AUTOSAR软件架构,DTC只是展示给诊断仪使用者,而Event才是DTC状态实际操控者,同时Event也是诊断NVM数据存储实际控制者。
为什么要引入 “Diagnostic event”呢?
“Diagnostic event”来源?
“Diagnostic event”有哪些特性呢?
“Diagnostic event”怎么控制DTC?
“Diagnostic event”怎么控制诊断数据存储?
接下来将会给大家一一解答上述问题。
1.描述层级:DTC是系统层面对于故障的描述,而Event是软件层面对故障监控的最小单元。
3.event之间的依赖关系决定了DTC的依赖关系;
Event Kind | 来源 | 上报方式 | 函数名 |
BSW Event | BSW模块 | 标准C接口 | Dem_ReportErrorStatus |
SWC Event | SWC模块 | RTE接口 | SetEventStatus(RTE) |
2.Event priority
对于诊断,能够存储的故障事件以及对应冻结帧等相关数据的数量是恒定的,需要软件开发工程师提前配置。当内部存储的故障事件已经满了,Event优先级可以解决新的故障事件如何存储的问题。
诊断事件优先级有下面几个重要特点:
2)Event优先级仅在诊断事件已经存满情况下发挥作用,其余情况根据FIFO原则存储。
3.Event occurrence
Event occurrence顾名思义就是故障事件上报计数器,故障上报次数越多,Event occurrence值越大,标志着该故障越“老”。“新”‘老’故障标签在后续新的故障事件如何存储的仲裁机制上也会发挥重要作用,这部分内容在后面的内容会详细说明。
1.每一个event memory entry都有对应的Event occurrence。
2.Event occurrence最大值为255。
3.Event occurrence的计数方式有如下两种配置选择:
配置属性 | 计数方式 |
DEM_PROCESS_OCCCTR_TF | Bit0(TestFail)由0跳变至1,Event occurrence +1 |
DEM_PROCESS_OCCCTR_CDTC | Bit0(TestFail)由0跳变至1和Bit3由0跳变至1,Event occurrence +1 |
上文对Event,冻结帧,扩展数据等作了详细描述,那么,这些数据在DEM中是怎么存储的呢?DEM提供了Event Memory概念,将Event,冻结帧,扩展数据全部归纳起来做了统一管理。废话不多说,开始探索Event Memory吧。
Event Memory分类:
类型 | 含义 |
DemPrimaryMemory | 存储EventId,故障状态,冻结帧,扩展数据 |
DemMirrorMemory | |
Permanent Event Memory | 用于存储OBD相关的DTC |
Event Memory组成架构图
当SWC或者BSW上报Event后,会经过哪些处理最终变成Flash中的Event Memory呢?
Event Memory management流程图
Event使能条件流程图
S1:首先,需要判断当前是否开启了操作循环,操作循环一般指的是点火循环,一个操作循环可以认为是DTC检测的一个周期。如果操作循环开启了,则开始下列的Enable Condition判断,否则直接退出整个Event Memory management流程。
S2::Enable Condition判断指的是Event上报增加的一个附加条件判断,Dem通过对应的接口给SWC使用,SWC实现附件条件处理。一般可以用来处理一些电压,车辆模式等限制条件。如果Enable Condition条件满足,则进行85服务判断;如果Enable Condition条件不满足,则直接退出Event Memory management流程。
S3: 若现在使用了85服务抑制DTC使能,则直接退出整个Event Memory management流程。若没有执行85服务,开始Event Debounce流程。
S4:经过Debounce后,如果最终Event结果为Pass或者Fail,则开始下一阶段Event控制DTC跳变;否则直接跳出退出整个Event Memory management流程。
本质上,Dem提供的Debounce为通过特定机制,处理PrePassed/Prefailed至Passed/Failed状态变化。
Dem提供了两种Debounce机制,即“Base Time”和“Base Counter”。
1.基于计数器的Debounce策略
基于Counter的Debounce策略的几个重要参数如下表格:
参数 | 含义 |
FDC(Fault Detection Counter) | 错误计数器,值范围为-128-127 |
DemDebounceCounterFailedThreshold | 使Event诊断事件状态最终为Failed的Debounce Counter阈值 |
DemDebounceCounterPassedThreshold | 使Event诊断事件状态最终为Passed的Debounce Counter阈值 |
DemDebounceCounterIncrementStepSize | 当SWC上报Prefailed,错误计数器增加量 |
DemDebounceCounterDecrementStepSize | 当SWC上报Prepassed,错误计数器增加量 |
基于Couneter的Debounce机制
如上图所示,在基于Counter的Deboucne机制中,Dem会提供一个计数器(FDC)用于记录判断的结果,当SWC上报给Dem的Event状态为Prefialed,计数器会按照步长增加,当达到设定的限值时,故障状态变成Failed。当上报状态为PrePassed时,计数器按照步长减少,当达到设定的限值时,故障状态变成Passed。
2.基于时间的Debounce策略
基于时间的Debounce策略的几个重要参数如下表格:
参数 | 含义 |
DebounceTimeBasedTaskTime | 基本的检测周期 |
DemDebounceTimeFailedThreshold | 定义故障状态从PreFailed跳转至Failed需要多少个DebounceTimeBasedTaskTime周期 |
DemDebounceTimePassedThreshold | 定义故障状态从PrePassed跳转至Passed需要多少个DebounceTimeBasedTaskTime周期 |
基于时间的Debounce机制
当Event经过一系列处理,最终能够对DTC状态进行更新,DTC 8个bit更新逻辑如下:
DTC Bit0 更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed |
1 -> 0 | 经Debounce后最终上报状态为Passed OR 使用14服务清除DTC OR 复位事件状态 |
DTC Bit0 更新逻辑图
DTC Bit1更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed |
1 -> 0 | 操作循环更新 OR 使用14服务清除DTC |
DTC Bit2更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed |
1 -> 0 | (操作循环更新 AND TestFailedThisOperationCycle == 0) OR 使用14服务清除DTC OR TestNotCompeleteThisOperationCycle == 0 |
DTC Bit2 更新逻辑图
DTC Bit3更新状态
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed AND Fialure Counter > = 故障确认阈值 |
1 -> 0 | 达到老化条件 OR 使用14服务清除DTC OR 故障溢出被替换 |
DTC Bit3 更新逻辑图
DTC Bit4更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed |
1 -> 0 | 使用14服务清除DTC |
DTC Bit4 更新逻辑图
DTC Bit5更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed |
1 -> 0 | 使用14服务清除DTC |
DTC Bit6更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed |
1 -> 0 | 使用14服务清除DTC OR 操作循环更新 |
DTC
Bit6更新逻辑图
DTC Bit7更新逻辑
Bit位更新 | 条件 |
0 -> 1 | 经Debounce后最终上报状态为Failed AND 点灯条件满足 |
1 -> 0 | 使用14服务清除DTC OR 点灯条件不满足 |
DTC
Bit7更新逻辑
DemEventMemoryEntryStorageTrigger | 分配条件 |
DEM_TRIGGER_ON_TEST_FAILED | DTC bit0 由0跳变成1 |
DEM_TRIGGER_ON_CONFIRMED | DTC bit3 由0跳变成1 |
DEM_TRIGGER_ON_PENDING | DTC bit2 由0跳变成1 |
DEM_TRIGGER_ON_FDC_THRESHOLD | DTC bit0 由0跳变成1 OR DTC bit1由0跳变成1 OR DTC bit2由0跳变成1 OR DTC bit3由0跳变成1 |
基本思路如下:
下图展示了整套Event Displacement机制,体现了三个核心原则在替换机制中的作用。
Event Displacement机制
分享不易,恳请点个【👍】和【在看】