• 1410查看
  • 0回复

[Autosar] 全面讲解系统诊断管理模块设计

[复制链接]


该用户从未签到

发表于 17-8-2023 12:51:27 | 显示全部楼层 |阅读模式

汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师


全面讲解系统诊断管理模块设计w1.jpg

前言

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

1.诊断故障基础

当人患了疾病,便需要医治,医生根据各种检验结果找出病因,并得出诊治策略。当汽车出现故障时,DTC故障码就等同于“检验结果”,汽车工程师通过该标识码便可以查表的方式获得该故障信息,如故障触发条件、故障解除条件、系统功能表现等,得出解决该故障的策略。DTC(DiagnosticTrouble Code)顾名思义诊断故障码,一种用来记录当ECU发生或者检测到某种故障时呈现给大家的标识码。1.1 DTC的组成

DTC故障码是一个4个字节的标识符,由以下两部分组成:DTC Catogory 与Failure Type,其中DTC Catogory 又可以根据Powertrain、Body、Chasis、N etwork四大子系统来进一步定义其范围,简称PBCU四大子系统,如下表所示:
全面讲解系统诊断管理模块设计w3.jpg

1.2 DTC的意义

故障码有以下两点意义:

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

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

以非排放相关的ECU为例,可以将DTC故障类型分为以下几个部分:
硬件故障:如RAM、Flash、CPU时钟等硬件本身失效的问题软件故障:如配置字故障,标定故障或客户定义的软件功能性故障外部环境故障:电压过高或者欠压、环境温度过高或过低等
通讯相关故障:如报文丢失、信号无效,Checksum/Rolling 障等
1.4DTC状态位介绍

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

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
具体解释如下: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中规定了冻结帧可以用来记录故障发生时的详细情况,扩展数据可以提供故障码相关的扩展信息,包括老化计数器。

类型

组成

内容

冻结帧

由一系列DID组成,用户可以自定义DID内容

描述车速,温度,油量,等信息

扩展信息

由一系列DID组成,DID内容由BSW规定

描述故障码的额外信息,比如老化周期数量。

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交互使用存储功能。

全面讲解系统诊断管理模块设计w4.jpg

                ???AUTOSAR架构图???2)Dem与其他模块依赖关系

全面讲解系统诊断管理模块设计w5.jpg

                                              ??? 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的具体功能前,先引入概念“Diagnosticevent”,“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上报为触发上报。两种上报方式各有优缺点,如下图所示,切不可一刀切。
全面讲解系统诊断管理模块设计w6.jpg

一般来说,对于小型控制器,需要上报Event数量不多,可以选择周期循环上报。对于域控制器,需要上报的Event数量庞大,为了保证负载率稳定,应该选择触发上报。

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

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

Event Kind

来源

上报方式

函数名

BSW Event

BSW模块

标准C接口

Dem_ReportErrorStatus

SWC Event

SWC模块

RTE接口

SetEventStatus(RTE)

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的计数方式有如下两种配置选择:

配置属性

计数方式

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

2.4 EventMemory存储内容

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

EventMemory分类:

类型

含义

DemPrimaryMemory

存储EventId,故障状态,冻结帧,扩展数据

DemMirrorMemory


Permanent Event Memory

用于存储OBD相关的DTC
Event Memory的组成架构如下图所示:
全面讲解系统诊断管理模块设计w7.jpg

Event Memory组成架构图

S1:Dem模块必须支持PrimaryMemory,Mirror和Permanent memory可根据用户需要具体选择,一般用不上。S2: Primary Memory是一个大小为DemMaxNumberEventEntryPrimary用于存储故障数据的非易失性存储空间。也就是PrimaryMemory由DemMaxNumberEventEntryPrimary个EventMemory Entry组成。本质上,DemMaxNumberEventEntryPrimary设置为多少,NVM就会提供多少个NVMBlock用于存储Primary Memory,就只能存储多少个Event信息。S3:每个Event Memory Entry存储的内容有:EventId,Occurance Counter,冻结帧,扩展数据,老化周期等。

2.5 EventMemory management

当SWC或者BSW上报Event后,会经过哪些处理最终变成Flash中的Event Memory呢?
从下图中可以看出,Event上报后需要经过下列处理:Event使能条件检测Event控制DTC Bit位更新Event Memory Retention
全面讲解系统诊断管理模块设计w8.jpg

Event Memory management流程图

1)Event使能条件检测

Event使能条件就相当于Dem中的一个闸门,只有在条件合适的情况下Event才能真正进入Dem的处理流程中。
全面讲解系统诊断管理模块设计w9.jpg

Event使能条件流程图
从图中可以看出,Event上报至最终能到第二阶段Event控制DTC bit位跳变,需要经历很多流程,接下来对上述流程进行详解。
S1:首先,需要判断当前是否开启了操作循环,操作循环一般指的是点火循环,一个操作循环可以认为是DTC检测的一个周期。如果操作循环开启了,则开始下列的Enable Condition判断,否则直接退出整个Event Memorymanagement流程。

S2::EnableCondition判断指的是Event上报增加的一个附加条件判断,Dem通过对应的接口给SWC使用,SWC实现附件条件处理。一般可以用来处理一些电压,车辆模式等限制条件。如果Enable Condition条件满足,则进行85服务判断;如果Enable Condition条件不满足,则直接退出Event Memorymanagement流程。

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策略的几个重要参数如下表格:

参数

含义

FDC(Fault Detection Counter)

错误计数器,值范围为-128-127

DemDebounceCounterFailedThreshold

使Event诊断事件状态最终为Failed的Debounce  Counter阈值

DemDebounceCounterPassedThreshold

使Event诊断事件状态最终为Passed的Debounce  Counter阈值

DemDebounceCounterIncrementStepSize

当SWC上报Prefailed,错误计数器增加量

DemDebounceCounterDecrementStepSize

当SWC上报Prepassed,错误计数器增加量

全面讲解系统诊断管理模块设计w10.jpg

基于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周期

全面讲解系统诊断管理模块设计w11.jpg

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

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

DTC Bit0 更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

1 -> 0

经Debounce后最终上报状态为Passed

OR

使用14服务清除DTC

OR

复位事件状态

全面讲解系统诊断管理模块设计w12.jpg

DTC Bit0 更新逻辑图

DTC Bit1更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

1 -> 0

操作循环更新

OR

使用14服务清除DTC



全面讲解系统诊断管理模块设计w13.jpg

DTC Bit1 更新逻辑图

DTC Bit2更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

1 -> 0

(操作循环更新 AND TestFailedThisOperationCycle == 0)

OR

使用14服务清除DTC

OR

TestNotCompeleteThisOperationCycle == 0




全面讲解系统诊断管理模块设计w14.jpg

DTC Bit2 更新逻辑图

DTC Bit3更新状态

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

AND

     Fialure Counter > = 故障确认阈值

1 -> 0

达到老化条件

OR

使用14服务清除DTC

OR

      故障溢出被替换

全面讲解系统诊断管理模块设计w15.jpg

DTC Bit3 更新逻辑图

DTC Bit4更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

1 -> 0

使用14服务清除DTC

全面讲解系统诊断管理模块设计w16.jpg

DTC Bit4 更新逻辑图

DTC Bit5更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

1 -> 0

使用14服务清除DTC

全面讲解系统诊断管理模块设计w17.jpg

DTCBit5 更新逻辑图
   DTC Bit6更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

1 -> 0

使用14服务清除DTC

OR

操作循环更新


全面讲解系统诊断管理模块设计w18.jpg

DTCBit6更新逻辑图

DTC Bit7更新逻辑

Bit位更新

条件

0 -> 1

经Debounce后最终上报状态为Failed

AND

点灯条件满足

1 -> 0

使用14服务清除DTC

OR

点灯条件不满足

DTCBit7更新逻辑

4)Retention条件检测

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

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



5)Event Memory Retention处理

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

全面讲解系统诊断管理模块设计w19.jpg

Event Memory Retention处理机制

S1:在Event Mmeory所有Event Mmeory Entry中搜索,检查该Event及相关数据是否已经存入Event Memory中,如果已经存在,则进入Event MemoryEntry Storage。如果不存在,则在Event Memory中寻找空间用于存储Event内容,如果Event Memory中空间已满,则需要使用Replacement机制。S2:当进入Event memory Storage,Occurance Counter需要加1,判断是否需要更新冻结帧,扩展数据。EventDisplacement处理Event Memory存储了数量为DemMaxNumberEventEntryPrimary的Event MemoryEntry,当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机制,体现了三个核心原则在替换机制中的作用。

全面讲解系统诊断管理模块设计w20.jpg

Event Displacement机制
总结

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

分享不易,恳请点个【?】和【在看】


该用户从未签到

发表于 20-3-2025 01:53:00 | 显示全部楼层
作为一名汽车工程师,深知系统诊断管理模块设计的重要性。针对您所提到的Dem模块,其作为AUTOSAR中的核心组成部分,主要负责故障诊断及关联数据的记录。其设计涵盖诊断故障基础、DTC管理、数据存储与传输等方面。其中,诊断故障基础模块实现故障的检测与触发,DTC管理则负责故障码的生成与传输。此外,数据存储需确保故障信息的持久性,而数据传输则使外部设备能读取故障信息。Dem模块的设计需考虑实时性、准确性及可靠性,以确保汽车诊断的精准与高效。后续将详细阐述各功能模块的详细设计与实现。
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 20-3-2025 01:53:00 | 显示全部楼层
作为汽车工程师,深知系统诊断管理模块设计的重要性。以下是对Dem(诊断管理模块)的全面讲解:

一、诊断故障基础

诊断故障类似于人类的医疗诊断。当汽车出现故障,DTC(诊断故障代码)相当于“检验结果”。工程师通过DTC获取故障信息,如触发条件、解除条件及系统功能表现等。

二、系统诊断管理模块设计

Dem作为AUTOSAR中的核心模块,主要负责故障诊断及其关联数据的记录。其设计包括:

1. 故障检测与识别:通过传感器数据实时监控,检测异常并生成DTC。
2. 故障信息存储:将DTC及相关数据存储在ECU中,供后续诊断使用。
3. 诊断通信:实现与其他诊断工具的信息交互,如读取、清除故障码等。
4. 故障策略管理:根据DTC信息,控制ECU执行相应的故障策略,如降级运行或关闭某些功能。

总结,Dem模块的设计关乎汽车的安全与性能,是诊断功能实现的关键。希望以上内容能为大家的学习提供帮助。
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 20-3-2025 01:53:00 | 显示全部楼层
根据您的要求和提供的文本内容,以下是关于系统诊断管理模块设计的专业回复:

---

关于系统诊断管理模块设计全面讲解

前言:

Dem模块在AUTOSAR架构中承担着关键角色,负责故障诊断及其相关数据的记录,是诊断功能的核心组成部分。本文将详细介绍其设计原理和功能。

一、诊断故障基础

汽车出现故障时,如同人生病需要医治。诊断故障的核心在于识别和理解故障的原因。诊断故障码(DTC)就如同医生的检验结果,为工程师提供了故障信息的关键线索。通过DTC,工程师可以快速获取故障触发条件、故障表现及解除条件等关键信息。

二、系统诊断管理模块设计概述

Dem模块设计围绕故障诊断的核心功能展开,包括故障检测、记录、报告和管理。其设计特点如下:

1. 故障检测:实时监控汽车各系统的运行状态,发现异常及时响应。
2. 故障记录:详细记录故障信息,包括故障码、时间、相关参数等。
3. 故障报告:通过特定的通信协议,向外部设备报告故障信息。
4. 故障管理:根据故障信息,采取相应的措施,如故障指示灯亮起、限制车辆功能等。

三、设计要点及流程

Dem模块设计需考虑以下几个方面:数据采集、数据处理、通信接口和安全性。设计流程包括需求分析、功能设计、软件编码、测试验证等环节。本文将对每个环节进行详细讲解。

后续将详细介绍Dem模块的具体设计细节和实现方式,帮助大家深入理解这一复杂模块的工作原理和功能。
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 20-3-2025 01:53:00 | 显示全部楼层
尊敬的楼主,以下是对系统诊断管理模块设计的全面讲解:

一、引言

系统诊断管理模块(Dem)是AUTOSAR架构中用于记录和管理故障诊断及其关联数据的核心模块,对实现车辆故障诊断功能至关重要。

二、诊断故障基础

诊断故障码(DTC)是车辆故障检测的标识。当车辆出现故障时,Dem模块会生成相应的DTC,并提供故障信息,如触发条件、故障表现及解除条件等。

三、Dem模块设计

1. 故障诊断记录:Dem模块会记录故障发生的时间、类型、严重程度等信息。
2. 故障策略管理:根据DTC,Dem模块提供解决故障的策略和建议。
3. 故障通讯:Dem模块与其他ECU或诊断工具进行通讯,传输故障信息。
4. 故障显示:在仪表板上显示故障警告,提示驾驶员注意。

四、功能特点

Dem模块具有高度的灵活性和可扩展性,能适应不同车型和诊断需求。其设计考虑了诊断的实时性和准确性,以确保车辆的安全和性能。

五、总结

Dem模块的设计是实现车辆故障诊断的关键,其重要性不言而喻。通过生成和管理DTC,Dem模块为工程师提供了解决车辆故障的有效手段。
回复 支持 反对

使用道具 举报

快速发帖

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

GMT+8, 19-8-2025 02:20 , Processed in 0.304775 second(s), 38 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.