CA2996546A1 - Devices, systems and methods for vehicle monitoring and platooning - Google Patents

Abstract

Systems and methods for coordinating and controlling vehicles, for example heavy trucks, to follow closely behind each other, or linking to form a platoon, in a convenient, safe manner and thus to save significant amounts of fuel while increasing safety. In an embodiment, on-board controllers in each vehicle interact with vehicular sensors to monitor and control, for example, relative distance, relative acceleration/deceleration, and speed. Various data is supplied by the vehicle's onboard systems to a Network Operations Center, and, in some embodiments, suggestions of vehicles for platooning are received from the NOC based on travel forecasts and an analysis of the relevant roadways to identify platoonable roadway segments. The NOC can also provide traffic, roadway, weather or system updates as well as various instructions. In some embodiments, a mesh network capability is provided for ensuring improved communication among vehicles and with the NOC.

Description

DEVICES, SYSTEMS AND METHODS
FOR VEHICLE MONITORING AND PLATOONING
Inventors:
Joshua P. Switkes Mountain View, CA ¨ US Citizen Joseph Christian Gerdes Los Altos, CA ¨ US Citizen Charles E. Price Los Altos, CA ¨ US Citizen Brian Smartt Los Gatos, CA ¨ US Citizen David F. Lyons Palo Alto, CA
Ganymed Stanek Palo Alto, CA
Austin Schuh Los Altos, CA
Michael O'Connor Redwood City, CA

CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a conversion of U.S. Patent Application S.N.
62/210,374, filed 8/26/2015. Further, this application is a continuation-in-part of PCT Application PCT/U514/30770, filed March 17, 2014, which is a conversion of U.S. patent application S.N. 61/792,304, filed March 15, 2013, and further is a continuation-in-part of S.N. 14/292,583, filed May 30, 2014, which is a divisional application of S.N. 13/542,622, filed July 5, 2012, now U.S. Patent No. 8,744,666, which in turn is a conversion of Provisional Application S. No. 61/505,076, filed on July 6, 2011, all entitled " Systems and Methods for Semi-Autonomous Vehicular Convoying". Further, this application is a continuation-in-part of S.N. 13/542,627, filed July 5, 2012, which in turn is also a conversion of S.N. 61/505,076, filed July 6, 2011.
Applicant claims the benefit of priority of each of the foregoing applications, all of which are incorporated herein by reference.
FIELD OF THE INVENTION

[0002] This application relates generally to methods, systems and devices that improve safety, diagnostics, analytics and fuel savings systems for vehicles, including but not limited to enabling at least a second vehicle to follow, safely, a first vehicle at a close distance in an automated or semi-automated manner. More particularly, the present invention relates to mesh networks, vehicle monitoring and control systems, and vehicle routing systems which achieve the foregoing objectives.
BACKGROUND

[0003] The present invention relates to systems and methods for enabling vehicles to closely follow one another safely through partial automation. Following closely behind another vehicle has significant fuel savings benefits, but is generally unsafe when done manually by the driver.
Currently the longitudinal motion of vehicles is controlled during normal driving either manually or by convenience systems. Convenience systems, such as adaptive cruise control, control the speed of the vehicle to make it more pleasurable or relaxing for the driver, by partially automating the driving task.
These systems use range sensors and vehicle sensors to then control the speed to maintain a constant headway to the leading vehicle. In general these systems provide zero added safety, and do not have full control authority over the vehicle (in terms of being able to fully brake or accelerate) but they do make the driving task easier, which is welcomed by the driver.

[0004] During rare emergencies, the acceleration and braking of a vehicle may be controlled by active safety systems. Some safety systems try to actively prevent accidents, by braking the vehicle automatically (without driver input), or assisting the driver in braking the vehicle, to avoid a collision.
These systems generally add zero convenience, and are only used in emergency situations, but they are able to fully control the longitudinal motion of the vehicle.

[0005] Manual control by a driver is incapable in several ways of matching the safety performance of even the current systems. First, a manual driver cannot safely maintain a close following distance. In fact, the relatively short distances between vehicles necessary to get any measurable fuel savings results in an unsafe condition if the vehicle is under a driver's manual control, risking a costly and destructive accident. Further, the manual driver is not as reliable at maintaining a constant headway as an automated system.
Additionally, a manual driver, when trying to maintain a constant headway, generally causes rapid and large changes in command (accelerator pedal position for example) which result in a loss of efficiency.

[0006] It is therefore apparent that an urgent need exists for at least reliable and economical semi-automated vehicular convoying systems. These improved semi-automated vehicular convoying systems enable vehicles to follow closely together in a safe, efficient, convenient manner.

[0007] For successful platooning of vehicles, careful selection of routing is also necessary. While various mapping algorithms have been developed which describe highways and other roads, heretofore routing appropriate for platooning has not been developed. As a result, there has been an equally urgent need to develop methods and systems for identifying appropriate sections of roadway over which platooning of vehicles, including tractor-trailer rigs, can be safely conducted.
SUMMARY

[0008] The system and methods comprising various aspects of the invention described herein combine attributes of state of the art convenience, safety systems and manual control to provide a safe, efficient convoying, or platooning, solution. The present invention achieves this objective by combining elements of active vehicle monitoring and control with communication techniques that permit drivers of both lead and trailing vehicles to have a clear understanding of their motoring environment, including a variety of visual displays, while offering increased convenience to the drivers together with the features and functionality of a manually controlled vehicle.

[0009] To achieve the foregoing and in accordance with the present invention, systems and methods for semi-automated vehicular convoying are provided. In particular the systems and methods of the present invention provide for, among other things: 1) a close following distance to save significant fuel; 2) safety in the event of emergency maneuvers by the leading vehicle; 3) safety in the event of component failures in the system or either vehicle; 4) an efficient mechanism for identifying partner vehicles with which to platoon, as well as identifying sections of road suitable for safe platooning, 5) an intelligent ordering of the vehicles based on several criteria; 6) other fuel economy optimizations made possible by the close following; 7) control algorithms to ensure smooth, comfortable, precise maintenance of the following distance appropriate for the operating environment and the vehicles in the platoon; 8) robust failsafe mechanical hardware onboard the vehicles;
9) robust electronics and communication; 10) robust, diverse forms of communication among the vehicles in and around the platoon for the benefit of the driver and for ensuring regular, reliable communications with a network operations center such as maintained by a fleet manager; and 11) assistance in preventing other types of accidents unrelated to the close following mode.

[0010] It will be appreciated by those skilled in the art that the various features of the present invention described herein can be practiced alone or in combination. These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order that the present invention may be more clearly ascertained, some embodiments will now be described, by way of illustration, with reference to the accompanying drawings, in which:

[0012] Figures 1A-1C show a lead vehicle and a following or trailing vehicle at the three stages of platooning in accordance with the invention:
available, linking, linked.

[0013] Figure 2 shows an embodiment of the forward-looking view seen by the trailing vehicle.

[0014] Figure 3 shows a variety of communications links between platooning vehicles, ancillary vehicles, wireless transceivers, and a network operations center.

[0015] Figure 4 illustrates a variety of factors that a central server, such as maintained at a NOC, might consider in determining candidates for linking.

16 [0016] Figure 5A illustrates in simplified form an embodiment of a control system onboard a vehicle for managing communications as well as monitoring and controlling various vehicle functions.

[0017] Figure 5B illustrates in simplified form an algorithm, operating on the onboard control system of Figure 5A, by which a lead vehicle issues commands to and receives data back from a proximately-located following vehicle.

[0018] Figure 6 illustrates in simplified form a variety of types of messages sent between the NOC and the vehicles, together with simplified architectures for the onboard system and the NOC.

[0019] Figure 7A illustrates in block diagram form the operation of a platooning supervisor system, comprising a vehicle monitoring and control system in combination with one or more software layers, in accordance with an embodiment of the invention.

[0020] Figure 7B illustrates in greater detail an embodiment of the processors, sensors and actuators of the vehicle monitoring and control system of Figure 7A, together with the associated software layers.

[0021] Figure 8A illustrates in greater detail the Platooning Supervisor Layer of Figure 7A. Figure 8B illustrates, from a software functionality perspective, the operation of an embodiment of the vehicle control system of the present invention.

[0022] Figure 9 illustrates in flow diagram form an embodiment of a vehicle data processing main loop in accordance with the invention.

[0023] Figure 10 illustrates in flow diagram form an embodiment of NOC-vehicle communications management.

[0024] Figures 11A-11B illustrates a long range coordination aspect of the present invention, including a geofencing capability.

[0025] Figures 12A-12B illustrate in flow diagram form an embodiment of a process for coordination and linking in accordance with the invention, including consideration of factors specific to the vehicles.

[0026] Figure 13 illustrates an embodiments of software architecture suited to perform the travel forecasting function that is one aspect of the present invention.

[0027] Figure 14 illustrates in flow chart form an embodiment of a sequence for platoon pairing discovery and monitoring.

[0028] Figure 15A illustrates in flow chart form an embodiment of an aspect of the invention by which platoonable road segments are identified.

[0029] Figure 15B illustrates in flow diagram form a process for identifying potential platoon partners.

[0030] Figures 16A-16E illustrates an embodiment of a process for segmenting a roadway for purposes of identifying sections where platooning can be authorized, and the resulting platooning routing for a pair of vehicles.

[0031] Figure 17Aillustrates an embodiment for analyzing platoon cost-benefit.

[0032] Figure 17B illustrates an embodiment of rendezvous analysis and guidance based on velocity and heading of a pair of potential platoon partners.

[0033] Figure 18 illustrates is block diagram form a processor-based system for capturing and calculating metrics associated with platooning.
DETAILED DESCRIPTION OF THE INVENTION

[0034] The present invention will now be described in detail with reference to several embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention, including the description of a plurality of different aspects of the invention, including, in some cases, one or more alternatives. It will be apparent to those skilled in the art that the invention can be practiced without implementing all of the features disclosed herein. The features and advantages of embodiments may be better understood with reference to the drawings and discussions that follow.

[0035] The present invention relates to systems and methods for automated and semi-automated vehicular convoying. Such systems enable vehicles to follow closely behind each other, in a convenient, safe manner.
For convenience of illustration, the exemplary vehicles referred to in the following description will, in general, be large trucks, but those skilled in the art will appreciate that many, if not all, of the features described herein also apply to many other types of vehicles and thus this disclosure, and at least some of the embodiments disclosed herein, is not limited to vehicles of any particular type.

[0036] Referring first to Figures 1A-1C, the three stages of a platoon can be appreciated. In Figure 1A, vehicle A, indicated at 100, and vehicle B, indicated at 105, are operating independently of one another, but each is available for linking. In some embodiments, the displays shown at 110 and 115, for vehicles A and B, respectively, illustrate status, distance from a candidate partner vehicle, and fuel consumption, in some instances, although other data can also be displayed as will be better appreciated hereinafter. In Figure 1B, vehicles A and B are sufficiently proximate to one another that linking, or a merge into a platoon, is allowed. As explained in greater detail hereinafter, candidates for linking are typically selected at a network operations center, such as, for example, a fleet management center if the vehicles are large trucks. In such an embodiment, the NOC sends to each vehicle a message identifying suitable candidates for linking, together with information to facilitate both drivers reaching a target rendezvous point at the same time so that they can form a platoon.

[0037] Thus, referring again to Figure 1B, vehicles A and B have at this point been guided to a rendezvous point on a section of roadway suitable for platooning. As discussed in U.S. Patent No. 8,744,666, incorporated herein by reference, and also as discussed in greater detail hereinafter, when the two vehicles are sufficiently proximate, a communications link is established between them, and a processing system resident in the front, or lead, truck, begins communicating with a similar processing system in the back, or follow, truck. In an embodiment, the lead truck then issues commands to the processing system of the follow truck to control, for example, the acceleration and braking of the follow truck and bring it into position at a close following distance behind the lead truck. In an embodiment, the processor in the lead truck also controls the acceleration and braking of the lead truck to ensure that the follow truck can be guided safely into position behind the lead truck but at a close following distance, for example in the range of 10 feet to 60 feet.

[0038] Once the follow truck has been guided into platooning position, the lead vehicle maintains control of at least the acceleration and braking of the following truck. At this point, the vehicles are linked, as shown in Figure 10. However, in at least some embodiments, the driver of the rear vehicle remaining in control of steering, such that the rear vehicle is operated only in a semi-automated manner. In other embodiments, fully automated operation of the rear vehicle is implemented. It will be appreciated by those skilled in the art that semi-automated and automated are sometimes referred to as semi-autonomous and autonomous.

[0039] When linked, the view from the front of the rear vehicle is as shown in Figure 2, again using large trucks as an example for purposes of illustration only. The lead truck 200 is immediately in front of the follow truck, and a display 210 shows the view from a forward-facing camera mounted on the lead truck. In some embodiments, haptic or audio devices can be implemented to ensure that the driver of the follow truck stays substantially directly behind the lead truck while platooning. For example, should the driver of the follow vehicle veer out of the lane to the left, an audio signal on the left side can be activated to assist the driver in returning the vehicle to the proper alignment with respect to the lead vehicle. Similarly, should the driver of the follow vehicle veer out of the lane to the right, an audio signal on the right side can be activated. In some embodiments, which audio signal is activated can be reversed; that is, a veer to the left can activate the right audio signal, and vice versa. Should a haptic stimulus be preferred, a pair [right and left] of vibration sources can be implemented either in the steering wheel, or the driver's seat, or both. Alternatively, a single vibration source can be used in some embodiments.

[0040] When the vehicles are in platoon formation, a short range communications link such as DSRC is adequate for communicating messages between the processors of each truck, although other forms of wireless communication can be used, for example, cellular. However, even while in platoon formation, it is useful for the vehicles to maintain regular communication with the NOC. As will be discussed in greater detail hereinafter, a variety of data is sent from each truck to the NOC, including truck condition and performance, route changes, local weather, and other data. This permits the fleet operator to proactively manage truck maintenance and repair, adjust routing for weather problems or road construction, identify vehicle location in the event of an emergency, and manage a variety of other analytics.

[0041] Figure 3 illustrates an embodiment of communications links for managing messaging in a system according to the invention. More specifically, Figure 3 illustrates an embodiment using a variety of communications protocols for managing messaging among potential or actual platoon partners, one or more associated NOC's, a wireless access point which provides remote access to the NOC's. Further, in instances where communication with the NOC is unavailable for a period of time, Figure 3 illustrates an embodiment of a mesh network by which messages can be communicated between the NOC and a vehicle through intermediary vehicles.
More particularly, vehicle 100 is in communication with platoon partner vehicle 105 via DSRC or other suitable wired or wireless technologies, as illustrated at 300. In addition, for most of vehicle 100's route, it is also in communication with NOC 310 via a cellular link 320. Similarly, vehicle 105 communicates with NOC 310 via a cellular link 320, absent a break in the wireless link.

[0042] However, cellular communication is not always possible, especially in vehicles driving long distances through varied terrain. Further, cellular is relatively slow for transfer of large amounts of data, such as may be stored on the vehicle if video recording or other high bandwidth functions are used. Thus, in some embodiments vehicles 100 and 105 are also equipped to access WiFi hotspots 330, which in turn communicate with the NOC
through either a wireless link illustrated at 340, or wired channel illustrated at 350. Fixed WiFi hotspots are increasingly ubiquitous along the roadway, as well as at fleet operations centers. In addition, WiFi hotspots in vehicles based on 4G LTE or similar services have been introduced. Microcell and similar technologies can also provide a communications link in some instances.

[0043] In some embodiments a relay technique based on an ad hoc mesh network can be used. For example, suppose vehicle 100 is traveling east, and just passed through an area of good cellular connectivity to the NOC 300 but is now passing through a zone that has no wireless connectivity.
Suppose, too, that vehicle X, shown at 360 is traveling west, and has been out of contact with the NOC for some period of time, but will regain wireless connectivity sooner than truck 100. In at least some embodiments, the NOC
310 knows with reasonable precision the location of each of the vehicles that it monitors based on travel forecasts, discussed in greater detail hereinafter, even when cellular or similar links are unavailable. Thus, if NOC 310 needs to send information to vehicle X, the NOC sends to vehicle 100 the message for vehicle X while vehicle 100 still has connectivity to the NOC. Then, when vehicle 100 and vehicle X are proximate, vehicle 100 relays the NOC's message to vehicle X. Similarly, if vehicle 100 needs to get data to the NOC, but is presently out of touch with the NOC, it can relay its data to vehicle X, and vehicle X retransmits the data to the NOC when vehicle X regains connectivity to the NOC.

[0044] It will be appreciated by those skilled in the art that, in some embodiments although possibly not in others, such wireless messaging will be encrypted for security purposes. With appropriate safeguards, vehicles not within the management of the fleet operation can also be used to relay messages. For example vehicles Y and Z, shown at 370 and 380, can receive messages from Vehicles A and B via link 390 and then relay them to NOC 310 if properly equipped for communication with the NOC, which can be by means of a standard protocol. In an environment having a sufficient quantity of vehicles equipped for wireless connectivity, a mesh network is created by which messages can be passed from vehicle to vehicle and thence to the NOC. Such a mesh network also permits the passing of status messages from vehicle to vehicle, so that, for example, the platoon of vehicles 100 and 105 is aware of the status of surrounding vehicles. For example, the platoon may be informed of where the car on the left needs to exit the roadway, which, for example, permits the platoon to avoid having that car cut in between vehicles 100 and 105 or otherwise behave in an unexpected manner. Likewise, emergency conditions can be communicated to the platoon, comprised of Vehicles A and B, well in advance, permitting increased operational safety.

[0045] With the foregoing understanding of platooning and communications across the network and from vehicle to vehicle, the operation of the central server that, in at least some embodiments, directs and monitors the vehicles 100, 105, etc., can be better appreciated. With reference next to Figure 4, the central server and some of its inputs can be seen in simplified block diagram form. The central server 400, either alone or in combination with the system onboard each vehicle 410, 420, makes decisions and suggestions either for platooning or simply for improved operation, based on knowledge of one or more of vehicle location, destination, load, weather, traffic conditions, vehicle type, trailer type, recent history of linking, fuel price, driver history, and other factors, all as shown at 430A-n. The central server and the onboard systems both communicate with the driver through display 440. Those communications can involve linking suggestions, road conditions, weather issues, updated routing information, traffic conditions, potential vehicle maintenance issues, and a host of other data. In some instances, a linking opportunity may present itself independently of the central server. In such an instance, once the pairing is identified that potential pairing is communicated to at least the onboard system and, in most instances although not necessarily all, also communicated to the central server. It is possible that either the central server or the on-board systems will conclude that the pair is not suitable for linking, and linking is disabled as shown at 450.

[0046] As discussed in pending PCT application PCT/US14/30770, filed March 17, 2014, linking opportunities can be determined while the vehicles are moving, but can also be determine while one or more of the vehicles is stationary, such as at a truck stop, rest stop, weigh station, warehouse, depot, etc. They can also be calculated ahead of time by the fleet manager or other associated personnel. They may be scheduled at time of departure, or hours or days ahead of time, or may be found ad-hoc while on the road, with or without the assistance of the coordination functionality of the system.

[0047] As noted above, much of the intelligence of the overall system can reside in either the central server, or in the system onboard each vehicle.
However, the onboard system includes specific functions for controlling the operation of the vehicle. For example, for large trucks as well as for most vehicles, the onboard system receives a variety of inputs reflecting immediate operating conditions and, based on those plus relevant information received from the central server, controls the vehicle in terms of at least acceleration/
velocity, and braking. Thus, as shown in Figure 5A, an embodiment of an onboard system comprises a control processor 500 that receives inputs from, for example, an onboard radar unit 505, a video camera 510, and a lidar unit 515 via connection (a), typically but not necessarily a CAN interface. The control processor can configure each of these units and receive data.
Connection (b) to inertial measurement sensors or gyros 520, which can be wireless, gives the control processor acceleration information in 1, 2 or 3 axes as well as rotation rate information about 1, 2 or 3 axes. In some embodiments, accelerometers can be substituted for gyros, although gyros are generally used for, for example, rotation rate. A plurality of data links 530, shown at (c) and expanded to show detail at the lower portion of Figure 5A, provides information about relevant characteristics of the leading truck 100, including its acceleration, or is used to provide the same or similar information to the following truck 105. The brake valve and sensor 550, connected on bus (d), provides data on brake pressure, and is used to apply pressure via a command from the control processor 500. The accelerator command 555 is sent via an analog voltage or a communications signal (CAN or otherwise).

[0048] The control processor performs calculations to process the sensor information, information from the GUI, and any other data sources, and determine the correct set of actuator commands to attain the current goal (example: maintaining a constant following distance to the preceding vehicle).

As shown there, the data links include one or more wireless links 535 such as cellular, DSRC, etc. The data links 530 also comprise inputs from the vehicle, shown at 540, which are typically transmitted via the vehicle's engine control unit, or ECU, indicated at 545 and typically provided by the vehicle manufacturer. Depending upon the embodiment, the control processor communicates bi-directionally with the various input devices.

[0049] The operation of the onboard system, or vehicle control unit, of the present invention can be better appreciated from Figure 5B, which shows, for an embodiment, the general flow between the vehicle control units of two linked vehicles. Depending upon the embodiment, two modes of operation are typically implemented: in a first mode, the front truck's control unit issues commands to the back truck's control unit, and those commands are, in general, followed, but can be ignored in appropriate circumstances, such as safety. In a second mode, the front truck's control unit sends data to the second truck, advising the trailing truck of the data sensed by the lead truck and the actions being taken by the lead truck. The second truck's control unit then operates on that data from the front truck to take appropriate action. As shown at 560, the following or trailing truck sends data about its operation to the front or lead truck. At 565, the lead truck receives the data from the trailing truck, and senses motion and/or external objects and/or communication inputs. The lead truck then decides upon actions for the lead truck, shown at 570, and, if operating in the first mode, also decides upon actions for the back truck, shown at 575. Then, depending upon whether operating in first or second mode, the lead truck either sends commands (580) to the trailing truck (first mode), or sends data (585) to the trailing truck (second mode). If operating in the first mode, the second truck receives the commands and performs them at 590, with the caveat that the second truck can also chose to ignore such commands in some embodiments. If operating in the second mode, the second truck receives the data at 595, and decides what actions to perform. Because the control programs for both units are, in some embodiments, the same, in most cases the resulting control of the second truck will be identical regardless of operating mode. Finally, the second truck communicates to the front truck what actions it has taken, shown at 600, so that each truck knows the state of the other. It will be appreciated by those skilled in the art that the control programs need not be the same for both vehicles in every embodiment.

[0050] In at least some embodiments, the above process is repeated substantially continually, for example, once per second, to ensure that each truck has the current state of the other truck, and the NOC has current status for both, thus assisting in ensuring safe and predictable operation of each truck even when operating in close-order formation at highway speeds.

[0051] In addition to the foregoing inputs to the control processor of the onboard system, in some embodiments various warnings and alerts can be implemented as inputs to either the control processor or a separate warnings and alerts processor, as described in greater detail in PCT Application PCT/US14/30770, filed March 17, 2014. Likewise, and also as described in the same PCT Application, a brake check process can be implemented both to ensure that the vehicle brakes are working correctly and to help determine which vehicle should lead, as the vehicle with the better brakes will usually be positioned as the follow vehicle, all other parameters being equal.

[0052] In at least some embodiments, reliably safe platooning involves a collaboration between the NOC and the onboard system. Thus, referring to Figure 6, the interaction between the functionalities provided by the NOC and the operation of the onboard system can be appreciated at a high level. For purposes of establishing a platoon, the NOC 601, which resides in the cloud in at least some embodiments, comprises, in simplified terms, a link finder function 605, a link approver function 610, and a logger function 615. The outputs of the functions are conveyed through a communication gateway 620 to the onboard system 625. The onboard system 625 receives from the NOC
601 information about vehicle pairings that the NOC has determined to have linking potential, followed by linking authorizations at the appropriate time, indicated at 630. In addition, the onboard system receives hazard advisories, indicated at 635, which in general comprise hazards to the vehicle based upon the projected route of travel.

[0053] The onboard system 625 comprises, from a functional standpoint, one or more electronic control units, or ECU's, which manage various functions as more specifically described in connection with Figure 7A.

For the sake of simplicity of explanation, in Figure 6 only a data ECU is shown, and it provides for message handling and communications management. It will be appreciated by those skilled in the art that the ECU
function can be implemented in a separate device, or can be integrated into a ECU which also provides other functions. It will be appreciated that, in most instances, an ECU as described herein comprises a controller or other processor, together with appropriate storage and other ancillaries to execute program instructions of the type discussed in greater detail as discussed herein and particularly beginning with Figure 7A.In an embodiment, the data ECU 640 manages the WiFi, LTE and Bluetooth interfaces, indicated at 645, 650 and 655, respectively, and in turn communicates bidirectionally with a platoon controller ECU function 660. The platoon controller ECU function in turn communicates bidirectionally with other platoon candidates and members via a DSRC link 665, and also outputs data to the driver's display 670.

[0054] In at least some embodiments, the onboard ECU function communicates with the vehicle's CAN bus 730 which provides connection to a platoon controller 675, log controller 680, driver interface 685. The ECU also provides back to the NOC reports of vehicle position and health, or "breadcrumbs", at a rate of approximately once per second, as indicated at 697. In addition, when a data link with suitable high bandwidth and low cost is available, such as WiFi, the ECU dumps its log to the NOC, as indicated at 699. Depending upon the embodiment, the log can comprise all data, including video information, or can comprise a subset of that data. For example, in an embodiment, the log dump can comprise some or all CAN bus data including SAE J1939 data, some or all radar, LIDAR and video data, some or all GPS data, some or all DSRC data, and some or all status data for both radio systems. It will be appreciated by those skilled in the art that not all such data is transmitted on the CAN bus, and instead may be communicated via an Ethernet connection, a point-to-point connection, or other suitable communications link.

[0055] Referring next to Figure 7A, an embodiment of a system in accordance with the invention is shown in a simplified form of schematic block diagram showing a hardware layer and the software layers that cause the hardware layer to perform the inventive functions. In particular, Vehicle Monitoring and Control System 700 comprises one or more processors and related hardware as further described in connection with Figure 7B et seq.
The System 700 provides data to and executes instructions from Vehicle Control Layer 705 via channel 705A and also provides data to and executes instructions from Platooning Supervisor Layer 710 via channel 710A. In addition, Platooning Supervisor Layer 710 also communicates with the Vehicle Control Layer 705 via channel 710B. It will be appreciated by those skilled in the art that layers 705 and 710 are software layers, executing on the hardware of the hardware layer shown as System 700.

[0056] The hardware components that comprise the Vehicle Monitoring and Control System 700, and their interoperation with software layers 705 and 710, can be better appreciated from Figure 7B. More specifically, in an embodiment, the Vehicle Monitoring and Control System comprises one or more Electronic Control Units (ECU's) that receive inputs from various sensors and provide outputs to various actuators and other devices comprising, for example, the driver HMI and cell and DSRC transceivers, under the control of the Vehicle Control Layer 705 and Platooning Supervisor Layer 710. The System 700 also communicates with the Driver 715 over a connection 715A. The System 700 also communicates with a NOC 720, usually over a wireless link such as shown by cell tower 720A.

[0057] While a single ECU can perform all of the functions necessary in at least some embodiments of the invention, most modern vehicles have a plurality of ECU's, with each being assigned a specialty. Thus, as shown in the embodiment illustrated in Figure 7B, a plurality of ECU's 725A-725N
comprise the core of the System 700 and communicate with one another on bus 730 which can be, in at least some embodiments, a CAN bus although, depending upon the particular device being linked, the bus 730 can be a different type of bus or even a point-to-point connection. In an embodiment, the ECU's 725A-725N, which are merely representative and are not intended to represent an exhaustive list, receive inputs from video sensors 735, GPS

device(s) 740, trailer sensors 745, hazard sensors 750, and tractor sensors 755. Depending upon the embodiment, fewer, more or different sensors can be used. The bus 730 also permits the ECU's to transmit control signals to tractor actuators 760, to provide data to and receive inputs from the driver via HMI 765, and to manage Cell and DSRC transceivers 770 and 775, respectively. Further, the bus 730 provides a link by which data from the various sensors and ECU's can be stored on Data Storage 780. The various ECU's 725A-N can comprise, among others. Radar ECU 725A, Braking/Stability ECU 725B, Adaptive Cruise Control ECU 725C, Platooning ECU 725D, Data Collection ECU 725E, HMI ECU 725F, DSRC ECU 725G, Engine ECU 725H, Dashboard ECU 7251, Chassis ECU 725J, transmission ECU 725K. Other tractor ECU's can also be implemented, as shown at 725M, and other trailer ECU's can similarly be implemented as shown at 725N. It will be appreciated by those skilled in the art that the software comprising the vehicle control layer and the platooning supervisor layer can be distributed across one, some, or all such ECU's.

[0058] Referring next to Figure 8A, the Platooning Supervisor Layer and its interaction with the Vehicle Monitoring and Control System 700 can be appreciated in greater detail. Except for the System 700, Figure 8A
illustrates various software functionalities of an embodiment of the present invention.
The Driver HMI functionality, indicated at 765, interacts directly with the vehicle driver, and presents to the driver information from the System 700 as well as the Platooning Supervisor Layer as well as serving as the input mechanism for the Driver's commands and choices, for example, selections of a linking partner, or acceptance by the driver of an offered link.

[0059] The NOC Communications Manager 800 establishes and maintains a secure communication link between the vehicle and the NOC, and provides the mechanism for passing messages reliably to and from the NOC. The NOC Communications Manager receives inputs from the Vehicle Monitoring function 805, the Hazards Monitoring function 810, the Software Update Management function 815, and the NOC itself.

[0060] The Vehicle Monitoring functionality 805 samples and filters the vehicle state from any of the sources connected to the bus 730, based on requests from the NOC 720. The NOC 720 specifies what information is to be provided, and at what interval, or frequency, and also specifies how the data is to be processed before being communicated back to the NOC.
Alternatively, local processing can replace the NOC. The Hazards Monitor 810 "listens" on the Bus 730 for vehicle faults and communicates relevant vehicle faults to the NOC. The Hazards Monitor 810 also receives hazard alerts from the NOC, and, based on its inputs including vehicle status and environmental conditions, makes a local determination on whether to override a platooning authorization. The Hazards Monitor provides an Authorization Override to Authorization Management function 820, and also sends a hazards warning to the driver via HMI Services function 840. The Software Update Manager 815 responds to version queries and provides the mechanism by which software on the vehicle can be remotely upgraded.

[0061] The Hazards Monitor can locally override a linking authorization from the NOC in the event a condition is detected which either negates a planned linking, adjusts the platooning distance, or otherwise alters the conditions on which the authorization is based. Such conditions typically include vehicle status problems, or adverse environmental conditions. If the Hazards Monitor override is based upon a vehicle fault or other status issue, that fault or issue is also communicated to the NOC so that the NOC can take it into consideration when evaluating future linking involving the vehicle.
Other conditions leading to a Hazards override can result from issues external to the vehicle itself, such as weather, traffic or road conditions detected by other vehicles. Depending upon the embodiment and the particular condition, the information about the external issue can be communicated to the NOC by another vehicle, and then sent to the vehicle receiving the linking authorization, or the information about the external issue can be communicated from the other vehicle directly to the vehicle receiving the linking authorization. In either case, the onboard system passes the hazard information to the Hazards Monitor, which takes appropriate action to either cancel or modify the authorized linking.

[0062] In the absence of an override from the Hazards Monitor, the Authorizations Manager 820 receives and interprets authorization packets from the NOC, via the NOC Communications Manager 800, in combination with absolute position, speed and heading information from the Vehicle Position Tracking function 825 [in turn received from the System 700] to help determine the proximity of the platooning partners proposed by the NOC, as discussed in greater detail hereinafter. The Authorizations Manager sends to the System 700 a link authorization status message together with a time to transition, i.e., a time at which the platooning partner is proximate and linking can begin. The Authorizations Manager also sends an identification of the selected platooning partner to Inter-vehicle Communications Management function 830, and, in some embodiments, sends to an Approach Guidance function 835 information regarding the selected platooning partner, its position, and guidance for linking.

[0063] The Inter-vehicle Communications Manager 830 manages the mutual authentication of the platooning partners by providing security credentials to the System 700, typically communicated over a DSRC [Digital Short Range Communications] link. In embodiments having approach guidance, the Approach Guidance function 835 operates in two modes.
When the partner vehicle is outside DSRC range, it provides approach guidance directly from the NOC, if such guidance is available. Then, once a secure communications link with the platooning partner has been established, over a DSRC link in at least some embodiments, the Approach Guidance function provides local approach guidance independent of the NOC, using position and speed information provided by the partner vehicle together with local vehicle tracking information, such as radar tracking status received from System 700 and data from Vehicle Position Tracking function 825.
Depending upon the embodiment, the guidance can comprise supplying the driver with none, some, or all of mapping, video and radar inputs, lane alignment, and any other data available from the system. In some embodiments, the driver manually uses such data to position the vehicle for platooning, at which point the platooning controller engages and brings the vehicles to the desired platooning gap.

[0064] The HMI Services function 840 provides the semantic layer for interaction with the driver of the vehicle, and converts status information from the vehicle, including the software layers, into relevant messages to the driver. In addition, the HMI Services function processes inputs from the driver. The HMI Services module provides presentation data to the Vehicle Hardware for display to the driver on the Driver HMI, typically a touchscreen display to permit easy entry of driver commands, choices, and other inputs.
For the driver of the following vehicle, the display typically includes a video stream of the forward-looking camera on the lead vehicle.

[0065] Referring next to Figure 8B, the software functionalities described above can be appreciated in the context of the software functions of the system as a whole. As in Figure 8A, the Inter-vehicle Communications function 830, which includes management of DSRC Communications, sends messages to HMI Services function 840, which provides an interface to the Driver function shown at 765. Inputs from the driver interface 765 include link requests based on the driver's selection of a platoon partner. It will be appreciated that multiple potential platoon partners will exist on many routes, thus giving the driver multiple options. However, in some embodiments and for some fleets, the platoon partner choices will be determined at fleet operations, for example where multiple trucks routinely follow the same route to the same or nearby destinations. In such instances the driver's options are either to accept the link or to reject it.

[0066] The HMI Services function also provides to a Supervisor Layer 850 input events received from the driver, and receives from the Supervisor Layer presentation data. The HMI Services function comprises, in an embodiment, a GUI 840A, video feed 840B, physical inputs 8400, and audio inputs and outputs 840D. The Supervisor Layer includes a Link Management function 850A, cellular communications management 850B and data store and logging 8500.

[0067] The Supervisor Layer also sends Link Authorizations to a Platooning Controller function 855, and receives from that controller status messages including DSRC status, faults, and radar status. The Platooning Controller 855 comprises various functions, including Gap Regulation 855A, Mass Estimation 855B, Brake Health Monitoring 8550, Platooning Status 855D, and Fault Handling 855E. Gap regulation can involve setting a distance from the lead to the follow vehicle, or can involve setting a time headway from the back of the lead vehicle to the front of the follow vehicle.
In either event, the objective is to ensure that the distance provides acceptable fuel economy benefits while at the same time ensuring the safety of both vehicles.

[0068] To perform the foregoing functions, the Platooning Controller receives inputs from the tractor representing status of various tractor functions, shown generally at Tractor Sensing 860. In an embodiment, those functions include Lidar data 860A, Visual data 860B, radar 8600, GPS
position 860D, wheel speed 860E, pedal position 860F, Engine Temperature 860G (sensed either from the block, from the engine bay, or other suitable location), steering 860H, inertial measurement 8601, brake pressure 860J, barometer and related weather sensing 860K, and combinations of such sensed data indicated as sensor fusion 860L. Other data, such as fuel level or remaining driving range, is also provided in some embodiments. The Platooning Controller communications bi-directionally with the Inter-vehicle Communication module 830 regarding mass, position, velocity, torque/braking, gear and faults. More specifically, the Controller 855 receives, via the DSRC link, data about the other vehicle including mass, position, velocity, torque/brake status, gear, and faults. The Platooning Controller uses these inputs to provide the status data to the Supervisor Layer, as mentioned above, and also provides torque and brake commands, and gear. In the absence of a gear sensor, gear selection can be calculated for manual transmissions based on engine speed and tire rotation speed. Gear on automatic transmissions can be sensed directly from the Transmission ECU.

[0069] The Platooning Controller 855 also receives status and fault information from a Tractor Actuation function 865, which, in an embodiment, comprises the functions 865A-865F of steering, throttle, shifting, clutch, and braking as well as other driver-controlled actions such as a jake brake, etc.
In at least some embodiments, the driver [function block 765] can provide all of such inputs to the tractor actuation block 865, although both braking and throttle are under the control of the platooning controller 855 during linking and while linked as a platoon. In some embodiments, a Tractor Indication function 870, comprising a Platooning Indication 870A, is also provided, and controls a physical indicator positioned on the tractor and visible to other vehicles proximate to the platoon. The physical indicator is typically enabled when a platoon is formed, and can also be enabled during the linking process.

[0070] Turning next to Figure 9, the data processing which occurs on the vehicle can be better appreciated. When the vehicle is started, the hardware starts up as shown at 900. The Data Bus handlers are registered with the system at 905, using either a default configuration or, if a configuration has been received from the NOC and is active, using that active configuration. At 910 a platoon authorization "listener" is started, whose function is to listen for platoon authorization messages from the NOC.

[0071] Next, at step 915 the latest vehicle event data is processed, after which a check is made at 920 to see whether a platoon authorization notice has been received from the NOC. If so, at 925 the authorization record is posted to the controller by a software interface such as an API. If no platoon authorization has been received, a check is made at step 930 to determine whether a configuration change has been received from the NOC.
If so, the new configuration is implemented and alters what data is collected from the vehicle and reported to the NOC in a "breadcrumb" message, and a restart signal is sent to cause a loop back to step 905 where the data bus handlers are re-registered in accordance with the new configuration.

[0072] If no new configuration has been received, the process advances to step 940, where a check is made to see if sufficient time has elapsed that position and status information are due to be sent to the NOC. If not, the process loops back to step 915. If so, the position and status information, or "breadcrumb" message, is sent to the NOC. The frequency at which such breadcrumb messages are sent to the NOC is, in at least some embodiments, defined by the configuration parameters received from the NOC, which parameters also define the event data that is to be sent to the NOC as part of the message. In at least some embodiments, the "breadcrumb" message is reported to the NOC regularly, for example once per second. In addition, when appropriate, an "I am available for platooning"
message is also sent regularly to the NOC.

[0073] Figure 10 illustrates an embodiment of the process by which connections between the NOC and the vehicle are managed. Service at the NOC starts as shown at step 1000, and the NOC waits for a connection from a vehicle on a known port, shown at 1005. The NOC then validates the truck and opens a secure session, shown at 1010, followed by creating a publisher message with a message broker functionality as shown at step 1015. A
publisher thread is then spawned at 1020, at which point the publisher connection and the network connection are passed to the thread. The thread listens for a message from the vehicle, for example a 'breadcrumb' message or an "I'm available for platooning" message, shown at step 1025. Once a message is received from the vehicle, shown at step 1030, the process loops and the NOC returns to listening mode at step 1025. If no message occurs within a given time window, the thread terminates as shown at step 1035.

[0074] Following the spawning of the publisher thread, and essentially in parallel with the execution of that thread, the process creates a subscriber message with a message broker as shown at 1040. A subscriber thread is then spawned at step 1045, and the subscriber connection and network connection are passed to the subscriber thread as shown at 1050. A check is made for queued messages at 1055, and any queued messages are sent to the vehicle at 1060. If there are no queued messages, or if the queued messages have been sent, the process advances to step 1065 and waits for the message to be published to the vehicle. The process then loops back to step 1060. In the event that the message could not be sent to the truck at step 1060, typically as the result of a connection failure, the messages are queued at step 1070 and the thread terminates at step 1075.

[0075] Referring next to Figures 11A and 11B, one can better appreciate the process of coordination and linking to form a platoon. Figure 11A shows one embodiment of the coordination and linking functionality, indicated generally at1100. After the process starts at step 1101, a set of platoon-capable pairings is received. The set of pairings is, in at least some embodiments, received from the NOC and comprises a list of potential platoon partners. Depending on the availability of other vehicles, or on the fleet's priorities, the driver may be presented with only a single platooning choice that is either accepted or rejected. Alternatively, in some embodiments and for some vehicles the identification of platoon-capable partners can be generated locally. In either event, authentication keys are provided to enable secure communications between linking partners. Thereafter, at step 1110, either the driver or the system identifies a vehicle available for coordination as a platooning partner, and a platooning offer is communicated as shown at 1122, indicated in some embodiments by a self-acceptance message. In either approach, the other vehicle (the "far" vehicle) can then accept, step 1124, meaning that the pair has agreed to coordinate for possible linking as shown at 1130. Depending on vehicle positioning, weight of load, vehicle equipment, and other factors, a vehicle within linking range may be identified as a Following Vehicle Available for Linking 1142 or a Leading Vehicle Available for Linking 1144. If neither of these is the case, the system returns to coordination mode. Once a Following Vehicle Available for Coordination has Accepted the link, 1152, and the Self Vehicle also accepts the link, 1153, (in any order), the link is initiated. Upon completion of the link, the vehicles are now linked 1162. Similarly, once a Leading Vehicle Available for Coordination has Accepted the link, step 1154, the Self Vehicle then also accepts the link, step 1155, initiating the link. Upon completion of the link, the vehicles are now linked as shown at step 1164.

[0076] To properly determine not only which vehicles are appropriate for linking, but also which vehicle should be the lead vehicle and which the follow, certain vehicle characteristics are important. One aspect is shown in Figure 11B, where the characteristics of engine torque and acceleration are collected internally to the vehicle at step 1165, and vehicle mass is calculated at step 1170. That information, which can be processed locally or at the NOC, is then used to adjust the gap between the vehicles, or to modify the algorithm, as shown at step 1175. In addition, the data can be used to choose whether to link or not, step 1180, although other factors can also be considered in at least some embodiments. Other factors can include, for example, the proposed distance of the platoon, time duration, time of day, hours of service and related restrictions, fuel level and driving range, refueling possibilities, service level agreement issues, the need for the vehicle to be at a destination at a given time for further use or maintenance, driver meals and relief breaks, driver satisfaction, driver pay, traffic rules and regulations, etc. If a link is to be made, one or more of the factors can assist in informing the decision on which vehicle should lead, step 1185.

[0077] Before a platoon can be formed, and even before potential platooning partners can be identified, the route for a vehicle available for platooning must be known at least in part. This can be accomplished by generating a vehicle travel forecast, as shown in Figure 12. The process there starts by receiving position information for a vehicle, designated Vehicle A, at step 1200. The position information can comprise longitude/latitude information, or a coordinate pair plus speed and heading, or a series or trail of coordinate pairs. A GPS device, as described in the foregoing figures, is suitable for providing such information.

[0078] The process of Figure 12 continues by checking at step 1205 to determine whether Vehicle A's route is known. In many instances, vehicles such as large commercial trucks travel routes that are repeated frequently, or are set by a fleet manager or other supervisor. As a result, in many instances a particular vehicle's route is known and stored in a database, typically maintained at a NOC and, in at least some instances, also available locally.
If, however, Vehicle A's route is not known, a search is made at step 1210 for nearby routes that would be acceptable for platooning. The process of identifying such routes is discussed in greater detail in connection with Figures 14A-14B and 15A-15B.

[0079] After the search at step 1210, a check is made at step 1215 to determine if at least one platoonable route, suitable for use by Vehicle A, is found. If not, the process stops for the time being, as shown at step 1220.
However, in most instances at least one platoonable route will be identified.
In such cases, a determination is then made as to where and when it is feasible for Vehicle A to join the platoonable route, as shown at step 1225.
Then, at step 1230, Vehicle A's route start location and time is used together with Vehicle A's expected speeds, to calculate, in the NOC or in the Vehicle Monitoring and Control System 700, minimum and maximum times for Vehicle A's arrival at specific waypoints on the identified route. Based on those calculations, a travel forecast for Vehicle A is then generated in either a local or remote process, as shown at step 1235. In addition to the factors discussed above for developing a travel forecast, one or more of the factors discussed in connection with Figure 11B, above, are also considered in formulating the travel forecast for some embodiments. The travel forecast, which is stored at the NOC in at least some embodiments, can then be used to search for potential platooning partners, as discussed in connection with Figure 13.

[0080] If Vehicle A's route is known, the route information is fetched from the database of known routes. Vehicle A's position is then compared to the known route, as shown at step 1245. If Vehicle A is off route, a determination is made at step 1250 as to where and when it is feasible for Vehicle A to rejoin the expected route. If rejoining is determined feasible, as shown at step 1255, the process loops back to step 1230 to provide Vehicle A
with appropriate guidance for rejoining the route, followed by generation of a travel forecast. If it is not feasible for Vehicle A to rejoin the route, the process terminates, for the time being, at step 1260. A termination at either step or step 1260 is temporary, since platooning possibilities change as Vehicle A's position on its route changes and, in at least some embodiments, vehicles report their changed position via breadcrumb messages.

[0081] Once a travel forecast has been generated for Vehicle A, it is possible to search for potential platooning partners. One embodiment for such a search and linking process is shown in Figure 13, which can be seen to elaborate in some respects on the process shown in Figure 11A. The process of Figure 13 begins with the receipt of a platoon request from Vehicle A. The request, shown at step 1300, is received at a processor, located in the NOC in at least some embodiments but potentially located elsewhere in other embodiments. A travel forecast such as results from the process of Figure 12 is then either generated or retrieved, as shown at step 1305. At step 1310, a search of the travel forecasts stored in a database at the NOC, shown at 1315, is made to identify other stored forecasts with similar routing. Based on those similar routings, a list of potential platoon partners is generated in the processor.

[0082] Occasionally, no potential platoon partners will be identified by the search, in which case a check made at step 1320 results in a "no." In such an event, Vehicle A's travel forecast is added to the database 1315 if not already stored, and the driver is informed that no platooning possibilities currently exist. In most cases, however, one or more potential platooning partners will be identified, such that a "yes" results from the check at step 1320. If so, a list of potential partners is sent to Vehicle A, as shown at step 1330. Depending upon the embodiment, a platoon offer can also be sent concurrently to the identified potential partners, B1, Bn, as shown at step 1335. In some cases, and as shown at step 1340, the driver selects from the list provided in step 1330, and a platooning offer is sent only to those partners selected by the driver of Vehicle A. In some embodiments, the fleet operator determines the potential pairings and the driver receives only one choice, which can either be accepted or rejected. At step 1345, Vehicle A's selection is retrieved, typically indicated by a manual or audible command from the driver. The responses from the potential partners, for example Vehicle B1, are shown at step 1350. A check for acceptance of the platooning offer is made at step 1355. Should there be no acceptances, Vehicle A's travel forecast is added, if not already stored, to the current travel forecasts database as shown at step 1325.

[0083] In most cases, Vehicles A and B1 agree, in which case the process advances to step 1360. As shown at step 1360, in most cases platoon approval is sent by the NOC, as discussed above in connection with Figure 8A-8B, together with advice for the respective rendezvous actions to be taken by Vehicles A and B1. In addition, as shown at step 1365, the travel forecasts for Vehicles A and B1 are removed from the database of current travel forecasts, since neither is currently available for platooning. In some embodiments, platoons of more than two vehicles are permitted, in which case the travel forecasts of Vehicles A and B1 are maintained in the database of current travel forecasts.

[0084] Following approval of the platoon, the positions of vehicles A
and B1 is monitored by the NOC, including during formation of the platoon and thereafter. In addition, the NOC monitors road and other conditions such as traffic, weather, construction, and so on, to identify conditions relevant to the platoon of Vehicles A and B1 provides alerts to both drivers as well as providing relevant data or commands to the onboard systems for each vehicle. Such monitoring continues at least until the platoonable routing is completed, step 1380, or one of the drivers disengages, step 1385, after which the process stops at 1390.

[0085] While the benefits of platooning make it desirable to link vehicles whenever possible, not all sections of a roadway are appropriate for platooning. Thus, long range coordination of vehicle for purposes of linking, such as shown in Figure 14A where vehicles 1410 and 1420 may be potential platoon partners, an analysis of the roadway is required before such platooning can be authorized. Thus, as shown in Figure 14B, some sections of a roadway may be designated in the NOC's database as inappropriate for linking. Such geo-fencing can exist for numerous reasons, such as road construction, traffic, traffic control, and so on. Figure 15A illustrates one embodiment for a process for identifying platoonable road segments. The process initiates by breaking a roadway into segments based on any suitable criteria. One example of a suitable criteria is to use mile markers, although latitude/longitude data and numerous other criteria can also be used. Then, each segment is evaluated to determine if it meets a basic criteria for platooning, as shown at step 1505. The basic criteria can include speed limit, known construction, known traffic choke points, excessive up- or down-grades, weather or other environmental problems, and so on.

[0086] If the segment under examination meets the general criteria, the process advances to step 1510, where the road segment can be evaluated in accordance with a class-specific criteria. Not all embodiments will use a class-specific criteria. However, some fleets or other traffic management systems may manage vehicles of various classes or types. In such instances, platooning is possible within a specific class, and the criteria appropriate for a platoon within a specific class may vary dramatically from the general criteria.
In some such instances, the class-specific criteria may be less limiting than the general criteria noted above. For example, while the general criteria may be applicable for large commercial trucks, the class "18 wheelers", a fleet may also include smaller box vans or similar vehicles that can handle grades or other roadway conditions that the larger vehicles cannot handle. In such instances, it may be desirable to reverse the order of steps 1505 and 1510, and it will therefore be appreciated that the order shown in Figure 15A is not intended to be limiting.

[0087] If the road segment does not meet the class specific criteria, the segment is added to the database for the general criteria only, as shown at step 1515. However, segments that meet both the general criteria and the class-specific criteria are added to database including class-specific data.
The process then advances to determine if there are other road segments to be analyzed, step 1525. If there are, the process loops back to step 1500 for the next segment. If not, the process terminates at step 1530.

[0088] The results generated by the process of Figure 15A permit the comparison of a travel forecast with the database of platoonable roadway segments. In some embodiments, the sections of platoonable roadway will be incorporated into the travel forecast developed by the process of Figure 12.
In other embodiments, the travel forecast includes only the routing, and the congruence of the routing with the database of platoonable roadway segments is determined by the appropriate processor at a later step.

[0089] To identify a potential platooning partner requires not only that the vehicles travel the same route, but that they travel the same route at relatively close to the same time. For example, if Vehicle A is an hour ahead of Vehicle B, and has no plans to stop, the loss of time by Vehicle A that would be required for Vehicle A to platoon with Vehicle B is so large that the cost of a platoon by those vehicles probably outweighs the benefits to be gained. However, if, for example, Vehicle A is only a minute ahead of Vehicle B, then the gain from platooning likely outweighs the time lost by Vehicle A
even if it is the only vehicle that adjusts speed to accommodate a linking. In many instances where platooning is viable, rendezvous guidance, as mentioned at step 1360, will suggest actions by both vehicles. However, many commercial vehicles, including many fleet-operated long-haul trucks, have governors which control maximum speed of the vehicle. In some vehicles the governor setting is accessible through the CAN bus [discussed at Figure 7I3], and may be adjustable from the NOC. In cases where Vehicle B
can increase speed safely and legally, the rendezvous guidance may suggest speed adjustments for both vehicles. In instances where Vehicle B is unable to increase speed, Vehicle A is typically guided to reduce speed to permit linking.

[0090] Referring still to Figure 15B, an analysis of the time and routing for Vehicles A and B is performed at steps 1540 through 1555. Thus, at 1540, the travel forecast for vehicle A is retrieved and at step 1545 the travel forecast for the first potential partner, B1, is retrieved. The forecasts are compared for common road segments, shown at 1550. If there are sufficient common road segments, a check of the timing criteria is made. If that, too, indicates a potential platooning partner, then, for some embodiments where only a single class of vehicle is involved such as long-haul trucks, vehicle will be added to the list of potential partners for Vehicle A. In some alternative embodiments where different classes of vehicles are managed by the system, a further check is made at step 1560 to determine whether the vehicles are in the same class. It will be appreciated that the step of checking the class could be done in any order. Further, in some embodiments an assessment of the cost-benefit of a platoon of Vehicle A and Vehicle B1 is made in accordance with a predetermined criteria, as shown at step 1565. Potential partners that meet each of the applied tests are then added to the list of potential partners at step 1570 and then advances to step 1575.

[0091] If the potential pairing fails to meet the acceptable criteria of any of steps 1550 through 1565, to the extent those steps apply, the process of Figure 15B advances to step 1575 where the system checks to determine if other potential partners remain to be evaluated. If so, the process loops to step 1545 for the next potential partner. If there are no more potential partners, the process terminates at step 1580.

[0092] Referring next to Figures 16A-16E, a visual representation of highway segments is provided to assist in understanding the identification of platoonable roadway segments and the development of a platoonable routing for a pair of vehicles. In particular, Figure 16A shows a section of roadway 1600 broken into segments, in this instance as determined by various mile markers such as 137.1, 196.4, 233.1 and 255.6. Then, shown in Figure 16B, overlaid on that road segment 1600 are smaller roadway segments 1605 and 1610 that are known to be unsuitable for platooning, such as a downhill grade indicated at 1605 and a construction zone indicated at 1610. Thus, the segment of roadway 1600 is platoonable except for the sections 1605 and 1610.

[0093] Next, the travel forecast for Vehicle A is applied to segment 1600. As shown in Figure 160, Vehicle A will travel on the road segment from mile marker 137.1 to mile marker 274.4, indicated at 1615. Similarly, Vehicle B's travel forecast shows that it will travel on the road segment from marker 123.6 to 255.8, shown in Figure 16D and indicated at 1620. By overlaying the travel forecasts of Vehicles A and B with the segment identified as platoonable, it can be seen that the platoonable routing 1625 for Vehicles A
and B is from marker 137.1 to marker 255.8, except for the downgrade and construction zone indicated at 1605 and 1610, as shown in Figure 16E.

[0094] Selections of vehicles for platooning can be represented mathematically. For example, for the roadway segment of Figures 16A-16E, the following describes the result shown in Figure 16E, given the mile post value sets representing of travel of each truck on the illustrated roadway segment:

[0095] A= [137.1, 274.4]

[0096] B = [123.6, 255.8]

[0097] Compute the shared travel section of Hwy 23:

[0098] A 11 B = [137.1, 255.8]

[0099] Given a mile post value set for the platoon-able section(s) of the illustrated roadway:

[00100] P = [0, 148.7] u [151.3, 231.4] u [234.5, 354.2]

[00101] Compute the platoon-able shared travel section(s) of Hwy 23

[00102] An Bn P= [137.1, 148.7] L.J [151.3, 231.4] L.J [234.5, 255.8]

[00103] If A 11 B is empty, then the two trucks do not share a route

[00104] If A 11B11P is empty, then any shared route is not platoon-able.

[00105] The total length of A fl B fl P represents the maximum payoff of forming the platoon, i.e., the number of platoonable miles of the shared route.

[00106] The set representation also forms the basis for creating a searchable database of current platoon opportunities, where, in an embodiment, each record in the database contains at least:

[00107] Highway designation, e.g. "N I-35W' (direction, system, number, optional descriptor)

[00108] Start and end mile post values

[00109] Minimum start and maximum end expected time stamps (a coarse feasibility filter)

[00110] Truck identifier, expiration time, ...

[00111] In determining whether to form a platoon, it is also valuable for either the drivers, the fleet operator, or other system operator to assess the cost benefit of forming a platoon. Thus, with reference to Figure 17A, some characteristics for evaluating the cost-benefit of a platoon can be understood.
The first, as noted above, is the destination arrival time sacrificed by the lead truck. Another is the ability of each vehicle to operate at the required speeds for the required periods of time to form the platoon and then the endurance to maintain the platoon once it has formed. This results in an assessment of the remaining platooning potential, and in an embodiment can be expressed as a distance relative to the platoonable segment(s).

[00112] In some respects, the decision to platoon can be regarded as a "contract" between the drivers (and authorized by the NOC in many embodiments). That contract essentially commits each vehicle to maintain particular speeds for particular times, both to achieve linking and to maintain the platoon. This can be appreciated from Figure 17B, where the rendezvous guidance suggests to each driver what speeds to maintain to achieve linking at a particular distance and time. However, that contract can be voided when circumstances change for either vehicle, and the revised rendezvous estimate exceeds either a distance threshold or a time limit.

[00113] In addition, maximizing the benefits of platooning for a fleet of trucks may mean selecting a platooning partner that is not optimal for a specific pair of trucks. For four trucks in a fleet, designated A, B, C and D, there are three possible pairings. This can be represented mathematically as

[00114] A-B/C-D, A-C/B-D, and A-D/B-C

[00115] Where len() represents a general benefit function, the pairing combinations can be expressed as:

[00116] /en(An B n P) > /en(An c n P) and /en(A n B n P) >
/en(B n D n P)

[00117] ien(A n B n P) + ien(c n D n P) < ien(A n c n P) + ien(B n D n P)

[00118] it can be seen that, for at least some definitions of len , the pairing combination that yields the maximum benefit for a specific vehicle or pair of vehicles is not the same as the pairings that yields the maximum combined benefit for all vehicles. Thus, in some embodiments, selection of pairings may be performed at the NOC level rather than by individual vehicles.

Such pairings can readily include one or more of the factors discussed above in connection with Figure 11B, including distance, time, hours of service, etc.

[00119] Referring next to Figure 18, an embodiment for collecting data about the operation of a particular truck, and a fleet as a whole, can be better appreciated. A variety of measured data 1800A-n, including vehicle speed, fuel consumption, historical data, braking information, gear information, driver sensors, gap information, weather, and grade as just some examples, are provided to the central server or the on-board system 1810. The server or other processor 1810 calculates a selection of metrics including miles per gallon, driver efficiency, savings, time linked, availability of linkings, and numerous variations. From these, selected metrics can be displayed to the driver, 1820, or the fleet manager 1830, or can be used to provide driver incentives, 1840. Various data may be displayed to the driver via the HMI
interface, such as, for example, savings per mile achieved by the driver.

[00120] In sum, the present invention provides devices, systems and methods for vehicle monitoring and platooning, including in some embodiments various capabilities for semi-automated vehicular convoying.
The advantages of such a system include the ability to follow closely together in a safe, efficient, convenient manner, together with improved fuel economy, better fleet management.

[00121] While this invention has been described in terms of several embodiments, there are alterations, modifications, permutations, and substitute equivalents, which fall within the scope of this invention. In view of the many alternative ways of implementing the methods and apparatuses of the present invention, it is intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true scope of the present invention.

Claims (6)

What is claimed is:

1. A vehicle monitoring and control system configured to control at least acceleration and braking of a plurality of vehicles wherein at least one follow vehicle follows behind a lead vehicle in a substantially linear arrangement comprising at least one electronic control unit comprising a processor for controlling at least acceleration and braking of at least a lead vehicle, a plurality of sensors for detecting the relative location of the front of a follow vehicle with respect to the rear of a lead vehicle, the plurality of sensors comprising at least two of a camera, GPS, radar, lidar, at least one actuator for increasing or decreasing acceleration and braking, and a platooning layer operating responsive to signals from the plurality of sensors for directing at least one electronic control unit to adjust the at least one actuator.

2. A vehicle monitoring and control system configured to control at least acceleration and braking of a plurality of vehicles, wherein at least one follow vehicle follows behind a lead vehicle, comprising a remote server for selecting pairings of a lead vehicle and at least one follow vehicle, the remote server configured to communicate pairing information to at least a lead vehicle, at least one electronic control unit in a lead vehicle comprising a processor for outputting control signals representative of desired acceleration and braking for at least the lead vehicle, a receiver on a lead vehicle configured to receive the pairing information from the remote server, a plurality of sensors for detecting the relative location of the front of a follow vehicle with respect to the rear of a lead vehicle, the plurality of sensors comprising at least one of a camera, a GPS receiver, radar, lidar, and generating an output representative of relative location, at least one actuator responsive to the control signals for causing at least the lead vehicle to accelerate or brake in accordance with the control signals, a control program operable on the at least one electronic control unit responsive to the pairing information received from the remote server and to the plurality of sensors for causing the at least one electronic control unit to output control signals in accordance with at least one of the pairing information and the output representative of relative location.

3. A method for managing a plurality of vehicles configured for at least one follow vehicle to maintain a position behind a lead vehicle on a roadway comprising the steps of sensing the operating conditions of each follow vehicle wherein the operating conditions comprise a plurality of position, wheel speed, engine temp, inertial measurement, brake pressure, steering, estimated mass, and pedal position, communicating at least some of the sensed operating conditions of each follow vehicle to a processor, determining, in the processor, an acceptable gap between the lead vehicle and the at least one follow vehicle in accordance with the sensed operating conditions of the at least one follow vehicle, actuating at least one of throttle, shifter, clutch, brakes or steering to cause the at least one follow vehicle to maintain a safe gap between the lead vehicle and the at least one follow vehicle.

4. A method for registering a vehicle with a remote server for management of vehicle routing and pairing comprising the steps of registering, in a processor, a vehicle configuration, starting, in the processor, a platoon authorization listener process, processing, in a processor, current vehicle event data, receiving, from a remote server, periodic configuration updates or status messages, providing, to the remote server, status and event data specific to the registered vehicle, repeating the processing, receiving and providing steps to enable management of vehicle routing and pairing based at least in part on the vehicle status and event data.

5. A process for developing a travel forecast for pairing of vehicles comprising the steps of receiving, in a processor, position information for a first vehicle, determining whether routing information for the first vehicle is available in memory associated with the processor and, if so, retrieving that routing information, if no routing information for the first vehicle is available in the memory, determining, in a processor based on a set of known acceptable routes stored in memory, routing information for the first vehicle, comparing, in a processor, the position of the first vehicle to the routing information, determining maximum and minimum times for the first vehicle to reach a specified waypoint on a route based at least in part on the position and routing information together with expected speeds, generating a travel forecast for the first vehicle, communicating the travel forecast for the first vehicle to a remote processor for identification of other vehicles suitable for pairing with the first vehicle.

6. A process for identifying potential platoon partners comprising the steps of retrieving from memory associated with a processor a travel forecast for a first vehicle, retrieving from memory associated with a processor a travel forecast for at least a second vehicle, comparing the travel forecasts of the first vehicle and at least a second vehicle to identify physical road segments common to the travel forecast of the first vehicle and at least a second vehicle, in a processor, determining from the travel forecasts of the first vehicle and at least a second vehicle whether the first vehicle and at least a second vehicle will arrive at a waypoint at times acceptable to a timing criteria, in a processor, determining from the travel forecasts whether the first vehicle and the at least a second vehicle are in compatible vehicle classes.