用于车内预测性故障检测的系统和方法与流程

本申请要求2016年10月12日提交的标题为“用于车内预测性故障检测的系统和方法(systemsandmethodsforin-vehiclepredictivefailuredetection)”的美国临时申请号62/407,359的优先权，其全部内容为了所有目的以引用方式并入本文。

本公开涉及用于预测结果的分析模型领域，更具体地涉及在工厂保修期间预测汽车原始设备制造商(oem)的未来汽车故障和产品(车辆)的修理。

背景技术：

汽车oem不断努力构建更好的产品，并减少车辆使用寿命期间所需的维修次数。为了增强消费者的信心，每辆新车都会提供保修。但是，即使有保修，对质量真实或不真实的感觉随着车辆返回保修维修的次数而减少。

技术实现要素：

通过在车辆品牌和型号上使用预测性分析模型，oem可以减少车辆进行维修的总次数，在需要大量维修之前改进产品，并且可能避免大规模召回。在这方面，可以使用能够在车辆发生故障之前预测车辆故障的系统；通过预测性地检测车辆故障，可以避免诸如损坏和路边维修之类的不良后果，从而改善消费者对车辆质量的感知和消费者信心。此外，预测性分析可以使oem能够在发生故障时观察故障趋势，从而防止昂贵且不方便的大规模召回。在以下描述中，其他益处将变得显而易见。

根据本公开的一个或多个方面，可以利用车内预测性故障检测系统来实现上述目的。本公开提供了统计模型和方法，其建立现有保修索赔与由车辆产生的诊断故障代码(dtc)之间的属性，以及dtc本身之间的因果关系。在预测性框架中实施时，这可以减少保修费用和不可预见的问题。根据本公开的预测性模型可以基于dtc模式的检测来提供故障的早期警告。

上述目的可以通过一种方法实现，所述方法包括基于一个或多个诊断故障代码(dtc)确定车辆故障的概率；以及响应于概率超过阈值而向车辆的操作者指示可能发生故障。所述确定可以基于将一个或多个dtc与一个或多个训练的模型对象进行比较。可以使用对历史dtc数据执行的机器学习算法来生成训练的模型对象。所述确定还可以基于包括里程表读数和电池电压的多个工况。

在一些示例中，所述指示可以包括经由屏幕显示文本消息，所述文本消息包括指令。所述指令可以包括访问机修站或服务站的推荐天数。推荐天数可以基于概率，对较低概率推荐较多天数并且对较高概率推荐较少天数；并且其中天数还基于生成dtc的车辆子系统。可以基于生成dtc的车辆子系统来选择阈值。

在其他示例中，上述目标可以通过一种系统来实现，所述系统包括：车辆、多个车辆子系统、具有存储在非暂时性存储器中的机器可读指令的控制器，所述控制器用于：从车辆子系统接收一个或多个诊断故障代码(dtc)；通过将一个或多个dtc与一个或多个训练的模型对象进行比较来生成车辆故障的概率；以及在概率超过阈值的情况下向车辆的操作者指示可能发生故障。

另外或替代地，这些目的可以通过一种方法实现，所述方法包括：接收诊断故障代码(dtc)和发动机操作参数；将dtc和发动机操作参数与训练的模型对象进行比较以生成车辆故障概率和指令；以及响应于故障概率大于阈值，而在屏幕上向车辆的操作者显示指令。

附图说明

通过参考附图来阅读下文对非限制性实施方案的描述，可以更好地理解本公开，其中以下：

图1示出了体现根据本公开的一个或多个实施方案的预测性故障检测系统的一个或多个方面的示例性电子装置；

图2示出了用于车内预测性故障检测的示例性方法；

图3示出了用于生成训练的模型对象以用于车内预测性故障检测系统和/或方法的示例性方法；

图4示出了用于将会话类型分类为故障会话和非故障会话的方法；

图5示出了示例性模式挖掘工作流程图；

图6a和图6b分别示出了在2015年7月至2015年12月和2016年1月至2016年6月期间，根据贝叶斯定理的模式排序，前面5个识别的症状模式故障的倾向；

图7示出了灵敏度和特异性图示；

图8示出了根据一个示例的示例性灵敏度和特异性曲线；

图9示出了根据给定概率截止的模型性能度量；

图10示出了在不同概率截止值下的真的正比率的折衷；

图11示出了用于模型验证的示例性数据准备工作流程的图示；

图12示出了示例性数据分箱决策树；

图13示出了不同数据集中故障模式和非故障模式的分布；

图14示出了最常见的故障会话dtc；

图15示出了故障会话对非故障会话依据dtc数量的频率；

图16示出了依据会话中dtc的数量的故障比例；

图17示出了故障会话和非故障会话的电池电压分布；

图18a至图18d示出了使用不同输入参数的模型准确度结果；

图19示出了dtc龄期的分布；

图20a和图20b示出了2016年5月和6月数据集的模型性能度量；以及

图21a和图21b示出了在包括和不包括电池电压和里程表读数情况下的模型性能度量。

具体实施方式

如上所述，提供了用于车内预测性故障检测系统和方法的系统和方法。以下是包括如本文使用的术语定义的表格：

图1是示例性电子装置100的框图，其可以包括如本文所公开的预测性故障检测系统或方法的一个或多个方面。电子装置100可以包括一组指令，该组指令可以被执行以使电子装置100执行所公开的一个或多个方法或基于计算机的功能，诸如接收由车辆子系统发布的一个或多个dtc；从多个车辆传感器接收一个或多个工况；将dtc和/或一个或多个工况与一个或多个规则或训练的模型对象进行比较；基于dtc、工况和训练的模型对象来生成故障概率；以及基于故障概率向操作者发出消息。电子装置100可以作为独立装置操作，或者可以诸如使用网络连接到其他计算机系统或外围装置。特定地说，电子装置可以是连接到车辆的独立装置，或者可以被实例化为预先存在的车辆系统(诸如ecu)中的计算机可读指令。

在联网部署的示例中，电子装置100可以在服务器的容量中或作为服务器-客户端用户网络环境中的客户端用户计算机、作为对等(或分布式)网络环境中的对等计算机系统，或以各种其他方式操作。电子装置100还可以实施为或并入各种电子装置(诸如台式和膝上型计算机)、手持装置(诸如智能电话和平板电脑)、便携式媒体装置(诸如记录、播放和游戏装置)、汽车电子器件(诸如主机单元和导航系统)、或能够执行一组指令(顺序或以其他方式)的其他机器，该组指令导致该机器采取行动。电子装置100可以使用提供语音、音频、视频和/或数据通信的电子装置来实施。虽然示出了单个电子装置100，但是术语“装置”可以包括单独或联合执行一组或多组指令以执行预测性故障检测系统的一个或多个电子功能的装置或子装置的集合，如下面更详细阐述。

电子装置100可以包括处理器102，诸如中央处理单元(cpu)、图形处理单元(gpu)或两者。处理器102可以是各种系统中的部件。例如，处理器102可以是车辆中的主机单元或ecu的一部分。另外，处理器102可以包括一个或多个通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列、服务器、网络、数字电路、模拟电路、它们的组合，或用于分析和处理数据的其他现在已知或以后开发的装置。处理器102可以实施软件程序，诸如手动生成或编程的代码。

电子装置100可以包括存储器，诸如可以经由总线110通信的存储器104。存储器104可以是或包括主存储器、静态存储器或动态存储器。存储器104可以包括非暂时性存储器装置。存储器104也可以包括计算机可读存储介质，诸如各种类型的易失性和非易失性存储介质，包括随机存取存储器、只读存储器、可编程只读存储器、电可编程只读存储器、电可擦除只读存储器、快闪存储器、磁带或磁盘、光学介质等。另外，存储器可以包括其上存储软件的非暂时性有形介质。软件可以电子方式存储为图像或以其他格式(例如通过光学扫描)存储，然后编译、解译或以其他方式处理。

在一个示例中，存储器104包括用于处理器102的高速缓存或随机存取存储器。在替代性示例中，存储器104可以与处理器102(诸如处理器的高速缓存存储器、系统存储器或其他存储器)分离。存储器104可以是或包括用于存储数据的外部存储装置或数据库。示例包括硬盘驱动器、光盘(“cd”)、数字视频光盘(“dvd”)、存储卡、记忆棒、软盘、通用串行总线(“usb”)存储器装置或可操作来存储数据的其他装置。例如，电子装置100还可以包括盘或光学驱动单元。驱动单元可以包括计算机可读介质，其中可以嵌入一组或多组软件或指令，诸如指令124。处理器102和存储器104还可以包括具有指令或软件的计算机可读介质。

存储器104可操作以存储可由处理器102执行的指令。图中所示或所描述的功能、动作或任务可以由执行存储在存储器104中的指令的编程处理器102执行。功能、动作或任务可以独立于特定类型的指令集、存储介质、处理器或处理策略，并且可以由单独或组合操作的软件、硬件、集成电路、固件、微代码等来执行。同样，处理策略可以包括多处理、多任务处理、并行处理等。

指令124可以体现本文描述的方法或逻辑中的一个或多个，包括电子装置100和/或示例性预测性故障检测系统的各方面。在由电子装置100执行期间，指令124可以完全或部分地驻留在存储器104内或处理器102内。例如，本文公开的预测性故障检测系统的软件方面可以包括下面更详细讨论的训练的模型对象的示例，其可以在由电子装置100执行期间完全或部分地驻留在存储器104内或处理器102内。

此外，电子装置100可以包括计算机可读介质，所述计算机可读介质包括指令124或响应于传播信号接收并执行指令124，使得连接到网络126的装置可以通过网络126传送语音、视频、音频、图像或其他数据。可以经由通信端口或接口120或使用总线110，通过网络126传输或接收指令124。通信端口或接口120可以是处理器102的一部分，或者可以是分离部件。通信端口或接口120可以在软件中创建，或者可以是硬件中的物理连接。通信端口或接口120可以被配置为与网络126、外部媒体、一个或多个输入装置132、一个或多个输出装置134、一个或多个车辆子系统136或电子装置100中的其他部件、或它们的组合连接。与网络126的连接可以是物理连接，诸如有线以太网连接，或者可以无线地建立。与电子装置100的其他部件的附加连接可以是物理连接，或者可以无线地建立。网络126可以替代地直接连接到总线110。

网络126可以包括有线网络、无线网络、以太网avb网络、can总线、most总线或它们的组合。无线网络可以是或包括蜂窝电话网络、802.11、802.16、802.20、802.1q或wimax网络。无线网络还可以包括经由wi-fi或蓝牙技术实施的无线lan。此外，网络126可以是或包括公共网络，诸如互联网；专用网络，诸如内联网；或者它们的组合，并且可以利用现在可用的或以后开发的各种联网协议，包括基于tcp/ip的联网协议。电子装置100的一个或多个部件可以由或通过网络126彼此通信。

电子装置100还可以包括一个或多个输入装置132，所述一个或多个输入装置132被配置为允许用户与电子装置的部件交互。一个或多个输入装置132可以包括小键盘、键盘和/或光标控制装置，诸如鼠标或操纵杆。另外，一个或多个输入装置132可以包括遥控器、触摸屏显示器或可操作以与电子装置100交互的其他装置，诸如可操作以充当电子装置与一个或多个用户之间的接口的装置和/或其他电子装置。

输入装置132还可以包括一个或多个传感器。所述一个或多个传感器可以包括一个或多个接近传感器、运动传感器或相机(诸如在移动装置中发现的)。在功能上，所述一个或多个传感器可以包括检测或测量运动、温度、磁场、重力、湿度、水分、振动、压力、电场、声音或与潜在用户或用户周围的环境相关联的其他物理方面的一个或多个传感器。输入装置132还可以包括被配置为捕获和生成图像的一个或多个相机。一个或多个相机可以是数字相机或电荷捕获装置(ccd)，其被配置为生成电子装置100的环境的数字图像。一个或多个相机可以包括响应于可见光的光学相机、红外相机、紫外相机或适合于该应用的其他相机。

电子装置可以包括一个或多个输出装置134。输出装置134可以被配置为显示消息、再现声音、点亮灯或采取其他动作以便将关于车辆和/或电子装置100的内部状态的信息传达给用户。输出装置可以包括屏幕、指示灯、扬声器、触觉反馈装置或其他适当装置中的一者或多者。在一个示例中，屏幕可以包括形成车内信息娱乐系统的一部分的触摸屏。在另一个示例中，屏幕可以是与其他车内系统分开的部件。屏幕可以被配置为向用户生成文本或视觉消息。扬声器可以是包括一个或多个音频通道的立体声系统或环绕声系统的一部分。特定地说，扬声器可以包括扬声器阵列。扬声器可以包括喇叭驱动扬声器、机电扬声器(诸如磁铁驱动器低音炮)和/或压电扬声器。指示灯可以包括集成到一个或多个车辆部件中的led或白炽灯，诸如发动机检查灯或设置在仪表盘、仪表板或其他位置的其他合适的灯。触觉反馈装置可以包括被配置为将可触知信号发送到诸如方向盘的车辆部件以将消息传送给操作者的装置。一个或多个输出装置134可以集成到车辆中或联接到车辆；在其他示例中，一个或多个输出装置134可以形成通信地联接到电子装置100的单独机械系统的一部分，诸如智能电话或诊断装置。例如，输出装置可以包括智能手机的触摸屏，所述智能手机通过无线连接(诸如网络连接126)无线连接到总线110，总线110可以包括can总线。还有其他变化是可能的。

电子装置100可以包括一个或多个车辆子系统136。车辆子系统136可以包括车辆的一部分，并且可以通信地联接到总线110，在一个示例中，总线110可以包括can总线。车辆子系统可以包括车辆的一个或多个元件，并且根据由obd-ii诊断故障代码规范提供的车辆子系统类别可以包括例如动力传动子系统、底盘子系统、车身子系统和网络子系统。在其他示例中，可以使用不同的子系统分类方案。可以根据功能、结构和/或程序考虑对车辆元件进行分组。在一个示例中，车辆子系统可以包括发动机系统、加燃料系统、蒸发系统、点火系统、电气系统、hvac系统、悬架系统等。

车辆子系统136可以包括一个或多个ecu137和传感器138。传感器138的非限制性示例包括map/maf传感器、uego、hego、温度传感器、压力传感器、湿度传感器、发动机转速传感器、霍尔效应传感器、爆震传感器等。在一些示例中，传感器138可以包括上面讨论的一个或多个输入装置132。传感器可以设置在发动机系统、进气歧管、排气歧管、燃料箱、车辆轮胎、冷却剂通道、egr通道、车辆驾驶室、车身中和其他适当的位置。ecu137可以被配置为从一个或多个传感器138接收信号。ecu137可以监控和评估所述信号，并且被配置为在条件允许时输出一个或多个dtc。可以根据例如obd-ii标准生成dtc。可以采用另外的或替代的标准或专有dtc生成方案。

因此，电子装置100可以被配置用于实施车内预测性故障检测系统和/或方法的一个或多个方面。转向图2，示出了预测性故障检测方法的示例。

方法200开始于210，其中处理器确定是否存在更新方法中使用的测试规则以预测故障的请求。这些规则可以包括由机器学习技术(诸如下面讨论的方法300中给出的那些)生成的一个或多个训练的模型对象。所述规则可以包括一组数学和/或统计关系、决策树、数据结构和/或启发法，其用于基于一个或多个工况(诸如dtc、里程表读数或电池电压)确定故障概率。规则可以基于工况指定要采取的指令或建议的动作。在一个示例中，方法200可以在预测性故障确定系统第一次操作时请求更新测试规则。在其他示例中，方法200可以例如通过网络连接远程地接收更新测试规则的请求。替代地，方法200可以在自上次更新起经过预定时间之后请求更新测试规则；例如，所述方法可以每月、其他预定间隔或每当车辆启动时请求规则更新一次。如果请求了更新，则处理进行到215。如果没有请求更新，则处理进行到220。

在215处，方法200继续更新测试规则。这可以包括发送对新规则的请求和接收新规则。所述请求可以被发送到本地或远程服务器、网络或其他数据源。可以从相同或不同的源接收新规则。在一个示例中，数据源可以发送一组完整的测试规则来替换当前的一组测试规则。在另一示例中，数据源可以仅发送自上次更新请求以来新的或改变的规则。一旦已经接收到更新的规则，处理就进行到220。

在220处，所述方法继续监控工况。这可以包括监控其中设置有电子装置100的车辆的工况，例如，包括监控由一个或多个传感器(诸如传感器138和/或输入装置132)生成的信号。这可以包括监控里程表读数和/或电池电压信号。可以在以下处理中监控和使用的工况的其他非限制性示例包括发动机转速、负荷、扭矩请求、排气温度、空燃比、冷却剂温度、maf/map、速度、湿度、制动请求、点火正时、气门正时或其他适当的条件。处理然后进行到230。

在230处，所述方法监控诊断故障代码。dtc可以由一个或多个ecu136生成。处理器还可以监控所生成的dtc的龄期。这可以包括监控所有dtc或仅监控一子组dtc，诸如由特定车辆子系统生成的dtc或特定龄期的dtc。例如，对dtc的监控可能仅包括对小于阈值龄期的dtc的监控。在一个示例中，阈值龄期可以是天数，诸如1天、3天、5天或其他适当的天数。在该示例中，所述方法可以忽略早于阈值龄期的所有dtc。然而，应当理解，所述方法在一些示例中可以不忽略任何dtc，并且可以在后续处理步骤中使用由车辆子系统生成的所有dtc。处理然后进行到240。

在240处，所述方法包括将dtc和工况与一个或多个规则或训练的模型对象进行比较。这可以包括将dtc和条件与一个或多个统计或数学关系、决策树、数据结构或其他对象进行比较。训练的模型对象的示例可以包括以下规则，所述规则指定如果观察到的dtc集合包括{b11ff，u2100}，则指示在接下来的五天内故障概率为80％。训练的模型对象可以包括进一步的关系：继续前面的示例，训练的模型对象可以包括进一步规则，所述进一步规则指定故障概率以可预测的方式随里程数增加，并且可以指定基于里程表读数修改80％的基础概率以随观察到的里程表读数增大而增加，随里程表读数降低而减小。

在其他示例中，训练的模型对象可以包括动态规则，所述动态规则可以根据车辆的工况而变化。例如，规则可以指定dtc{p2459，u0128}指示故障概率为74％，但是故障概率根据发动机负荷进一步动态变化。发动机负荷较高时故障概率可能增加，而发动机负荷较低时故障概率可能减小。训练的模型对象还可以包括以下规则，所述规则基于观察到的dtc和/或一个或多个工况指定指令或推荐，下面参考框270讨论。一旦将dtc和工况与训练的模型对象和/或规则进行比较，处理就进行到250。

在250处，所述方法确定故障的概率。在一个示例中，这可以通过直接应用一个规则或训练的模型对象来实现。基于在先前步骤中执行的比较，规则或训练的模型对象可以提供故障概率。在其他示例中，可以采用一个以上的规则或训练的模型对象。例如，如果观察到的dtc和/或其他参数的模式被多个规则包含，则所述方法可以包括以适当的方式组合概率。例如，所述方法可以选择最低概率、最高概率或一些算术组合。特定地说，鉴于多个规则r1...rn，所述多个规则提供多个故障概率p1...pn，则所述方法可以根据下式来计算总体故障概率p

p＝1-(1-p1)(1-p2)…(1-pn)。

在已经确定了故障概率之后，处理进行到260。

在260处，所述方法可选地包括将先前生成的概率与阈值进行比较。替代地，阈值比较可以作为模型生成过程的一部分来执行，下面参考方法300进行描述。特定地说，在框380处，可以定义最佳截止概率。在框260处，下面参考框380讨论的程序可以替代地作为方法200的一部分来执行。因此，在260处，可以将概率与阈值进行比较。阈值可以是预定的和恒定的，或者可以基于工况来确定。例如，所述方法可以在高速和/或高负荷条件期间选择较低概率阈值并且在低速和/或低负荷条件期间选择较高概率阈值。例如，这可以允许根据在不同驾驶条件下增加或减少故障机会来动态控制方法。作为另一示例，可以根据处理器接收的dtc中涉及哪些车辆子系统来选择不同的概率阈值。例如，所述方法可以为涉及发动机子系统的dtc选择较低概率阈值，并为涉及电气或hvac系统的dtc选择较高概率阈值。还有其他变化是可能的。如果确定故障概率小于阈值概率，则所述方法返回到220并继续监控工况和dtc。如果确定故障概率大于阈值概率，则方法进行到270。

在270处，所述方法基于dtc、工况和/或训练的模型对象生成指令。所生成的指令可以旨在被传递给人类操作者并为其所理解。示例性指令可以包括相对简单的指令，诸如“检查发动机”或“尽快维修车辆”。在其他示例中，所述方法可以生成更具体的指令，诸如“x天内维修车辆”，其中x是基于dtc、工况和/或训练的模型对象而确定。指令还可以包括“尽快维修车辆”。在方法判断即将发生故障的情况下，所生成的指令可以包括“立即靠边停车”。所述方法可以另外或替代地为操作者生成指令以进行旨在最小化故障可能性的特定驾驶行为。这些类型的指令的非限制性示例可以包括“降低速度”或“关闭空调”。

可以基于dtc、工况和/或训练的模型对象生成特定指令。指令还可以基于上面确定的概率。例如，当所述方法生成“x天内维修车辆”的指令时，可以基于所述概率确定x。天数可以与概率成反比关系，其中较高的故障概率对应于较少的天数，反之亦然。诸如“尽快维修车辆”和“立即靠边停车”等指令可以基于非常高的故障概率生成，诸如高于第二阈值的故障概率、高于框260中所用的概率阈值的故障概率。在一些示例中，特定指令可以包括在训练的模型对象中。例如，基于由hvacecu生成的dtc诊断hvac系统中的故障的训练的模型对象可以包括当故障概率大于阈值时“关闭空调”的指令。所述方法可以基于以上考虑生成一组或多组指令。在生成指令之后，处理进行到280。

在280处，所述方法通过向操作者显示指令来进行。这可以使用一个或多个输出装置134来执行。可以通过点亮发动机检查灯，通过向屏幕输出文本消息，通过经由扬声器再现可听消息，或以其他适当的方式来显示指令。在已经向操作者显示指令之后，方法200返回。

现在参考图3，示出了用于生成用于上述车内预测性故障检测系统的训练的模型对象或规则的方法300。方法300可以采用一种或多种计算机学习技术来生成规则或训练的模型对象。可以在电子装置100和/或方法200中采用或实例化这些规则或训练的模型对象，以用于预测性地确定故障概率，和/或生成操作者指令。在较高级别，执行以下步骤：

1.数据理解、清洁和处理

2.数据存储策略，其用于以最佳方式将数据存储在hadoopmap-reduce数据库中，以促进更快地进行模型构建和数据提取

3.dtc和其他派生变量在预测故障时的预测能力

4.对dtc数据的持续时间分析，其用于检查实际故障前的预先通知

5.关联规则挖掘，其用于检测导致故障的dtc模式

6.规则排序方法，其用于通过导致故障的相关联的倾向对dtc模式进行排序

7.预测性模型，其从训练数据识别导致故障的dtc模式

8.模型验证，其通过使用混淆矩阵识别样本数据中的故障

基于下面讨论的方法和实验，获得以下结果：

在实际故障发生之前，可以以合理的准确性和充分的预先通知找到导致故障比非故障情况更多的dtc；

dtc模式可以从实际故障发生前至少一天使用数据来帮助预测故障(准确度超过65％)的数据中找到，即故障可以在实际损坏发生前至少一天预测，准确度超过65％；

向如里程表和/或电池电压等dtc模式添加更多数据可以将损坏的预测准确度提高到75％；

实现超过65％的准确度。

所述方法开始于310，其中对适当的数据库进行汇编。数据库可以由数据汇编，例如，所述数据包括在一段时间内由一辆或多辆车辆生成的dtc以及诸如车辆型号、里程数(里程表读数)、电池荷电状态或设定dtc时或发起会话时测量的任何其他工况等其他信息。车辆反馈数据库可以用于数据提取。此外，会话类型的扁平文件可以用于将会话文件名映射到会话类型。

可以运行许多查询以便在与数据库用户指南协商后彻底理解数据库。另外，数据字典可以用于理解dtc数据的每个字段。使用以下标准运行查询并在数据库上进行后处理以进行最终数据提取以进行分析：

对于dtc(在快照情况下)标准：2014年6月至2016年6月

使用http调用从网站自动提取。

症状数据仅从2014年10月开始提供。

会话类型数据可用于2014年6月至2016年6月的所有会话。汇编数据库还包括将会话数据分类为故障会话和非故障会话。故障会话可以包括例如损坏会话或路边救援会话，而非故障会话可以包括例如日常维护或维修。为区分故障会话和非故障会话，可以使用以下规则：

故障会话是仅来自某些经销商的会话

每个其他会话都是非故障会话

“维修功能”类型的非损坏会话被视为非故障会话

该规则的示例由图4中的图示400示出。一旦汇编了适当的数据库，处理就前进到步骤320。

在步骤320处，所述方法包括数据清理和预处理。从数据库中提取的与复制和无效数据相关的原始数据中可能存在一些问题。导入的数据可能需要清理或预处理以确保所得到的训练的模型对象和车内预测性故障检测系统的稳健操作。例如，在一些会话中可能会发现dtc复制。可以使用自动脚本删除复制的dtc，并且可以仅保留会话中第一次出现的dtc，以便每个dtc在会话中仅出现一次。此外，一些路边救援会话被标记为“维修功能”类型，这是不可能的。将这些会话从分析中删除。处理然后进行到330。

在330处，所述方法包括在汇编的数据库上执行模式挖掘。为了检查通过基于顺序和非顺序模式的规则挖掘预测每种故障类型的可行性，可以首先对一个月的数据的dtc和症状进行分析。示出该过程的示例性工作流程500可以在图5中看到。

可以在332处执行非顺序模式挖掘作为模式挖掘330的一部分。非顺序模式挖掘包括以下程序。1个月的症状数据和快照数据是在2016年5月至2016年6月在一定的过滤条件下从hadoop中提取。在此期间观察到的症状总数为1095。使用此数据，可以对最前面的故障模式进行分类。使用序列挖掘估计具有不同水平的5种症状的故障模式的频率，并进一步识别最前面的故障模式。前5个症状路径，其中第4级被视为截止，包括总损坏的40％，如下表所示：

如该表所示，故障模式以四个类别开始“电气->仪器->信息和消息中心->消息显示区域”，占测试期间观察到的1095种症状模式中的57种。与前三个症状路径一起，这四个组合在一起构成了所观察到的所有故障模式的34.5％。然后，在非顺序模式挖掘算法中进一步处理这些识别的故障模式。

模式挖掘330还可以包括334处的关联规则挖掘。对于关联规则挖掘，前5个症状路径被识别为主要故障模式，并且与此故障模式对应的会话文件名从dtc快照数据映射，以便识别导致故障模式的dtc。观察到的dtc与会话文件名映射，并且使用关联规则挖掘(arm)估计具有高支持度和置信度的模式(dtc集合)。故障模式2由b11ff和u2100引起，此处未捕获序列。该分析的结果在下表中给出：

顺序模式挖掘336也可以作为模式挖掘330的一部分来执行。可以在小数据集上采用顺序模式挖掘来确定dtc序列是否在所确定的规则的置信度、支持度或提升度方面产生任何差异。在顺序规则挖掘中，观察到的dtc被映射为针对会话密钥的时间序列，并且使用顺序挖掘算法估计具有高支持度和置信度的模式(dtc集合)。顺序规则挖掘的结果如下表所示：

对于故障模式1，顺序和非顺序规则都将p0130识别为导致故障的dtc。基于did的进一步分析是针对发生此dtc的会话进行，以找出是否存在任何故障指示，即任何did值超出范围。但是，所有did值都在高-低范围内，并且因此，仅查看did值无法得出结论。

顺序模式挖掘可以生成一个或多个规则或训练的模型对象(参见下文)，其取决于dtc的顺序或序列。规则可能取决于dtc的顺序而有所不同；在一些示例中，一组dtc可以以第一顺序生成第一故障概率，并且以第二顺序生成第二概率，第二概率与第一概率不同。例如，包括两个不同dtc的dtc集合可以以第一顺序生成第一概率；如果检测到dtc处于不同于第一顺序的第二顺序(例如反向顺序)，则可以应用不同的顺序规则，其生成例如大于第一概率的第二概率。

在其他示例中，顺序规则可以取决于dtc的顺序向操作者提供不同的指令。在一个示例中，处于第一顺序的dtc集合可以提供“在5天内维修车辆”的指令，而处于不同的第二顺序的同一dtc集合可以提供“立即靠边停车”的指令。在另一个示例中，dtc的第一顺序可以提供诸如“关闭空调”的指令，而dtc的第二不同顺序可以根本不提供指令。还有其他变化是可能的。

为了继续此分析，样本大小扩大到包括6个月的数据，并且仅进行非顺序模式挖掘，因为在本研究中可能不考虑dtc的序列。执行使用如上所述的更大的数据集和类似的模式挖掘方法以导出导致故障类型的非顺序模式。症状数据和快照数据是在2016年1月1日至2016年6月25日在市场和经销商的过滤条件下从hadoopdb中提取；观察到的症状总数为8376。

非序列模式挖掘的数据准备继续进行前面的故障模式的分类：使用序列挖掘估计具有不同级别的5个症状的故障模式的频率，并且进一步识别前面的故障模式。将第4级的前6个症状路径视为截止。每个会话文件具有多次记录的相同症状模式。包括这6种症状模式的会话文件的总数为3057。这些模式如下表所示：

然后，所述方法对准备好的数据执行非顺序dtc模式挖掘。前6个症状路径被识别为主要故障模式，并且与该故障模式相对应的会话文件名称从dtc快照数据映射，以便识别导致故障模式的dtc。在来自前6种症状模式的3057个会话文件中，仅观察到2850个会话文件，因为其他会话文件未记录在dtc快照数据中。发生非故障模式的会话总数为38899。发生的dtc与会话文件名映射，并且使用关联规则挖掘(arm)估计具有高支持度和置信度的模式(dtc集合)。未观察到故障模式2、3和4，因为导致这些故障模式的dtc的支持度小于0.05％。非顺序模式挖掘的结果总结在下表中：

上表说明了规则挖掘的结果，特别是最后一列比较了对导致故障会话和非故障会话的同一规则的支持度。这促使推导出一种对规则进行排序的方法，其中在故障会话和非故障会话两者中可以发生相同的规则，以便识别相比于非故障导致故障的倾向更多的规则。

基于此分析，建议的后续步骤是：将所有故障类型分组为单一模式；导出单一的置信度度量，结合故障模式和非故障模式以比较规则，并根据相关联的规则导致故障的倾向对其进行排序；使用完整dtc中的模块名称，即完整dtc＝模块-dtc-类型描述。鉴于这些考虑因素，可以应用贝叶斯规则。在非顺序模式挖掘完成之后，处理进行到340。

在340处，所述方法包括使用贝叶斯定理的模式排序。为了通过导致故障的相关重要性(例如，相对可能性)对从非顺序模式挖掘导出的模式进行排序，使用贝叶斯定理。假设模式已经发生，则模式按条件故障概率排序：

假设模式p1已经在会话中发生，则该等式估计故障f的概率，其是导致故障的p1的支持度在p1的总支持度中的比例。

此方法中的每个术语都按如下方式解释和导出：

pr(f)群体的故障概率。这是使用从2013年1月至2016年6月的销售数据进行估计，以获得具有路边救援设施的车辆数量(3年)以及2016年1月至2016年6月期间观察到的实际故障数量。2016年1月至2016年6月期间的示例：pr(f)＝(故障会话的示例)/(2013年1月至2016年6月的总销售额)

pr(nf)群体的非故障概率，其是1pr(f)，因为f&nf是互斥的

pr(p1|f)导致故障的条件模式概率p1：pr(p1|f)＝(包含模式p1的故障会话的数量)/(故障会话的总数量)

pr(p1|nf)导致非故障的条件模式概率p1：pr(p1|f)＝(包含模式p1的非故障会话的数量)/(非故障会话的总数量)

图6a和图6b示出了用贝叶斯定理进行模式排序的结果。图6a示出了在2015年7月至2015年12月间隔期间前5种模式的故障倾向的图表600a。图6b示出了在2016年1月至2016年6月间隔期间前5种模式的故障倾向的图表600b。

可以通过扩展基于贝叶斯规则的模式排序机制来开发一种使用从样本数据中训练模型导出的规则来验证模型的新方法：

pr(f|dtc)v＝在已经检测到模式dtc的情况下，验证会话的车辆故障概率

pr(f)＝车辆故障的概率

pr(nf)＝1-pr(f)＝车辆未发生故障(即未发生损坏)的概率

pr(dtc|f)t＝在故障训练数据中在车辆已经出现故障的情况下，看到模式dtc的概率

pr(dtc|nf)t＝在非故障训练数据中在车辆还没有出现故障的情况下，看到模式dtc的概率

上述计算可以用于根据从训练集合估计的先验概率来估计验证集合(样本外)中的条件故障概率。在贝叶斯定理的模式排序完成之后，所述方法进行到350。

在350处，所述方法继续选择截止概率。截止概率可以是阈值概率值，其中如果确定的故障概率高于阈值，则向操作者指示潜在故障，而如果确定的故障概率低于阈值，则可能不向操作者指示潜在故障。另外或替代地，这可以作为方法200的一部分发生，例如，在框260至280中。这可以包括在车内预测性故障检测系统中本地或非本地选择概率，可以包括多个不同的阈值，和/或可以包括基于故障概率或依据故障概率向操作者发出指令。例如，如上所述，这些功能可以包括在方法200的框260中。然而，在其他示例中，在350处，可以执行适当概率截止阈值的选择作为方法300的一部分。

为了将会话识别为故障或非故障，通过使用故障会话和非故障会话两者的dtc模式概率来导出截止概率。该过程包括为包含{dtci}，i＝1..n的训练集合中的每个会话创建所有可能的dtc模式(即{dtci}的幂集)。然后，对于p中的每个y，使用如上所述的贝叶斯定理估计pr(f|y)。然后将具有最高py＝pr(f|y)的模式y识别为实际导致故障的模式。然后估计来自不同会话的每个py的灵敏度和特异性曲线。参见图7，其示出了灵敏度和特异性的图示700。故障截止概率将是这两条曲线(灵敏度和特异性曲线)的交点，并且此交点将为故障会话和非故障会话提供最高的总体分类。

为了使用截止概率进行分类(在验证期间，在下面讨论)，观察到以下规则：对于验证集合中的每个会话，如上所述估计py。如果py大于或等于截止概率，则会话被分类为故障，否则被分类为为非故障。

作为该程序的示例，考虑一个会话文件：针对会话文件观察到的dtc是abs-u3006-16、pcm-p0504-62、pcm-p2263-22、pcm-p253f-00。计算会话中观察到的dtc内不同的模式组合的故障概率，并通过插入p(f)＝0.002854989、p(nf)＝1-p(f)＝0.997145011中按降序排序。观察到的最大概率考虑用于预测会话是故障还是非故障，因此排除100％概率，这里{abs-u3006-16，pcm-p2263-22}的最高概率＝2.71％将用于为故障会话进行训练。对训练数据集中的每个会话重复类似的程序。图8示出了从该示例绘制的灵敏度和特异性曲线的图表800。

在图8中，两条曲线在x值为0.0121635处相交，这是要使用的最佳截止。如果p(f|dtc)大于截止概率，则会话被分类为故障，否则被分类为非故障。基于截止为0.0121635，验证结果给出64.47％的总体准确度，如图9的图表900所示。在不同截止值处的真的正比率的折衷在图10的图表1000中示出。在选择了截止概率之后，方法进行到360。

在360处，执行模型验证。模型验证可以包括评估附加条件(诸如电池电压和里程表读数)对故障可能性的贡献，如框362中所示。使用一种车辆模型的所有会话，为由以下产生的组合构建了12种不同的型号：

3种dtc模式-{完整dtc、完整dtc+里程表+#dtc、完整dtc+里程表+#dtc+电池电压}

4次故障-{最后一个dtc，距离最后一个dtc1天、距离最后一个dtc3天、距离最后一个dtc5天}

用于模型验证的数据准备和工作流程在图11的图示1100中示出。

可以根据适当的程序处理数据集中缺失的值。大约25％的dtc未填充电池电压。这些被视为单独的“na”类别。为每个会话记录的总距离被视为该会话的里程表读数。如果总距离为“零”，则该会话的该参数的最大值被视为里程表读数作为缺失值处理。

诸如电池电压、里程表和#dtc等连续变量被分箱，用于以下处理。决策树(诸如图12中所示的示例性树1200)可以用于数据分箱。最后，会话中的每个dtc被转换为模块名称-dtc-类型描述-里程表箱-电池电压箱-dtc数量箱作为建模阶段的输入。

模型验证的结果如下图所示。训练(2014年10月至2016年4月)中故障会话与非故障会话的分解、测试(2016年5月)和验证(2016年6月)数据1300在图13中示出。故障会话中的前面的dtc的频率计数在图14的图表1400中示出。依据会话中的#dtc的会话频率计数在图15的图表1500中示出。随着会话中的#dtc增加，会话是故障会话的概率增加，如图16的图表1600所示。

故障会话和非故障会话的比率与电池电压逆相关，在电池电压较低时该比率较高，这表明在较低的电池电压下，找到故障会话的可能性大于非故障会话的可能性。这在图17的图表1700中示出。

在模型验证期间，故障之间的关联规则和输入变量的组合针对以下导出：

完整dtc-模块+dtc+类型描述

里程表读数

dtc数量

电池电压

还调查了不同天数截止的影响，如在框364处-即，使用直到最后一个dtc、出现最后一个dtc之前的1天、3天、5天的数据。这如下表所示：

使用最后一个dtc、1天、3天和5天的截止的模型验证结果表明，由于数据可用性随着截止时间段增加而降低，总体准确度随截止增大而降低。这在图18a的图表1800a中示出。

当使用完整dtc、里程表读数和dtc数量的组合作为模型的输入时，发现类似但更一致的准确度降低。这些结果总结在图18b的图表1800b中。

当使用完整dtc、里程表读数、dtc数量和电池电压的特征组合时，发现由于不可用电池电压会话的准确度偏差，包括电池电压实际上降低了总体准确度。这在图18c的图表1800c中示出。

使用电池电压只会产生严重偏向真的负情况但在真的正情况下表现不佳的结果，-即准确地预测非故障情况但在预测实际故障时准确度非常低。这在图18d的图表1800d中示出。(注意：对于此结果，会话的最小电池电压用作预测故障的因变量)

从结果的所有组合来看，与最后一个dtc模型相比，使用完整dtc+里程表+#dtc和一天截止的模型结果表现为最佳，其充分预先通知故障而不会太多地折衷准确度。

基于描述性分析和初步模型结果，可以得出以下结论：

在实际损坏发生之前，可以以合理的准确度和充分的预先通知找到导致故障比非故障情况更多的dtc。图19的图表1900示出了以天表示的dtc龄期的分布。

使用贝叶斯规则的模式排序是识别主要导致故障然后是非故障的dtc模式的有效方法，并且在超过65％的不同时间段内给出一致的结果。图20a和图20b示出了图表2000a和2000b中2016年5月和2016年6月数据的模型性能度量，其示出了所述一致性。

使用从最后一次dtc发生之前的数据和基于模式排序的预测导出的模式，可以在实际损坏之前至少一天预测故障，准确度超过60％。基于最后一次dtc发生的模型性能度量在图21a的图表2100a中示出。

向如里程表、电池电压等dtc模式添加更多数据可以在实际故障预测之前至少1天将损坏的预测准确度提高8％。具有包括里程表读数和电池电压的另外参数的模型性能度量在图21b的图表2100b中示出。

在模型验证之后，处理进行到370。

在370处，所述方法包括基于先前的处理步骤生成一个或多个训练的模型对象。训练的模型对象可以包括dtc模式、工况和在上述过程框310至360中学习的故障概率之间的一个或多个统计或数学关系。训练的模型对象可以存储为数据结构、决策树或其他适当的形式。训练的模型对象可以被实例化为计算机可读指令，适合于由电子装置100接收、读取和使用，并且在方法200中例如在步骤240至270处实施。训练的模型对象还可以包括一组或多组指令。这些指令可以是如果满足某些条件则将向车辆的操作者显示的指令。以上参考框240至270更深入地讨论训练的模型对象的性质。一旦生成训练的模型对象，方法300就返回。

本公开提供了检查诊断故障代码(dtc)以帮助早期故障发现的系统和方法。例如，可以仅使用dtc和/或使用无其他元件的dtc来检测车辆或部件故障，以提供故障状况的早期检测。可以为每个dtc/故障关联确定提前时间(例如，接收/检测dtc和相关故障的展示之间的时间)，以确定哪个dtc为相应的相关故障预测提供最大提前时间。还可以为每个dtc/故障关联确定准确度(例如，故障的正确预测与故障的假的正预测的比率)，以确定哪个dtc提供最准确的故障预测。使用上述数据，系统可以选择dtc的子集来监控给定的故障和/或可以基于上述数据权衡关于潜在故障指示的dtc状态。dtc的选择和/或权衡的技术效果是可以节省计算资源(由于减少对仅最准确/早期警告dtc的监控)并且可以减少部件故障(由于在故障发生或影响其他系统之前早期检测到故障)。

为了使用如上所述的dtc分析，车内计算框架可以接受包括dtc的信号，允许系统集成到任何车辆中以使用车辆的标准dtc报告机制。基于dtc，所公开的系统和方法可以使用车辆的当前数据、车辆的先前记录数据、其他车辆的先前记录数据(例如，可以是群体范围或目标为与所述车辆共享一个或多个属性的其他车辆的趋势)、来自原始设备制造商(oem)的信息、召回信息和/或其他数据来生成定制报告。在一些示例中，报告可以被发送到外部服务(例如，发送到不同的oem)和/或以其他方式用于未来的dtc分析。dtc可以从车辆传输到集中式云服务以进行聚合和分析，以便构建一个或多个模型来预测车辆部件的故障或降级。在一些示例中，车辆可以将数据(例如，本地生成的dtc)发送到云服务以进行处理并接收潜在故障的指示。在其他示例中，模型可以本地存储在车辆上并且用于当在车辆中发布dtc时生成潜在故障的指示。车辆可以在本地存储一些模型并将数据传输到云服务以用于构建/更新车辆外部的其他(例如，不同的)模型。当与云服务和/或其他远程装置通信时，通信装置(例如，车辆和云服务和/或其他远程装置)可以参与数据和/或模型的双向验证(例如，使用内置于用于传送数据的通信协议中的安全协议，和/或使用与基于dtc的模型相关联的安全协议)。

本公开还提供了一种方法，所述方法包括基于一个或多个诊断故障代码(dtc)确定车辆故障的概率；以及响应于概率超过阈值而向车辆的操作者指示可能发生故障。在所述方法的第一示例中，所述确定可以另外或替代地基于将一个或多个dtc与一个或多个训练的模型对象进行比较。所述方法的第二示例可选地包括第一示例，并且还包括所述方法，其中使用在历史dtc数据上执行的机器学习算法来生成训练的模型对象。所述方法的第三示例可选地包括第一示例和第二示例中的一个或两个，并且还包括所述方法，其中所述确定还基于包括里程表读数和电池电压的多个工况。所述方法的第四示例可选地包括第一至第三示例中的一个或多个，并且还包括所述方法，其中所述指示包括经由屏幕显示文本消息，所述文本消息包括指令。所述方法的第五示例可选地包括第一至第四示例中的一个或多个，并且还包括所述方法，其中指令包括访问服务站的推荐天数。第六示例可选地包括第一至第五示例中的一个或多个，并且还包括所述方法，其中所述推荐天数是基于概率，对较低概率推荐较多天数并且对较高概率推荐较少天数；并且其中天数还基于生成dtc的车辆子系统。第七示例可选地包括第一至第六示例中的一个或多个，并且还包括所述方法，其中一个或多个dtc包括多个dtc，并且响应于dtc处于第一顺序，确定概率为第一值，响应于dtc处于不同于第一顺序的第二顺序，确定概率为低于第一值的第二值。

本公开还提供了一种系统，所述系统包括车辆、多个车辆子系统、具有存储在非暂时性存储器中的机器可读指令的控制器，所述控制器用于：从车辆子系统接收一个或多个诊断故障代码(dtc)；通过将一个或多个dtc与一个或多个训练的模型对象进行比较来生成车辆故障的概率；以及如果概率超过阈值，则向车辆的操作者指示可能发生故障。在系统的第一示例中，阈值可以另外或替代地基于生成dtc的车辆子系统。系统的第二示例可选地包括第一示例，并且还包括所述系统，其中所述阈值在从动力传动子系统接收到dtc时较低，并且在从底盘子系统接收到dtc时较高。系统的第三示例可选地包括第一示例和第二示例中的一个或两个，并且还包括所述系统，其中指示包括向操作者显示消息，所述消息包括一个或多个指令，并且其中指令是基于dtc与训练的模型对象的比较。系统的第四示例可选地包括第一至第三示例中的一个或多个，并且还包括所述系统，其中指令基于生成dtc的车辆子系统，其中响应于dtc由hvac系统生成而生成关闭空调的指令，并且其中响应于dtc由发动机系统生成而生成减少发动机负荷的指令。系统的第五示例可选地包括第一至第四示例中的一个或多个，并且还包括所述系统，其中指令还基于概率，指令包括访问服务站的推荐时间，推荐时间与概率成反比关系。所述系统的第六示例可选地包括第一至第五示例中的一个或多个，并且还包括所述系统，其中控制器被配置为忽略龄期大于阈值龄期的dtc；其中训练的模型对象是经由关于历史dtc数据的机器学习算法在远程服务器处生成；并且其中响应于更新请求，在车辆处从远程服务器接收训练的模型对象。

本公开还提供了一种方法，所述方法包括：接收诊断故障代码(dtc)和发动机操作参数；将dtc和发动机操作参数与训练的模型对象进行比较以生成车辆故障概率和指令；以及响应于故障概率大于阈值，在屏幕上向车辆的操作者显示指令。在所述方法的第一示例中，训练的模型对象可以另外或替代地指定dtc、发动机操作参数和故障概率之间的一个或多个关系。所述方法的第二示例可选地包括第一示例，并且还包括所述方法，其还包括响应于更新请求从远程服务器接收训练的模型对象。所述方法的第三示例可选地包括第一示例和第二示例中的一个或两个，并且还包括所述方法，其中使用一种或多种计算机学习技术生成训练的模型对象，并且其中计算机学习技术包括非顺序模式挖掘、关联规则挖掘和利用贝叶斯定理的模式排序。所述方法的第四示例可选地包括第一至第三示例中的一个或多个，并且还包括所述方法，其中计算机学习技术应用于历史数据，所述历史数据包括车辆型号、里程表读数、电池电压读数、dtc模式以及故障状态。

已经出于说明和描述的目的而呈现了对实施方案的描述。可以鉴于以上描述执行或可以通过实践方法获得实施方案的合适的修改和变化。例如，除非另外指出，否则所描述的一种或多种方法可以由合适的装置和/或装置的组合(诸如关于图1描述的电子装置100)来执行。所述方法可以通过以下方式来执行：利用一个或多个逻辑装置(例如，处理器)结合一个或多个另外的硬件元件(诸如存储装置、存储器、硬件网络接口/天线、开关、致动器、时钟电路等)来执行存储的指令。所述方法和相关联动作还可以按除了本申请中所述的顺序之外的各种顺序并行和/或同时执行。所述系统本质上是示例性的，并且可包括另外的元件和/或省略元件。本公开的主题包括所公开的各种系统和配置以及其他特征、功能和/或性质的全部新颖的且非显而易见的组合和子组合。

如本申请中所使用的，以单数形式列举并且前面带有词语“一/一个”的元件或步骤应当被理解为并不排除多个所述元件或步骤，除非指出这种排除情况。此外，对本公开的“一个实施方案”或“一个示例”的参考并非意图解释为排除也并入所列举特征的另外实施方案的存在。术语“第一”、“第二”和“第三”等仅用作标记，而并非意在对相关联的对象施加数值要求或特定位置顺序。以下权利要求特别指出来自上述公开内容的并被认为是新颖的且非显而易见的主题。