如何实现交互式智能汽车诊断。汽车行业中如何从数字化信息中受益。
每位驾驶最新一代汽车的人都知道:汽车的数字化进程经历了漫长的 过程(例如Audi Connect、BMW Connected Drive 和 Mercedes Benz 数字式汽车钥匙)。这些技术自然提高了驾驶者的舒适性和安 全性。
不言而喻,汽车驾驶者希望汽修厂在进行保养和修理过程中、以及在 排查意外故障时,能够提供内行高效的专业服务。
汽车研发及数字式服务方面的高速发展导致汽车修理厂在保养服务和 诊断方面需要 OEM 的更多支持。
因此,每家 OEM 均必须决定,是否仅发送诸如 PDF 文件、HTML 文 档或 XML 格式的数字式诊断和保养信息既已足够满足修理厂的要求 和客户的需要。
换句话说:数字化信息是否足以实现智能诊断?
智能汽车诊断意味着什么?
传统流程是:维修服务人员和修理技工习惯使用比较容易上手的数字式诊断信息和维修信息。某些情况下必须提供相应的快捷互联信息, 以便选择相应的维修流程。
随着所安装电子元件数量及复杂性的增加,维修技工要面对海量的错误代码(例如诊断错误代码),以便区分原因和结果,从而进行正确 的维修流程。
当然,提供 IT 支持分析以及适当维修建议的前提是当前已存在相应文件、结构和信息,并能够通过软件扩展调用场景相关信息以及快捷互联信息原先用于诊断和维修手册的传统结构化文档无法实现这一点。
诊断文档与车辆之间的交互联系
现有的诊断文档一般情况下可为维修技工提供用于诊断和最终维修的 步骤性说明——这一点就像智能诊断一样,但是区别在于智能诊断中 文档和车辆之间存在交互联系。
因此,智能诊断不仅仅是诸如迄今数字化的诊断文档,而且还具有半 自动化进程,以前许多通过测试软件与车辆间对话进行的手动测试步 骤,如今无需技术人员干预即可实现。
理想情况下甚至可以进行全自动维修操作——即软件可在与车辆连接 之后,通过正确配置之前控制器的错误设置、或通过ECU“刷机”(在 ECU 上安装已纠错的新软件),从而修正现有的故障。
半自动化诊断方式至少可为服务技术人员提供有关如何根据诊断进行 维修的明确说明。维修过程完成之后,智能诊断功能可确保其成功。
实现这点不只有一种方法
最大的问题在于如何以智能化且适合应用场景的方式提供内容、元数 据以及附加信息,以供软件系统使用。
一般来说有两种不同的策略:
- 完全重新创建智能诊断所需的信息和内容(同时继续保留之前的传 统文档)。
- 或
- 应用、转换及改进传统文档,以便用于智能诊断。
此过程不仅要注重创建和传输信息,而且还要考虑整个进程。这包括 将信息模块化、发布、实时使用、闭环报告以及系统整合到现有场景 中。
如何用决策树创建智能信息。必须考虑什么因素?
如前所述,有两种将现有知识转换为数字化应用格式的理想方法 – 即 用于机器解读。
首先,由编辑团队创建新的诊断方式,即在相应开发环境中创建决策 树。此时可将现有诊断信息作为基础。最后,专家将其“翻译”为决策树。
决策树中也可实现与车辆的交互联系,即查询 ECU 信息以及各项参 数,以便自行进行故障分析,包括获取对维修技术人员的建议或执行“ 全自动维修”。
其次,创建理想的故障诊断树时结合了专业知识,因此开发过程具有 极高质量。通过将现有的诊断信息文档自动转换为故障诊断树,可以 获得相当可观的结果。一般来说,这些文档原本均具有特定结构(例 如以XML格式,部分采用DITA标准),以便可以提取及再次应用诸 如例如指令、任务或测试等各项元素。
遗憾的是这极少能完全实现,因为机器进行自动化智能诊断所需要的 互联信息,通常是由维修技术人员直接进行故障检测来获取。因此这 种情况需要手动处理。
编辑用于智能诊断的信息时,开发团队必须首先编辑每个决策树,描 述所需的技术进程。然而,随着时间的推移,越来越多的决策树元素 可以在其他类似领域或新款产品中重复使用。所进行的开发工作由此 变得更有价值。
在其他 IT 系统中创建新的决策树时存在信息存储过量的风险。在修 改和扩展时还存在信息重复的风险。此外,还存在数据不一致、过长 的诊断时间和维修时间等风险,严重时还可能导致诊断错误及不必要 的维修作业。
实施需要资源
无论采取哪种策略,实施起来都需要资源。
开发过程中预计将主要精力用于编辑新内容,而在整合先导系统的遗 留数据时,数据迁移和集成则会成为工作重点。
这两种策略都需要高度的技术能力来定义“智能”(即模型、元数据及 应用数据),以便实现机器处理。
决策树的模块化
针对每项新产品及新形式来说,焦点是适合模块化且可重复应用的决 策树。因此会将决策树元素分离成模块形式,以便可以在其他树中使 用。这可简化开发流程,便于进行正确选择:使用现有模块、使用未 改变的现有模块、稍作修改或重新创建。
对现有信息进行自动转换或由开发人员进行转换的进程可能会有差 异,但实现优化的可能性均相同。
发布(提供信息和数据)
提到发布,我们可以理解为选择、链接和提供信息及数据。有各种标 准可应用于发布(车辆类型、形式、系列等),并作为机器用来诊断 和排除故障的基础。
实时使用决策树
部分自动化的实时故障排除功能使服务技术人员能够立即评估故障排 除过程的结果。例如当改变车辆设置时,可以重新启动诊断过程,并 以不同方式确认之前存在的问题已解决,诸如通过执行器的有效测量 值、正确的传感器返回值或 ECU 处不再有错误消息。
关于保修的闭环报告
特别有用的是半自动维修过程中的保修索赔检验选项及后续报告选 项。开发者创建决策树时既已定义最具成本效益的备件及最耗时的维 修步骤,该报告可确保技术人员按照工艺流程进行工作并降低成本。
反之,针对高端领域,开发时将确保执行全面措施以便永久消除问题。 通过相应报告可以帮助遵守准则并进行监控。
同时,全面的报告中会包含全部流程的持续且详细的记录,可用于持 续性流程及信息优化。有多种选择可能:推荐在文档创建范围内以及 机器示教学习方面的优化措施,使用日志数据进行自动化操作建议。
智能诊断应用的系统集成 - 消除数据孤岛!
除了车辆与测试仪连接之外,还必须集成其他系统,即能够实现创建 决策树的开发系统(系统数据结果会限制可能的系统状态)。
接口数量有无限可能。但实际应用和经济层面会限制开发优化系统的 可能性。
智能诊断应用的决定性成功因素是其开放性以及传统数据孤岛的消除。 此外,相关信息和内容必须紧密互联,且须提供给维修技术人员,以 支持其日常工作。用于智能诊断来说,冗余数据及新的数据孤岛均会 对整个过程产生不良后果。
那么现在呢?应该选择哪种策略? 首选策略取决于情况发生的概率。非常频繁发生的情况(例如针对当 前产品线、核心业务产品)适用开发工作。对于极少数情况(例如停 产的产品系列或空缺产品),则建议使用自动转换方式。同时采用两 种策略的情况越来越多。策略决策最终取决于数字服务信息的智能交 互方式。
作者:Rainer Terlutter 先生,专业服务总监,Empolis Information Management GmbH