Dem开发详解

cqzyf

1.需求分解

1.1DTC信息

一般在主机厂释放的诊断调查表中，首先会简略的介绍下DTC的码、DTC名（分解的Event名）、故障确认条件、故障解除条件、测试DTC的前置条件。



可以根据这些信息，画个蹩脚的流程图阐述下Event的状态处理。



1.2 扩展、快照数据

除此之外，快照信息（也可以叫Snapshot或者Freeze）和扩展数据，是在故障触发或确认时记录当时数据的信息，也是开发内容的关键。





可以看到快照信息和扩展信息都带有记录号（DID是快照信息独有的，这里是需求有问题显示扩展信息也有DID）。
1.3 DTC状态位

DTC的状态位，其实我们在开发过程中只需要去置位bit0，和设置点火周期，其他的逻辑autosar的DEM协议栈已经帮我们实现了。



关于每个bit位的转换方式，协议中章节 D.2.3 DTC status bit definitions有具体的描述，在与测试小伙伴的“争辩”中可能需要用到。



另外在D.6 DTCFaultDetectionCounter operation implementation example章节中，有对bit状态变化的示例。



基本上要在诊断调查表中分析完以上需求，就可以开始Autosar的DEM配置了。

2.Dem配置

2.1 DTC状态位



在这里配置Mask即可。
2.2 快照、扩展信息相关配置

2.2.1 DemDataElementClass

不管是快照还是扩展信息，对于DEM来说都是一个个元素组成的信息。



元素一共三种，一种是内部变量，如上图，具体的意义可以在SWS中查看。还有常用的就是CSData，如下图



同样的需要设置数据的大小、接口函数名、是否使用rte接口。
2.2.2 DemDidClass

快照数据是有did的，需要将DID和元素关联起来。



2.2.3 DemExtendedDataRecordClass

RecordNum即xlsx中表格对应的记录号了，此外还需要配置扩展信息以什么bit为来记录，以及是否需要在故障重新确认时更新扩展数据内容。



这里也可可以看到，扩展信息时直接关联元素的，没有DID。
2.2.4 DemFreezeFrameClass

其实和扩展信息一样，可以为不同的DTC配置不同的Class记录不同的内容。例如，硬件相关的故障可能需要记录一些硬件寄存器信息，而软件的故障我们更多的需要关注具体变量来查验问题。



在每个Class中配置DID。
2.2.5 DemFreezeFrameRecordClass

同 2.2.3。不过这里可以看到，扩展信息是支持不同记录号记录不同内容的配置，而快照信息是不支持的。



2.2.6  DemFreezeFrameRecNumClass

组合成class等待配置DTC属性时使用。



2.3 前置条件配置

2.3.1 DemEnableCondition

这里配置DTC判断的前置条件，前置条件满足后，调用的Dem_SetEventStatus的接口才有效。



true、flase的意义，等编码的时候再说吧。
2.3.2 DemEnableConditionGroup



Group即是将不同的前置条件组合起来给DTC属性配置使用的。
2.4 NVM相关配置

Nvm的block，如果客户的要求不高，可以少配置一些，但是如果客户的要求比较高，要求记录所有DTC的历史信息，则需要按DTC的个数来配置，但是这样会导致NvM模块在换页时占用大量时间，如果ECU的电源环境不稳定，对NvM的存取很不友好。Block的Lenth大小配置，可以在生成代码以后，sizeof（Dem_EvMemEventMemoryType）来看。



2.5 Debounce配置

DEM贴心的有基于时间和次数的两种debouce，我们可以基于任务的调度周期、故障的触发条件综合考虑后，来确定使用哪种Debounce方式。



2.6 DemDTCAttributes

属性这里，我看很多工程师都是一个DTC配置一个属性，其实大部分主机厂的需求,DTC所需要记录的内容都是一样的。



此外，老化次数也是在这里配置。
2.7 header file

后续手写实现的内容，需要放到这个.h中让DEM包含，是软件能正确编译通过。



2.8 DTC

注意下DTC名和DTC号即可。



2.9 Event

需要注意配置debounce的算法和DTC、前置条件的Refrence。



3.编码

集成完软件之后就可以开始编码啦。Isolar会帮我们生成很多接口等待我们实现。
3.1 前置条件

此前配置的前置条件，其实只是生成了宏定义的枚举：



而DEM软件会根据条件的满足或不满足，来判断是否可以进行Event的状态切换（即配置中的true/flase）

咱们用个指针数组来遍历调用Dem_SetEnableCondition即可。





3.2 扩展、快照的实现

DEM代码中只做了函数的使用，具体的内容需要我们手动去实现。



可以注意到，内部变量是已经有函数实现的蓝色，因为他们被定义成了宏。

其他的函数我们需要手动实现，如下：



最后记得函数的声明。



3.3 Event状态触发/取消

最大的编码工作量即是在这里。

挑一个逻辑简单的超时来举例吧，由于我们的形参是DEM_EVENT_STATUS_PREFAILED，则会按照event中配置的debouce算法来累计，直到debouce完成才会置位DTC状态位的bit0。



比方说，可能某些故障出现即需要testfailed，我们又不想改dem的配置了，形参改为DEM_EVENT_STATUS_FAILED就可以了。
3.4 老化

我们只需要根据ECU的电源状态来调用函数Dem_SetOperationCycleState即可，DEM协议栈会在点火周期变化后自动根据EVENT的状态来判断是否可以增加老化次数。



3.5 测试代码编写

由于繁杂的测试前置条件和event触发逻辑，我们可以使用测试代码来测试配置的实现状态。







贴一下代码，其实就是用调试器暴力调用DEM接口。

4. 19 04/06

以快照数据查看为例，介绍下uds字节内容的意义。

Req:



19 04代表查看DTC的快照数据，后面跟着的570054是DTC码，FF则是代表查看所有记录号（如果输入01则是查看01记录号）

Resp:

dtc号570054跟着的第一个字节，2F是dtc的状态位，

0112代表记录号01一共有20个DID，之后即是DID+DID内容的组合，图就不截全了。



5. 调试验证

工作原因没有条件去看协议栈的代码实现和关键变量啦。



用华为看战狼吃华莱士开byd支持rng，仅仅纪念下中日文化交流人员。



（好久没更新，对不起大家啦）