用于维护诊断及维护程序加强的方法

1.一种利用以前维护车辆的维护修理数据来加强维护诊断的方法，所述方法包括如下步骤：
从记忆储存器件中获取以前维护车辆的维护修理数据；
使用基于处理器的装置将所述维护修理数据编译入维护诊断代码数据集和维护工作代码数据集，其中，所述维护诊断代码数据集包括报告的诊断故障代码，所述报告的诊断故障代码确定检测故障，其中，所述维护工作代码数据集包括报告的修理代码，所述报告的修理代码用于响应于所确定的检测故障而修理所述车辆；
使用所述基于处理器的装置将所述维护诊断代码数据集和维护工作代码数据集分类入电子数据表中，其中，对于各报告的修理，在所述电子数据表中在至少一个相应的维护诊断代码与至少一个相应的维护工作代码之间形成相应组合；
为所述电子数据表中的每个相应组合确定一个合计数；
确定与维护诊断代码或维护工作代码中的多于一个的代码具有相关性的相应诊断代码或相应维护工作代码；以及
响应于对相应组合的分析对以下各项中的至少一个进行修改：用于修理所述车辆的维护修理程序、或者用于确定故障的相应维护诊断代码。
2.如权利要求1所述的方法，其中，所述将维护修理数据编译入维护诊断代码数据集和维护工作代码数据集中的步骤包括：仅对与特定车辆制造商有关的维护修理数据进行编译。
3.如权利要求2所述的方法，其中，所述将维护修理数据编译入维护诊断代码数据集和维护工作代码数据集中的步骤包括：仅对与特定型号车辆有关的维护修理数据进行编译。
4.如权利要求3所述的方法，其中，所述将维护修理数据编译入维护诊断代码数据集和维护工作代码数据集中的步骤包括：仅对与对所述特定型号车辆进行维护的代理商有关的维护修理数据进行编译。
5.如权利要求1所述的方法，其中，对相应组合进行分析包括下列步骤：
确定包含具有大于第一预定阈值的合计数的组合的诊断故障代码；
确定包含所述诊断故障代码的一个或多个组合，其中，所述合计数小于第二预定阈值；
以及
执行纠正措施，以防止与被确定小于所述第二预定阈值的每个组合的相应工作代码有关的进一步修理。
6.如权利要求5所述的方法，其中，对相应组合进行分析包括下列步骤：
确定包含所述诊断故障代码和相应工作代码的组合，其中，所述合计数在所确定的组合中均匀地分布；
对所述相关性电子数据表进行精细化，从而对一类车辆或一组代理商中的一者进行评估；
响应于所述精细化的相关性电子数据表的合计数，确定所述故障的根本原因；以及采取修改所述维护诊断的纠正措施，以确定所述故障的根本原因。
7.如权利要求6所述的方法，其中，所述纠正措施还包括修改所述诊断故障代码。
8.如权利要求6所述的方法，其中，所述纠正措施还包括修改维护修理程序。
9.如权利要求6所述的方法，其中，所述纠正措施还包括加强维护修理技术人员的培训。
10.如权利要求6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定车辆制造商有关的维护修理数据来编译维护修理数据。
11.如权利要求6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定类型车辆有关的维护修理数据来编译维护修理数据。
12.如权利要求11所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定代理商有关的维护修理数据来编译维护修理数据。
13.如权利要求6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定类型车辆发动机有关的维护修理数据来编译维护修理数据。
14.如权利要求13所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用与里程超过预定里程的车辆有关的维护修理数据来编译维护修理数据。
15.如权利要求13所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用与超过预定龄期的车辆有关的维护修理数据来编译维护修理数据。
16.如权利要求6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与相应区域内的特定代理商有关的维护修理数据来编译维护修理数据。
17.如权利要求6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与超过预定里程的车辆有关的维护修理数据来编译维护修理数据。
18.如权利要求1所述的方法，其中，所述合计数基于在预定时段内所收集的实时维护修理数据。

用于维护诊断及维护程序加强的方法 \n技术领域\n[0001] 本发明的实施例总体上涉及对维护程序及维护诊断的开发和加强。\n背景技术\n[0002] 车载诊断处理器产生用以帮助技术人员确定车辆中的问题的诊断故障代码(DTC)。诊断故障代码是当检测到问题时由车载诊断处理器生成的5位的字母数字代码。当车载诊断处理器基于来自一个或多个传感器的传感器输入而检测到错误时，诊断算法对感测到的输入进行分析，并且输出由诊断算法所确定的诊断故障代码。诊断故障代码与然后可被用来对问题进行诊断的故障相对应。诊断故障代码提供对问题进行诊断的起点。在某些情况下，仅存在一个可能是问题根本原因的特定部件。在其它情况下，诊断故障代码则是一个根本原因不明的故障。因此，诊断故障代码给技术人员提供诊断并解决问题的起点，但在许多情况下最初的评判却不能提供问题的实际根本原因。\n[0003] 维护提供者(如代理商的维护部门)借助于采用诊断软件算法的维护诊断工具来诊断车辆电子器件中的问题。诊断故障代码(DTC)基于诊断软件算法设定在车辆中。维护诊断工具从车辆处理器的存储器中检索出诊断故障代码并用该代码确定车辆中的故障。车辆中的各处理器包含当车辆发生故障时存储诊断故障代码的存储器。维护技术人员可以检查当前或过去的任何触发的诊断故障代码，从而帮助确定车辆中的根本原因。诊断故障代码是用以确定车辆各种部件中所发生故障的字母数字代码。这种诊断故障代码与各种电动车辆功能(包括但不限于：发动机工作、排放、制动、动力系、安全、和转向)有关。各子系统可以具有其自身的用以监测子系统运行故障的车载处理器；或者集中处理器可负责监测多个子系统的故障。当子系统处理器检测到故障时，生成一个或多个诊断故障代码。\n[0004] 诊断故障代码帮助维护技术人员查明关注区域。维护技术人员借助于扫描工具检索出诊断故障代码。尽管诊断故障代码帮助技术人员查明关注区域，但诊断故障代码也许不能提供关于根本原因的确定信息。通常，诊断故障代码指出在特定部件、连接该部件到控制模块的电路、或者控制模块自身中的故障。\n[0005] 工作代码（labor code）是由维护技术人员输入的代码。工作代码包括对与被修理零件有关的车辆进行的修理或操作的预定描述。工作代码通常是由设备制造商所要求的(用于保修报告的目的)，以便主题专家可以对数据进行分析以确定是如何纠正各修理的。\n[0006] 对于每个相应的诊断故障代码，可以存在一个或多个可以针对诊断故障代码而报告的工作代码。亦即，诊断故障代码仅提供故障并且不一定对需要修理或更换的部件或系统进行确定。因此，如果问题需要多次修理则可以使用多个工作代码，或者当对问题进行诊断时技术人员可能会进行多于一次的修理。因此，通过对所报告的诊断故障代码和工作代码进行分析，可离散地提供一些关于技术人员如何诊断并解决问题的细节的了解；然而，单独地查看各相关的诊断故障代码和工作代码，不能提供关于维护程序是否错误、是否需要额外的诊断步骤、诊断故障代码是否准确地描述问题、或者零部件/系统是否具有设计缺陷的了解。\n发明内容\n[0007] 本发明实施例的一个优点是基于对相关性电子数据表内数据的编译，确定错误的维护修理，其中相关性电子数据表由从保修存储数据库（warranty storage database）中获取的诊断故障代码和工作代码所组成。基于由维护修理机构所报告的修理数据，确定合计数(aggregate count)。针对单个诊断故障代码而报告的多于一个的工作代码，表明正在以非有效率的方式进行修理。建议对维护诊断进行进一步的精细化（refine），从而通过对所确定故障的分析和诊断来有效地指导维护修理技术人员，以减小针对确定的故障对车辆进行修理的次数以及相关的保修成本。\n[0008] 本发明的一个实施例设想了一种利用以前维护车辆的维护修理数据来加强维护诊断的方法。从记忆存储器件中获取以前维护车辆的维护修理数据。使用基于处理器的装置将维护数据编译入维护诊断代码数据集和维护工作代码数据集中。维护诊断代码数据集包括报告的诊断故障代码，该代码用于确定检测故障。维护工作代码数据集包括报告的修理代码，该代码用于响应于所确定的检测故障来修理车辆。使用基于处理器的装置将维护诊断代码数据集和维护工作代码数据集分类入电子数据表中。对于各报告的修理，在电子数据表中在至少一个相应的维护诊断代码与至少一个相应的维护工作代码之间形成相应组合。为电子数据表中的每个相应组合确定一个合计数。确定与维护诊断代码或维护工作代码中的多于一个的代码具有相关性的相应诊断代码或相应维护工作代码。响应于对相应组合进行的分析，对用于修理车辆的维护修理程序或者用于确定故障的相应维护诊断代码中的至少一个进行修改。\n[0009] 本发明还涉及以下技术方案。\n[0010] 方案1. 一种利用以前维护车辆的维护修理数据来加强维护诊断的方法，所述方法包括如下步骤：\n[0011] 从记忆储存器件中获取以前维护车辆的维护修理数据；\n[0012] 使用基于处理器的装置将所述维护数据编译入维护诊断代码数据集和维护工作代码数据集，其中，所述维护诊断代码数据集包括报告的诊断故障代码，所述报告的诊断故障代码确定检测故障，其中，所述维护工作代码数据集包括报告的修理代码，所述报告的修理代码用于响应于所确定的检测故障而修理所述车辆；\n[0013] 使用所述基于处理器的装置将所述维护诊断代码数据集和维护工作代码数据集分类入电子数据表中，其中，对于各报告的修理，在所述电子数据表中在至少一个相应的维护诊断代码与至少一个相应的维护工作代码之间形成相应组合；\n[0014] 为所述电子数据表中的每个相应组合确定一个合计数；\n[0015] 确定与维护诊断代码或维护工作代码中的多于一个的代码具有相关性的相应诊断代码或相应维护工作代码；以及\n[0016] 响应于对相应组合的分析对以下各项中的至少一个进行修改：用于修理所述车辆的维护修理程序、或者用于确定故障的相应维护诊断代码。\n[0017] 方案2. 如方案1所述的方法，其中，所述将维护数据编译入维护诊断代码数据集和维护工作代码数据集中的步骤包括：仅对与特定车辆制造商有关的维护数据进行编译。\n[0018] 方案3. 如方案2所述的方法，其中，所述将维护数据编译入维护诊断代码数据集和维护工作代码数据集中的步骤包括：仅对与特定型号车辆有关的维护数据进行编译。\n[0019] 方案4. 如方案3所述的方法，其中，所述将维护数据编译入维护诊断代码数据集和维护工作代码数据集中的步骤包括：仅对与对所述特定型号车辆进行维护的代理商有关的维护数据进行编译。\n[0020] 方案5. 如方案1所述的方法，其中，对相应组合进行分析包括下列步骤：\n[0021] 确定包含具有大于第一预定阈值的合计数的组合的诊断故障代码；\n[0022] 确定包含所述诊断故障代码的一个或多个组合，其中，所述合计数小于第二预定阈值；以及\n[0023] 执行纠正措施，以防止与被确定小于所述第二预定阈值的每个组合的相应工作代码有关的进一步修理。\n[0024] 方案6. 如方案5所述的方法，其中，对相应组合进行分析包括下列步骤：\n[0025] 确定包含所述诊断故障代码和相应工作代码的组合，其中，所述合计数在所确定的组合中均匀地分布；\n[0026] 对所述相关性电子数据表进行精细化，从而对一类车辆或一组代理商中的一者进行评估；\n[0027] 响应于所述精细化的相关性电子数据表的合计数，确定所述故障的根本原因；以及\n[0028] 采取修改所述维护诊断的纠正措施，以确定所述故障的根本原因。\n[0029] 方案7. 如方案6所述的方法，其中，所述纠正措施还包括修改所述诊断故障代码。\n[0030] 方案8. 如方案6所述的方法，其中，所述纠正措施还包括修改维护修理程序。\n[0031] 方案9. 如方案6所述的方法，其中，所述纠正措施还包括加强维护修理技术人员的培训。\n[0032] 方案10. 如方案6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定车辆制造商有关的维护数据来编译维护数据。\n[0033] 方案11. 如方案6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定类型车辆有关的维护数据来编译维护数据。\n[0034] 方案12. 如方案11所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定代理商有关的维护数据来编译维护数据。\n[0035] 方案13. 如方案6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与特定类型车辆发动机有关的维护数据来编译维护数据。\n[0036] 方案14. 如方案13所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用与里程超过预定里程的车辆有关的维护数据来编译维护数据。\n[0037] 方案15. 如方案13所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用与超过预定龄期的车辆有关的维护数据来编译维护数据。\n[0038] 方案16. 如方案6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与相应区域内的特定代理商有关的维护数据来编译维护数据。\n[0039] 方案17. 如方案6所述的方法，还包括以下步骤：对所述电子数据表进行精细化，从而利用仅与超过预定里程的车辆有关的维护数据来编译维护数据。\n[0040] 方案18. 如方案1所述的方法，其中，所述合计数基于在预定时段内所收集的实时维护数据。\n附图说明\n[0041] 图1是用于加强车辆维护诊断的诊断系统的方框图。\n[0042] 图2是示例性的相关性电子数据表。\n[0043] 图3是用于加强车辆维护诊断的方法的流程图。\n具体实施方式\n[0044] 图1中示出了诊断系统10的实施例，诊断系统10用以加强使用维护诊断代码和工作代码保修报告的车辆或任何类型机械装置的维护诊断。诊断系统10利用数据挖掘工具从保修存储数据库12中获取数据集并进行编译。保修存储数据库12包括记忆存储单元，该单元存储与车辆的修理和关注问题（concern）有关的信息。保修存储数据库12优选的是中央数据库，该中央数据库从对保修报告系统内的车辆进行维护的所有维护修理机构中接收维护修理详细报告（service repair verbatim）并进行编译。通常，维护机构(如车辆代理商)在判定问题的原因时，向保修存储数据库12提交代表所确定故障的数据库诊断故障代码(DTC)和代表对车辆所进行的修理的工作代码。\n[0045] 诊断故障代码代表由车辆诊断算法所确定的诊断故障，并且诊断故障代码提供从哪里开始对故障进行分析的起点。维护修理技术人员在诊断问题的过程中，基于所确定的故障而采用维护修理程序或者其自己的分析技能或经验。\n[0046] 报告的工作代码代表在修理车辆的过程中由维护修理技术人员完成的维护修理工作。进行维护修理的车辆可具有多于一个的工作代码来报告给与所确定的诊断故障代码相关的保修数据库系统。亦即，一些诊断故障代码对故障是非常特异性的，对于该确定的故障仅能进行一次修理，但是其它诊断故障代码是故障的一般标识，并且仅提供从哪里开始对问题进行分析的起点。在这些情况下，依赖于维护修理程序和维护修理技术人员来判定问题的根本原因。因此，如果维护修理技术人员不能正确地对故障进行诊断、或者如果在确定故障中修理维护程序不能准确地指导维护修理技术人员，那么在问题被正确地解决之前可能对车辆进行各种修理。在这种情况下，对于单个诊断故障代码，可能报告多于一个的工作代码。\n[0047] 此外，对于一个检测到的故障，维护诊断算法可确定多于一个的诊断故障代码。在这种情况下，维护修理技术人员可采用一个或多个维护修理程序直到问题得到纠正。这导致响应于多个为问题启动的诊断故障代码，一个或多个工作代码被报告给保修存储数据库。\n[0048] 提供编译及分类模块14，其功用是当对车辆进行查询(即，车辆品牌（make）、型号、和年份)时对维护数据进行编译，其中，为了加强维护诊断而期望进行数据挖掘。将维护数据编译入维护诊断代码数据集和维护工作代码数据集。编译是由基于处理器的装置(如计算机)而完成。维护诊断代码数据集包括报告的诊断故障代码，该诊断故障代码确定由所维护车辆的车辆诊断系统所检测到的故障。维护工作代码数据集包括由维护修理技术人员报告的报告工作代码，其基于所确定的检测到的故障来确定给车辆所做的修理。\n[0049] 编译及分类模块14进一步将维护诊断代码数据集和维护工作代码数据集分类入相关性电子数据表(在下文中称为矩阵)，该电子数据表确定诊断故障代码与工作代码的所有潜在组合。对于相应车辆(例如，型号、品牌、和年份)生成相应矩阵。各矩阵包含分类于列中的所有诊断故障代码和分类于行中的所有工作代码。可替代地，可将诊断故障代码设置于行中，同时将工作代码设置于列中。\n[0050] 对于正被分析的车辆类型，相关性矩阵模块16(示于图2)为每个报告的维护修理确定相应诊断故障代码与工作代码之间的相关性。对于在相应诊断故障代码与相关的工作代码之间所报告的各车辆修理，对于该相应的组合将在矩阵中保留计数。结果，诊断故障代码与相关工作代码的每个相应的组合将具有在矩阵中确定的计数，该计数代表关于所完成修理次数的合计数，其中诊断故障代码与工作代码被一起报告，作为修理的一部分。应当理解的是，并不是矩阵中的诊断故障代码与工作代码的所有相应组合都将具有计数，因为在报告的修理中在相应的诊断故障代码与工作代码之间可能不存在相关性。因此，矩阵可确定：与单个工作代码有关的单个诊断故障代码、与工作代码的组合有关的单个诊断故障代码、与单个工作代码有关的诊断故障代码的组合、与工作代码的组合有关的诊断故障代码的组合。\n[0051] 当矩阵的各组合的合计数填充完成时，可利用规定的程序对矩阵内的相关性进行分析，以确定诊断故障代码分离出相应故障的优良程度。例如，相应诊断故障代码与相应工作代码之间有大合计数并且其它工作代码无合计数或有小合计数与该相应诊断故障代码相关，表明在问题维护中具有与修理有关的大合计数的工作代码是正确的修理。相应诊断故障代码与其它工作代码之间的低合计数，表明进行了错误的修理。在另一个实例中，对于相应的诊断故障代码，如果在已与该相应诊断故障代码一起报告的各种工作代码每个的合计数中存在宽分布，那么可确定不是仅有一个纠正问题的方案。\n[0052] 现在再次参照图1，建议模块18根据诊断故障代码和工作代码的相应计数对这两种代码的相关性进行分析，并且提供加强维护修理过程或者确定根本原因的行动步骤。由建议模块输出的用以确定根本原因的以下建议可包括但不限于：对维护技术人员如何解决问题的深入检查、可产生不同修理响应的关于如何在车辆上设置诊断故障代码的变化、改变工作代码、加强维护技术人员的培训、修改维护程序或工作流程、向与特定问题和修理有关的维护修理地点提供维护公告、确定存在如何实施修理的差异的维护修理地点间的区域差异；建议的设计变化是车辆系统/子系统/部件；并且确定其它的与车辆里程的相关性。\n[0053] 图3示出了加强车辆维护诊断的方法的流程图。在步骤20，从保修存储数据库中获取车辆维护数据。从车辆存储数据库中查询到的车辆维护数据是针对车辆的特定型号、品牌和年份。应当理解的是，本文中所描述的过程是从车辆数据的方面进行描述，但该过程也可应用于需要维护的、获取维护诊断故障代码和工作代码的任何类型的机械装置。\n[0054] 在步骤21，基于诊断故障代码数据集代码和工作数据集代码对维护数据进行编译。对针对查询车辆所报告的各诊断故障代码、和针对查询车辆列为修理的被采用的各工作代码进行编译。\n[0055] 在步骤22，将由保修维护数据库获取的各诊断故障代码列于矩阵的相应列中。将由保修维护数据库获取的报告的各工作代码列于矩阵的相应行中。可替代地，可将工作代码设置于列中，可将诊断故障代码设置于行中。\n[0056] 在步骤23，确定各组合的合计数，其中，对于车辆修理中经确定的诊断故障代码，工作代码作为修理而被报告。亦即，对于相应的诊断故障代码和相关的工作代码，将记录一个计数，该计数是关于在被查询车辆上进行了多少次与工作代码相关的修理。结果，矩阵中的各组合（其中，对于工作代码与诊断故障代码的该组合而言进行了至少一次修理）将产生一个计数。如果对于相应的诊断故障代码工作代码未被关联为修理，那么计数将保持零或空白。\n[0057] 在步骤24，将对矩阵内具有计数值的组合进行分析，以确定修理过程是否有效、或者是否需要加强以下分析工具(包括但不限于诊断算法、诊断故障代码、工作代码、维护修理程序、技术人员培训、和通信)。通过查看诊断故障代码的各组合的合计数并确定对于该诊断故障代码是否报告了多于一个的工作代码，来确定对合计数的分析。例如，如果针对某一诊断故障代码的工作代码超过第一预定阈值并且与该诊断故障代码相关的其它工作代码低于第二预定阈值，那么判定超过第一预定阈值的工作代码是正确修理。可确定关于如何使与其它工作代码有关的修理次数最小化的进一步评估。在另一个例子中，如果工作代码的合计数与相关的诊断故障代码之间存在均匀分布、或者多个工作代码超过第一预定阈值，那么建议将会是检查维护修理程序，因为当前的程序并未有效地确定根本原因。亦即，维护程序可基于在诊断/测试阶段所获得的最初评估把维护技术人员引导至替代路径，同时对车辆进行维护。以下是数据可用于确定保修问题的根本原因的各种方法：对于新车辆下线，设计或系统的问题可能会导致异常高的相关性；对于新的车辆子系统，合计数在多个工作代码中的均匀分布可表明维护修理技术人员检测并解决问题的优良程度、或者可表明将诊断故障代码设定于车辆中的方式应当被改变，由此产生不同的修理响应；当关于选择哪个工作代码存在混乱(即，正确地进行了修理但输入了错误的工作代码)时工作代码会要求改变；合计数的均匀分布可表明维护修理技术人员需要进行广泛的培训；给中心发出维护公告，确定不应为特定故障进行的特定修理或者如何正确地诊断特定故障；确定各次修理来自区域性地区，其可表明来自维护人员的错误维护或者部件在该区域的环境条件下是有故障的。其它建议可包括但不限于：车辆、系统、子系统、部件、软件的设计变化，维护修理程序、操作指南、工具的加强，和对超过一定里程的车辆的深入分析。\n[0058] 如果对于相应诊断故障代码所存在（populated）的工作代码存在宽分布，那么可建议对车队水平统计值进行分析以提取更多信息并且确定这是否是车辆品牌特定问题、车辆型号特定问题、或车辆代理商特定问题(例如，维护树（service tree）是不适当的或者未正确地遵循)。以下提供一个例子：如何从车队水平的角度计算出诊断故障代码-工作代码相关性和合计数，并将其相应地窄化而进一步分离出故障的根本原因。将车辆的“品牌”列于以下表1中：\n[0059] 表1\n[0060] \n[0061] 其后跟随假设测试（hypothesis testing）的测试统计量将提供第一水平分析，以确定该问题是涉及车队水平问题(即，由制造商制造的所有车辆)还是涉及特定车辆品牌的问题。如果统计学测试指向H1，那么假设是该问题不是所有车辆中的共同问题，并且必须对车辆车队中的隔离进行进一步分析。启动与车辆“型号”有关的下一个水平的统计学测试，如表2中所示。\n[0062] 表2\n[0063] \n[0064] 接着将进行关于该问题是否由特定型号(例如，车辆A型号)产生的测试。如果问题来自特定型号，那么下一个水平的测试评估此问题是否来源于特定的维护修理提供者、或者是否此问题在所有维护修理提供者中是共同的问题。启动与“代理商”有关的测试，如表3中所示。\n[0065] 表3\n[0066] \n[0067] 根据这是共同问题还是代理商特定问题，如果这是特定维护修理提供者的问题则可以对工作流程进行修改，或者如果这是所有维护修理提供者中的共同问题则可以确定对维护程序/操作指南的修改。如果收集到的数据在群体（population）中增加，那么可以仅基于一定比例的数据来更新数据表。例如，可以确定，当预订百分比(例如，25%-35%)的整个群体达到选择标准(例如，里程或龄期)时，正在被分析的群体的成熟度数据（maturity data）可以代表该组。而且，数据可以作为实时数据而收集，其中仅将已在预定时段内被收集的数据用于分析。\n[0068] 如果收集到的故障数据在群体中增加，那么可要求仅基于一定比例的该数据来更新数据表。亦即，当一定百分比的车辆群体达到预订的龄期或里程时，数据的数据成熟度代表整个组。作为一个实例，可以确定的是，当预定百分比(例如，25%-35%)的整个群体达到选择的标准(例如，里程或龄期)时，正在被分析的群体的成熟度数据可以代表该组。而且，数据可以作为实时数据而被收集，其中仅将已在预定时段内所收集的数据用于分析。\n[0069] 应当理解的是，以上所示的表或统计学测试可以转换为决策树（decision tree），其中各项目表示潜在的修理决策。决策例如关于相应的修理是否可以应对整个车队或者是否可以对特定品牌的车辆进行推断并且并入修理/维护数据库。这种决策可以被认为是进行不同修理的可能性并且可被转换成决策树(例如，Bayesian决策树)，该决策树可以用于指导维护技术人员进行正确的修理。\n[0070] 以上示出的表也可以用作指向以前修理的合适个案史的指示物。基于案例的推理系统（case base reasoning system）可以利用这种信息来确定最佳的修理，同时有可能将基于案例的推理用作连续修理过程。\n[0071] 可以利用信息(如发动机特定数据)对如上所述的表进行进一步的窄化，从而进一步分离故障、超过相应里程的车辆、和超过相应使用时间(即，车辆的龄期)的车辆。当进行修理时，可以对表的数据进行自动编译，同时信息被用于连续调整诊断修理程序。\n[0072] 在步骤25，采取纠正措施来修改加强故障根本原因确认的维护诊断。纠正措施可包括但不限于：修改诊断故障代码、修改维护修理技术人员培训、修改维护修理程序。\n[0073] 虽然已详细描述了本发明的某些实施例，但本发明相关领域的技术人员将认识到如以下权利要求所限定的用以实施本发明的各种替代性设计和实施例。