车辆队列中的协调测试的制作方法

本发明涉及一种协调测试方法及系统，并具体涉及一种车辆队列中进行协调测试的方法及系统。

背景技术：

车载诊断(OBD)测试分析车辆运行并且可以识别车辆部件的问题。OBD测试可以被延迟和/或少量地执行，然而，因为执行OBD测试通常取决于在测试之前和/或期间符合先决条件(有时被称为入口)。OBD测试的实例包括蒸发排放控制(EVAP)测试、废气再循环(EGR)测试、氧传感器测试、加热催化剂测试等等。入口条件的实例包括容量在15％和85％之间的燃料体积、从40华氏度到95华氏度的环境温度、小于8500英尺的海拔高度、大于每小时25英里的车辆速度等等。

技术实现要素：

一种方法，包括：

在领头车辆中确定诊断测试的一个或多个条件被满足；

向一个或多个跟随车辆发送车辆间消息，该消息提供指示每个跟随车辆在特定时间执行测试的数据；以及

在特定时间在领头车辆中执行测试。

根据前述方法的一非限定性实施例，还包括从领头车辆向一个或多个跟随车辆提供操作指令。

根据前述方法的另一非限定性实施例，其中数据包括在特定时间执行测试的指令。

根据前述方法的另一非限定性实施例，其中数据包括指示跟随车辆中的至少一个修改跟随车辆中的该至少一个的操作的指令和使跟随车辆中的至少一个修改诊断测试的测试协议的指令。

根据前述方法的另一非限定性实施例，其中数据包括关于领头车辆前方道路的信息。

根据前述方法的另一非限定性实施例，还包括从跟随车辆中的一个或多个接收测试结果。

根据前述方法的另一非限定性实施例，其中数据包括领头车辆传感器的测量。

根据前述方法的另一非限定性实施例，其中条件包括环境温度、燃料体积、车辆速度和车辆加速度中的至少一个。

根据前述方法的另一非限定性实施例，还包括从领头车辆向一个或多个跟随车辆发送用于指示一个或多个跟随车辆暂停测试的第二车辆间消息。

根据前述方法的另一非限定性实施例，其中诊断测试是车载诊断(OBD)测试。

一种系统，包括：

车辆计算机，车辆计算机包括处理器和存储器，存储器存储可由处理器执行以进行以下操作的指令：

在领头车辆中确定诊断测试的一个或多个条件被满足；

在特定时间向一个或多个跟随车辆发送车辆间消息，该消息提供指示每个跟随车辆在特定时间执行测试的数据；以及

在特定时间在领头车辆中执行测试。

根据前述系统的一非限定性实施例，其中计算机还被编程为从领头车辆向一个或多个跟随车辆提供操作指令。

根据前述系统的另一非限定性实施例，其中数据包括在特定时间执行测试的指令。

根据前述系统的另一非限定性实施例，其中数据包括使跟随车辆中的至少一个车辆修改跟随车辆中的该至少一个的操作的指令和使跟随车辆中的至少一个修改诊断测试的测试协议的指令。

根据前述系统的另一非限定性实施例，其中数据包括关于领头车辆前方道路的信息。

根据前述系统的另一非限定性实施例，其中计算机还被编程为从跟随车辆中的一个或多个接收测试结果。

根据前述系统的另一非限定性实施例，其中数据包括领头车辆传感器的测量。

根据前述系统的另一非限定性实施例，其中条件包括环境温度、燃料体积、车辆速度和车辆加速度中的至少一个。

根据前述系统的另一非限定性实施例，其中计算机还被编程为从领头车辆向一个或多个跟随车辆发送用于指示一个或多个跟随车辆暂停测试的第二车辆间消息。

根据前述系统的另一非限定性实施例，其中诊断测试是车载诊断(OBD)测试。

附图说明

图1示出了用于车辆队列中的OBD测试的示例性系统；

图2是用于车辆队列中的OBD测试的示例性过程的图示。

具体实施方式

概述

图1是示例性用于包括领头车辆101和跟随车辆102的队列的多车辆测试系统的框图。尽管在本文示例中描述的测试是车载诊断(OBD)系统测试，但是所公开的主题可在测试其他车辆101、102系统和/或元件的情况中实践。一般而言，本文所示的原理可以应用于车辆101、102以队列方式运行的任何情况中，并且其中领头车辆101的计算机105可以确定一个或多个跟随车辆102的测试条件是否满足。在任何这样的情况中，计算机105可以向一个或多个跟随车辆102的计算机106发送消息，该消息包括用于启动一个或多个测试的指令，这些指令补充和/或超驰用于控制一个或多个测试的执行的计算机106中的程序设计。

车辆101包括计算机105，计算机105包括或通信地连接到如已知的提供向车辆101的部件和/或电子控制单元110的通信和来自车辆101的部件和/或电子控制单元110的通信的车辆101的通信总线125上，电子控制单元110如车辆101转向、制动、节流的控制器。计算机105可以接收与操作车辆101有关的数据。计算机105通常与网络130通信地连接，计算机105可以通过网络130与服务器140通信，服务器140进而通信地连接到数据存储145。

车辆101是包括周围(通常是跟随)车辆102的车辆队列中的领头车辆。车辆101、102可以通过诸如专用短程通信(DSRC)之类的车辆间(V2V)通信等进行通信。领头车辆101可以向跟随车辆102提供例如关于速度、加速度、制动、转向等各种指令。车辆101、102可以或可以不被人类操作者使用。换句话说，车辆101、102可以形成队列并且根据用于车辆队列的各种已知系统来运行。

此外，车辆101、102在一起行驶时(例如，成队列在道路上)可协调OBD测试。例如，车辆101的计算机105可以确定车辆101中何时满足用于车辆101和/或车辆102的OBD测试(或多个测试)的一个或多个先决条件(如有时被称为“入口”条件)，因此车辆101可以启动车辆101中的OBD测试并且可以向跟随车辆102发送消息以执行测试。该消息可以指定在车辆101、102中的每一个中执行测试的时间和/或位置(例如，特定的全球定位系统坐标)从而同步进行测试。此外，车辆102的计算机106可以被编程为在从车辆101接收到这样的消息时执行一个或多个测试，即使在车辆102中不满足先决条件，和/或根据在车辆102中的修改的先决条件来执行，即车辆102可以使用基于对来自领头车辆101的消息的依赖而被修改的测试的先决条件。

因此，有利地，车辆101、102可以更经常和更有效地进行OBD测试。由于变化的和/或不可预见的条件而中止OBD测试的风险被降低。

示例系统元件

如已知的，包括处理器和存储器的车辆101的计算机105可以通过例如通信总线125或其他已知的有线或无线连接通信地连接，或者计算机105可以包括一个或多个更多的电子控制单元，例如包括在车辆101中用于监测和/或控制各种车辆101部件的控制器或类似部件，各种车辆101部件例如发动机控制单元(ECU)、变速器控制单元(TCU)等。总线125可以是控制器局域网(CAN)总线和/或任何其他合适的诸如JASPAR(日本汽车软件平台和架构)、LIN(本地互联网络)、SAE(美国汽车工程师协会)J1850、AUTOSAR(汽车开放系统架构)、MOST(媒体导向系统传输协议)等车内通信总线。电子控制单元可以被连接到已知的例如CAN总线上。车辆101还可以包括专门用于接收和传输诊断信息的一个或多个电子控制单元，例如车载诊断连接器(OBD II)。通过CAN总线、OBD II和/或其它有线或无线机制，计算机105可以向车辆101中的各种装置发送消息和/或从各种装置接收消息，这些装置例如控制器、致动器等。选择性地或者另外地，在计算机105实际上包括多个装置的情况下，CAN总线等可以被用来提供表示为本公开中计算机105的装置(例如，各种ECU)之间的通信。

计算机105可以使用多个通信协议来发送和/或接收消息，例如，计算机105可以包括和/或通信地连接到如已知的用于提供这种通信的一个或多个收发器。例如，计算机105可以使用诸如专用短程通信(DSRC)、蜂窝调制解调器和短程无线电频率的车辆间协议来发送和/或接收消息。

此外，计算机105通常包括和/或通信地连接到诸如已知的用于访问OBD并确定各种OBD测试的先决条件何时满足并进行这样的测试的OBD控制器。

车辆101可以包括各种传感器115。传感器115可以链接到电子控制单元并且在CAN总线协议或如上所述的任何其他合适的协议中操作。传感器115可以发送和接收数据。传感器115可以经由例如CAN总线协议与计算机105或其他电子控制单元通信，以处理从传感器115发送或由传感器115接收的信息。传感器115可以通过任何合适的无线和/或有线方式与计算机105或其他电子控制单元通信。传感器115可以包括任何类型的摄像机、雷达单元、激光雷达单元、声纳单元、呼吸分析仪、运动检测器等等。此外，传感器115可以包括全球定位系统(GPS)接收器，该全球定位系统(GPS)接收器可以与全球定位系统卫星通信。传感器115可以测量与车辆101的运行以及周围车辆和环境相关的值。例如，传感器115可以测量车辆101的速度和位置、周围车辆106相对于车辆101的速度和位置、和/或与用于一个或多个OBD测试的先决条件相关的值，例如海拔高度、速度、燃料体积、加速度、温度等。

车辆102中的每一个通常包括计算机106、传感器116和通信总线126。元件106、116和126中的每一个类似于车辆101中的元件105、115和125，并且此外，除非本文另有说明，否则每个车辆102的运行类似于车辆101的运行。作为一个区别，如上所述，计算机105可以执行编程以识别要由跟随车辆102和车辆101执行的一个或多个OBD测试，和/或可以执行编程以指定车辆102执行一个或多个OBD测试的时间。

如上所述，车辆101和车辆102可以以队列行驶。因此，车辆101的计算机105可以包括用来提供与队列行驶和/或由一个或多个车辆102推荐的和/或所需的动作有关(例如与车辆102的速度、转向角、制动等有关)的消息的程序设计，并且车辆102的计算机106可以包括用于接收与队列行驶和/或由一个或多个车辆102推荐的和/或所需的动作有关(例如与车辆102的速度、转向角、制动等有关)的消息和按照该消息进行行动的程序设计。可以采用诸如已知的各种技术来使车辆101、102以队列行驶。

在车辆101、102中的每一个中，计算机105、106接收传感器115、116的数据并监测OBD测试的先决条件。然而，每个车辆102的计算机106可以被编程为超驰入口条件要求等以及改为基于例如由计算机106的判断而遵循来自领头车辆101的消息中的指令。计算机105可以在满足条件时启动OBD测试并且可以监测整个ODB测试的条件。计算机105可以中止OBD测试，例如，如果条件改变。车辆102计算机106可以至少部分地根据车辆101的计算机105确定启动OBD测试。

在一个示例中，车辆101、102可以在丘陵的或多山的道路上行驶，例如，在五公里的路程上具有正或负二百五十米的海拔高度变化的道路。领头车辆101的计算机105可以被编程来识别当包括车辆101、102的队列行驶500米时将满足进行特定OBD测试的条件，因为在该位置，车辆101、102将处于测试的合适的海拔高度(足够低或足够高)。因此，计算机105可以使指定开始OBD测试的时间的消息被发送给车辆102的计算机106，该特定时间是计算机105已经确定车辆101、102中的每一个将处在可以启动测试的位置的时间。计算机105还可以执行程序设计以在特定时间启动车辆101中的测试。

在另一个示例中，车辆101、102可以以低于进行特定OBD测试所需速度的速度行驶。领头车辆101可以检测到前方的交通畅通，例如，领头车辆101前面的车辆以高于特定OBD测试所需的阈值速度的速度移动。替代地或另外地，领头车辆101可以使用来自例如通过蜂窝网络等连接到远程服务器的导航系统的信息，来确定道路将要行驶的部分上的交通速度可能超过用于OBD测试的阈值。在任何情况下，一旦得出这种判断，领头车辆101可以指示跟随车辆102在特定时间进行测试，所述特定时间是计算机105已经预估车辆101、102可能将要以高于速度阈值的速度行驶的时间。

对于另外的示例，车辆101可以在具有变化的表面条件的道路上行驶。车辆101可以生成道路的表面形貌并且使用该地形来指示车辆102进行OBD测试。具体地，车辆101可确定车辆102驶过特定道路地形(例如，道路的干燥部分、道路的潮湿部分等)的时间，并且如果满足道路条件则指示车辆102进行OBD测试。

在上述示例中的一个或多个中的附加和/或替代实施方式中，计算机105可以指示跟随车辆102的计算机106进行OBD测试，即使不符合计算机106通常需要的先决条件。例如，在确定车辆101、102接近用于测试的可接受的海拔高度、速度等时，计算机105可以例如通过V2V消息指示计算机106在特定时间(其可以是在接收到消息时)执行特定测试，而不管计算机106是否确定满足测试条件，和/或计算机106可以被编程为遵循来自领头车辆101计算机105的测试指令，而不考虑并且可能不评估车辆102中的测试条件。

示例性过程

图2是用于在包括领头车辆101和一个或多个跟随车辆102的队列中测试车辆部件(例如，OBD测试)的示例性过程200的示图。在OBD数据和OBD测试的情况中通过示例性而非限制的方式对过程200进行了描述；过程200可以应用于其他类型的数据和测试中。根据在计算机105中执行的程序设计，通常在领头车辆101中执行示例性过程200的步骤。然而，将清楚的从文中得知，过程200的至少一些部分可以在下文所述的至少一些跟随车辆102的计算机106中执行。

过程200开始于方框205，其中领头车辆101的计算机105收集数据。可以以已知方式通过总线125从各种源(例如，车辆电子控制单元(ECU)、传感器115和/或可能已知的其他车辆101部件)接收所收集的数据。如已知的，收集的数据通常包括可以与用于执行一个或多个OBD测试的先决条件相比较的测量。从诸如ECU、传感器115等车辆101部件收集的数据的示例包括与车辆101正在行驶的环境(例如，环境光亮度、降水的存在或不存在、外部空气温度等)、车辆101的操作参数(例如，车辆101速度、前进方向、转向角、制动器的激活、节气门设置等)、来自传感器115和/或导航系统关于将要到来的地形的信息(例如，起伏道路、高度、曲线等的变化)相关的数据。

计算机105可以被编程为从这样的数据预测在车辆101、102的一个或多个OBD测试的持续时间期间遇到的条件，例如车辆101、102计划路线、期望的交通密度、外部空气温度、路面状况、路面摩擦、车辆101、102速度等。此外，计算机105通常存储关于要在车辆101中执行的一个或多个OBD测试的信息，例如，特定OBD测试是否要被执行、执行特定OBD测试所根据的频率等。

接下来，在方框210中，车辆101的计算机105识别要执行OBD测试的特定时间，例如，已知的在车辆101、102中进行OBD测试的时间，然后确定是否满足用于特定OBD测试的一个或多个先决条件，例如，表明是根据存储在计算机105的存储器中的数据在特定时间所需的，或在特定时间窗口内所需的测试。通常，计算机105被编程以确定在车辆101中用于特定测试的条件是否目前或被预测为在预定未来时间(例如30秒、60秒等)被满足。计算机105可以以已知方式确定测试条件是否被满足，例如通过将如上所述的总线125接收的数据与例如存储在计算机105存储器中的先决条件进行比较。此外，计算机105通常被编程为确定在一个或多个跟随车辆102中进行测试的一个或多个先决条件是否被满足。例如，计算机105可以被编程为基于速度和/或跟随车辆102的跟随距离，来确定在跟随车辆102的一些或全部中(例如，至少大多数跟随车辆102)测试的条件是否被预测为在领头车辆101的条件被满足的同时被满足。如果接收的数据指示满足测试的先决条件和/或指示在领头车辆101和在跟随车辆102(例如，队列中的车辆101、102的大部分)中满足预期持续时间的特定OBD测试(例如，如存储在计算机105的存储器中)的条件，则接下来执行方框215。否则，过程200进行到方框220。

接下来，在方框215中，车辆101的计算机105向其车辆102发送消息以从方框210执行特定的OBD测试。或者，代替车辆101的计算机105确定跟随车辆102可以开启一个或多个OBD测试并将消息发送到车辆102的计算机106以开启一个或多个OBD测试，车辆101的计算机105可以将收集的数据发送到跟随车辆102。车辆102的计算机106在受到收集的数据后，可以基于来自车辆101计算机105所收集的数据，其替代或者附加于由车辆102计算机106所搜集的数据，来确定开启一个或多个OBD测试。此外，车辆101的计算机105可以选择性地将收集的数据发送到车辆102的计算机106，例如，当计算机105已经确定了测试的条件被或者将被满足时，并且可以以这种方式至少部分地确定在跟随车辆102中OBD测试的时间和/或位置。

在方框220中，如果在一个或多个车辆101、102中不满足测试条件的情况下会到达该方框220，车辆101计算机105尝试识别对一个或多个队列车辆101、102的操作的调整，这将允许方框210中指定的测试被执行。例如，速度、加速度、主动悬架等的改变可允许执行测试。

在方框220之后，在框225中，计算机105发出消息(例如，车辆间消息)到跟随车辆102计算机106以对操作进行调整，例如以调整速度、加速度、主动悬架等。例如，因为车辆102以队列方式跟随车辆101，所以车辆102中的测试可以相对于车辆101中的一个或多个测试时间被时移，例如延迟特定时间段，例如一秒、五秒等。因此，从车辆101计算机发送到车辆102计算机106的消息可以包括时间和/或位置(例如，特定的全球定位系统坐标)，在该时间和/或位置上车辆102计算机106将开启一个或多个OBD测试。

在可以在方框215、225中的任一个之后的方框230中，车辆101、102执行一个或多个OBD测试，关于该测试，如关于框210所描述的，已经确定满足先决条件，和/或车辆101、102中的每个根据由各个车辆101、102计算机105、106至少部分地基于由领头车辆101计算机105提供和收集的数据而作出的判断来执行(或不执行)OBD测试。在执行一个或多个OBD测试期间，车辆101的计算机105和车辆102的计算机106中的至少一个监视测试条件是否继续被满足。如果不满足条件，则车辆101的计算机105和/或跟随车辆102的计算机106可以中止OBD测试。例如，计算机105、106在确定不再满足测试条件时可以终止车辆101、102的计算机105、106中的测试，并且还将车辆间消息发送给该队列中的其他车辆101、102指示中止测试。

接下来，在方框235中，车辆101、102，例如在计算机105、106的存储器中，储存测试结果；测试结果数据还可以以常规方式(例如通过诸如已知的OBD端口)被提供给车辆101、102外部和/或可以被上传到外部数据存储器，例如通过无线、蜂窝等网络访问的服务器。另外，如已知的，计算机105、106可以向车辆101的操作者发出指示OBD测试已经发现问题的一个或多个通知，例如通过由人机界面(HMI)等启动仪表板上的发动机检查灯等。

接下来，在方框235之后或在方框220之后，在方框240中，车辆101计算机105确定过程200是否应当继续。例如，如果车辆101的操作者关闭过程200的功能、如果车辆被熄火等，则过程200可以结束。在任何情况下，如果过程200不应当继续，则过程200在方框240之后结束。否则，过程200返回到方框205。

示例性场景

为了提供前述原理的说明，可以在如本文所述的车辆101、102的队列中执行的一个OBD测试是燃料箱泄漏或蒸发测试。例如，提供OBD测试以确定燃料箱是否具有小至0.04”或更大的孔。该测试被称为“巡航测试”，因为它是在车辆在道路上巡航时执行的。该试验使用真空抽空燃料箱。为了进行测试，必须满足某些入口条件，包括(提供示例而不是完整列表)环境温度在45和95华氏度之间、海拔高度小于8500英尺、车辆燃料水平在总容量的15％和85％之间。

领头车辆101计算机105存储器可以例如基于当前时间与存储在计算机105的存储器中并且与燃料箱泄露测试相关联的时间的比较来指示将要进行燃料箱泄漏测试。计算机105可以确定各种入口条件被满足，例如，满足环境温度和海拔高度条件等。然后，计算机105可以向跟随车辆102中的计算机106发送消息以在特定时间进行燃料箱泄漏测试。

此外，如上所述，计算机105可以指示车辆102在开始测试之前调整运行条件，例如，将速度增加到每小时25英里以上、保持加速度低于阈值等，和/或在测试的持续时间内保持这样的条件。此外，计算机105可以在满足条件之前对队列中的所有车辆101、102的测试进行排序。例如，车辆101可以接收传感器115的数据，该数据指示前面的车辆以每小时超过25英里的速度行驶，即使该队列目前以较慢的速度行驶。再举一个例子，导航数据和/或传感器115的数据可以指示，虽然当前在海平面以上超过8500英尺，但该队列在一分钟内将下降到低于该阈值的海拔高度。因此，计算机105可以指示车辆102开始燃料箱泄漏测试，并且可以在预期测试持续时间的大部分时间内满足条件时的较早的时间在车辆101中进行测试。

为了继续该示例，与大多数OBD测试一样，燃料箱泄漏测试与中止条件相关联，即在测试期间出现时指示应该中止测试的条件。例如，车辆高度大于8500英尺、环境温度低于45华氏度等，都是燃料箱泄漏测试的中止条件。如果在车辆101、102进行测试期间一辆或者多辆车辆101、102中出现这样的条件或多个条件，则计算机105可以指示队列中的所有车辆101、102中止测试。

结论

诸如本文讨论的那些的计算装置通常每个包括可由一个或多个诸如上面所确定的那些计算装置执行的指令，和用于执行上述过程的方框或步骤。计算机可执行指令可以由使用各种编程语言和/或技术创建的计算机程序编译或解释，包括但不限于单独或组合的Java TM、C、C++、Visual Basic、Java Script、Perl、HTML等。一般来说，处理器(例如，微处理器)例如从存储器、计算机可读介质等接收指令，并执行这些指令，从而执行一个或多个过程，包括一个或多个本文所述的过程。这样的指令和其他数据可以使用各种计算机可读介质存储和传输。计算装置中的文件通常是存储在诸如存储介质、随机存取存储器等的计算机可读介质上的数据的集合。

计算机可读介质包括参与提供可以由计算机读取的数据(例如，指令)的任何介质。这样的介质可以采取许多形式，包括但不限于非易失性介质、易失性介质等。非易失性介质包括例如光盘或磁盘和其他永久性存储器。易失性介质包括动态随机存取存储器(DRAM)，其通常构成主存储器。计算机可读介质的常见形式包括例如软盘、柔性盘、硬盘、磁带、任何其它磁介质、只读光盘存储器(CD-ROM)、数字化视频光盘(DVD)，任何其他光学介质、穿孔卡、纸带，任何其他具有孔图案的物理介质、随机存取存储器(RAM)、可编程序只读存储器(PROM)、电可编程只读存储器(EPROM)、快速电可擦可编程只读存储器(FLASH EEPROM)、任何其它存储器芯片或盒、或计算机可以从其读取的任何其它介质。

关于本文所描述的介质、过程、系统、方法等，应当理解的是，尽管这样的过程的步骤等已经被描述为根据某个有序序列发生，但是这样的过程可以以不同于本文所述顺序的顺序执行所述步骤的方式来实施。还应当理解，某些步骤可以同时执行、可以添加其他步骤或者可以省略本文所述的某些步骤。换句话说，本文所述的系统和/或过程是为了说明某些实施例的目的而提供的，并且不应被解释为限制所公开的主题。

因此，应当理解，上述说明书旨在是说明性的而不是限制性的。在阅读上述说明书之后，除了所提供的示例之外的许多实施例和用途对于本领域技术人员将是显而易见的。应当参考所附权利要求和/或包括在基于本发明的非临时专利申请中的权利要求以及这些权利要求享有的全部等同范围，而不是参考上述说明书，来确定本发明的范围。可以预料和预期的是，在本文中讨论的技术中将会出现未来的发展，并且所公开的系统和方法将被并入这些未来的实施例中。总之，应当理解，所公开的主题能够被修改和改变。