Coordinated testing in vehicle groups

Abstract

Procedure comprising: Determining, in a lead vehicle (101), that one or more conditions for a diagnostic test are met; Sending a vehicle-to-vehicle message to one or more follower vehicles (102), the message providing data to indicate to each follower vehicle to perform the diagnostic test at a specified time determined by the lead vehicle (101); and Performing the diagnostic test in the lead vehicle (101) at the specified time.

Description

BACKGROUND OF THE INVENTIONOn-board diagnostics (OBD) tests analyze vehicle operation and may identify problems with vehicle components. However, OBD tests may be performed in a delayed and / or sparse manner, as performing the OBD tests often depends on sufficient prerequisite conditions (sometimes also referred to as input conditions) before and / or during a test. Examples of OBD tests include an evaporative emissions control (EVAP) test, an exhaust gas recirculation (EGR) test, an oxygen sensor test, a catalyst heating test, to name a few. Examples of input conditions include fuel volumes between 15% and 85% capacity, ambient temperature from 40° Fahrenheit to 95° Fahrenheit, altitude below 8500 feet, vehicle speed greater than 20 miles per hour, etc.US 2010 / 0 256 852 A1 discloses a method for controlling a plurality of vehicles for operating the plurality of vehicles in a train. The method includes a lead vehicle selected from the plurality of vehicles. In the method, at least the steps of: monitoring a respective actual position of each of the vehicles other than the lead vehicle by vehicle-to-vehicle communication based on data from a respective global positioning device in each of the plurality of vehicles are carried out. determining distances to operate the plurality of vehicles in the train based on the respective current positions of each of the vehicles and selecting a respective commanded vehicle position including a respective global positioning coordinate for each of the vehicles based on the determined distances. Each respective commanded vehicle position is transmitted to the respective vehicle.U.S. Pat. No. 6,505,106 B1 discloses a method in which data sets transmitted from a plurality of vehicles are collected in a central data memory, where real-time or stack analysis and profile creation can take place in order to facilitate maintenance of the fleet of vehicles. Preferably, each data set contains data derived, time correlated, and provided with vehicle identification information by synchronizing onboard diagnostic computer outputs and three dimensional GPS location data. The data record is forwarded to the central data memory via the cellular Internet. The central data store contains analysis and profiling routines to determine immediate operating issues of a particular vehicle. The more data collected over time, the more valuable the experience database becomes and allows the fleet manager to improve its operational decisions.US 2015 / 0 206 360 A1 discloses a method for planning a vehicle diagnosis in a vehicle, comprising: estimating an operating characteristic of the vehicle on a route to be traveled by the vehicle; and planning the vehicle diagnosis on the basis of a probability that the estimated operating characteristic of the vehicle corresponds to an operating characteristic suitable for the vehicle diagnosis.Starting from this prior art, according to the invention a method according to claim 1 and a system according to claim 10 are proposed. Advantageous embodiments of the invention are evident from the dependent claims and the following description.DRAWINGSFIG. 1 illustrates an example system for OBD testing in a vehicle pack. FIG. 2 is a diagram for an example process for OBD testing in a vehicle powder.DETAILED DESCRIPTIONOverviewFIG. 1 is a block diagram of an example multi-vehicle test system, i.e., for a platoon including a lead vehicle 101 and following vehicles 102. Although the tests described herein in the examples are onboard diagnostics (OBD) system tests, the disclosed subject matter could be practiced in the context of testing systems and / or elements of other vehicles 101, 102. In general, the principles illustrated herein could be applied in any context in which vehicles 101, 102 operate in a platoon and in which a computer 105 of a lead vehicle 101 could determine whether test conditions are met for one or more of the follower vehicles 102. In any such context, the computer 105 could cause a message to be sent to one or more computers 106 of the follower vehicle 102 that include instructions to initiate a test or tests such that instructions directing execution of the test or tests supplement and / or override programming in the computer 106.A vehicle 101 includes a computer 105 coupled to or including a communication bus 125 of the vehicle 101 that is known to provide communication to the components and / or electronic control units 110 of the vehicle 101, e.g., controllers for steering, braking, throttling, etc., of the vehicle 101. The computer 105 may receive data related to the operation of the vehicle 101. The computer 105 is typically communicatively coupled to a network 130, via which the computer 105 can communicate with a server 140, which in turn is communicatively coupled to a data repository 145.The vehicle 101 is lead vehicle in a pack of vehicles that includes surrounding, typically following, vehicles 102. The vehicles 101, 102 may communicate via, for example, vehicle-to-vehicle (V2V) communication (V2V), such as dedicated short-range communications (DSRC), etc. The lead vehicle 101 may provide various instructions to the follower vehicles 102, e.g., regarding speed, acceleration, braking, steering, etc. The vehicles 101, 102 may or may not be occupied by human operators. In other words, the vehicles 101, 102 may form a pack and operate in accordance with various known systems for vehicle powdering.Further, for example, when the vehicles 101, 102 are merging on a road in a hatch, they may coordinate OBD tests. For example, the vehicle 101 computer 105 may determine when one or more prerequisite conditions, e.g., what is sometimes referred to as "input" conditions, are met in the lead vehicle 101 for an OBD test (or tests) in the vehicle 101 and / or the vehicles 102, whereupon the vehicle 101 may initiate the OBD test in the vehicle 101 and may send a message to the follower vehicles 102 to perform the test or tests. The message may specify a time and / or location (e.g., particular GPS coordinates) at which the test is to be performed in each of the vehicles 101, 102, thereby synchronizing the tests. Further, a computer 106 in a vehicle 102 may be programmed to, upon receipt of such a message from the vehicle 101, perform one or more tests even if prerequisite conditions in the vehicle 102 are not met, and / or according to modified precondition conditions in the vehicle 102, i.e., a vehicle 102 may employ the precondition conditions for a test that are modified based on relying on a message from the lead vehicle 101.Advantageously, therefore, the vehicles 101, 102 may perform OBD testing more frequently and efficiently. A risk of aborting an OBD test due to changing and / or unpredictable conditions is reduced.Example System ElementsThe vehicle 101 computer 105, which is known to include a processor and memory, may be coupled via a communication bus 125 or other known wired or wireless connections, or the computer 105 may include one or more electronic control units, e.g., controllers or the like, included in the vehicle 101 for monitoring and / or controlling various components of the vehicle 101, e.g., an engine control unit (ECU), a transmission control unit (TCU), etc. The bus 125 may be a controller area network (CAN) bus and / or any other suitable in-vehicle communication bus, such as JASPAR, LIN, SAE J1850, AUTOSTAR, MOST, etc. Electronic control units may be known to be connected to the CAN bus, for example. The vehicle 101 may also include one or more electronic control units specifically for receiving and transmitting diagnostic information, such as an onboard diagnostic connector (OBD-II). Via the CAN bus, OBD-II, and / or wired or wireless mechanisms, the computer 105 may transmit messages to various devices in the vehicle 101 and / or receive messages from the various devices, e.g., controllers, actuators, etc. Alternatively or additionally, in cases where the computer 105 actually comprises multiple devices, the CAN bus or the like may be used for communication between devices represented as the computer 105 in this disclosure, e.g., the various ECUs.The computer 105 may transmit and / or receive messages using a variety of communication protocols, e.g., the computer 105 may include or be coupled to one or more transceivers as are known to provide such communication. For example, the computer 105 may transmit and / or receive messages using a vehicle-to-vehicle protocol, such as dedicated short range communication (DSRC), cellular modem, and short range high frequency.Further, the computer 105 typically includes and / or is communicatively coupled to an OBD controller as known for accessing OBD as well as determining when prerequisite conditions are met for various OBD tests and executing such tests.The vehicle 101 may include a variety of sensors 115. The sensors 115 may be connected to electronic control units and operate within a CAN bus protocol or any other suitable protocol as described above. The sensors 115 can both transmit and receive data. The sensors 115 may be in communication with the computer 105 or with another electronic control unit, for example, via the CAN bus protocol, to process information transmitted from or received by the sensors 115. The sensors 115 may be in communication with the computer 105 or other electronic control unit in a suitable wireless and / or wired manner. The sensors 115 may include any selection from a camera, a RADAR unit, a LADAR unit, a sonar unit, a breath analyzer, a motion detector, etc. Additionally, the sensors 115 may include a Global Positioning System (GPS) receiver that may communicate with a GPS satellite. The sensors 115 may measure values related to the operation of the vehicle 101 and the surrounding vehicles and environment. For example, the sensors 115 may measure the speed and position of the vehicle 101, a speed and position of surrounding vehicles 106 relative to the vehicle 101, and / or values related to prerequisite conditions for the one or more OBD tests, e.g., elevation, speed, fuel volume, acceleration, temperature, etc.Each of the vehicles 102 typically includes a computer 106, sensors 116, and a communication bus 126. Each of the elements 106, 116, and 126 is similar to the elements 105, 115, and 125 in the vehicle 101 and, moreover, the operation of each vehicle 102 is similar to the operation of the vehicle 101 unless otherwise noted herein. As a difference, as noted above, the computer 105 may execute a program to identify one or more OBD tests to be performed by the follower vehicles 102 in addition to the vehicle 101 and / or may execute programming to specify a time when the vehicle(s) 102 perform the one or more OBD tests.The vehicle 101 and the vehicles 102 may travel in a pulk as discussed above. Accordingly, the vehicle 101 computer 105 may include programming to provide to and the vehicles 102 computers 106 may include programming to receive and respond to messages related to the travel of the vehicle and / or recommended and / or required actions of one or more of the vehicles 102, e.g., regarding speed, steering angle, brakes, etc., of the vehicles 102. Various known techniques may be employed for the vehicles 101, 102 to travel in a pulk.In each of the vehicles 101, 102, the computer 105, 106 receives data from sensors 115, 116 and monitors the prerequisite conditions for the OBD test. However, the computer 106 of each vehicle 102 may be programmed to override input condition requests or the like and instead follow instructions in a message from a lead vehicle 101, e.g., based on a determination by the computer 106. The computer 105 may initiate the OBD test when the conditions are met and may monitor the conditions across the OBD test. The computer 105 may abort the OBD test if, for example, the conditions change. The vehicle 102 computer 106 may determine, at least in part, to initiate the OBD test based on the vehicle 101 computer 105.In one example, the vehicles 101, 102 may travel on a hilly or mountainous road, e.g., a road having differences in elevation of plus or minus two hundred and fifty meters over a five kilometre distance. The computer 105 of the lead vehicle 101 could be programmed to recognize that conditions for performing a particular OBD test will be met when a log including the vehicles 101, 102 travels 500 meters because the vehicles 101, 102 will be at that location at an elevation appropriate (low enough or high enough) for the test. Accordingly, the computer 105 could cause a message to be sent to the computers 106 of the follower vehicles 102 that specifies a time at which the test is to begin, the specified time being a time at which the computer 105 determined that each of the vehicles 101, 102 will be at the location at which the test can be initiated. The computer 105 may further execute programming to initiate the test at the specified time in the vehicle 101.In another example, the vehicles 101, 102 could travel at a speed that is less than a speed needed to perform a particular OBD test. Lead vehicle 101 could detect that there is traffic in front, e.g., that vehicles are moving in front of lead vehicle 101 at a speed above the threshold speed needed for a particular OBD test. Alternatively or additionally, the lead vehicle 101 could use information from a navigation system, e.g., connected to a remote server via a cellular network or the like, to determine that traffic speeds on an emerging portion of a road will likely exceed the threshold for the OBD test. In any case, upon such a determination, the lead vehicle 101 may instruct the follower vehicles 102 to perform the test at a specified time, which is a time for which the computer 105 has estimated that the vehicles 101, 102 are likely to travel above the speed threshold.As another example, the vehicle 101 may travel on a road with changing surface conditions. The vehicle 101 may generate a surface topography of the road and use the topography to direct the vehicles 102 to perform OBD tests. In particular, the vehicle 101 may determine the time at which the vehicles 102 will travel over particular road topographies, e.g., a dry road section, a wet road section, etc., and instruct the vehicles 102 to perform the OBD tests if the road conditions are met.In an additional and / or alternative implementation in one or more of the above examples, the computer 105 could instruct the computers 106 of the follower vehicles 102 to perform an OBD test even if the prerequisite conditions that would normally be required by the computer 106 are not met. For example, upon determining that the vehicles 101, 102 are approaching an acceptable altitude, speed, etc. for a test, e.g., via a V2V message, the computer 105 could instruct the computers 106 to perform a particular test at a particular time (which could occur upon receipt of the message) regardless of whether the computer 106 determines that the test conditions are met and / or the computer 106 could be programmed to follow test instructions from the computer 105 of the lead vehicle 101 regardless of, and probably without, the conditions for the test in the vehicle 102.Example ProcessFIG. 2 is a diagram of an example process 200 for testing vehicle components, e.g., OBD testing, in a log including a lead vehicle 101 and one or more follower vehicles 102. The process 200 is described in the context of OBD data and OBD testing by way of example and not limitation; the process 200 could be applicable to other types of data and testing. Steps of the example process 200 are typically performed in the lead vehicle 101 according to programming performed in the computer 105. However, as will be apparent from the context, at least some portions of the process 200 may be performed in at least some of the computers 106 of the follower vehicles 102, as described further below.The process 200 begins in a block 205, in which the vehicle 101 computer 105 collects data. The collected data may be obtained in a known manner via bus 125 from a variety of sources, e.g., electronic control units (ECUs), sensors 115, and / or other components of vehicles 101, as may be known. The collected data is known to typically include measurements that are compared to prerequisite conditions for performing one or more OBD tests. Examples of collected data of components of the vehicle 101 such as ECUs, sensors 115, or the like include data related to an environment in which the vehicle 101 is traveling (e.g., ambient light level, occurrence or absence of precipitation, outside air temperature, etc.), operating parameters of the vehicle 101 (e.g., speed of the vehicle 101, heading, steering angle, brake activation, throttle position, etc.), information regarding emerging terrains of sensors 115 and / or a navigation system (e.g., a rough road, elevation change, turn, etc.).The computer 105 may be programmed to predict, from such data, conditions that will be met during a duration of the one or more OBD tests of the vehicles 101, 102, e.g., the planned route of the vehicles 101, 102, expected traffic density, outside air temperature, road surface conditions, road friction, speed of the vehicles 101, 102, etc. Further, the computer 105 typically stores information about one or more OBD tests to be performed in the vehicle 101, e.g., whether the particular OBD test is due to performance, a frequency according to which a particular OBD test is performed, etc.Next, in a block 210, the vehicle 101 computer 105 identifies an OBD test to be performed at a particular time, such as is known to perform OBD tests in the vehicles 101, 102, and then determines whether one or more prerequisite conditions for the specified OBD test are met, e.g., a test that is indicated as being needed at a specified time or within a specified time window according to data stored in a memory of the computer 105. Typically, the computer 105 is programmed to determine whether conditions are currently met or are likely to be met at a predetermined time, e.g., in 30 seconds, 60 seconds, etc., in the vehicle 101 for a particular test. The computer 105 may determine whether the test conditions are met in a known manner, e.g., by comparing data received over the bus 125, such as described above with respect to the prerequisite conditions stored in the memory of the computer 105. Moreover, the computer 105 is generally programmed to determine whether the one or more prerequisite conditions for a test in one or more following vehicles 102 are met. For example, the computer 105 may be programmed to determine whether conditions for the test are predicted to be met in some or all of the follower vehicle 102 or the follower vehicles 102, e.g., at least a majority of the follower vehicles 102 at the same time when the conditions are met in the lead vehicle 101, based on a speed and / or a following distance of the follower vehicle 102 or the follower vehicles 102. Next, if the received data indicates that the prerequisite conditions for a test are met and / or indicate that the conditions for an expected amount of time (e.g., as stored in memory of the computer 105) of the particular OBD test in the lead vehicle 101 and in the follower vehicle 102 or vehicles 102, such as a majority of the vehicles 101, 102 in a log, will be met, then a block 215 is executed. Otherwise, the process 200 proceeds to a block 220.Next, at block 215, the vehicle 101 computer 105 sends a message to its vehicle or vehicles 102 to perform the specified OBD test of block 210. Alternatively, instead of determining the vehicle 101 computer 105 that the follower vehicles 102 trigger the one or more OBD tests and sending the message to the vehicles 102 computers 106 to trigger the one or more OBD tests, the vehicle 101 computer 105 may send collected data to the follower vehicles 102. The vehicles 102 computers 106 may determine, upon receipt of the collected data, to trigger the one or more OBD tests based on the collected data from the vehicle 101 computer 105, instead of or in addition to data collected from the vehicle 102 computer 106. Further, the vehicle 101 computer 105 may selectively send collected data to the vehicles 102 computers 106, e.g., when the computer 105 has determined that conditions for a test are met or will be met, and in this way may determine, at least in part, a time and / or location of OBD tests in the follower vehicles 102.At block 220, which is reached when test conditions in one or more vehicles 101, 102 are not met, the vehicle 101 computer 105 may attempt to identify adjustments to operations of one or more hatch vehicles 101, 102 that would allow the test specified at block 210 to be performed. For example, a change in speed, acceleration, active suspension, etc. could allow a test to be performed.Following the block 220, in block 225, the computer 105 initiates a message, e.g., a vehicle-to-vehicle message, to computers 106 of following vehicles 102 to make adjustments to operations, e.g., to adjust a speed, acceleration, active suspension, etc. For example, as the vehicles 102 follow the vehicle 101 in the log, testing in the vehicles 102 could be time shifted, e.g., for a specified time duration, e.g., one second, five seconds, etc., relative to a time of a test or tests in the vehicle 101. Thus, the message sent from the vehicle 101 computer to the vehicles 102 computers 106 may include a time and / or location (e.g., determined GPS coordinates) at which the vehicles 102 computers 106 are to initiate the one or more OBD tests.At a block 230 that may follow both of the blocks 215, 225, the vehicles 101, 102 perform the one or more OBD tests for which, as described with reference to the block 210, it has been determined that (a) prerequisite conditions are met and / or each vehicle 101, 102 performs (or does not) an OBD test according to a determination made by the respective computer 105, 106 of the vehicle 101, 102 based at least in part on the data collected and provided by the computer 105 of the lead vehicle 101. During execution of the one or more OBD tests, at least one of the vehicle 101 computer 105 and the vehicles 102 computers 106 monitors whether the test conditions continue to be met. If the conditions are not fulfilled, the vehicle 101 computer 105 and / or the following vehicle 102 computers 106 may / may abort the OBD test. For example, upon determining that the test conditions are no longer met, a computer 105, 106 may end the test in the vehicles 101, 102 of the computer 105, 106 and also send a vehicle-to-vehicle message to other vehicles 101, 102 in the pulk indicating to abort the test.Next, at a block 235, the vehicles 101, 102 store the test results, e.g., in a memory of the computer 105, 106; test result data may also be provided externally to a vehicle 101, 102 in a conventional manner, e.g., as is known, via an OBD port and / or may be uploaded to an external data store, e.g., server access via a wireless, cellular network, etc. Additionally, as is known, a computer 105, 106 may trigger one or more notifications to an operator of the vehicle 101 indicating that the OBD test has detected a problem, e.g., by activating an engine check lamp on the dashboard, etc., via a human-machine interface (HMI), etc.Following either block 235 or block 220, the vehicle 101 computer 105 determines whether to continue the process 200 in block 240. For example, the process 200 may end if the operator of the vehicle 101 disables the function of process 200, if the vehicle is disabled, etc. In any event, the process 200 ends following the block 240 if the process 200 is not to continue. Otherwise, the process 200 returns to the block 205.Example ScenarioTo provide an illustration of the foregoing principles, an OBD test that could be carried out in a pack of vehicles 101, 102 as described herein is a fuel tank leak or evaporation test. For example, an OBD test is provided to determine whether a fuel tank has as small a hole as 0.04" or greater. The test is known as a "trip test" because it is executed when a vehicle is travelling on a road. The test uses a vacuum to evacuate a fuel tank. To run the test, certain entry conditions must be met, including (to provide examples and not a full list) an ambient temperature between 45 and 95 degrees Fahrenheit, a altitude of less than 8500 feet, and a fuel level between 15% and 85% of the total capacity.A memory of the computer 105 of the lead vehicle 101 could indicate that the fuel tank leak test is to be performed, e.g., based on a comparison of a current time to a time stored in a memory of the computer 105 and associated with the fuel tank leak test. The computer 105 could determine that various input conditions would be met, e.g., that ambient temperature and altitude conditions would be met, etc. The computer 105 could then send a message to the computers 106 in follower vehicles 102 to perform the fuel tank leak test at a specified time.Further, as described above, it is possible that the computer 105 could instruct the vehicles 102 to adjust the operating conditions, e.g., increase the speed to greater than 25 miles per hour, maintain acceleration below a threshold, etc., before the test is initiated and / or meet such conditions for a test duration. Still further, the computer 105 could command the test prior to satisfying the conditions for all vehicles 101, 102 in the platoon. For example, the vehicle 101 could receive data from the sensor 115 indicating that traffic ahead would travel at speeds above 25 miles per hour, although the hatch is currently driving at a lower speed. To take another example, navigation data and / or data from sensor 115 could indicate that the pulk, although currently above 8500 feet above sea level, would descend to a level below this threshold in one minute. Accordingly, the computer 105 could instruct the vehicles 102 to begin the fuel tank leak test and could conduct the test in the vehicle 101 pre-empting the majority of the test duration of met conditions at an earlier time.Continuing this example, the fuel tank leak test, such as most of the OBD tests, is associated with abort conditions, i.e., conditions that indicate that the test should be aborted upon occurrence during a test. For example, vehicle altitude greater than 8500 feet, ambient temperature below 45 degrees Fahrenheit, etc. are abort conditions for the fuel tank leak test. If such a condition occurs or such conditions occur while a test is being performed by the vehicles 101, 102 for one or more vehicles 101, 102, the computer 105 could instruct all of the vehicles 101, 102 in the log to abort the test.FINAL EXECUTIONComputing devices such as those discussed herein generally each include instructions executable by one or more computing devices such as those identified above and for executing blocks or steps of processes described above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and / or technologies, including, without limitation, and either alone or in combination, Java™ C, C++, Visual Basic, Java Script, Perl, HTML, etc. In general, a processor (e.g., a microprocessor) receives instructions from, for example, a memory, a computer readable storage medium, etc., and executes these instructions while executing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer readable media. A file in a computing device is generally a collection of data stored in a computer readable medium such as a storage medium, random access memory, etc.A computer-readable medium includes any medium that participates in providing data (e.g., instructions) that may be read by a computer. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, etc. Non-volatile media includes, for example, optical or magnetic disks and other persistent storage. Volatile media includes dynamic random access memory (DRAM) which typically constitutes main memory. Common forms of computer readable media include, for example, a floppy disk, a floppy disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a flash EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.With respect to the media, processes, systems, methods, etc. described herein, it should be appreciated that although the steps of such processes, etc. have been described as occurring according to a particular ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. Furthermore, it should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the present descriptions of systems and / or processes are provided for the purpose of illustrating certain embodiments and should not be construed in any way as limiting the disclosed subject matter.Accordingly, it is to be understood that the above description is not intended to be limiting, but is intended to be illustrative. Many embodiments and applications other than the examples given would become apparent to those skilled in the art upon review of the above description. The scope of the invention should not be determined with reference to the above description, but should instead be determined with reference to the claims appended hereto and / or included in a final patent application based thereon, along with the full scope of equivalents to which these claims are entitled. It is anticipated and intended that future developments will occur in the art discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In summary, it should be understood that the disclosed subject matter may be modified and modified.

Claims

A method comprising: determining, in a lead vehicle (101), that one or more conditions for a diagnostic test are met; sending a vehicle-to-vehicle message to one or more follower vehicles (102), the message providing data for display to each follower vehicle, performing the diagnostic test at a specified time determined by the lead vehicle (101); and performing the diagnostic test in the lead vehicle (101) at the specified time.The method of claim 1, further comprising providing operating instructions to the one or more follower vehicles (102) from the lead vehicle (101).The method of claim 1, wherein the data includes an instruction to perform the diagnostic test at a specified time.The method of claim 1, wherein the data includes an instruction to indicate at least one of the follower vehicles (102), modify operations of the at least one of the follower vehicles (102), and an instruction to the at least one of the follower vehicles (102) to modify a diagnostic test log of the diagnostic test.The method of claim 1, wherein the data includes information about a road in front of the lead vehicle (101).The method of claim 1, wherein the data includes a lead vehicle sensor measurement.The method of claim 1, wherein the conditions comprise an ambient temperature and / or a fuel volume and / or a vehicle speed and / or a vehicle acceleration.The method of claim 1, further comprising sending a second vehicle-to-vehicle message from the lead vehicle (101) to the one or more follower vehicles (102) instructing the one or more follower vehicles (102) to suspend the diagnostic test.The method of claim 1, wherein the diagnostic test is an onboard diagnostics (OBD) test.A system comprising: a vehicle computer (105) comprising a processor and memory, the memory storing instructions executable by the processor for: determining, in a lead vehicle (101), that one or more conditions for a diagnostic test are met; sending a vehicle-to-vehicle message to one or more follower vehicles (102) at a specified time, the message providing data for display for each follower vehicle (102) to perform the diagnostic test at a specified time determined by the lead vehicle (101); and performing the diagnostic test in the lead vehicle (101) at the specified time.The system of claim 10, wherein the computer (105) is further programmed to provide operating instructions to the one or more follower vehicles (102) from the lead vehicle (101).The system of claim 10, wherein the data includes an instruction to perform the diagnostic test at a specified time.The system of claim 10, wherein the data includes an instruction to at least one of the follower vehicles (102) to modify operations of the at least one of the follower vehicles (102), and an instruction to the at least one of the follower vehicles (102) to modify a diagnostic test log of the diagnostic test.The system of claim 10, wherein the data includes information about a road in front of the lead vehicle (101).The system of claim 10, wherein the computer (105) is further programmed to receive diagnostic test results from one or more of the following vehicles (102).The system of claim 10, wherein the data includes a lead vehicle sensor measurement.The system of claim 10, wherein the conditions comprise an ambient temperature and / or a fuel volume and / or a vehicle speed and / or a vehicle acceleration.The system of claim 10, wherein the computer (105) is further programmed to send a second vehicle-to-vehicle message from the lead vehicle (101) to the one or more follower vehicles (102) instructing the one or more follower vehicles (102) to suspend the diagnostic test.The system of claim 10, wherein the diagnostic test is an onboard diagnostics (OBD) test.

Images