您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
一文读懂AUTOSAR系列 – DEM功能详解
 
 
   次浏览      
 2023-11-23
 
编辑推荐:
本文将以最简单的方式将Dem的功能聊具体,聊透彻。希望对你的学习有帮助。
本文来自于微信公众号汽车电子嵌入式,由火龙果软件Linda编辑,推荐。

前言

Dem是AUTOSAR中配置项最多,实现功能最为复杂的模块之一,主要负责记录故障诊断以及其关联数据,是实现诊断功能至关重要的模块,本文将以最简单的方式将Dem的功能聊具体,聊透彻。为了方便大家学习,以下是本文的大纲。

1.诊断故障基础

当人患了疾病,便需要医治,医生根据各种检验结果找出病因,并得出诊治策略。当汽车出现故障时,DTC故障码就等同于“检验结果”,汽车工程师通过该标识码便可以查表的方式获得该故障信息,如故障触发条件、故障解除条件、系统功能表现等,得出解决该故障的策略。

DTC(Diagnostic Trouble Code)顾名思义诊断故障码,一种用来记录当ECU发生或者检测到某种故障时呈现给大家的标识码。

1.1 DTC的组成

DTC故障码是一个4个字节的标识符,由以下两部分组成:DTC Catogory 与Failure Type,其中DTC Catogory 又可以根据Powertrain、Body、Chasis、N etwork四大子系统来进一步定义其范围,简称PBCU四大子系统,如下表所示:

1.2 DTC的意义

故障码有以下两点意义:

1)产线下线检测:一辆车的零部件的开发,系统集成,整车组装,其中涉及的流程之长,零部件数量之多,可以说是相当复杂。为了产线生产的车能正常下线,安全上路,就需要确保在车辆下线前,各零部件本身以及零部件相互配合是没有问题的。因此在产线电检流程中,会读取整车故障码,通过故障码说明车辆是否正常。

2)车辆维修:当车辆出故障时,维修工程师是如何快速定位到故障零部件呢?车辆是由上万个零部件组成,如果依赖于维修工程根据经验慢慢排查,效率会极其低下。因此,维修工程师会使用诊断仪读取整车故障码,并将故障码与故障现象对照,快速得出维修策略。

1.3 DTC故障类型

以非排放相关的ECU为例,可以将DTC故障类型分为以下几个部分:

硬件故障:如RAM、Flash、CPU时钟等硬件本身失效的问题

软件故障:如配置字故障,标定故障或客户定义的软件功能性故障

外部环境故障:电压过高或者欠压、环境温度过高或过低等

通讯相关故障:如报文丢失、信号无效,Checksum/Rolling 障等

1.4 DTC状态位介绍

每个DTC都有一个字节用来表示该故障的状态,这个字节中每个bit的含义如下:

具体解释如下:

Bit0:请求时刻测试结果为失败;

Bit1:在当前点火循环至少失败过1次;

Bit2:在当前或者上一个点火循环测试结果不为失败;

Bit3:请求时刻DTC被确认,一般确认是在一个点火周期内发生错误1次;

Bit4:自上次清除DTC之后测试结果已完成,即测试结果为PASS或者FAIL结果;

Bit5:自上次清除DTC后测试结果都不是FAIL;

Bit6:在当前点火周期内测试结果已完成,即为PASS或FAIL状态;

Bit7:ECU没有得到点亮警示灯请求

1.5冻结帧与扩展数据

从上文可知,DTC中8bit位可以描述DTC状态,但8个bit位能够承载的信息是有限的,仅能说明故障是当前故障还是历史故障。故障发生时的车速,温度,油量,电量等关键信息怎么记录呢?

UDS中规定了冻结帧可以用来记录故障发生时的详细情况,扩展数据可以提供故障码相关的扩展信息,包括老化计数器。

 

2.DEM详解

2.1 DEM主要功能

Dem全称Diagnostic Event Manager,负责诊断故障事件的处理,存储诊断故障事件以及故障事件相关联的数据(故障发生时温度,车速等)。简而言之,Dem发挥了AUTOSAR架构中故障”中央处理器作用”,用户软件模块只需要将故障上报给DEM,所有故障信息的处理都由DEM执行:

1.故障确认前:用户模块上报故障的Debounce防抖处理,确保对应故障不为误报故障。

2. 故障确认时:故障事件确认时的故障数据存储至NVM,保证故障能长期保存。

3. 故障确认后:故障的老化,替代,实现故障修复后,故障能被清除的功能。例如,仪表上的发动机故障灯,在发动机修好后一段时间后就会熄灭。

2.2 DEM与其他模块关系

1)DEM在AUTOSAR架构位置

Dem位于AUTOSAR架构系统服务层,系统服务层提供了以下服务:

1.操作系统调度与监控服务、

2.通信与网络管理服务

3.存储服务

4.诊断服务(UDS通信服务以及故障服务)

5.ECU状态管理服务

从下面架构图可以看出,Dcm与Dem作为“诊断双雄”,完整提供了所有的诊断服务。区别在于,Dcm主修“UDS诊断通信服务”,对下与通信协议栈联系,与外部诊断仪交互提供诊断通信服务(10,22等服务);Dem主修故障诊断服务,与上层SWC,BSW模块交互,接收故障上报,与NVM交互使用存储功能。

AUTOSAR架构图

2)Dem与其他模块依赖关系

Dem与其他模块关系链路图

NVM: Nvm能够提供存储服务给Dem使用,即提供诊断故障存储所需的NVM BLOCK。需要注意的是,Nvm给Dem提供了两类存储服务接口,Nvm_WriteBlock()供DEM实时存储诊断故障,NvM_SetRamBlockStatus()供Dem下电存储诊断故障,上述存储模式可以在DTC配置属性中体现。

DCM:从上图中可以看出,DCM在接收到诊断仪的19服务(get Dtc),14服务(Clear Dtc)时,需要实时通过Dem获取DTC数据以及对DTC进行清除操作。

ECUM:对Dem模块执行初始化以及ShutDown操作。

SWC(Monitor):监控诊断故障事件Event,通过使用Dem_SetEventStatus()函数,将Event状态上报给Dem。使用Dem_SetOperationCycleState()对操作循环状态进行控制。

2.3 DEM核心Event

在介绍DEM的具体功能前,先引入概念“Diagnostic event”,“Diagnostic event”也是DEM模块中最重要的元素。对于AUTOSAR软件架构,DTC只是展示给诊断仪使用者,而Event才是DTC状态实际操控者,同时Event也是诊断NVM数据存储实际控制者。

各位读者肯定会有如下问题:

为什么要引入 “Diagnostic event”呢?

“Diagnostic event”来源?

“Diagnostic event”有哪些特性呢?

“Diagnostic event”怎么控制DTC?

“Diagnostic event”怎么控制诊断数据存储?

接下来将会给大家一一解答上述问题。

1)Event与DTC的联系与区别

区别:

1.描述层级:DTC是系统层面对于故障的描述,而Event是软件层面对故障监控的最小单元。

例子:某个电机故障会由电压过高造成,但软件是无法直接识别该故障,软件只能监控是否产生了电压过高的时间Event,从而计算出是否产生DTC.

2.链接关系:多个event可以mapping 同一个DTC;而同一个event不能mapping 多个DTC;

3.可见度:DTC可以直接可见,但Event需通过进一步手段才能看到,有时仅对ECU供应商可见;

联系:

1.DTC代表某类event集中表现,而event则是某个DTC的具体实例;

2.event的优先级决定了DTC的优先级;

3.event之间的依赖关系决定了DTC的依赖关系;

2)“Diagnostic event的上报方式

上文提到了SWC监控故障Event的状态,并可以通过Dem_SetEventStatus(EventId,EventStatus)向DEM上报Event状态。那么对于SWC,应该怎样上报Event状态呢?周期调用Dem_SetEventStatus上报即为周期循环上报;当Event状态变化时,调用Dem_SetEventStatus上报为触发上报。两种上报方式各有优缺点,如下图所示,切不可一刀切。

一般来说,对于小型控制器,需要上报Event数量不多,可以选择周期循环上报。

对于域控制器,需要上报的Event数量庞大,为了保证负载率稳定,应该选择触发上报。

3)“Diagnostic event”有哪些特性呢?

1.Event Kind

Event Kind根据故障事件上报方式可分为:BSW Event与SWC Event。

2.Event priority

对于诊断,能够存储的故障事件以及对应冻结帧等相关数据的数量是恒定的,需要软件开发工程师提前配置。当内部存储的故障事件已经满了,Event优先级可以解决新的故障事件如何存储的问题。

一般来说,诊断优先级的设定由诊断系统工程师从整车功能出发,根据诊断故障的重要性,安全性,严重性综合评估。比如汽车的动力故障远比空调故障严重,所以动力相关故障优先级一般会大于空调相关故障。

诊断事件优先级有下面几个重要特点:

1)诊断事件优先级数值越小,优先级越高,数值为1优先级最大。

2)Event优先级仅在诊断事件已经存满情况下发挥作用,其余情况根据FIFO原则存储。

3.Event occurrence

Event occurrence顾名思义就是故障事件上报计数器,故障上报次数越多,Event occurrence值越大,标志着该故障越“老”。“新”‘老’故障标签在后续新的故障事件如何存储的仲裁机制上也会发挥重要作用,这部分内容在后面的内容会详细说明。

Event occurrence存在以下特点,如下所示:

1.每一个event memory entry都有对应的Event occurrence。

2.Event occurrence最大值为255。

3.Event occurrence的计数方式有如下两种配置选择:

2.4 Event Memory存储内容

上文对Event,冻结帧,扩展数据等作了详细描述,那么,这些数据在DEM中是怎么存储的呢?DEM提供了Event Memory概念,将Event,冻结帧,扩展数据全部归纳起来做了统一管理。废话不多说,开始探索Event Memory吧。

Event Memory分类:

 

Event Memory的组成架构如下图所示:

Event Memory组成架构图

S1:Dem模块必须支持Primary Memory,Mirror和Permanent memory可根据用户需要具体选择,一般用不上。

S2: Primary Memory是一个大小为DemMaxNumberEventEntryPrimary用于存储故障数据的非易失性存储空间。也就是Primary Memory由DemMaxNumberEventEntryPrimary个Event Memory Entry组成。

本质上,DemMaxNumberEventEntryPrimary设置为多少,NVM就会提供多少个NVM Block用于存储Primary Memory,就只能存储多少个Event信息。

S3:每个Event Memory Entry存储的内容有:EventId,Occurance Counter,冻结帧,扩展数据,老化周期等。

2.5 Event Memory management

当SWC或者BSW上报Event后,会经过哪些处理最终变成Flash中的Event Memory呢?

从下图中可以看出,Event上报后需要经过下列处理:

Event使能条件检测

Event控制DTC Bit位更新

Event Memory Retention

Event Memory management流程图

1)Event使能条件检测

Event使能条件就相当于Dem中的一个闸门,只有在条件合适的情况下Event才能真正进入Dem的处理流程中。

Event使能条件流程图

从图中可以看出,Event上报至最终能到第二阶段Event控制DTC bit位跳变,需要经历很多流程,接下来对上述流程进行详解。

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流程。

Event Debounce

“Debounce”顾名思义,指对于Event的防抖处理,防止Event误报导致DTC误报。

SWC通过Dem_SetEventStatus(EventId,EventStatus)上报Passed/Failed/PrePassed/Prefailed四种状态。

1)当SWC上报Passed和Failed状态时,Dem不需要进行Debounce处理。

2)当SWC上报Prefailed和Prepassed状态时,Dem需要进行Debounce处理。

本质上,Dem提供的Debounce为通过特定机制,处理PrePassed/Prefailed至Passed/Failed状态变化。

Dem提供了两种Debounce机制,即“Base Time”和“Base Counter”。

1.基于计数器的Debounce策略

基于Counter的Debounce策略的几个重要参数如下表格:

基于Couneter的Debounce机制

如上图所示,在基于Counter的Deboucne机制中,Dem会提供一个计数器(FDC)用于记录判断的结果,当SWC上报给Dem的Event状态为Prefialed,计数器会按照步长增加,当达到设定的限值时,故障状态变成Failed。当上报状态为PrePassed时,计数器按照步长减少,当达到设定的限值时,故障状态变成Passed。

2.基于时间的Debounce策略

基于时间的Debounce策略的几个重要参数如下表格:

基于时间的Debounce机制

在这种策略下,当SWC开始上报Event状态后,Dem模块会提供一个计时器用于记录判断的结果,计时器的增长方向由Event状态决定。当计时器累积到一定阈值后,故障状态变为Passed或者Failed。

3)Event 控制DTC状态更新

当Event经过一系列处理,最终能够对DTC状态进行更新,DTC 8个bit更新逻辑如下:

DTC Bit0 更新逻辑

DTC Bit0 更新逻辑图

DTC Bit1更新逻辑

DTC Bit1 更新逻辑图

DTC Bit2更新逻辑

Bit位更新

DTC Bit2 更新逻辑图

DTC Bit3更新状态

DTC Bit3 更新逻辑图

DTC Bit4更新逻辑

DTC Bit4 更新逻辑图

DTC Bit5更新逻辑

DTC Bit5 更新逻辑图

DTC Bit6更新逻辑

DTC Bit6更新逻辑图

DTC Bit7更新逻辑

DTC Bit7更新逻辑

4)Retention条件检测

当DTC状态完成更新后,Dem将开始进行Retention条件检测。Dem给用户提供多种策略用以判断是否需要分配Event Memory Entry。分配策略由配置DemEventMemoryEntryStorageTrigger决定,具体如下面表格所示:

5)Event Memory Retention处理

Event上报经过了使能条件检测,Event控制DTC Bit位状态更新,Retention条件检测重重难关,最终被允许进入Event Memory,Dem会怎样将Event(DTCs),DTC状态,快照,扩展数据存入Event Memory中呢?

基本思路如下:

Event Memory Retention处理机制

S1:在Event Mmeory所有Event Mmeory Entry中搜索,检查该Event及相关数据是否已经存入Event Memory中,如果已经存在,则进入Event Memory Entry Storage。如果不存在,则在Event Memory中寻找空间用于存储Event内容,如果Event Memory中空间已满,则需要使用Replacement机制。

S2:当进入Event memory Storage,Occurance Counter需要加1,判断是否需要更新冻结帧,扩展数据。

Event Displacement处理

Event Memory存储了数量为DemMaxNumberEventEntryPrimary的Event Memory Entry,当Event Memory Entry已满,需要进行Replacement,即根据一定的策略决定新增的Event如何存储。Dem模块提供了一套完善的机制用于Replacement,该机制有三个核心原则:

1.Event Priority(数字越小存储优先级越高)

2.Event Active或者Event Passive状态(Active优先级高于Passive优先级)

3.Event Occurance Counter(最近发生的存储优先级高于之前发生的)

被替换的Event对应DTC中Bit2,Bit3 ,Bit5会被设置为0.

下图展示了整套Event Displacement机制,体现了三个核心原则在替换机制中的作用。

Event Displacement机制

总结

DEM是以DTC为核心的AUTOSAR基础软件模块,实现了对DTC的监控上报,存储等功能,如果需要对AUTOSAR诊断进行进一步学习,还需要对DCM,Doip,Cantp等模块进行系统性学习。

 
   
次浏览       
相关文章

中央计算的软件定义汽车架构设计
汽车电子控制系统中的软件开发过程
一文读懂汽车芯片-有线通信芯片
OTA在汽车上有哪些难点痛点?
相关文档

汽车设计-汽车的整体结构及动力系统
自动驾驶汽车软件计算框架
SysML在汽车领域的应用实践
电子电气架构-大陆汽车系统架构平台
相关课程

AutoSAR原理与实践
功能安全管理体系(基于ISO26262)
MBSE(基于模型的系统工程)
基于SOA的汽车电子架构设计与开发

最新活动计划
SysML和EA系统设计与建模 7-26[特惠]
Python、数据分析与机器学习 8-23[特惠]
软件架构设计方法、案例与实践 8-23[特惠]
嵌入式软件架构设计 8-22[线上]
Linux内核编程及设备驱动 7-25[北京]
 
 
最新文章
中央计算的软件定义汽车架构设计方案解析
汽车电子控制系统中的软件开发过程
一文读懂汽车芯片-有线通信芯片
OTA在汽车上有哪些难点痛点?
智能汽车车用基础软件的内核和中间件
最新课程
Auto SAR原理与实践
MBSE(基于模型的系统工程)
基于SOA的汽车电子架构设计与开发(域控模式)
人工智能助力汽车行业升级
基于UML和EA进行系统分析设计
SysML和EA进行系统设计建模
更多...   
成功案例
奇瑞商用车 购买建模工具EA完全版
航空发动机研究院 购买建模工具EA完全版
联创汽车 购买建模工具EA完全版
江淮汽车 购买建模工具EA
更多...