CN103493019A - 多代理程序合作车辆故障诊断系统和相关联的方法 - Google Patents

Abstract

一种控制单元执行车辆第一子系统的第一代理程序，所述第一代理程序包括故障检测代理程序和通信代理程序。所述故障检测代理程序为了识别在所述第一子系统中的问题而监视所述第一子系统的性能数据，在第一存储器中存储所述第一子系统所对应的若干第一候选故障诊断过程，以及从所述若干第一候选故障诊断过程当中搜索对引起所述第一子系统中所述问题的故障进行识别的故障诊断过程。当所述故障检测代理程序的搜索未能找到识别所述故障的所述故障诊断过程时所述通信代理程序与第二代理程序合作。所述合作包括对存储着若干第二候选故障诊断过程的第二存储器进行搜索，向所述第二代理程序发送所述监视的性能数据以及在所述第一与第二代理程序之间交换搜索结果数据。

Description

多代理程序合作车辆故障诊断系统和相关联的方法

相关申请的交叉引用

本申请要求2011年4月29日提交的美国序列号13/097,703的优先权，其全部内容在此引用作为参考。

技术领域

本申请涉及诊断车辆故障的方法、系统、算法和过程，更确切地说，使用智能代理程序诊断车辆。其应用包括在没有诊断故障码（DTC）时高效地识别和诊断当前的和潜在的未来的车辆故障。

背景技术

车载诊断（OBD）系统协助技术人员诊断和保养计算机化车辆系统，比如发动机和制动系统。OBD系统用于诊断子系统组件故障和失灵，并且用于检测子系统组件损坏。当组件的损坏达到危急程度时，能够产生DTC以及/或者车辆的仪表板上的报警灯能够亮起以向驾驶员通报此错误。

车辆的若干组件的损坏程度由许多因素影响，包括驾驶员的行为、天气、驾驶条件和里程/时间。损坏的这种程度一般称为车辆的健康状况。为了确保DTC由技术人员以及时的间隔检查并且为了避免车辆组件中的危急故障，劝告驾驶员定期地、固定的里程后或固定的时段后保养其车辆，以便检查和维护。

典型情况下，进行OBD的方式为由有经验的技术人员寻找已知问题。在这些情况下，已知问题已经被记录为车辆上的DTC，因此能够容易地识别和修理。

不过，只是遵循推荐的日程表进行当前的基于里程的和基于时间的检查可能有问题。例如，定期检查不考虑影响车辆组件寿命的多种因素，比如驾驶员行为、天气、驾驶条件和其他有影响的因素。所以，这样的检查对于防止车辆组件的附加损害可能太迟了，引起昂贵的修理或伤害。同样，在最优条件下驾驶车辆时，可能不必要地对车辆维护，引起车主无谓的成本。

此外，当前的车辆诊断一般依赖于可获得的DTC。当DTC不可获得时，对于车辆故障确定，车辆检查和诊断漫长而昂贵。

发明内容

本申请书涉及的系统和相关联方法在定期维护中考虑了车辆子系统的性能和车辆驾驶条件，在DTC不可用时识别潜在的车辆故障。因此能够快速地识别车辆故障的原因同时避免不必要的维护。

示范控制单元包括处理器，被配置为执行车辆的第一子系统的第一代理程序。所述第一代理程序包括故障检测代理程序和通信代理程序。所述故障检测代理程序被配置为为了识别在所述第一子系统中的问题而监视所述第一子系统的性能数据，在第一存储器中存储所述第一子系统所对应的若干第一候选故障诊断过程，以及从所述若干第一候选故障诊断过程当中搜索对引起所述第一子系统中所述问题的故障进行识别的故障诊断过程。所述通信代理程序被配置为当所述故障检测代理程序的搜索未能找到识别所述故障的所述故障诊断过程时与第二代理程序合作。与所述第二代理程序的所述合作包括对存储着若干第二候选故障诊断过程的第二存储器进行搜索，向所述第二代理程序发送所述监视的性能数据以及在所述第一与第二代理程序之间交换搜索结果数据。

所述控制单元可以包括网络接口控制器，被配置为与所述第二代理程序的所述合作未能引起找到识别所述故障的所述故障诊断过程时建立所述第一代理程序与服务器代理程序之间的通信链接。注意，所述通信代理程序被配置为从所述服务器代理程序接收服务器候选故障诊断过程。在某示范方面，所述服务器代理程序由远离所述控制器单元运行的服务器执行。

在一个方面，所述通信代理程序被配置为把所述服务器候选故障诊断过程分配到所述第一代理程序和所述第二代理程序的所述故障检测代理程序。所述通信代理程序可以接收所述第二代理程序应用所述服务器候选故障诊断过程的结果，而所述故障检测代理程序可以把所述故障检测代理程序应用所述服务器候选故障诊断过程的结果与所述第二代理程序应用所述服务器候选故障诊断过程的结果进行对比以识别所述故障。在某些方面，所述故障的所述识别事件记录被存储在所述第一存储器中。

在另一个方面，所述网络接口控制器被配置为通过网络创建所述第一代理程序、所述第二代理程序与所述服务器代理程序之间的通信链接，以及所述通信代理程序被配置为从所述服务器代理程序接收所述服务器候选故障诊断过程以响应：(1)所述服务器代理程序连接到所述网络，以及(2)所述通信代理程序响应所述服务器代理程序连接到所述网络，向所述服务器代理程序传送所述受监视的性能数据以及在所述第一和第二代理程序之间交换的所述搜索结果数据。注意，所述通信代理程序可以进一步被配置为向所述服务器代理程序发送所述受监视的性能数据的统计和概率模型。

在又一个方面，所述第二代理程序对应于所述车辆的第二子系统，以及所述第二代理程序被配置为监视所述第二子系统的性能数据。在这个方面，所述第一代理程序被配置为识别所述第一与第二子系统的所述受监视性能数据之间的相关性，以及所述第一代理程序在所述第二存储器中搜索根据所述相关性识别所述故障的所述故障诊断过程。在替代方面，所述控制单元包括存储器模块，包括所述第一和第二存储器作为离散的存储体，其中所述处理器进一步被配置为执行所述第二代理程序。在另一个替代方面，所述控制单元包括网络接口控制器，被配置为把所述第一代理程序与所述第二代理程序通信地链接，其中所述第二代理程序由另一个控制单元的处理器执行。

所述第一代理程序可以包括汇聚代理程序，被配置为从所述受监视性能数据产生统计模型和概率模型以预测未来问题的概率。所述故障检测代理程序被配置为把所述第一子系统的所述受监视性能数据与来自所述汇聚代理程序的所述统计和概率模型的数据进行对比以识别在所述第一子系统中的所述问题。

所述搜索结果数据可以包括向所述受监视性能数据的至少一部分应用候选故障诊断过程的至少一部分的结果。所述候选故障诊断过程包括以下至少其一：(1)读取所述受监视子系统性能数据的选定部分，(2)对比所述受监视子系统性能数据和阈值，(3)检验所述受监视子系统性能数据的计时要求，以及(4)报告或记录所述受监视子系统性能数据。所述第一代理程序可以进一步包括学习代理程序，在健康的性能数据上进行训练，并且被配置为通过对比所述受监视性能数据和所述健康的性能数据而识别所述问题。

附图简要说明

通过参考附图可以获得本公开的更全面理解，其中：

图1是多代理程序诊断系统的示范构架框图；

图2A是智能代理程序的特征表；

图2B是智能代理程序的分解表；

图3A是显示驾驶地理位置信息的表；

图3B是显示车辆信息的表；

图3C是温度随时间变化的曲线；

图3D是湿度随时间变化的曲线；

图4展示了从给定数据集产生模型的剖析器；

图5是流程图，展示了由目标代理程序和服务器代理程序执行的算法过程；

图6是流程图，展示了故障诊断模型的功能块算法的串行执行；

图7是流程图，展示了以状态机确定的顺序执行的功能块算法；

图8是流程图，展示了功能块算法的并行执行；

图9是流程图，展示了功能块算法的条件执行；

图10是流程图，展示了功能块算法的串行和并行执行；

图11是流程图，展示了功能块算法由两个代理程序并行执行；

图12是代理程序软件框架的展示；

图13是代理程序通信协议的展示；

图14是实例消息帧的展示；

图15是连接到局域网并包括代理程序集的远程代理程序的框图；

图16是由数据汇聚代理程序产生的数据密度直方图，作为统计模型；

图17是由数据汇聚代理程序利用的理想高斯分布，作为测量误差的示范概率模型；

图18是学习系统的学习代理程序的框图；

图19是框图，展示了图15所示远程代理程序的代理程序集的算法互动；

图20是框图，展示了远程代理程序从车辆制动模块接收数据；

图21是直方图，展示的统计模型定义了制动踏板压力量与正常车辆的车辆响应之间的关系；

图22是由数据汇聚代理程序通过积累统计模型比如图21展示的直方图的许多事例逐步形成的概率模型；

图23是智能代理程序的诊断算法的流程图；

图24是智能代理程序的故障识别和缓解算法的流程图；

图25A-25D展示了采用多个合作智能代理程序的故障检测算法。

具体实施方式

车辆包括由电子控制单元（ECU）控制的多个计算机化子系统。ECU可以在OBD系统中运行或与其一起运行以监视子系统的性能以便检测车辆状态，比如失灵或其他异常运行状态。作为保养特征，车辆包括与保养终端连接的接口以从OBO系统读出数据，识别故障和推荐要进行的保养。

从OBD系统读出的数据包括识别故障的DTC，它与来自技术人员的视觉检查结合，体现了常规诊断实践。本申请针对得不到DTC假设下运行的多代理程序系统。

在某些方面，系统登录全车数据（即涉及不止一个车辆子系统的数据）以便建立子系统间信号的相关性，通过执行实施为车内代理程序的奇异检测、汇聚和机器学习算法而进行快速的初步车载分析，以确定可能的故障位置和严重性。当车载分析不确定时可以由数据中心（在商品特许经销商的服务终端处的服务器）请求更复杂的分析。

不仅如此，利用这样的系统运行在得不到DTC的假设下，有可能抢先地识别可能的未来故障。所以，驾驶员能够受到警告和更好的准备，并且经销商/服务中心能够削减前置时间以使得车辆更快地修理。常规诊断惯例为“后修”或反应性方式，其中在子系统显示故障迹象或顾客抱怨性能后进行保养。

本申请的若干方面针对“前修”即预示方式。也就是，本申请介绍的若干方面监视全车信号并建立不仅彼此而且与多种历史信息的互相关，如车辆使用模式（即驾驶风格、环境条件），所以进行多个子系统的代理程序之间的协作以识别车辆故障，可以包括预测车辆故障。

在流程图中的任何过程、描述或块都应当被理解为表示若干模块、分段、代码部分，它们包括一条或多条可执行指令，用于实施这些过程/算法中的特定逻辑功能或步骤，并且替代实施方案包括在示范实施例的范围内，其中若干功能可以不以所示和讨论的顺序执行，包括实质上同时发生或以倒序执行，取决于所涉及的功能，正如本领域技术人员会理解。

不仅如此，正如本领域技术人员接受了本公开的教导后将认识到，在不脱离附带的权利要求书所包含的本公开范围的情况下也能够设想所呈现实施例的几种结合和修改。因此，按照以上教导，权利要求书的许多修改和变种是可能的，所以应当理解，在附带的权利要求书的范围内，以本文专门介绍的方式以外的方式也可以实践若干实施例。

现在参考附图，其中在几幅图中相同附图标记始终指明一致或对应部分/步骤，图1描述了系统100的示范构架，利用服务器104和控制单元106的智能代理程序诊断车辆102中的故障。系统100包括若干智能代理程序如服务器代理程序104和目标代理程序106。

服务器104包括处理器106，比如英特尔公司生产的至强微处理器，连接到存储器108和数据库110以执行智能代理程序，服务器代理程序112。服务器104可以实施为个人计算机并配备服务器接口114，比如网络控制器，以建立经由网络116与控制单元106的通信。网络116可以包括局域网（LAN）或车辆局域网（通常称为VLAN）。LAN可以是基于以太网的网络，而VLAN可以基于LIN（局部互连网）。在一个方面，网络116被配置为使用流行的汽车通信协议的网络层，比如CAN、TCP/IP、Flexray和MOST。

网络116也可以包括连接到因特网的LAN或VLAN，在此情况下，服务器104和控制单元106通过无线电发射机执行无线通信任务。示范无线电发射机包括基于移动电话的发射机，比如基于GSM、CDMA和LTE标准的发射机。

控制单元106是车辆102的控制单元，并把车辆102的VLAN通信地链接到车辆102的多个其他其他控制单元。在某些方面，控制单元106是在车辆112中配置的ECU或其组件。ECU是在车辆中配置的计算机，并且控制单元106包括远程接口118经由网络116通信，而处理器120连接到相关联的存储器122以执行智能代理程序、目标代理程序。在一些方面，处理器120执行多个目标代理程序124、126和128，如图1所示。在其他方面，在图1中未显示，目标代理程序124、126和128的每一个都由车辆102的离散、分开的ECU运行。

与目标代理程序124（和126或128）相比，服务器代理程序112关于可访问资源比如存储器和处理能力的限制更少。目标代理程序124从车辆102的一个或多个子系统接收实时数据流，并且与服务器代理程序112相比通常处理能力和存储器有限。因此，在某些方面，目标代理程序124仅仅以高效代码执行紧凑的算法，并且仅仅在存储器122中存储有限数量的数据库集和功能库集。

在其他方面，目标代理程序124实时地执行适度复杂的算法，以下将讨论其进一步细节。目标代理程序124、126和128的每一个都为特定任务而构造和采用，比如诊断制动问题，并且在示范实施例中经由VLAN与在车辆102中其他配置的其他目标代理程序通信地链接，以便协同诊断车辆故障。

图2A显示了智能代理程序的属性，比如目标代理程序124。智能代理程序对于故障早期检测在采取某些行动时是自主的、反应性的、抢先的，并且与其他智能代理程序是共同存在的。智能代理程序在可靠和不可靠环境中都是能够做出合理决策的理性实体。

图2B显示了智能代理程序的示范结构，包括数据库集、功能库集、模型库集、通信通道、剖析器和状态机。数据库集是存储在例如数据库或存储器中的数据结构的集合。数据结构被划分为相关数据的若干小集合、即数据集，它们使用关系标签彼此发生关系并与大量数据链接在一起。

数据集可以包括如车辆、气候、天气和驾驶习惯信息。某些数据集，比如车辆信息和主要地理位置是静态的，而其他数据集，比如温度、湿度和道路条件是动态的，即随时间变化。

图3A和3B显示了存储在表中的示范数据。如图3A所示，车辆的驾驶位置一般是静态的或不经常改变，驾驶位置的海拔被设置为500英尺而道路条件被标识为‘OK’，它是相对的测量结果。这种信息也能够例如关于时间动态地存储。另一方面，如图3B所示，车辆信息比如型号/制造商是静态的。也就是，车辆的制造商、车型、发动机类型和驱动是恒定的并不改变。

图3C和3D以曲线图显示了示范动态数据，关于时间绘制。图3C是随时间的温度直方图而图3D是随时间的湿度直方图。正如以上指出，当信息是动态时在图3A所示表中列出的信息也可以类似地绘出。

在示范车辆制动系统中，目标代理程序收集关于该制动系统的数据的不同集合或类别。例如目标代理程序收集的第一数据集包括与车辆有关的数据，比如制造商、型号、传动系统类型和制动类型，而第二数据集为驾驶员操作车辆时随时间收集的驾驶习惯数据。目标代理程序还收集气候信息的第三数据集，比如天气、温度和湿度以及比如经由车辆悬挂系统收集的道路条件数据的第四数据集。这些数据流/元素能够通过与不同于目标代理程序的各种各样的智能代理程序通信而收集。

智能代理程序的功能库集包括若干功能块或单元，每一个都被设计为执行多部分任务（算法或过程）的特定部分。功能块是可重入的函数。也就是，它们在任何组合中使用而彼此没有依赖性。在示范实施例中，功能块通过应用多种算法实现了数据收集、数据操纵和数据理解，并且执行转换、对比（如，与阈值）、归一化和记录的功能。这些功能块进一步具有唯一的ID并由代理程序运行时间环境指定。

智能代理程序的剖析器是引擎，它执行时使用来自智能代理程序的功能库集的若干功能块和数据库集的若干数据集产生故障诊断模型。一般来说，剖析器是服务器代理程序112的组件。剖析器考虑了与比如驾驶行为、道路条件和气候有关的数据集。

在图4描绘的实例中，剖析器根据图3A至图3D描绘的静态和动态数据集逐步形成了新的故障诊断模型，并且进一步考虑了也被存储在智能代理程序的数据库集中的关于某些故障类型的车辆历史。如图4实例所示，剖析器使得这些模型相关到可能问题410和实际问题420的区域中。

例如，剖析器首先使用与车辆制造商/型号有关的数据集执行多个算法，以检测该车辆的具体制造商/型号是否具有制动问题的历史。如果剖析器确定所述车辆的制造商/型号具有制动问题的历史，那么剖析器就把该信息添加到制造商/型号作为已知问题。

剖析器然后结合制造商/型号信息相关的数据集和驾驶习惯信息相关的数据集，并且执行算法以确定驾驶员的驾驶习惯对该车辆制造商/型号的制动系统的潜在影响。如果剖析器确定某潜在影响存在，那么剖析器就将该潜在影响添加到该车辆的制造商/型号作为已知问题。

取以上讨论的制动系统作为实例，制动系统具有在不同气候下反应和表现不同的机械部件。具体地说，与寒冷气候相比，制动衬块的腐蚀在炎热气候可能更快地发生。因此，剖析器还评估气候特征的影响，比如湿度、温度和几种其他环境因素，方式为根据制造商/型号、驾驶习惯和气候相关的数据集逐步形成若干模型并且运行算法以确定相关因子。

如果剖析器确定影响存在，那么剖析器就把适当信息存储在智能代理程序的型号库集中作为已知问题。最后，剖析器使用一切可用数据执行多种算法以检测可能的车辆故障，并且在模型库集中存储这些结果作为制动系统的智能代理程序的故障诊断模型。在一个方面，以上讨论的实例把服务器代理程序112描绘为执行剖析的智能代理程序而目标代理程序124为对制动系统监视制动系统性能数据的智能代理程序。

如以上讨论，剖析器根据对每个目标代理程序可用的数据集和功能块建立故障诊断模型。因此例如，目标代理程序具有相关联的故障诊断模型，它也被称为目标代理程序具有的有关该车辆的已知问题或置信集。例如，示范制动系统的目标代理程序具有相关联的故障诊断模型，它是为了检查和检测潜在的制动系统问题专门逐步形成的，从而包括对检测故障制动器所必要的全部信息。

通信通道为智能代理程序之间的通信提供了定义明确的网络协议。开发标准的通信协议是为了改进通信效率，以下将关于示范代理程序软件框架进行讨论。

状态机是有限数量的状态以及这些状态与动作之间转换的行为模型（算法）（类似于流程图，其中能够检查在某些条件满足时逻辑如何进行）。在一个方面，状态机是if-then-else语句的集合，它响应事件，尤其是同步和异步事件，并且确定要执行的适当算法及其执行的适宜时间，以获得最好的可能解决方案。状态机不知道由服务器代理程序或目标代理程序所执行的诊断类型，这便利了多个智能代理程序的开发和部署。

在一个方面，状态机不是服务器状态机就是目标状态机。服务器状态机把适当的功能块排序以创建功能块算法，并且存取大量的历史数据以逐步形成互相关表，按照车辆故障描述车辆子系统对彼此的相对影响。

多代理程序系统执行若干一般算法，它们以顺序的、并行的或混合的次序执行选定的目标代理程序以实现所期望的多步骤诊断过程。不过，由于目标代理程序的存储器和处理能力相对有限，所以目标代理程序必须把问题分解为更多的可管理程序块或子问题，以便使它能够通过代理程序的合作求解。

图5展示了目标代理程序与服务器代理程序之间的示范算法互动。在步骤510和512，开始执行目标代理程序和服务器代理程序。在步骤514，目标代理程序监视并收集来自车辆子系统的适当数据用于临时车载存储器。在步骤516，目标代理程序通过应用无损压缩技术处理该数据并包装到压缩数据集之中。目标代理程序然后把该压缩数据发送到服务器代理程序。

服务器代理程序在步骤520接收该压缩数据并对该压缩数据采取适当的动作，例如执行多个算法比如无监督学习、汇聚和分类。服务器代理程序然后在步骤522执行ID剖析并建立用于目标代理程序的适当数据和功能块。这种数据在步骤524被包装到压缩格式中并发送到目标代理程序。

目标代理程序在步骤526从服务器代理程序接收这种数据。在步骤528，目标代理程序的状态机执行收到的功能块以执行诊断在步骤530识别车辆故障。

功能块算法包括串行地、并行地或混合地执行功能块，取决于当前情况和需要。在图6展示的串行执行算法中，功能块F1读取信号，F2对比在F1读取的信号与阈值，F3检验计时需求而F4报告和存入这些结果。图7至图11显示了其他过程的多个实施例。

在图7中，状态机已经随机化了若干功能块的执行顺序或者功能块的顺序以实现最佳的解决方案。注意，F1读取信号，F13读取另一个信号，F24对比F1与F13的结果，而F2对比F1对F13的影响。

图8展示了功能块算法的并行执行。因此，功能块的两个序列，即F2/F3/F4序列和F13/F24/F2序列的结果都被求值，并且（在D）确定了最好的可能解决方案并使用。如果状态机判定因为来自单一算法的结果太缺乏说服力，所以确定车辆故障需要多个算法，如D所表明，该状态机便产生并行执行算法。例如，与数据信号相关联的误差或概率模型可能导致状态机判定结果是不确定的。

在图9描绘的示范功能块算法中，若干功能块有条件地执行并且执行路径根据条件功能块的结果而确定。有条件执行向系统增添了灵活性并且被用于单一预定义算法将不充分时。在图9的实例中，功能块F1读取信号，而执行路径──即不是F3就是F24──根据该信号的值确定──它可以使用若干阈值或若干范围。

状态机可以进一步评估一切可能解决方案的结合以确定最佳解决方案。图10展示了既有串行执行又有并行执行的示范功能执行算法。混合执行算法用在检测故障的可能性非常低时。如图10描述，这种算法并行地执行多个嵌套的功能块算法，向每个嵌套算法的结果分配权重，并且根据每个嵌套算法的增益──即权重值与结果的乘积──确定车辆故障。例如，以功能块F1开始的嵌套算法与以F2开始的嵌套算法被并行执行，并且每个嵌套算法的结果都被分配了权重，它与结果相乘以确定车辆故障。

正如先前介绍，系统100可以包括多个目标代理程序，它们共享若干资源。例如，目标代理程序124能够与目标代理程序126共享其若干功能块并合作。正如图11展示，目标代理程序A1和A2在一起合作/工作以实现共同的目标。目标代理程序A1和A2并行地执行不同算法并对比这些结果。这样的实施例可以使用不止两个目标代理程序。

为了便利执行多个智能代理程序，系统100支持一组应用程序编程接口（API）。如图12描述，这些API组成了代理程序软件框架（ASF）1200，它具有分层体系结构。ASF1200具有硬件1202，由设备驱动程序1204和操作系统层1206支持。ASF120还包括在设备驱动程序1204和操作系统层1206上建立的代理程序运行时间环境（ARE）1208。代理程序探测协议（APP）1210和代理程序通信协议（ACP）1212支持ARE1208。ACP1212由代理程序消息传递协议（AMPP）1214支持。智能代理程序A1-A9支持APP层1210和AMPP层1214。此外，有能力运行本文介绍的代理程序系统的车辆子系统支持ARE1208。

ARE1208是预定义的软件框架，能够远程地和安全地接受智能代理程序并提供智能代理程序的运行时间执行。ARE1208在数据库中注册若干智能代理程序并为每个智能代理程序提供唯一ID。ARE1208进一步为在同一子系统中和车辆中的其他智能代理程序提供代理程序扫描特征。

APP1210提供了若干功能，目标代理程序经由其监视和收集数据，比如预定义的探测功能以及监视和记录功能。ACP1212提供了不依赖网络的消息传递服务并且基于ARE1208的每个智能代理程序具有唯一ID（如A1-A9）的特征。ACP1212进一步提供了在服务器代理程序与目标代理程序之间实现通信的一组接口，并且被配置为使用流行汽车通信协议的网络层，比如图13描绘的CAN、TCP/IP、Flexray和MOST。

AMPP1214使用ARE1208的ACP1212特征与其他智能代理程序通信。具体地说，AMPP1214把消息包装为帧，如图14展示，包括帧头1410和消息体1412。帧头1410存储着关于源和目的地代理程序、通信类型比如发送或接收以及消息长度的信息。消息体1412存储着要被发送或接收的消息。虽然图14展示的消息具有8字节的尺寸，但是消息长度/尺寸可以按照需要变化并且可以进一步由消息帧头编码。

本公开的示范实施例包括执行车辆诊断相对更复杂和更自主的远程代理程序。远程代理程序对应于以上讨论的目标代理程序，但是包括进一步的特征。图15把示范远程代理程序1510描述为智能代理程序的集合，为了识别难以检测的故障在一起运行。远程代理程序1510是广泛覆盖的代理程序，即能够与尽可能多的车辆子系统互动，它能够观察到车辆子系统之间的交叉连接，对于原因-结果分析往往是关键的。

远程代理程序1510连接到车辆局域网（VLAN/LAN）1512──车辆通信主要总线，智能代理程序经由其从车辆子系统收集数据，并且消息经由其在多个车辆模块之间被发送和接收，它们包括其他的远程代理程序（图15中未显示）。不过，为了与车辆模块通信，远程代理程序1510对经由LAN1512接收/发送的消息进行解码和编码。

远程代理程序1510的示范实施例包括数据收集代理程序（DCA）1514，它经由LAN1512监视和收集数据。LAN1512传送三种类型的数据：周期数据、异步数据和请求的即随选数据。典型情况下周期数据表示车辆子系统的健康和状态并经由LAN1512周期地广播，如每10/100ms；当车辆子系统出现异常事件或故障时发送异步数据；而请求的数据是由另一个车辆子系统从一个车辆子系统请求的数据。在周期或请求的数据的情况下，DCA1514选择所期望的数据信号并实施适当的数据收集模式，如不变的采样率或可变的采样率。

远程代理程序1510还包括数据预处理代理程序（DPA）1516，它立即作用于由DCA1514收集的数据以从消息中除去数据头信息，并且如果消息以多帧发送，便等待到收集了整条消息或数据。由DPA1516进行的预处理可以包括简单的以及适度复杂的操作，比如移动平均计算或子波分解而且是针对信号的。然后使处理后数据作为“特征”对其他代理程序可用。

数据汇聚代理程序1518根据从DPA1516收到的数据产生统计和概率模型，并且可以进一步产生高级汇聚算法对数据加以分类。不过，大多数数据很可能保持未标注和未分类直到连接了服务器代理程序并根据详尽得多的分析提供了分类标注信息，使错误的概率足够小。

由数据汇聚代理程序1518产生的统计模型表示数据的快照并可以包括例如与图16中描述的数据直方图类似的数据直方图。另一方面，由数据汇聚代理程序1518产生的概率模型从更大量的数据逐步形成并被用于以统计方面显著的方式预测故障的概率。图17中描述的高斯分布是有关测量误差的示范概率模型和流行假设。

回顾图15，远程代理程序1510的数据记录代理程序1520存储一定时段的特定数据（如停帧数据）。具体地说，数据记录代理程序1520选择来自DCA1514的期望信号并对给定时段记录这些信号值，如从旅途的起点到终点。

学习代理程序1522实施人工智能和机器学习算法。图18描述了示范学习代理程序1522，它展示由学习代理程序1522把一组数据映射到另一组，如把若干输入变量映射到若干输出。

故障/奇异检测代理程序1524从数据汇聚代理程序1518、数据记录代理程序1520和学习代理程序1522接收数据，并且把（特征空间中的）处理后数据对照已知数据进行对比，对不寻常和/或异常行为进行车载检测和分类。处理后数据例如经由数据记录代理程序1520从DPA1516收到，并且在所述问题的危险程度需要快速纠正行动时也可以由通信代理程序1526发送到服务器代理程序对车载完成的分析进行补充分析或确认。通信代理程序1526包括发送代理程序1528、接收代理程序1530和数据记录器代理程序1532。

当新车辆从销售商或工厂离开时就采集已知数据（基线数据），并且远程代理程序1510假设这种初始数据是无故障的，并且表示车辆子系统和健康的性能数据的特征值。也就是，远程代理程序1510假设每辆车在离开工厂时都具有独特的特征传感器值，从其建立独特的基线以体现车辆子系统健康的模型。

正如以上讨论，故障/奇异检测代理程序1524使用来自数据汇聚代理程序1518、数据记录代理程序1520和学习代理程序1522的数据检测奇异性。例如，故障/奇异检测代理程序1522使用来自数据汇聚代理程序1518的数据来区分由于如操作模式变化或环境变化在数据值中造成的自然变化与由于车辆故障造成的变化。图19显示了用于远程代理程序1510的示范算法过程。

正如以上指出，在图15中，通信代理程序1526包括发送代理程序1528、接收代理程序1530和数据记录器代理程序1532。通信代理程序1526控制远程代理程序1510与连接到LAN1512的服务器代理程序（比如服务器代理程序122）和其他远程代理程序（未显示）之间的通信。例如，发送代理程序1528使用无损失压缩算法压缩要传输的数据，接收代理程序1530接收来自服务器代理程序的数据，而数据记录器代理程序1532实现远程代理程序1510存储车载数据，建立了与服务器代理程序的通信后向服务器代理程序广播（或者当通信中断时作为临时存储器）。

在一个示范通信情景下，由远程代理程序监视的子系统的一切性能数据都经由专用通道被注入到服务器代理程序。这种情景需要高带宽和恒定的车辆/服务器连接。这种情景对于在工厂的初始化或经销商访问期间是理想的，并且将更及时地可存取，比如经由下一代WiMax或认知无线电。

在另一个示范通信情景下，只有选中的数据如最关键信号或车载处理结果才被发送到服务器代理程序。这种情况需要的带宽小得多。这种情景实施了选择过程以选择所期望的高优先级数据和信息用于向服务器代理程序发送。

正如以上讨论，本公开的若干方面能够实施在车辆制动系统中，机械和电子组件它都有。车辆制动系统是最关键的安全系统之一，所以一般建议每年检查两次。对制动系统中故障的早期检测不仅节省了金钱而且预防了致命事故。参考以上讨论的制动系统讨论本公开的进一步方面。

在示范实施例中，正如图20描述，远程代理程序1510经由LAN1512与车辆制动模块通信，其中DCA1514收集了两种信号：制动踏板压力和车辆速度，被用于如确定该车辆的减速度速率（车辆响应）。DCA1514连续地监视这些输入信号。

DPA1516通过应用适当的滤波器降低信号中的噪声量，把来自DCA1514的数据预处理为滤波后的制动踏板压力和滤波后的车辆速度。数据汇聚代理程序1518逐步形成统计模型，比如图21所示的模型，以便使用DPA1516的结果对健康的车辆定义制动踏板压力量与车辆响应之间的关系。数据汇聚代理程序1518逐步形成概率模型，比如图22所示的模型，方式为累积如在许多不同旅途上的统计模型的许多实例。

数据记录代理程序1520为可以由起点/终点GPS位置确定的给定旅途存储了一组新鲜数据。随着时间流逝，制动系统的性能不可避免地开始下降，这由数据汇聚代理程序1518检测为统计模型（数据快照）与概率模型之间的统计上的显著差异，其中统计差异由比如方差分析（ANOVA）或χ检验法准则确定（概率模型使用比统计模型多得多的平均）。如果统计上的显著差异在几幅数据快照上持续，那么数据汇聚代理程序1518就发出奇异性（问题）存在的信号，并且怀疑有故障。图22描述的示范概率模型包括子系统性能的健康区和故障区二者，其中“问题”区在图22中被识别为从μ增加的距离。

学习代理程序1522也用于对比预期的故障制动行为与实际的故障制动行为，其中学习代理程序1522把基于物理的制动模型表示为按照不同等级的性能下降，比如刹车垫磨损，如以上讨论它可以考虑气候因素。学习代理程序1522能够由服务器代理程序根据来自共同模型的多台车辆的数据逐步形成，然后部署到远程代理程序1510以辅助把数据汇聚到特定的制动下降分类中。因此，学习代理程序1522不需要从目标车辆所特有的数据起源，而是能够由服务器发送到目标车辆以便最好地匹配实际车辆数据，“最佳地”预测车辆响应的输出。这种“最佳”预测能够利用实际数据与模型数据之间的均方根误差描述制动下降的等级。类似方法使用已知正常模型与故障行为（已知问题）的对比的类似方式也可以用于查明制动问题的源头（如刹车垫磨损、制动靴磨损或液压问题）以确定车辆故障的根本原因。

另外，对多代理程序设置的诊断可以采用高等级的算法，其中每个算法块自身都可以是实施以上讨论的过程之一的代理程序或代理程序系列。

图23展示了示范智能诊断算法，它包括监视数据集、识别可能的问题以及采取适当的动作。正如先前陈述，当车辆初始离开工厂或经销商时，系统假设该车辆的全部模块都工作正常而且仅仅在某段时间后车辆的若干模块才将开始显示异常行为的征兆。因此，在图23中算法的第一步骤2302，信号受到监视。不过，因为无法在车辆的车载系统中存储或向服务器代理程序广播全部的可能记录的数据，所以由DCA1518实施汇聚模式以监视原始输入并逐步形成统计模型比如直方图以识别故障。无监督学习代理程序1522与DCA1518并排地执行并使用健康的数据训练，使得一旦故障发生，学习代理程序1522就能够检测出故障。

一旦车辆开始显示异常行为，在步骤2304故障检测代理程序1524就把输入信号特征对照由DCA1518逐步形成的统计模型对比以识别问题。正如以上讨论，在步骤2304学习代理程序1522也能够识别问题。在以上讨论的制动模型中，受监视的数据集包括车辆滑移，制动器响应所花的时间以及几个其他因素。在步骤2306通过执行算法识别出导致在步骤2304所识别问题的故障。

图24的流程图展示了检测车辆中故障的算法，其中智能代理程序系统100进一步发现解决方案以缓解故障。步骤2402和2404与图23的步骤类似。一旦在步骤2404识别了问题，便在步骤2406识别故障，它可以包括执行对该故障进行识别的算法。

在步骤2408，对该故障是否已知做出判断。已知时，已知解决方案通常可用于缓解故障，在步骤2410应用它。否则，在步骤2412找到缓解该故障的解决方案。步骤2412可以包括与服务器代理程序或其他智能代理程序通信。一旦找到了解决方案，便在步骤2414应用该解决方案以缓解所述故障。

图25A是展示多代理程序算法的算法流程图，用于由车辆的目标或远程代理程序所执行的故障检测。在步骤2502，子系统的性能数据（数据集）受到监视并在步骤2504识别问题。当在步骤2504识别出问题时，便执行算法搜寻以识别导致问题的故障。注意，所述问题是指奇异数据集或异常数据集，而故障是导致该奇异数据集或异常数据集的机械/电气问题。未找到适当的算法时，便在步骤2510执行与该车辆的其他目标（或远程）代理程序的合作。

在步骤2512与其他目标代理程序的合作未能找到识别故障的算法时，便在步骤2514执行与服务器代理程序的合作。正如以上讨论，由于服务器代理程序具有多得多的资源，所以这通常将引起的适当的算法要被发现。不过，未找到算法时，便在步骤2518存入该算法的若干事件。找到算法时，便在步骤2520应用该算法。

在图25B进一步详细地显示了若干目标代理程序之间在步骤2510的合作。注意，在步骤2522识别可用代理程序后跟随的过程在步骤2524搜索可用代理程序的数据库集以及在步骤2526交换此目标代理程序与其他目标代理程序之间的数据/结果。尽管以步骤2524然后步骤2526的次序显示，但是应当认识到，合作过程能够重复其部分或全部，或者以不同的次序进行（步骤2526先于步骤2524）。

图25C进一步详细显示了目标代理程序与服务器代理程序之间在步骤2514的合作。注意，在步骤2528与服务器代理程序的启动通信（LAN初始化）后跟随的过程在步骤2530与服务器代理程序共享受监视数据集和初步结果（失败的结果/失败算法的结果）。然后服务器代理程序建立或找到识别该故障的算法，它在步骤2532收到。

在以上搜索适当算法（步骤2508、2512和2516）中任何一次成功，都在步骤2520应用该算法，如图25A所示。在图25D中进一步详细显示了算法应用步骤2520。注意，在步骤2534向涉及的目标代理程序分发由服务器代理程序收到的算法后跟随的过程在步骤2536在每个目标代理程序处应用该算法。在步骤2538对比了被应用的算法的结果，并且在步骤2540识别出故障。从而能够识别出该问题的根源。

Claims (20)

1.一种控制单元，包括：

处理器，被配置为执行车辆的第一子系统的第一代理程序，所述第一代理程序包括故障检测代理程序和通信代理程序，

所述故障检测代理程序被配置为为了识别在所述第一子系统中的问题而监视所述第一子系统的性能数据，在第一存储器中存储所述第一子系统所对应的若干第一候选故障诊断过程，以及从所述若干第一候选故障诊断过程当中搜索对引起所述第一子系统中所述问题的故障进行识别的故障诊断过程，以及

所述通信代理程序被配置为当所述故障检测代理程序的搜索未能找到识别所述故障的所述故障诊断过程时与第二代理程序合作，与所述第二代理程序的所述合作包括对存储着若干第二候选故障诊断过程的第二存储器进行搜索，向所述第二代理程序发送所述监视的性能数据以及在所述第一与第二代理程序之间交换搜索结果数据。

2.根据权利要求1的控制单元，进一步包括：

网络接口控制器，被配置为与所述第二代理程序的所述合作未能引起找到识别所述故障的所述故障诊断过程时建立所述第一代理程序与服务器代理程序之间的通信链接，

所述通信代理程序，被配置为从所述服务器代理程序接收服务器候选故障诊断过程。

3.根据权利要求2的控制单元，其中，所述通信代理程序被配置为把所述服务器候选故障诊断过程分配到所述第一代理程序和所述第二代理程序的所述故障检测代理程序。

4.根据权利要求3的控制单元，其中，

所述通信代理程序接收所述第二代理程序应用所述服务器候选故障诊断过程的结果，以及

所述故障检测代理程序把所述故障检测代理程序应用所述服务器候选故障诊断过程的结果与所述第二代理程序应用所述服务器候选故障诊断过程的结果进行对比以识别所述故障。

5.根据权利要求4的控制单元，其中，所述故障的识别事件记录被存储在所述第一存储器中。

6.根据权利要求2的控制单元，其中，所述服务器代理程序由所述控制器单元远程操作的服务器执行。

7.根据权利要求2的控制单元，其中，

所述网络接口控制器被配置为通过网络创建所述第一代理程序、所述第二代理程序与所述服务器代理程序之间的通信链接，以及

所述通信代理程序被配置为从所述服务器代理程序接收所述服务器候选故障诊断过程以响应：(1)所述服务器代理程序连接到所述网络，以及(2)所述通信代理程序响应所述服务器代理程序连接到所述网络，向所述服务器代理程序传送所述受监视的性能数据以及在所述第一和第二代理程序之间交换的所述搜索结果数据。

8.根据权利要求7的控制单元，其中，所述通信代理程序进一步被配置为向所述服务器代理程序发送所述受监视的性能数据的统计和概率模型。

9.根据权利要求1的控制单元，其中，

所述第二代理程序对应于所述车辆的第二子系统，以及

所述第二代理程序被配置为监视所述第二子系统的性能数据。

10.根据权利要求9的控制单元，其中，

所述第一代理程序被配置为识别所述第一子系统与第二子系统的所述受监视性能数据之间的相关性，以及

所述第一代理程序在所述第二存储器中搜索根据所述相关性识别所述故障的所述故障诊断过程。

11.根据权利要求9的控制单元，进一步包括：

存储器模块，包括所述第一存储器和第二存储器作为离散的存储体，其中，所述处理器进一步被配置为执行所述第二代理程序。

12.根据权利要求1的控制单元，其中，所述第一代理程序进一步包括汇聚代理程序，被配置为从所述受监视性能数据产生统计模型和概率模型以预测未来问题的概率。

13.根据权利要求12的控制单元，其中，所述故障检测代理程序被配置为把所述第一子系统的所述受监视性能数据与来自所述汇聚代理程序的所述统计和概率模型的数据进行对比以识别和预测在所述第一子系统中的问题。

14.根据权利要求1的控制单元，其中，所述搜索结果数据包括向所述受监视性能数据的至少一部分应用候选故障诊断过程的至少一部分的结果。

15.根据权利要求14的控制单元，其中，所述候选故障诊断过程包括以下至少其一：(1)读取所述受监视子系统性能数据的选定部分，(2)对比所述受监视子系统性能数据和阈值，(3)检验所述受监视子系统性能数据的计时要求，以及(4)报告或记录所述受监视子系统性能数据。

16.根据权利要求1的控制单元，其中，所述第一代理程序进一步包括学习代理程序，在健康的性能数据上进行训练，并且被配置为通过对比所述受监视性能数据和所述健康的性能数据而识别问题。

17.根据权利要求1的控制单元，进一步包括：

网络接口控制器，被配置为通信地链接所述第一代理程序与所述第二代理程序，其中，所述第二代理程序由另一个控制单元的处理器执行。

18.一种车辆，包括根据权利要求1的控制单元。

19.一种计算机可读介质，存储着诊断车辆故障的程序，其由计算机执行时，执行用于识别导致车辆子系统中问题的故障的方法，所述方法包括：

执行车辆第一子系统的第一代理程序，所述第一代理程序包括故障检测代理程序和通信代理程序；

由所述故障检测代理程序为了识别在所述第一子系统中的问题而监视所述第一子系统的性能数据；

由所述故障检测代理程序从第一存储器中存储的与所述第一子系统对应的若干第一候选故障诊断过程当中搜索对引起所述第一子系统中问题的故障进行识别的故障诊断过程；以及

当所述故障检测代理程序的所述搜索未能找到识别所述故障的所述故障诊断过程时由所述通信代理程序与第二代理程序合作，所述合作包括对存储着若干第二候选故障诊断过程的第二存储器进行搜索，向所述第二代理程序发送所述监视的性能数据以及在所述第一代理程序与第二代理程序之间交换搜索结果数据。

20.一种方法，用于识别导致车辆子系统中问题的故障，所述方法包括：

执行车辆第一子系统的第一代理程序，所述第一代理程序包括故障检测代理程序和通信代理程序；

由所述故障检测代理程序为了识别在所述第一子系统中的问题而监视所述第一子系统的性能数据；

由所述故障检测代理程序从第一存储器中存储的与所述第一子系统对应的若干第一候选故障诊断过程当中搜索对引起所述第一子系统中的问题的故障进行识别的故障诊断过程；以及

当所述故障检测代理程序的所述搜索未能找到识别所述故障的所述故障诊断过程时由所述通信代理程序与第二代理程序合作，所述合作包括对存储着若干第二候选故障诊断过程的第二存储器进行搜索，向所述第二代理程序发送所述监视的性能数据以及在所述第一代理程序与第二代理程序之间交换搜索结果数据。

Images