【汽车故障诊断4】一文了解故障诊断码DTC验证程度、快照和扩展数据
在本系列前7篇文章中介绍了DTC和故障诊断系统的部分内容，如下：
这些内容基本为介绍故障诊断列表做好了铺垫，本文将通过一个例子从正向设计角度定义故障诊断列表。
source：CDD文件——CANdelaStudio_诊断协议那些事儿的博客-CSDN博客
案例：电源电压监测--过压，欠压
注意：本例子数据的数值均为虚构，重在辅助具象化故障诊断的正向开发，以下内容也并非考虑到了故障诊断正向开发的所有关键点，重在展现故障诊断的正向思考或开发过程。
电源电压KL30给某ECU供电，通常硬件电路路径是：KL30通过接插件的电源引脚输入给ECU，ECU硬件电路将对KL30做保护，通断和滤波等处理，然后KL30给ECU的电源管理芯片PMIC，以及一些执行器的驱动芯片供电。当然这些电子器件有相应的供电范围要求，所以需要监测KL30，即增加相应的硬件采集电路，将采集的电压输入给微控制器，最终通过软件逻辑判断电源电压是否正常。
因此，电源部分的硬件电路可简化成如下所示逻辑：
这里，我们的目标是需要监测KL30是否出现过压，欠压故障。针对这两个故障：
首先，定义它们的DTC。采用OBD格式的DTC，如下表定义：
其对应十六进制格式表示则对应为：0x0562和0x0563。
相关内容可参考：【汽车故障诊断2】一文了解诊断故障码DTC
然后，如何实施故障诊断。
已知KL30正常范围为9V到16V；KL30高于16V过压，处于过压状态时，如果KL30低于15V，则可恢复正常；KL30低于9V欠压，处于欠压状态时，如果KL30高于10V，则可恢复正常，如下所示：
当然，对于硬件采集电路输入给微控制器的V_k30的电压并不能等于KL30的电压值，通常低于5V范围，假设V_k30与KL30的电压值成比例关系，V_k30=KL30电压/4，则有：
参照 【汽车故障诊断5】ECU如何进行故障诊断的思路：
1）MC。对于电源电压，一直在供电，故应该实时监测，设置为周期性监测，10ms一次。
2）FC。根据已知部分提供的信息，判断逻辑为：
V_K30高于4V，则电源电压过压；V_K30低于2.25V，则电源电压欠压。
3）Debounce算法。考虑到电源电压可能收到干扰等因素出现偶然的尖峰，因此需要采用Debounce算法，采用基于时间的Debounce算法，Debounce时间为500ms。
4）处理策略。电源电压过压或欠压将可能导致ECU相关的功能出现异常，这时应该立马提醒驾驶员，比如点亮警告灯，在仪表显示。
5）存储策略。考虑到电源电压故障与排放不相关，那么不需要存储该故障相关的快照信息和扩展数据信息。
如果电源电压过压或欠压故障后，其电压范围又恢复到正常范围，这时是不是应该删除这个故障信息？因此，这里第一步是需要如何判断确认的故障是不是消除了，即确定愈合策略，包括愈合条件和愈合时间。
根据已知部分提供的信息，愈合的判断逻辑可设置为：当电源电压过压时，一旦V_K30低于3.75V，持续500ms，则警告灯熄灭；当电源电压欠压时，一旦V_K30高于2.5V，持续500ms，则警告灯熄灭。
第二步是故障真的消除了，原先故障确认时存储的相关信息是不是应该清除，那么根据怎样策略逻辑来确定，即确定老化策略。对这两个故障，故障愈合后，设置为经过1个驾驶循环，故障确认状态被重置；经过30个暖机循环，故障快照信息和扩展数据从内存中被清除。
因此根据上述故障诊断的正向开发过程，我们可以得到故障诊断列表的两条故障，如下所示：
这样通过本例实施正向设计后，就得到故障诊断列表的核心内容，希望你以后在项目中看到这个列表的时候不再陌生。就本人经历，不同公司对于故障诊断列表定义内容会稍有不同，但其核心内容还是本例所列举的。
故障诊断的需求一般包括两部分：故障诊断列表和UDS服务相关需求。本系列到此基本介绍完了第一部分-故障诊断列表，接下来将介绍UDS服务，请关注下篇文章。
-------------------------------------------------------------------------------------------------------------------------
创作不易，欢迎点赞收藏关注。
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车行业从业人员。
3295
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
