8

面向未来的车辆预测诊断技术

 2 years ago
source link: https://www.eefocus.com/automobile-electronics/519255
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

面向未来的车辆预测诊断技术-汽车电子-与非网

83a41eee183992fa750ba38de7775a7c.jpg
321504b240280fe88a83ca965f2f051d.jpg

今天介绍一个汽车行业的标准,虽然这个标准并非新标准——在2018年就已经发布了,但是在国内好像还很少看到相关的讨论。在讨论这个标准之前,我们先回顾一下当前被广泛使用的汽车诊断技术的现状。

传统的汽车诊断被称为diagnostic,而当前一些先进的OEM已经进化为采用prognostics – predictive diagnostics,即预测型诊断。而且,诊断的方式已经不再限于通过诊断仪的本地诊断,或者是借助网联技术的云端在线诊断,而是基于大数据与故障预测模型的预测型诊断。

传统的诊断手段有诸多弊病,如:只能在故障发生后进行记录,可以诊断的故障类型很有限,大多数故障的读取或信息展示渠道单一等。目前,大多数汽车诊断是由技术员使用服务信息(在线的文档或手册)、测试设备和车间工具(如诊断仪)进行的。任何的软件更新都是在车间或维修中心内进行的,通常使用符合SAE J2534标准的设备或OEM特有的工具。只有少数汽车能够使用OTA技术来 "空中 "更新软件。

而当大数据与云技术与车辆结合之后,诊断领域的想象空间就大幅度提升了。基于数据的积累和收集,再借助云存储计算的能力,理论上已经可以实现在车辆部件和系统可能发生的故障之前进行预测。这一点在今天越来越重要,尤其对于自动驾驶车辆来说,这可能是非常关键的一点。因为虽然大部分车辆的自动驾驶系统都已经按照功能安全的标准来进行了设计和开发,但功能安全只能尽量保证人员的安全,而无法保证车辆功能的可用性与可靠性。也就是可以保证系统在单点失效后不对人身产生重大的伤害,但是车辆的某项功能却无法使用了。

在传统的车辆质量保证环节中,车辆定期保养和检查是一个重要的活动。但这种定期保养和检查是基于里程和时间的保养间隔,虽然有效,但却浪费了大量的人力和时间,对于客户而言是一种效果并不那么显著的成本投入。而如果采用预测技术(prognostics – predictive diagnostics),则会将机动车的保养和维修改变为基于实时数据分析的后的精准服务。故障发生后的诊断将被尽可能被提前两周预测未来可能的故障所取代。预测工作的目标是那些发现那些似乎性能仍在正常范围的、但即将发生的故障。

预测性诊断的目的是为了让部件和系统能够有最大的使用寿命,同时,用户能够安全使用车辆。汽车部件一般都是为了长时间的使用而设计的,除了部分易损件之外,大多数预期寿命都可能超过10年。即使是易损件,大部分寿命也在一年以上。确定这样一个为长寿命而设计的部件何时接近故障,意味着必须有关于其 "健康状况 "的连续可用的数据。例如,根据通用汽车的安吉星提供的数据,该公司在一系列具有安吉星4G连接的2016年雪佛兰车型上引入了汽车部件故障预知功能,涵盖了发动机启动和运行的关键部分,包括电池、启动器和燃油泵。

车上的大部分部件都在 "优雅地老化",即按照已知的曲线发生寿命的衰减及性能的恶化,并且很容易进行预测。那些目前不太容易预测的关键部件的寿命将可以从实时健康评估中受益更多,它们的健康状况预测可以通过机器学习或其他辅助手段来加强。

健康评估必须建立在部件和系统中。2018年,SAE发布了JA 6268,这是一个航空和汽车推荐实践(RP,Recommended Practice ),题为 "健康就绪组件的设计和运行时信息交流(“Design and Run-Time Information Exchange for Health-Ready Components.”)"。一个 "健康就绪(Health-Ready)"的部件是指一个由供应商交付的部件或子系统,这个部件或子系统被加强了:也许有额外的传感器,可以报告其健康状况,和/或 提供集成信息,以便部件和/或整个车载系统都可以获得其状态信息。

在SAE’s Industry Technology Consortia (ITC) via JA 6268标准中,将汽车诊断分为0~5级的6个层级:

0:有限的车辆报警提示,维修服务是基于定期的维护保养,或当车辆的操作人员或维修工注意到车辆上的相应的故障指示灯或简单的提示设备;

1:使用诊断工具的增强型诊断,通过使用自动化的诊断仪来提取存储于车辆内部的操作参数和诊断码来获取车辆的内部信息,维修服务可以部分基于诊断结果来进行;

2:通过Telematics提供实时的数据,通过基于车辆的远程监测来实时的获取车辆数据,从而可以根据更加完整的问题信息来展开维修保养服务;

3:部件层级的主动提示,操作人员和服务技师能够在故障发生之前获得部件的健康状态(R/Y/G,红黄绿),实现有限的基于条件(Condition-Based)的维修保养;

4:IVHM,集成式车辆健康管理,操作人员和服务技师能够在故障发生之前获得系统或车辆层级的整体健康指示信息,并可以估计剩余的使用时间,实现基于条件的维修保养;

5:自适应的健康管理,通过获取潜在的或实际的故障信息来实现自适应的控制和优化,从而能够延长车辆的使用,并增强安全性。

具体的信息如下图:

forward?url=https%3A%2F%2Fmmbiz.qpic.cn%2Fmmbiz_png%2Fj4AMQjW4IAicwGWp7sFicrzlySibGW3M3JQjlK7cM2STCkp0u4cqhyYpxIgtAcQXUicGWCWP4rBQhB8ibZQQCEqpbkg%2F640%3Fwx_fmt%3Dpng&s=5b7a88

在JA 6268中将诊断分为了两个大的阶段。

1. 由技师来执行的手动诊断和维修,对应层级0~2;

2. 基于预测分析的诊断与维修,对应层级3~5;

预测式诊断的第一个级别(总第3级)需要在部件层面实现主动预警功能。ITC正在寻求建立一个注册表。目前,在初始阶段,它将包括:组件标识和供应商,加上验证方法(设计时和/或运行时信息),健康就绪信息的格式(机器可读格式的数学模型或数学关系),OEM或集成商的名称,以及合规日期。

该注册表是ITC的衍生产品,用于开始开发HRCS(Health-Ready Components and Systems,健康就绪的部件和系统)。它的目的是为了实现IVHM(Integrated Vehicle Health Management,集成式车辆健康管理),并最终(主要针对自动驾驶车辆)达到SAHM(Self-Adaptive Health Management,自适应健康管理)。

但目前在诊断层面和预测方面都存在困难。一般而言,在出现故障后进行的诊断中,实际被记录的故障比例并不高:在汽车中的NTF(No Trouble Found,未发现故障)或航空业的NFF(No Fault Found,未发现故障)的比率可能超过50%,甚至高达90%以上。这种现象的原因包括: 

原有的故障测试方法没有记录所有的故障模式。但当更换一个没有故障记录代码(DTC)或有任何其他不良征兆的电子模块时,却发现该问题已经被修复了。

测试环境不能代表故障发生的情况,包括温度、压力、湿度、振动等。

存在着测试程序无法识别的电路或连接问题。

与该模块或系统关联的其他模块或系统没有达到预期的性能或实现应有的功能。

为了节约成本而将该组件的一个关键规格要求放弃了。

也许这个组件真的没有问题。

注册表的目的:使参与者知道该过程与推荐实践(RP)一致,并得到了验证。将已知供应商放到注册表里面还能实现成本共享和一些知识的利用。纳入健康评估的传感器将被整合到基于ISO 13374的IVHM架构中,该架构包括数据采集、操作、状态和健康测量的能力,以及预知(如有必要)和咨询的生成。

失效模式分类也是评估策略的一部分,主要由每辆车修复预测故障的成本来主导。接下来是严重程度。依次是:,最严重(Most Severe,车辆无法运行或存在安全问题),紧急(Urgent),重要(Important,包括客户的不便因素),然后是小修(Minor Repair),最后是最不严重(Least Severe,进入常规维护)。

关于这个标准就不多说了,感兴趣的朋友可以自己去查一下这个标准。

这里想补充一下自己的感受:当前的中国汽车行业在如火如荼的发展中,我们在造车的数量与质量方面都已经处于世界的前列了,尤其是在新能源汽车领域,更是一骑绝尘。但在汽车相关的基础技术与标准领域却一直只能跟随,很多时候都只能Copy&Paste。

我们的强项仍然还是停留在应用与生产领域。一个行业的强大,不能只看应用领域,否则就永远只能跟在别人屁股后面,赚点辛苦钱而已,无法实现真正的超越。只有当我们能引领国际标准的时候,才说明我们是真正的强大了。

注:上面的数据均来自SAE网站。

作者: 侯哥@Roy 专注汽车电子电气架构开发

编辑: 文昌@Vincent 汽车信息安全从业者


版权声明:与非网经原作者授权转载,版权属于原作者。文章观点仅代表作者本人,不代表与非网立场。文章及其配图仅供工程师学习之用,如有侵权或者其他问题,请联系本站作侵删。 侵权投诉


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK