用于验证由车辆的车载诊断系统生成的诊断故障代码的系统和方法

1.本部分中提供的信息是为了总体上呈现本公开的背景的目的。在本部分中所描述的程度上，当前署名的发明人的工作，以及在提交时可能在其他方面无资格作为现有技术的本说明书的各方面，均未明确地或隐含地被承认为抵触本公开的现有技术。
2.本公开总体上涉及车辆的车载诊断系统，并且更具体而言，涉及用于验证由车辆的车载诊断系统生成的诊断故障代码的系统和方法。


背景技术：

3.车载诊断（obd）对车辆中使用的各种子系统执行，以确保这些子系统正常操作并检测这些子系统中是否发生或即将发生任何故障。当子系统中发生或即将发生故障时，子系统的obd会生成诊断故障代码（dtc）。该dtc通常显示在车辆的仪表板上或以任何其他合适的方式（例如，通过视听指示）呈警告的形式提供给车辆的驾驶员。作为响应，驾驶员可基于该dtc采取适当的行动（例如，安排维修）。dtc可在故障排除和修复故障中帮助维修人员。


技术实现要素：

4.一种用于验证车辆中的诊断故障代码（dtc）的系统包括：处理器；以及存储指令的存储器，所述指令当通过所述处理器执行时将所述处理器配置成：从所述车辆接收dtc数据；使用预限定的规则过滤所述dtc数据；基于经过滤的dtc数据生成一个或多个度量（metrics）；以及基于所述度量来确定所述dtc是否满足所述dtc的规范。
5.在其他特征中，所述处理器被配置成：基于所述度量和所述预限定的规则来检测所述dtc的问题；将所述问题与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc的所述问题的根本原因。
6.在另一特征中，所述处理器被配置成基于与所述软件和校准版本的关联来提供关于更新软件或校准版本的指示。
7.在另一特征中，所述处理器被配置成基于与所述vin的关联来提供关于维修所述车辆中的一个或多个的指示。
8.在另一特征中，所述处理器被配置成基于与所述vin的关联来提供关于修改所述软件或校准版本中的至少一者的指示。
9.在其他特征中，所述处理器被配置成基于以下一项或多项来过滤所述dtc数据：所述dtc数据是否来自测试车辆；针对每个驾驶循环（drive cycle）满足生成所述dtc的条件；在对应故障被清除后，所述dtc被重置；所述dtc在所述车辆已行驶一段时间后生成；以及用于生成所述度量的变量是否在相应的默认值范围内。
10.在其他特征中，所述度量中的一个是使用中监测性能比（iumpr）。所述处理器被配置成基于所述dtc中的一个的所述iumpr是否在预定范围内，来确定所述dtc中的所述一个是否满足对应规范。
11.在其他特征中，所述度量中的一个具有比率类型，并且所述处理器被配置成基于所述dtc中的一个的变量与对应阈值的比率是否在预定限度内，来确定所述dtc中的所述一个是否满足对应规范。
12.在其他特征中，所述度量中的一个具有统计类型，并且所述处理器被配置成基于所述dtc中的一个的变量的平均值是否为远离对应阈值的预定数量的标准差，来确定所述dtc中的所述一个是否满足对应规范。
13.在其他特征中，所述处理器被配置成：检测与选择作为所述dtc中的一个的品质因数变量的变量相对应的数据中的异常值（outlier）；将所述异常值与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc中的所述一个的问题的根本原因。
14.在再其他的特征中，一种用于验证车辆中的诊断故障代码（dtc）的方法包括：从所述车辆接收dtc数据；使用预限定的规则过滤所述dtc数据；基于经过滤的dtc数据生成一个或多个度量；以及基于所述度量来确定所述dtc是否满足所述dtc的规范。
15.在其他特征中，所述方法还包括：基于所述度量和所述预限定的规则来检测所述dtc的问题；将所述问题与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc的所述问题的根本原因。
16.在另一个特征中，所述方法还包括基于与所述软件和校准版本的关联来提供关于更新软件或校准版本的指示。
17.在另一个特征中，所述方法还包括基于与所述vin的关联来提供关于维修所述车辆中的一个或多个的指示。
18.在另一个特征中，所述方法还包括基于与所述vin的关联来提供关于修改所述软件或校准版本中的至少一者的指示。
19.在其他特征中，所述方法还包括基于以下一项或多项来过滤所述dtc数据：所述dtc数据是否来自测试车辆；针对每个驾驶循环满足生成所述dtc的条件；在对应故障被清除后，所述dtc被重置；所述dtc在所述车辆已行驶一段时间后生成；以及用于生成所述度量的变量是否在相应的默认值范围内。
20.在其他特征中，所述度量中的一个是使用中监测性能比（iumpr）。所述方法还包括基于所述dtc中的一个的所述iumpr是否在预定范围内，来确定所述dtc中的所述一个是否满足对应规范。
21.在其他特征中，所述度量中的一个具有比率类型，并且所述方法还包括基于所述dtc中的一个的变量与对应阈值的比率是否在预定限度内，来确定所述dtc中的所述一个是否满足对应规范。
22.在其他特征中，所述度量中的一个具有统计类型，所述方法还包括基于所述dtc中的一个的变量的平均值是否为远离对应阈值的预定数量的标准差，来确定所述dtc中的所述一个是否满足对应规范。
23.在其他特征中，所述方法还包括：检测与选择作为所述dtc中的一个的品质因数变量的变量相对应的数据中的异常值；将所述异常值与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc中的所述一个的问题的根本原因。
24.本发明还包括以下技术方案。
25.方案1. 一种用于验证车辆中的诊断故障代码（dtc）的系统，所述系统包括：处理器；以及存储指令的存储器，所述指令当通过所述处理器执行时将所述处理器配置成：从所述车辆接收dtc数据；使用预限定的规则过滤所述dtc数据；基于经过滤的dtc数据生成一个或多个度量；以及基于所述度量来确定所述dtc是否满足所述dtc的规范。
26.方案2. 根据方案1所述的系统，其中，所述处理器被配置成：基于所述度量和所述预限定的规则来检测所述dtc的问题；将所述问题与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc的所述问题的根本原因。
27.方案3. 根据方案2所述的系统，其中，所述处理器被配置成基于与所述软件和校准版本的关联来提供关于更新软件或校准版本的指示。
28.方案4. 根据方案2所述的系统，其中，所述处理器被配置成基于与所述vin的关联来提供关于维修所述车辆中的一个或多个的指示。
29.方案5. 根据方案2所述的系统，其中，所述处理器被配置成基于与所述vin的关联来提供关于修改所述软件或校准版本中的至少一者的指示。
30.方案6. 根据方案1所述的系统，其中，所述处理器被配置成基于以下一项或多项来过滤所述dtc数据：所述dtc数据是否来自测试车辆；针对每个驾驶循环满足生成所述dtc的条件；在对应故障被清除后，所述dtc被重置；所述dtc在所述车辆已行驶一段时间后生成；以及用于生成所述度量的变量是否在相应的默认值范围内。
31.方案7. 根据方案1所述的系统，其中，所述度量中的一个是使用中监测性能比（iumpr），并且其中，所述处理器被配置成基于所述dtc中的一个的所述iumpr是否在预定范围内，来确定所述dtc中的所述一个是否满足对应规范。
32.方案8. 根据方案1所述的系统，其中，所述度量中的一个具有比率类型，并且其中，所述处理器被配置成基于所述dtc中的一个的变量与对应阈值的比率是否在预定限度内，来确定所述dtc中的所述一个是否满足对应规范。
33.方案9. 根据方案1所述的系统，其中，所述度量中的一个具有统计类型，并且其中，所述处理器被配置成基于所述dtc中的一个的变量的平均值是否为远离对应阈值的预定数量的标准差，来确定所述dtc中的所述一个是否满足对应规范。
34.方案10. 根据方案1所述的系统，其中，所述处理器被配置成：检测与选择作为所述dtc中的一个的品质因数变量的变量相对应的数据中的异常值；将所述异常值与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号
（vin）和环境变量相关联；以及识别所述dtc中的所述一个的问题的根本原因。
35.方案11. 一种用于验证车辆中的诊断故障代码（dtc）的方法，所述方法包括：从所述车辆接收dtc数据；使用预限定的规则过滤所述dtc数据；基于经过滤的dtc数据生成一个或多个度量；以及基于所述度量来确定所述dtc是否满足所述dtc的规范。
36.方案12. 根据方案11所述的方法，还包括：基于所述度量和所述预限定的规则来检测所述dtc的问题；将所述问题与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc的所述问题的根本原因。
37.方案13. 根据方案12所述的方法，还包括基于与所述软件和校准版本的关联来提供关于更新软件或校准版本的指示。
38.方案14. 根据方案12所述的方法，还包括基于与所述vin的关联来提供关于维修所述车辆中的一个或多个的指示。
39.方案15. 根据方案12所述的方法，还包括基于与所述vin的关联来提供关于修改所述软件或校准版本中的至少一者的指示。
40.方案16. 根据方案11所述的方法，还包括基于以下一项或多项来过滤所述dtc数据：所述dtc数据是否来自测试车辆；针对每个驾驶循环满足生成所述dtc的条件；在对应故障被清除后，所述dtc被重置；所述dtc在所述车辆已行驶一段时间后生成；以及用于生成所述度量的变量是否在相应的默认值范围内。
41.方案17. 根据方案11所述的方法，其中，所述度量中的一个是使用中监测性能比（iumpr），所述方法还包括基于所述dtc中的一个的所述iumpr是否在预定范围内，来确定所述dtc中的所述一个是否满足对应规范。
42.方案18. 根据方案11所述的方法，其中，所述度量中的一个具有比率类型，所述方法还包括基于所述dtc中的一个的变量与对应阈值的比率是否在预定限度内，来确定所述dtc中的所述一个是否满足对应规范。
43.方案19. 根据方案11所述的方法，其中，所述度量中的一个具有统计类型，所述方法还包括基于所述dtc中的一个的变量的平均值是否为远离对应阈值的预定数量的标准差，来确定所述dtc中的所述一个是否满足对应规范。
44.方案20. 根据方案11所述的方法，还包括：检测与选择作为所述dtc中的一个的品质因数变量的变量相对应的数据中的异常值；将所述异常值与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及
识别所述dtc中的所述一个的问题的根本原因。
45.通过详细描述、权利要求和附图，本公开的适用性的另外的方面将变得显而易见。详细描述和具体示例仅意在用于说明的目的，并不意在限制本公开的范围。
附图说明
46.通过详细描述和附图，将会更充分地理解本公开，附图中：图1示出了使用车辆中的控制局域网（can）总线来连接到彼此的车辆的多个子系统；图2示出了包括多个服务器和多个图1中所示的车辆的分布式网络系统的示例；图3示出了在图2的分布式网络系统中使用的服务器的示例；图4示出了使用图2的分布式网络系统来验证由车辆中的车载诊断（ods）系统生成的诊断故障代码（dtc）的方法；图5示出了限定用于验证dtc的规则的方法；图6示出了过滤在验证dtc中使用的dtc数据的方法；图7a和7b示出了生成在验证dtc中使用的度量的方法；图8a和8b示出了使用所述度量来检测dtc的问题的方法；图9a-9c示出了将检测到的问题与用于生成dtc、车辆识别号（vin）和环境变量的软件和/或校准相关联的方法；图10示出了用于确定检测到的dtc的问题的根本原因的方法；以及图11示出了用于对检测到的dtc的问题分类并提供解决检测到的dtc的问题的建议的方法。
47.在附图中，附图标记可重复用于标识相似和/或相同的元件。
具体实施方式
48.诊断故障代码（dtc）的性能，或者dtc指示车辆的各种子系统的状态的准确性，可能会影响车辆排放、安全和保修成本。每个dtc都使用特定方法由车载诊断（obd）系统生成。例如，用于生成dtc的方法可涉及监测子系统的一个或多个变量，使用监测的变量执行一个或多个计算，将计算的结果与相应阈值比较，以及基于这些比较产生dtc。这些阈值在车辆的制造期间针对特定的车辆组以经验为主地校准。校准考虑了车辆在道路上可能遇到的大多数状况。然而，当dtc不应被触发（误报）时，某些状况可能会触发dtc。相反，当dtc应被触发（漏报）时，某些状况可能不会触发dtc。这种不一致不仅可能因误报（例如，由于需要不必要的维修）而给用户带来不便，而且还可能因漏报（例如，由于未检测到需要维修的故障）而影响车辆排放、安全性和obd合规性。
49.本公开提供了一种系统和方法，其用于从车辆收集dtc数据、验证该dtc数据，并向驾驶员、维修人员和设计工程师提供各种指示，以使得dtc稳健，使得可最大限度地减少或消除误报和漏报。为了验证dtc并使dtc稳健，本公开的系统和方法提供dtc品质因数（fom）和使用中监测性能比（iumpr）分析，以供工程师校准obd系统。本公开的系统和方法在下文中统称为dtc验证系统。
50.dtc验证系统获取使用obd服务工具手动收集并使用车辆上的车辆数据记录器
（vdr）自动收集的dtc数据。dtc验证系统从使用中的车辆和开发车辆获取dtc数据。dtc验证系统从获取的数据中过滤不良样本（例如，异常值），并通过计算dtc度量并将其与设计目标比较来检测和识别车队的dtc性能问题。dtc验证系统建议驾驶员、维修人员和设计工程师采取纠正动作。
51.当前系统手动过滤从车辆收集的数据并使用近似来计算dtc度量，这使得这些系统慢且易于出错。这些系统的速度进一步降低，这是因为在这些系统中，数据关联手动执行，并且手动探索各个原始数据文件以检测异常。相反，本公开的dtc验证系统自动过滤不良样本（例如，异常值），并使用基于物理和机器学习的模型来快速检测dtc问题，如下文进一步详细解释的。
52.例如，dtc验证系统自动过滤带有偏差和噪声的数据样本，这使得dtc系统稳健，并使得能够准确地检测和识别dtc问题。dtc验证系统还对检测到的dtc问题与环境变量进行综合相关性分析。dtc验证系统以电子方式向驾驶员、维修人员和工程师提供关于为解决检测到的dtc问题要采取的动作和/或要应用的修复的指引。
53.因此，本公开的dtc验证系统改善了汽车行业中的obd系统的技术领域。此外，dtc验证系统的教导适用于其他类型的交通工具，包括但不限于飞机、休闲车、推土机和任何其他设备，例如依赖obd和dtc的电器用具。
54.本公开组织如下。开头，为了介绍obd和dtc，参考图1示出和描述了包括车辆的多个子系统的系统。参考图2和图3示出和描述了一种分布式网络系统，其包括多个车辆以及一个或多个服务器，该一个或多个服务器配置成实施本公开的dtc验证系统。参考图4-11示出和描述了由本公开的dtc验证系统执行的用于验证dtc的各种方法。如本文所用的，验证dtc意味着批准dtc满足指定要求。
55.在车辆中，用于控制各种子系统的控制系统被通常实施为电子控制单元（ecu）。ecu通过控制器局域网（can）总线连接到彼此。每个ecu控制车辆的特定子系统（例如，发动机、变速箱、排气、制动、加热和冷却、信息娱乐、导航等）。每个ecu包括微控制器、can控制器和收发器。在每个ecu中，微控制器包括处理器、存储器以及用于控制特定子系统的其他电路。每个ecu都可通过can控制器和收发器经由can总线与其他ecu通信。
56.图1示出了车辆10的示例，其包括通过can总线连接到彼此的多个ecu。该多个ecu包括ecu-1 12-1、
…
、和ecu-n 12-n（统称为ecu 12），其中n是大于1的整数。在下文中，ecu 12指的是该多个ecu 12中的任何一个。虽然图1示出了仅ecu-n 12-n的详细功能框图，但其他ecu 12也具有与ecu-n 12-n相似的结构。每个ecu 12或其任何部分可实现为一个或多个模块。
57.每个ecu 12控制车辆10的相应子系统。例如，ecu-1 12-1控制子系统14-1，ecu-1 12-2控制子系统14-2，
…
，并且ecu-n 12-n控制子系统14-n。子系统14-1、14-2、
…
和14-n统称为子系统14。子系统14的非限制性示例包括发动机子系统、变速器子系统、排气子系统、制动子系统、牵引子系统、悬架子系统、安全子系统、信息娱乐子系统、导航子系统、通信子系统、生理数据采集子系统、气候控制子系统等。
58.每个子系统14可包括一个或多个传感器，以感测来自子系统14的一个或多个部件的数据。此外，每个子系统14可包括一个或多个致动器，以致动子系统14的一个或多个部件。ecu 12可从对应子系统14的一个或多个传感器接收数据。根据子系统14的类型，ecu 12
还可从车辆10的乘员接收一个或多个输入。ecu 12可基于从该一个或多个传感器接收的数据和/或来自车辆10的乘员的该一个或多个输入来控制对应子系统14的一个或多个致动器。
59.ecu 12被连接到can总线16。ecu 12可经由can总线16彼此通信。ecu 12可与连接到can总线16的其他装置（例如，测试设备、通信网关等）通信。每个ecu 12包括微控制器20和can收发器22。微控制器20与由ecu 12控制的子系统14通信。can收发器22与can总线16通信，并在can总线16上发送和接收数据。
60.微控制器20包括处理器30、存储器32、can控制器34和电源36。存储器32包括易失性存储器（ram），并且可另外包括非易失性存储器（例如，闪存）和/或其他类型的数据存储装置。处理器30和存储器32经由总线38彼此通信。处理器30执行存储在存储器32中的代码，以控制子系统14。例如，该代码可包括车载诊断（obd），以诊断子系统14。电源36向微控制器20和ecu 12的所有部件供电。can控制器34与can收发器22通信。
61.处理器30可在子系统14上执行obd，并且可生成指示子系统14的操作状态的一个或多个诊断故障代码（dtc）。该obd和子系统14的任何传感器在制造车辆10时被校准。子系统14可包括通信子系统（例如，子系统14-1）。通信子系统14-1可包括用于无线（例如，蜂窝、wifi等）通信的一个或多个收发器、用于导航的gps系统等，以与分布式通信系统110通信。通信子系统14-1可经由分布式通信系统110将dtc数据传输到在云中的一个或多个服务器（图2中所示）中实现的dtc验证系统。通信子系统14-1可经由分布式通信系统110从dtc验证系统接收软件更新（例如，用于obd）。
62.子系统14还可包括信息娱乐子系统（例如，子系统14-n）。虽然未示出，但信息娱乐子系统14-n可包括无线电接收器、卫星接收器和一个或多个显示器，包括车辆10的仪表板上的显示控制台以及包括用于车辆10的乘员的触摸屏的多个显示器。信息娱乐子系统14-n可包括视听多媒体子系统以及允许车辆10的乘员与一个或多个子系统14交互的人机界面（hmi）。信息娱乐子系统14-n可向车辆10的乘员提供dtc的视听指示。信息娱乐子系统14-n还可经由hmi向车辆10的乘员提供从dtc验证系统接收到的警报和/或消息。
63.图2示出了分布式网络系统100的简化示例。分布式网络系统100包括分布式通信系统110。分布式网络系统100包括一个或多个服务器130-1、130-2、...和130-n（统称为服务器130）；以及一个或多个车辆140-1、140-2、...和140-p（统称为车辆140），其中n和p是正整数。例如，服务器130可位于云中。分布式通信系统110可包括蜂窝网络、基于卫星的通信网络、wi-fi网络、互联网或其他类型的网络。服务器130可使用无线和/或有线连接来连接到分布式通信系统110。
64.服务器130实现本公开的dtc验证系统，其在下面参考图4-11来详细描述。每个车辆140与上述车辆10相似，并包括图1中所示的ecu 12和子系统14。在整个本公开中，与车辆140并且通过车辆140的通信应被理解为与车辆140中的ecu 12和子系统14的通信。例如，在每个车辆140中，通信子系统（例如，子系统14-1）可经由分布式通信系统110与在服务器130中实现的dtc验证系统通信。
65.图3示出了服务器130（例如，服务器130-1）的简化示例。服务器130-1通常包括一个或多个cpu或处理器170、一个或多个输入装置172（例如，小键盘、触摸板、鼠标等）、包括显示器172的显示子系统174、网络接口178、存储器180和大容量存储器182。网络接口178经
由网络110将服务器130-1连接到分布式网络系统100。例如，网络接口178可包括有线接口（例如，以太网接口）和/或无线接口（例如，wi-fi、蓝牙、近场通信（nfc）、蜂窝或其他无线接口）。存储器180可包括易失性或非易失性存储器、高速缓存或其他类型的存储器。大容量存储器182可包括闪存、一个或多个硬盘驱动器（hdd）或其他大容量存储装置。
66.服务器130-1的处理器170可执行操作系统（os）184和一个或多个服务器应用186。服务器应用186可包括实施下述方法以根据本公开执行dtc验证的应用。大容量存储器182可存储一个或多个数据库188，其存储由服务器应用186用来执行相应功能的数据结构。服务器130和服务器应用186，包括实施下面参考图4-11示出和描述的方法以执行dtc验证的一个或多个应用，构成根据本公开的dtc验证系统。
67.在整个本公开中，对诸如“服务器”、“应用”之类的术语的引用仅用于说明目的。术语“服务器”应广义地理解为表示包括配置成执行机器可读指令的一个或多个处理器和存储器的计算装置。术语“应用”和“计算机程序”应被广义地理解为表示可由计算装置执行的机器可读指令。
68.图4示出了根据本公开的用于执行dtc验证的方法200。在202处，方法200限定规则，以评估可由车队生成的dtc的性能。参考图5详细示出和描述了限定规则的方法，包括在规则中使用的变量和在dtc验证中使用的其他参数，包括但不限于阈值、过滤器、边界等。
69.在203处，方法200导入用于dtc的可变信息。在204处，方法200从车辆获取dtc数据。在206处，方法200使用这些规则从获取的dtc数据中过滤过早的dtc样本。参考图6详细示出和描述了过滤过程。
70.在208处，方法200使用规则生成dtc的度量。参考图7a和7b详细示出和描述了度量的生成。在210处，方法200使用规则来检测dtc的问题。参考图8a和8b详细示出和描述了问题检测。
71.在212处，方法200确定是否检测到dtc的问题。如果没有检测到dtc的问题，则在214处，方法200确定dtc满足要求（即，该方法将dtc批准或确认为满足要求），并且方法200结束。当dtc正确指示dtc被设计成指示的问题时，dtc满足要求。因此，满足要求表明dtc生成正确（即，用于生成dtc的诸如校准、感测数据、处理数据、阈值比较之类的程序按照规范运行，而没有产生误报和漏报）。
72.然而，如果检测到dtc的问题，则在216处，方法200将检测到的一个或多个问题与用于生成dtc的软件版本和/或校准、车辆标识符（例如，车辆识别号或vin）和环境变量（例如，环境温度、天气条件、道路条件等）相关联。参考图9a-10详细示出和描述了关联方法。
73.在218处，方法200对dtc的问题的类型分类，使得可采取合适的纠正措施（例如，更新用于生成dtc的软件和/或校准，补偿环境变量，安排硬件维修等）。参考图11详细示出和描述了对问题类型分类和建议解决问题的纠正措施的方法。
74.图5进一步详细地示出了方法200的步骤202（即，限定规则的方法，包括在规则中使用的变量以及在dtc验证中使用的其他参数，诸如阈值、过滤器、边界等）。在230处，方法200指定用于（例如，在方程中）计算车队的每个dtc的变量。此外，方法200指定其他参数，包括但不限于阈值、过滤器、边界等，这些参数被用于针对每个dtc的如参考图6-11描述的dtc数据的进一步处理中。在232处，方法200指定用于针对每个dtc过滤所获取的dtc数据的过滤标准。参考图6详细示出和描述了使用这些过滤标准执行的过滤过程。
75.在234处，方法200指定用于计算每个dtc的品质因数（fom）的阈值。参考图7a和7b详细示出和描述了计算fom的方法。在236处，方法200指定用于检测每个dtc的问题的边界。参考图8a和8b详细示出和描述了用于检测dtc的问题的方法。在238处，该方法指定用于通知检测到的dtc的问题的分层通知方案。参考图11详细示出和描述了通知的方法。
76.图6进一步详细地示出了方法200的步骤206（即，过滤过早dtc样本的方法）。在252处，方法200确定获取的数据是否来自车辆的测试行程（例如，出于诊断评估目的而带有植入故障的车辆所进行的行程）。如果是，则方法200在262处丢弃获取的数据，因为分析这样的数据并不反映dtc的实际行为，并且因此不能用于验证dtc。如果否，则方法200继续进行到252。
77.在252处，方法200确定对于车辆进行的每个行程是否满足使得能够生成dtc的条件（即，是否在每个行程中一致地生成dtc）。如果否，则方法200在262处丢弃获取的数据。如果是，则方法200继续进行到254。
78.在254处，方法200确定在硬件相关故障或注入故障被清除之后dtc是否被重置（即，由于先前条件而设置的dtc是否不继续存在）。如果否，则方法200在262处丢弃获取的数据。如果是，则方法200继续进行到256。
79.在256处，方法200确定车辆是否已被驾驶足够的时间，以允许数据成熟。例如，在基于来自排气系统的数据生成的dtc有效之前，车辆的排气系统可能需要时间以从冷启动预热。如果否，则方法200在262处丢弃获取的数据。如果是，则方法200继续进行到258。
80.在258处，方法200确定dtc的fom变量是否不在预定的默认值范围内。如果否，则方法200在262处丢弃获取的数据。如果是，则方法200继续进行到260。在260处，在如步骤250至258中所述的过滤获取的数据之后，方法200保留经过滤的数据以用于图7a中向前所示的进一步处理。
81.图7a和7b进一步详细地示出了方法200的步骤208（即，使用来自图6中所示的步骤260的经过滤数据的度量生成的方法）。图7a示出了称为使用中性能监测比（iumpr）的度量的计算作为步骤208-1，该步骤是步骤208的一部分。图7b示出了称为称为fom比和fom sigma的度量的计算作为步骤208-2，该步骤也是步骤208的一部分。
82.在图7a中，在280处，方法200选择dtc和从图6中执行的过滤获得的相关经过滤数据。在282处，方法200通过使用一组预定过滤器（例如，如参考图5所述限定的）来确定来自行程的数据是否应包括在度量计算中。
83.在284处，对于每个dtc，方法200确定分子，其是车辆已被操作使得已遇到特定监测器检测到故障所需的所有监测条件的次数。在286处，方法200计算分子与分母的比率，其中分母是计数器，如果已满足标准驾驶循环的限定条件，则该计数器在特定驾驶循环时递增。
84.在288处，方法200将该比率与预定阈值比较，并确定iumpr是否足够（即，dtc是否满足iumpr要求）。例如，小于1（例如，0.336）的比值被认为是足够的。iumpr的充足性是基于根据规定将运行诊断的规定次数和运行诊断的实际次数。因此，该比率的非常低的值（例如，小于0.336）不足以满足iumpr要求。
85.在图7b中，在300处，方法200通过使用一组预定过滤器（例如，如参考图5所述限定的）来确定来自行程的数据是否应包括在度量计算中。在302处，方法200从针对dtc的规则
中选择用于dtc的fom变量和阈值（例如，如参考图5所述的那样限定的）。
86.在304处，根据如参考图5所述限定的规则，方法200确定dtc的fom类型是限定为比率还是限定为统计参数sigma。如果将dtc的fom类型限定为比率，则方法200继续进行到306。如果dtc的fom类型被限定为统计参数sigma，则方法200继续进行到308。
87.在306处，方法200使用来自经过滤数据的fom变量的值，并计算fom变量与对应阈值的比率。方法200如下文参考图8a所述的处理该比率。在308处，方法200使用来自经过滤数据的fom变量的值，并计算fom变量的平均值。方法200确定平均值偏离阈值的sigma（标准差）的数量。方法200如下文参考图8b所述的处理该平均值。
88.图8a和8b进一步详细地示出了方法200的步骤210（即，基于如参考图7a和7b所述计算的度量的问题检测的方法）。图8a示出了基于图7a中所示计算的比率的问题检测作为步骤210-1，该步骤是步骤210的一部分。图8b示出了基于图7b中所示的sigma计算的问题检测作为步骤210-2，该步骤也是步骤210的一部分。
89.在图8a中，在320处，方法200确定如参考图7a所述计算的比率是否小于或等于预定阈值（例如，在如参考图5所述的规则中限定）。例如，对于误报dtc，该比率可以是类型1比率，并且对于漏报dtc，是类型2比率。在任何一种情况下，该比率都可归一化为介于0和1之间的值。该比率的低值（例如，与1相比更接近0）表明dtc数据是可靠的。
90.如果该比率小于或等于预定阈值，则在322处，方法200确定dtc的fom数据在边界（例如，在如参考图5所述的规则中限定）内。在324处，方法200确定dtc的obd满足要求。
91.然而，如果该比率不小于或等于预定阈值，则在326处，方法200确定dtc的fom数据不在边界内（即，在边界外）。在328处，方法200确定dtc的obd不满足要求。
92.在图8b中，在340处，方法200确定如参考图8b所述来确定的sigma的数量是否满足目标值（例如，在参考图5所述的规则中限定）。例如，对于类型1（误报dtc），sigma的数量可大于或等于4个sigma，并且对于类型2（漏报dtc），可大于或等于2个sigma。在任何一种情况下，该比率都可归一化为介于0和1之间的值。
93.如果所确定的sigma的数量满足目标值，则在342处，方法200确定dtc的fom数据在边界（例如，在如参考图5所述的规则中限定）内。在344处，方法200确定dtc的obd满足要求。
94.然而，如果所确定的sigma的数量不满足目标值，则在326处，方法200确定dtc的fom数据不在边界内（即，在边界外）。在348处，方法200确定dtc的obd不满足要求。
95.图9a-9c和图10进一步详细地示出了方法200的步骤216（即，将检测到的一个或多个问题与软件版本和/或校准、vin和环境变量相关联的方法）。图9a示出了与软件版本的关联作为步骤216-1，该步骤是步骤216的一部分。图9b示出了与vin的关联作为步骤216-2，该步骤是步骤216的一部分。图9c示出了与环境变量的关联作为步骤216-2，该步骤是步骤216的一部分。图10示出了异常数据与这些因素的关联作为步骤216-4，该步骤也是步骤216的一部分。
96.在图9a中，在360处，方法200确定dtc的fom数据是否超出边界（如在图8a中的步骤326处或在图8b中的步骤346处所确定的）。如果dtc的fom数据超出边界，则在362处，方法200基于正用于生成dtc的软件版本或校准版本来过滤fom数据。在364处，方法200识别引起dtc的问题的软件版本或校准版本。
97.在图9b中，在380处，方法200确定dtc的fom数据是否超出边界（如在图8a中的步骤
326处或在图8b中的步骤346处所确定的）。如果dtc的fom数据超出边界，则在382处，方法200基于vin来过滤fom数据。在364处，方法200识别具有dtc问题的一个或多个车辆。
98.在图9c中，在400处，方法200确定dtc的fom数据是否超出边界（如在图8a中的步骤326处或在图8b中的步骤346处所确定的）。如果dtc的fom数据超出边界，则在402处，方法200确定dtc的问题是由于软件或校准版本（如参考图9a所述来确定）还是由于vin（如参考图9b所述来确定）。如果dtc的问题既不是由于软件或校准版本也不是由于vin，则在404处，方法200将dtc的fom数据与一个或多个环境变量（例如，环境温度、道路的粗糙度等）相关联。在406处，方法200将具有最高相关性的环境变量识别为引起dtc的问题。
99.在图10中，在420处，方法200将dtc的fom数据输入到基于机器学习的异常值检测器。在422处，方法200确定是否在dtc的fom数据中检测到任何异常值。如果检测到任何异常值，则在424处，方法200将该异常值与软件或校准版本、vin和环境变量相关联。在426处，方法200确定在该异常值与包括软件或校准版本、vin和环境变量的任何因素之间是否存在强相关性。如果是，则在430处，方法300基于该异常值与之具有最强（最高）相关性的因素来确定或识别该异常值的一个或多个根本原因。
100.图11进一步详细地示出了方法200的步骤218（即，对dtc的问题类型分类并建议纠正措施的方法）。在440处，方法200确保图5中限定的规则和相关参数（例如，阈值、过滤器、边界等）是正确的（例如，从设计和工程角度来看）。在442处，方法200确定dtc的问题是否是由于特定的软件版本或校准版本（基于参考图9a-10所述的相关性）。如果是，则在444处，方法200更新与dtc相关联的软件。如果否，则方法200继续进行到446。
101.在446处，方法200确定dtc的问题是否与特定的一个或多个vin相关。如果是，则在448处，方法200提供维修车辆硬件的指示（例如，通过dtc的子系统指示故障）。如果否，则方法200继续进行到450。在450处，该方法更新用于dtc的软件或校准。
102.前述描述本质上仅仅是说明性的，并且不意在限制本公开、其应用或用途。本公开的宽泛教导能够以多种形式实施。因此，虽然本公开包括特定示例，但本公开的实际范围不应仅限于此，这是由于依据对附图、说明书和以下权利要求的研究，其他修改将变得显而易见。
103.应当理解的是，方法内的一个或多个步骤可按照不同的顺序（或同时地）执行，而不改变本公开的原理。此外，尽管实施例中的每一个在上文中被描述为具有某些特征，但是关于本公开的任何实施例描述的那些特征中的任何一个或多个都可在任何其他实施例中实施和/或与任何其他实施例中的特征组合，即使该组合未明确地描述。换句话说，所描述的实施例不是互斥的，并且一个或多个实施例彼此的置换仍处于本公开的范围内。
104.元件之间（例如，模块、电路元件、半导体层等之间）的空间和功能关系使用各种术语来描述，包括“连接”、“接合”、“耦接”、“相邻”、“旁边”、“处于顶部上”、“上方”、“下方”和“设置”。除非明确地描述为“直接”，否则在上面的公开中描述第一和第二元件之间的关系时，该关系可以是该第一和第二元件之间不存在其他中介元件的直接关系，但也可以是该第一和第二元件之间（空间上或功能上）存在一个或多个中介元件的间接关系。如本文所用的，措辞“a、b和c中的至少一个”应当被解释为意指使用非排他性逻辑or的逻辑（a or b or c），并且不应被解释为意指“a中的至少一个、b中的至少一个以及c中的至少一个”。
105.在附图中，如箭头尖头所指示的箭头的方向通常展示该图示所关注的信息流（例
如，数据或指令）。例如，当元件a和元件b交换各种信息但从元件a传输到元件b的信息与图示有关时，箭头可从元件a指向元件b。该单向箭头并不意味着没有其他信息从元件b传输到元件a。此外，对于从元件a发送到元件b的信息，元件b可将对信息的请求或接收确认发送到元件a。
106.在包括以下限定的本技术中，术语“模块”、“控制器”或“子系统”可替换为术语“电路”。术语“模块”、“控制器”和“子系统”可指下列各项、下列各项的一部分或者包括下列各项，即：专用集成电路（asic）；数字、模拟或混合的模/数离散电路；数字、模拟或混合的模/数集成电路；组合式逻辑电路；现场可编程门阵列（fpga）；执行代码的处理器电路（共享的、专用的或群组）；存储通过处理器电路执行的代码的存储器电路（共享的、专用的或群组）；提供所述功能的其他合适的硬件部件；或者例如片上系统中的上述各项中的某些或全部的组合。此外，术语“子系统”可包括模块和/或控制器，并且可另外包括一个或多个传感器和致动器，以提供所描述的功能。
107.所述模块、控制器和子系统可包括一个或多个接口电路。在一些示例中，所述接口电路可包括连接到局域网（lan）、互联网、广域网（wan）或其组合的有线或无线的接口。本公开的任何给定的模块、控制器和子系统的功能可分布在经由接口电路连接的多个模块、控制器和子系统之中。例如，多个模块可允许负载平衡。在另一示例中，服务器（也称为远程或云）模块可代表客户端模块完成一些功能。
108.如上文中所用的术语“代码”可包括软件、固件和/或微码，并且可指程序、例程、函数、类、数据结构和/或对象。术语“共享处理器电路”涵盖执行来自多个模块、控制器和子系统的某些或全部代码的单处理器电路。术语“群组处理器电路”涵盖与附加的处理器电路相结合执行来自一个或多个模块、控制器和子系统的某些或全部代码的处理器电路。对多个处理器电路的引用涵盖离散管芯上的多个处理器电路、单管芯上的多个处理器电路、单处理器电路的多个核心、单处理器电路的多个线程或者上述各项的组合。术语“共享存储器电路”涵盖存储来自多个模块、控制器和子系统的某些或全部代码的单存储器电路。术语“群组存储器电路”涵盖与附加的存储器相结合存储来自一个或多个模块、控制器和子系统的某些或全部代码的存储器电路。
109.术语“存储器电路”是术语“计算机可读介质”的子集。如本文中所用的术语“计算机可读介质”不涵盖通过介质（例如，在载波上）传播的暂时性电信号或电磁信号；因此，术语“计算机可读介质”可被认为是有形的或非暂时性的。非暂时性、有形的计算机可读介质的非限制性示例是非易失性存储器电路（例如，闪速存储器电路、可擦除可编程只读存储器电路或掩模只读存储器电路）、易失性存储器电路（例如，静态随机存取存储器电路或动态随机存取存储器电路）、磁性存储介质（例如，模拟或数字的磁带或者硬盘驱动器）以及光存储介质（例如，cd、dvd或蓝光光盘）。
110.本技术中描述的设备和方法可通过专用计算机来部分或全部地实施，所述专用计算机通过将通用计算机配置成执行体现在计算机程序中的一个或多个特定功能来创建。上述的功能框、流程图部件和其他元件作为软件规范，该软件规范可通过技术人员或程序员的日常工作来转换成计算机程序。
111.所述计算机程序包括存储在至少一个非暂时性、有形的计算机可读介质上的处理器可执行指令。所述计算机程序还可包括或依靠所存储的数据。所述计算机程序可涵盖与
专用计算机的硬件相互作用的基本输入/输出系统（bios）、与专用计算机的特定装置相互作用的装置驱动、一个或多个操作系统、用户应用程序、后台服务、后台应用程序等。
112.所述计算机程序可包括：（i）待解析的描述性文本，例如html（超文本标记语言）、xml（可扩展标记语言）或json（javascript对象符号）；（ii）汇编代码；（iii）通过编译器由源代码生成的目标代码；（iv）供解释器执行的源代码；（v）供即时编译器编译和执行的源代码等。仅作为示例，源代码可使用来自以下语言的语法来编写，所述语言包括：c、c++、c#、objective-c、swift、haskell、go、sql、r、lisp、java
®
、fortran、perl、pascal、curl、ocaml、javascript
®
、html5（超文本标记语言第5版）、ada、asp（动态服务器网页）、php（php：超文本预处理器）、scala、eiffel、smalltalk、erlang、ruby、flash
®
、visual basic
®
、lua、matlab、simulink以及python
®
。

技术特征：
1. 一种用于验证车辆中的诊断故障代码（dtc）的系统，所述系统包括：处理器；以及存储指令的存储器，所述指令当通过所述处理器执行时将所述处理器配置成：从所述车辆接收dtc数据；使用预限定的规则过滤所述dtc数据；基于经过滤的dtc数据生成一个或多个度量；以及基于所述度量来确定所述dtc是否满足所述dtc的规范。2.根据权利要求1所述的系统，其中，所述处理器被配置成：基于所述度量和所述预限定的规则来检测所述dtc的问题；将所述问题与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc的所述问题的根本原因。3.根据权利要求2所述的系统，其中，所述处理器被配置成基于与所述软件和校准版本的关联来提供关于更新软件或校准版本的指示。4.根据权利要求2所述的系统，其中，所述处理器被配置成基于与所述vin的关联来提供关于维修所述车辆中的一个或多个的指示。5.根据权利要求2所述的系统，其中，所述处理器被配置成基于与所述vin的关联来提供关于修改所述软件或校准版本中的至少一者的指示。6.根据权利要求1所述的系统，其中，所述处理器被配置成基于以下一项或多项来过滤所述dtc数据：所述dtc数据是否来自测试车辆；针对每个驾驶循环满足生成所述dtc的条件；在对应故障被清除后，所述dtc被重置；所述dtc在所述车辆已行驶一段时间后生成；以及用于生成所述度量的变量是否在相应的默认值范围内。7.根据权利要求1所述的系统，其中，所述度量中的一个是使用中监测性能比（iumpr），并且其中，所述处理器被配置成基于所述dtc中的一个的所述iumpr是否在预定范围内，来确定所述dtc中的所述一个是否满足对应规范。8.根据权利要求1所述的系统，其中，所述度量中的一个具有比率类型，并且其中，所述处理器被配置成基于所述dtc中的一个的变量与对应阈值的比率是否在预定限度内，来确定所述dtc中的所述一个是否满足对应规范。9.根据权利要求1所述的系统，其中，所述度量中的一个具有统计类型，并且其中，所述处理器被配置成基于所述dtc中的一个的变量的平均值是否为远离对应阈值的预定数量的标准差，来确定所述dtc中的所述一个是否满足对应规范。10.根据权利要求1所述的系统，其中，所述处理器被配置成：检测与选择作为所述dtc中的一个的品质因数变量的变量相对应的数据中的异常值；将所述异常值与用于生成所述dtc的软件和校准版本、所述车辆的车辆识别号（vin）和环境变量相关联；以及识别所述dtc中的所述一个的问题的根本原因。

技术总结
本发明涉及用于验证由车辆的车载诊断系统生成的诊断故障代码的系统和方法。一种用于验证车辆中的诊断故障代码（DTC）的系统包括：处理器；以及存储指令的存储器，所述指令当通过所述处理器执行时将所述处理器配置成：从所述车辆接收DTC数据；使用预限定的规则过滤所述DTC数据；基于经过滤的DTC数据生成一个或多个度量；以及基于所述度量来确定所述DTC是否满足所述DTC的规范。满足所述DTC的规范。满足所述DTC的规范。


技术研发人员：段时鸣 Y
受保护的技术使用者：东北大学
技术研发日：2022.10.20
技术公布日：2023/9/13