Note: Descriptions are shown in the official language in which they were submitted.
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
1
VEHICLE IDENTIFICATION AND LOCATION USING SENSOR FUSION
AND INTER-VEHICLE COMMUNICATION
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a conversion of U.S. Patent Application S.N.
62/249,898, filed November 2, 2015. It is further a continuation-in-part of
U.S.
Patent application S.N. 14/855,044, filed 9/15/2015, which in turn is a 371
application based on PCT Application P0T/US14/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.
This
application is also a continuation-in-part of PCT Application PCT/US16/49143
filed 8/26/2016, which in turn is a conversion of U.S. Patent Application S.N.
62/210,374, filed 26 August 2015. This application is further a conversion of
U.S. Patent Application S.N. 62/343,819, filed 5/31/2016, as well as U.S.
Patent Application SN 62/363,192 filed 7/15/2016, and further as well as U.S.
Patent Application SN 62/377,970 filed 8/22/2016. 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
2
follow, safely, a first vehicle at a close distance in an automated or semi-
automated manner. More particularly, the present invention relates to
methods, systems and devices which permit vehicles to identify one another
on the open road using the sensors local to one or more sensing vehicles
together with inter-vehicle, wireless, and satellite signals
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.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
3
[0006] 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.
[0008] Further, in some instances it is desirable, and even necessary,
to select correctly one specific vehicle out of a plurality of similar-
appearing
vehicles. Still further, it is sometimes important for a first vehicle to
identify
characteristics of at least a second vehicle while both (or all) vehicles are
proceeding at speed on an open road, for example, the length of all or some
portion of the second vehicle,
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
4
SUMMARY
[0009] 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, for example, a safe, efficient
convoying, or platooning, solution or other partly or fully automated vehicle
solution. For example, but without limitation, aspects of the present
invention
enable a first potential platooning partner to identify a sensed vehicle based
on data received from the sensors local to the first vehicle, sometimes in
combination with communications received from the sensed vehicle, or from a
NOC or other network source, or via satellite link. 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.
[0010] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
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 ("NOC") such as maintained by a fleet manager; 11)
assistance in preventing other types of accidents unrelated to the close
following mode, 12) identification of one or more vehicles with which a first
vehicle is communicating; 13) use of one or more modalities for determining
and/or confirming distance separating vehicles of interest; 14) integrating
data
received from one or more sensors on a local, or sensing, vehicle, for
identifying a second, or sensed, vehicle; 15) developing alternative
approaches for determining vehicle location, including relative location among
two or more vehicles,
[0011] ltw 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
[0012] 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:
[0013] 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.
[0014] Figure 2 shows an embodiment of the forward-looking view seen
by the trailing vehicle.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
6
[0015] Figure 3 shows a variety of communications links between
platooning vehicles, ancillary vehicles, wireless transceivers, and a network
operations center.
[0016] Figure 4 illustrates a variety of factors that a central server,
such
as maintained at a NOC, might consider in determining candidates for linking.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] Figure 9 illustrates in flow diagram form an embodiment of a
vehicle data processing main loop in accordance with the invention.
[0024] Figure 10 illustrates in flow diagram form an embodiment of
NOC-vehicle communications management.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
7
[0026] Figures 11A-11B illustrates a long range coordination aspect of
the present invention, including a geofendng capability.
[0026] 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.
[0027] Figure 13 illustrates an embodiments of software architecture
suited to perform the travel forecasting function that is one aspect of the
present invention.
[0028] Figure 14 illustrates in flow chart form an embodiment of a
sequence for platoon pairing discovery and monitoring.
[0029] Figure 15A illustrates in flow chart form an embodiment of an
aspect of the invention by which platoonable road segments are identified.
[0030] Figure 15B illustrates in flow diagram form a process for
identifying potential platoon partners.
[0031] 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.
[0032] Figure 17A illustrates a plurality of vehicles, among which is a
vehicle to be identified and a vehicle seeking to make that identification.
[0033] Figures 17B-17C illustrate in flow diagram form two exemplary
embodiments of processes by which a "sensing" vehicle identifies a "sensed"
vehicle through the use of a vehicle signature.
[0034] Figures 18A-18B illustrates in flow diagram form alternative
embodiments of a process by which a sensing vehicle identifies the back end
of a sensed vehicle.
[0035] Figure 19A illustrates a pair of vehicles traveling in close
proximity to one another, and the GPS satellites seen by each.
[0036] Figures 19B-19D illustrate in flow diagram form various
alternative processes for ensuring that vehicles traveling in close proximity
to
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
8
one another and using GPS position information rely on such position
information from the same satellites..
[0037] Figure 20A shows an alternative approach for monitoring
relative vehicle position among vehicles traveling in close proximity to one
another, when the number of viewable satellites is fewer than normally
desired.
[0038] Figure 20B shows in flow diagram from an embodiment of a
process for evaluating vehicle position where, as shown in Figure 20A, the
number of viewable satellites is less than normally desired.
[0039] Figure 21A shows a pair of vehicles traveling in close proximity
and approaching an incline having, for example, two different grades.
[0040] Figure 21B illustrates in flow diagram form an embodiment of a
process by which the impact of the grade on vehicle performance can be
anticipated and compensated for.
DETAILED DESCRIPTION OF THE INVENTION
[0041] 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.
[0042] 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.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
9
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.
[0043] 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.
[0044] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
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.
[0046] 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
1C. 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.
[0046] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
11
driver's seat, or both. Alternatively, a single vibration source can be used
in
some embodiments.
[0047] 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.
[0048] 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.
[0049] However, cellular communication is not always possible,
especially in vehicles driving long distances through varied terrain. Further,
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
12
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.
[0050] 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.
[0051] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
13
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.
[0052] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
14
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.
[0053] 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.
[0054] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
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).
[0055] 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.
[0066] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
16
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.
[0057] 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.
[0058] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
17
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.
[0059] 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.
[0060] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
18
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.
[0061] 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.
[0062] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
19
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.
[0063] 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,
[0064] While a single ECU can perform all of the functions necessary in
at least some embodiments of the invention, most modem 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,
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
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.
[0065] 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 Drivers commands and choices, for example, selections of
a linking partner, or acceptance by the driver of an offered link.
[0066] 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.
[0067] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
21
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.
[0068] 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.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
22
[0069] 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.
[0070] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
23
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.
[0071] 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.
[0072] 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 and
Incoming Vehicle Signature Commands, discussed hereinafter at Figures 17A
et seq., 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.
[0073] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
24
inputs and outputs 840D. The Supervisor Layer includes a Link Management
function 850A, cellular communications management 850B and data store
and logging 8500.
[0074] The Supervisor Layer also sends Link Authorizations and
Vehicle Signature commands and data 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.
[0075] 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, as well as Sensed Vehicle Signature Data
(discussed hereinafter at Figures 17 et seq.) is also provided in some
embodiments. In some embodiments, the Tractor Sensing function
communicates bi-directionally with the Inter-Vehicle Communication module,
in particular where some processing of the data related to vehicle signature
occurs within the ECU's associated with the Tractor Sensing functions.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
[0076] 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.
[0077] 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.
[0078] 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.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
26
[0079] 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 NOG.
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.
[0080] 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.
[0081] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
27
listens for a message from the vehicle, for example a treadcrumb' 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.
[0082] 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.
[0083] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
28
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.
[0084] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
29
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.
[0085] 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.
[0086] 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.
[0087] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
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,
[0088] 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
1220
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.
[0089] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
31
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.
[0090] 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.
[0091] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
32
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.
[0092] 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.
[0093] 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.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
33
[0094] 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.
[0096] 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.
[0096] 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.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
34
[0097] 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 7B], 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.
[0098] 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
B1
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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
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.
[0099] 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.
[00100] 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.
[00101] 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
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
36
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.
[00102] 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:
[00103] A = [137.1, 274.4]
[00104] B = [123.6, 255.8]
[00105] Compute the shared travel section of Hwy 23:
[00106] A fl B = [137.1, 255.8]
[00107] Given a mile post value set for the platoon-able section(s) of
the
illustrated roadway:
[00108] P = [0, 148.71 u [151.3, 231.4] u [234.5, 354.2]
[00109] Compute the platoon-able shared travel section(s) of Hwy 23
[00110] An Bn P=[137.1, 148.7] U [151.3, 231.4] Li [234.5,255.8]
[00111] If A 1.1 B is empty, then the two trucks do not share a route
[00112] If A 11 B (IP is empty, then any shared route is not platoon-
able.
[00113] The total length of A r) B fl P represents the maximum payoff of
forming the platoon, i.e., the number of platoonable miles of the shared
route.
[00114] 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:
[00115] Highway designation, e.g. "N I-35W' (direction, system, number,
optional descriptor)
[00116] Start and end mile post values
[00117] Minimum start and maximum end expected time stamps (a
coarse feasibility filter)
[00118] Truck identifier, expiration time, ...
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
37
[00119] One challenge faced, at least occasionally, by vehicles seeking
to travel in close proximity to one another, is to identify the partner
vehicle or
vehicles. Thus, for example, as shown in Figure 17A, vehicular traffic over a
given section of roadway can involve multiple vehicles with similar
appearances. In such a circumstance, confusion in identifying the vehicular
partner can occur. As shown in Figure 17A, Vehicle A, indicated at 100, is the
intended partner vehicle for Vehicle B, indicated at 105. Both are proceeding
in the same lane of a three lane roadway indicated at 1700. However,
Vehicles C, D and E, indicated at 1705, 1710 and 1715, respectively, are all
similar vehicles and all proceeding in the same direction as Vehicles A and B.
In addition, Vehicles X, Y, W and Z, indicated at 1720 -1735, respectively,
while smaller, are also proceeding in the same direction and inhibit relative
movement between Vehicles A and B. However, Vehicles A and B are each
able to communicate with one another, either directly through DSRC,
microcell, or other wireless network, as indicated at 1740, and may also be
able to communicate with one another via a proximate WiFi hotspot or similar,
indicated at 1745. Further, Vehicles A and B may be able to communicate
with one another via cellular data connection managed through a Network
Operations Center (NOC) 1750. In accordance with the present invention,
these communications links, together with the sensors local to at least some
of the vehicles shown in Figure 17A, can be used to affirmatively identify the
vehicles to one another, or at least to allow the rear vehicle to identify the
lead
vehicle.
[00120] Referring next to Figures 17B-17C, two exemplary processes
are shown by which a "sensed" vehicle, typically the lead vehicle, can be
identified by a "sensing" vehicle, typically the trailing or following
vehicle.
These processes can be performed at a distance, or more closely, such that
either vehicle to vehicle communication can use any available form of vehicle-
to-vehicle communication. The process of identifying a sensed vehicle can,
but need not in all embodiments, include fore-knowledge of various
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
38
characteristics of the sensed vehicle. The movements and other
characteristics (if available) of the sensed vehicle can, taken together,
comprise a "vehicle signature" of the sensed vehicle, thus allowing it to be
identified by the sensors local to the sensing vehicle either alone or in
combination with communications from either the sensed vehicle or the NOC,
[00121] In the context of the present invention, a sensed vehicle's
signature can comprise either a natural action of the vehicle, or can comprise
a purposeful action of the vehicle. A natural motion can comprise, for
example, the vehicle's position and speed on the roadway as it navigates its
intended route as though independent of any need to be sensed. In contrast,
a purposeful motion of the vehicle could be any of a lengthy list of arbitrary
events, such as a lane change, speeding up or slowing down, flashing or
blinking of either taillights or brake lights, or flashing of a platooning
beacon,
or any other suitable event that can be commanded remotely and can be
reasonably performed without causing a safety risk.
[00122] With particular reference to Figure 17B, a process for detecting
a sensed vehicle using the natural motion of that vehicle can be better
understood. In this instance, some identifying characteristics of the sensed
vehicle are known to some part of the system, and are made available to the
sensing vehicle. These characteristics can comprise route information, such
as developed in accordance with Figures 12-15, above, or can comprise
speed or position information, such as provided to the NOC in accordance
with, for example, the breadcrumb messages shown in Figure 9, or other
vehicle characteristics. In some embodiments date and time information may
also be recorded along with position. The known characteristics can be
provided by the NOC, or can be provided by vehicle-to-vehicle
communications. Thus, the process of Figure 17B begins at step 1753 by
retrieving at the sensing vehicle such known characteristics of the sensed
vehicle. Then, at step 1755, the sensors local to (i.e., on board) the sensing
vehicle (1755B) monitor the vehicle signature event(s) determined by those
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
39
known characteristics. At step 1760 the sensor data is compared to the
vehicle signature identified by the known characteristics. If the two match,
within a predetermined tolerance, the sensed vehicle is identified as the
target
vehicle, shown at step 1763, and the process ends. If not, the process
advances to step 1765 to determine whether the vehicle signatures of other
candidate vehicles remain to be evaluated. If so, the process loops back to
step 1760, until the target vehicle is identified. In some embodiments, rather
than looping back, the process redirects to the process shown in Figure 170,
where a purposeful vehicle signature is generated by the sensed vehicle.
Likewise, if no more candidate vehicles remain, and the target vehicle has not
been identified, the process can advance to step 1770, Figure 17C.
[00123] While the exemplary process of Figure 17B is shown as
capturing the vehicle signature of multiple candidate vehicles at step 1765,
and then looping from step 1765 to step 1760 to process additional vehicle
signatures, those skilled in the art will appreciate that the candidate
vehicle
signatures can be captured individually, for example serially, such that the
process would loop differently, for example from step 1760 back to step 1755.
[00124] In the process shown in Figure 170, the sensed vehicle is
commanded to perform a particular, purposeful action to enable the sensing
vehicle to identify the sensed vehicle by means of that purposeful
vehiclesignature. The command can be generated by the system local to
either the sensed vehicle or the sensing vehicle, or by the NOC. If the
specific command is generated by the system or systems local to the sensed
vehicle, the command can be, for example, in response to a message from
either the NOC or the sensing vehicle that the sensed vehicle has not been
identified. A time-out can also be used. Regardless of the source of the
command, the process of Figure 170 begins at step 1770 with the sensed
vehicle being commanded to perform a purposeful maneuver or other
commanded event, which it then performs at step 1775. If the source of the
command is not the sensing vehicle, the sensing vehicle is provided the type
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
of commanded event at step 1780, where the sensing vehicle captures the
intended purposeful vehicle signature of the sensed vehicle. It will be
appreciated that the purposeful vehicle signature may be provided to the
sensing vehicle in advance of, or contemporaneous with, or after, the
performace of the commanded event by the sensed vehicle. In addition, and
in some embodiments concurrently, at step 1785 the sensing vehicle uses its
local sensors to capture the vehicle signatures of all candidate vehicles. At
step 1790, the expected vehicle signature is compared to the vehicle
signature of the first (or next) candidate vehicle as detected by the local
sensors. If they match within a predetermined tolerance, the sensed vehicle
is identified as the target or potential partner at step 1795 If not, the
process
advances to step 1797 to determine whether more candidate vehicles remain
to be processed. If so, the process loops back to step 1790 and the next
candidate vehicle signature is processed. In most instances, the sensed
vehicle will be identified. However, if for some reason the sensed vehicle
cannot be identified, the process aborts at 1799 in some embodiments.
Alternatively, the process of Figure 170 simply restarts by commanding the
sensed vehicle to perform a different event to provide a purposeful vehicle
signature.
[00125] To permit vehicles to travel in close proximity to one another,
such as in a platoon of heavy trucks, it is necessary for the trailing vehicle
to
control the gap between the rear of the leading vehicle and the front of the
trailing vehicle. An initial condition for such control is to identify the
back of
the lead vehicle. Exemplary, alternative processes by which the back of a
lead vehicle can be identified to a trailing vehicle are shown in Figures 18A-
18B. The processes of Figures 18A and 18B are typically undertaken when
the vehicles are within sufficiently close proximity that DSRC or similar
short-
range communications are usable, or typically around one-half mile or less.
These same processes, including the short-range communications links, then
continue to be usable while the vehicles are in much closer proximity, for
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
41
example when platooning where the gap between the back of the lead vehicle
and the front of the trailing vehicle is less than one hundred feet, and may
be
as little as ten feet or less.
[00126] Figure 18A illustrates an embodiment of a process by which the
back of the lead vehicle can be identified by the trailing or following
vehicle.
The process of Figure 18A is used is where the sensing vehicle knows some
characteristics of the lead vehicle, but not its length, and can use its local
sensors to determine other data sufficient to identify the back of the lead
vehicle. The known characteristics can include one or more of: lane position,
velocity, vehicle characteristics, information communicated V2V such as via
DSRC or similar short range wireless links, relative GPS information, absolute
GPS information, information communicated from the NOC, etc. The local
sensors can include one, some or all of the sensors identified in Figure 8B,
including radar, lidar, video or camera, etc. The interaction of the Vehicle
signature functionality with the tractor sensors, Supervisor Layer and
Platooning Controller are shown in Figure 8B and discussed in connection
with that Figure.
[00127] The process of Figure 18A begins by using sensors local to the
following vehicle to detect the back of the lead vehicle, shown at step 1800.
Although in many embodiments the data will be provided by sensors local to
the sensing vehicle, or based on instructions received from the NOC, in some
embodiments data can be determined visually by the driver, for example, if
the length of a trailer is marked on the side or back of the trailer in a way
that
is not readily determined by the system. At step 1805 the known
characteristics of the sensed vehicle are retrieved if not previously received
and stored, after which a comparison is made at step 1810 between the
sensed rear of the vehicle and the known characteristics. Because multiple
local sensors can be used to determine the back of the lead vehicle, in at
least some embodiments comparisons are made among the results from the
local sensors, and, if consistent, the multiple sensing modalities are used to
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
42
confirm the location of the rear of the lead vehicle. In some instances, no
vehicle characteristics are known, and only the multiple modalities of the
local
sensors are used to identify the rear of the lead vehicle. However, in those
instances where vehicle characteristics are provided at step 1805, that
additional data provides further confirmation of the length of the lead
vehicle.
[00128] GPS data can be particularly useful, where relative position is
determined rather than absolute position. However, if GPS-based relative
position data is used, it is important to know the location of the GPS
receiver
within the lead truck, and to adjust vehicle length accordingly.
[00129] Radar data can also be very helpful in identifying or confirming
the back of the lead vehicle with respect to the following vehicle. In
addition,
in some instances, radar can be helpful in making an initial determination of
which vehicle is the communicating partner. The structures in the vehicle that
reflect radar waves can, in some instances, provide a signature pattern that
assists the system of the sensing vehicle to identify the sensed vehicle. In
addition, the native radar signature of a particular vehicle, such as a
tractor,
trailer, or automobile, can be augmented by the addition of a radar reflector
of
a sufficiently unique shape that it permits easy identification of the desired
characteristics of the sensed vehicle.
[00130] If the comparison at step 1810 confirms that the sensed back of
the vehicle yields consistent results, and matches the known characteristics,
the vehicle length is calculated at step 1815, and, in at least some
embodiments, the length is stored at step 1820. The gap between the lead
and trailing vehicles can then be controlled and adjusted to permit improved
performance while taking into account the prevailing operating conditions, as
shown at step 1825. However, if the check at step 1810 negates the
confirmation, the process loops back to step 1800 and repeats. In the event
of repeated failures, the process can be aborted in at least some
embodiments.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
43
[00131] In some instances, the length of the vehicle is known in
advance, and can be communicated to the trailing vehicle. For example,
some operators of truck fleets maintain a database shown the length of each
trailer in combination with a unique identifier such as serial number. In such
instances, the process of Figure 18B can be used to identify the rear of the
lead vehicle. Thus, at step 1830, the length of the vehicle and other known
vehicle characteristics are retrieved from either the NOC, the local storage,
the lead vehicle, or any other location accessible to the system on board the
trailing vehicle, as shown at 1835. Based on that information, the expected
back of the lead vehicle is calculated or otherwise determined at step 1840.
Further, the local sensors detect the back of the sensed vehicle as as step
1800, and the expected back of the lead vehicle is compared to the detected
back of the lead vehicle at step 1850. If the comparison is a match, the
process advances to step 1855 and the sensing vehicle identifies the sensed
vehicle as the target or potential partner. Based on that, the system can
adjust the gap distance between the vehicles based on length and operating
conditions, as with Figure 18A. However, if the comparison at step 1850 fails
to yield a match, the process loops back to step 1830 until either a match is
confirmed or the system terminates unsuccessfully.
[00132] It will be appreciated by those skilled in the art that the
fusion of
the data from local sensors with the data available either through DSRC or
other short-range communications channels, or from the NOC, yields more
reliable and more accurate information than any single modality or source
taken alone. This increased accuracy permits better vehicle management
both when the vehicles are maneuvering into close proximity substantially
under manual/driver control, and while that close proximity is being
maintained in a semi-automatic mode. On a larger scale, the fusion of such
sensor data with communications links can provide a safer environment for
fully automated vehicles of any type, especially where all vehicles on a
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
44
roadway are equipped with compatible sensors, communications links, and
control systems as disclosed herein.
[00133] In at least some embodiments, GPS position data is used at
least to guide potential partner vehicles into close proximity, and in some
embodiments, as discussed above, is used to provide relative position data;
that is, the position of a first vehicle to a second vehicle such as the lead
vehicle and the following vehicle in a platoon. In many circumstances, the
accuracy of relative GPS position data can be within a few centimeters, and
thus provides valuable data for managing the gap between the vehicles.
However, the accuracy of relative GPS position can vary depending upon the
satellites visible to each vehicle. Thus, for example, Figure 19A illustrates
a
real world scenario where Vehicle A, indicated at 100, and Vehicle B,
indicated at 105, are traveling at different points along the same roadway and
in the same direction as shown by the arrows.
[00134] Even if the distance between the vehicles is comparatively
small, obstructions such as those shown at 1900 and 1905 can prevent the
GPS receiver in each vehicle from seeing the same satellites that are seen by
the other vehicle. Differences in the set of satellites used by the two
vehicles
can cause significant errors in sensed relative positioning between the
vehicles. For example, obstruction 1900 can be a berm adjacent a portion of
the roadway, sufficient to block vehicle A from seeing satellite 1910.
Similarly,
obstruction 1905 can be a large building adjacent a roadway, and prevent
vehicle B from seeing satellite 1915 or prevent both vehicles A and B from
seeing satellite 1920. However, both vehicles A and B can see satellites
1925A-1925D, which is typically adequate for obtaining reliable GPS relative
position data.
[00135] The potential difficulty comes from the fact that vehicle A can
see satellite 1915, whereas vehicle B cannot; and vehicle B can see satellite
1900 whereas vehicle A cannot. To optimize accuracy, it is desirable in some
instances and in some embodiments to have the GPS receivers in both
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
vehicles relying on data from only the same satellites. In some embodiments,
this is achieved by each vehicle using the common set of satellites. In other
embodiments, the vehicles may choose to use, or be commanded to use,
more than the common set of satellites, but choose an optimum set for each
vehicle based on knowledge of the visible satellites to the other vehicle.
This
can be achieved through the process shown in Figure 198, or the alternative
processes shown in Figures 19C and 19D.
[00136] The process of Figure 198 begins with each vehicle's GPS
receiver identifying the satellites it sees at that time, shown at steps
1930A,
1930B. Each vehicle then sends to the other the satellites that that vehicles
sees, shown at 1935A-1935B, or, optionally, one vehicle sends the satellites
it
sees to the other but the second vehicle does not send that information to the
first vehicle. In addition, and also optionally, data representing which
satellites are viewable by each vehicle at that time is sent to the cloud/NOC
for storage as shown at 1940A-1940B. In addition, in some embodiments
location information for the vehicles is also sent to the cloud, although the
transmission of position information can occur as part of the breadcrumbs
message shown in Figure 9 rather than being separately sent in the process
of Figure 19B. For those embodiments where the satellite data is sent to the
cloud, the data is stored as shown at 1945A-1945B. The data can also include
date and time information. Again, it will be appreciated that, as an
alternative,
one vehicle may transmit its satellite data to the other vehicle and leave the
other vehicle to manage communication of that data to the NOG. Such load
sharing permits better utilization of the communications links as well as
permitting the non-responsible vehicle to perform other tasks.
[00137] Next, as shown in steps 1950A-1950B, one or both vehicles
determine which ones are the commonly viewable satellites, or other optimal
set of satellites, and limits their GPS receivers to relying upon only the
pseudoranging data from either the commonly viewable satellites or other
optimal set of satellites as shown at step 1955. It will be appreciated that
the
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
46
limitation can be imposed either in advance of processing, such that only
certain inputs are considered, or it can be imposed after processing by not
considering the data from satellites that are not commonly viewable or
otherwise part of the optimal set. It will be appreciated by those skilled in
the
art that the process of Figure 196 can take many forms, but, at bottom, the
objective is that each vehicle determines which satellites it can view, and
that
information is then either shared or not, but at least one of Vehicle A,
Vehicle
B, or the cloud/NOC, knows which satellites are in view for each vehicle, and
based on that knowledge the GPS receivers in each vehicle ultimately rely
only on data derived from the satellite that are optimal to each vehicle,
which
may be those that are commonly viewable. It will be appreciated that the
visibility of one or more satellites varies significantly with location, and
thus
the process of Figure 196 is, in at least some embodiments, repeated
regularly to ensure reliable relative position information for the vehicles
traveling in close proximity.
[00138] Turning next to Figure 190, an embodiment in which the cloud
determines which satellites should be relied upon by each vehicle can be
better understood. As with Figure 19B, vehicles A and B each determine
which satellites they can each view, shown at 1960A-1960B. Again, each
sends its satellite information to the cloud, steps 1965A-1965B, or,
alternatively, one offloads its satellite data to the other and allows the
other to
manage communications with the cloud. In either approach, the satellite IDs
viewable by each vehicle's GPS receiver are stored in the cloud, steps
1970A-1970B and including date and time in at least embodiments, where the
NOC or other cloud-based system determines which satellites should be
relied upon by each vehicle and messages both vehicles accordingly, step
1975. As with Figure 19B, the NOC or other cloud service receives location
information for each vehicle, such as shown in Figure 9, in a manner that
allows correlation with the satellite data.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
47
[00139] The process of Figure 190 permits vehicles C and D to rely on
information maintained in the cloud regarding the satellite that are commonly
viewable along a given route. Thus, at steps 1980A-1980B, vehicles C and D
each provide their location, date and time information to the cloud in the
routine manner. At step 1985, the cloud-based service or NOC retrieves from
its database the stored data for which satellites are viewable at the
locations
of vehicles C and D at those dates and times. The cloud then determines the
commonly viewable satellites and messages vehicles C and D accordingly. It
will be appreciated by those skilled in the art that, while the locations of
the
satellites changes, their paths are precisely predictable and thus it is
straightforward to compensate for the changes in satellite location that
naturally occur. Those skilled in the art will also appreciate that, in most
instances, the processes of Figures 19B-19D will occur when the vehicles are
relatively proximate to one another, typically within DSRC range, although
such proximity is not required in all instances or all embodiments.
[00140] In some locations, it is difficult for GPS receivers to see the
typical minimum of four satellites. For example, mountainous areas limit the
number of visible satellites. At the same time, it can be desirable to
calculate
and receive relative GPS position data in those locations. In such
challenging environments, an alternative approach can be to use
pseudorange data from satellites that are substantially collinear with the
vehicles velocity vector. Referring next to Figure 20A, for example, assume
that vehicles A and B, indicated at 100 and 105, respectively, are traveling
in
close proximity along a mountainous roadway. Because mountains rise up on
either side of the roadway, satellites positioned laterally to the vehicles
are not
visible. At the same time, Satellites 2000, 2010 and 2020 are visible, and
they are substantially collinear with the roadway. Thus, vehicle A has line of
sight 2000A to satellite 2000, line of sight 2010A to satellite 2010, and line
of
sight 2020A to satellite 2020. Vehicle B has similar lines of site as
indicated
on Figure 20A.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
48
[00141] In such an arrangement, relative position data for vehicle A
with
respect to vehicle B can be determined by the process shown in Figure 20B.
The process starts at steps 2030 and 2040 with each vehicle's GPS receivers
collecting the available pseudorange data from satellites 2000, 2010 and
2020. Then, at step 2050, the pseudorange data is combined by either
vehicle's control system or by a cloud-based server. Finally, at step 2060,
the
combined pseudorange data provides the gap distance between vehicles.
The gap distance determined in this manner can, of course, serve as one
modality of measuring gap, and used for validation of gap distance as
measured by the vehicles' local sensors in the various manners discussed
above.
[00142] One aspect of vehicles operating in close proximity to one
another, such as in a platoon of long-haul trucks, is how to anticipate
varying
road conditions. One particular aspect of road conditions in changes in the
grade of the roadway, such as for an incline. To reap the substantial benefits
of platooning, it is desirable to maintain platoon formation as much as
possible. Maintaining gap distance on an incline is typically difficult even
for
trucks of equal performance and carrying equal loads. If, as will sometimes
happen, the lead truck is more lightly loaded that the following truck, the
lead
truck will pull away from the following truck as the incline begins, and,
unless
the lead truck slows down ¨ undesirable in itself ¨ the following truck will
not
catch up until past the incline.
[00143] One approach to maintaining platoon position on an incline is to
anticipate the occurrence of the incline, and to increase engine torque by an
amount appropriate for the imminent incline. Such as approach can be better
appreciated from Figures 21A-21B. As shown in Figure 21A, vehicles 100
and 105 are traveling down a roadway 2100, with incline 2110 fast
approaching. The overall incline may include more than one incline section,
as shown at 2120. To maintain platooning efficiency in the face of such
changing road conditions, the process of Figure 21B can be implemented. In
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
49
particular, the process of Figure 21B involves retrieving road grade
information from the NOC database for routes, which is shown and discussed
in connection with Figures 12-15B. In particular, the road database is
augmented to include grade information, including identification of the
location
within a roadway segment where the incline begins. Such data can be readily
developed from the truck performance data provided to the NOC. Thus, the
process of Figure 21B starts by retrieving route information including grade
information from the route database, shown at step 2130, Next, at step 2140,
the time and distance to the upcoming grade is determined, followed, at step
2150, by determining the amount of torque adjustment appropriate to maintain
platoon formation on the upcoming grade, as well as the appropriate time to
modify the engine torque to achieve that adjustment. Those parameters are
then passed to the control system [see Figures 8A-8B, above] to cause the
vehicle to respond accordingly. The amount of engine torque increase,
acceleration, or other change to vehicle command, and the time at which is
can be best applied, can vary based on a number of factors, including vehicle
performance, vehicle load, and other issues of vehicle performance which will
be appreciated by those skilled in the art given the teachings herein.
[00144] 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 as
well as systems, processes and methodologies for integrating sensor data
with communicated data to yield improved identification of platoon partners as
well as providing increased safety for vehicles traveling in close proximity
and
improved platoon performance. Among the many advantages of such a
system are the ability to follow closely together in a safe, efficient,
convenient
manner, together with improved fuel economy, better fleet management,
improved proactive fleet and vehicle maintenance, reduced accident risk, and
numerous other benefits.
SUBSTITUTE SHEET (RULE 26)
CA 03004051 2018-05-02
WO 2017/070714
PCT/US2016/060167
[00145] 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.
SUBSTITUTE SHEET (RULE 26)
