Patent Application
20210148716
Embodiments of the present invention relate generally to a method, apparatus, and computer program product for providing information for the operations of platoons including routing of a group of vehicles to include platooning, and more particularly, to multi-vehicle aware routing and scheduling for platoon formation and optimization.
The number of vehicles on roadways is increasing at a rate that outpaces the construction of new roadways and additional roadway capacity. Further, budget constraints limit the ability to construct new roadways and to handle the aging roadway infrastructure presently in place. To address the challenges posed by the growing traffic volumes and a lack of resources or ability to widen or add roadways, alternative measures for increasing efficiency of existing roadways is needed. Instead of adding new roadways or adding vehicle lanes to existing roadways, methods of increasing the efficiency of use of existing roadways can reduce traffic congestion, increase roadway safety, and prolong the life of existing roadway infrastructure.
Along with volume comes greater energy consumption for vehicles traveling along road networks. Vehicle manufacturers strive to improve vehicle efficiency through costly developments and advances. The efficiency of vehicles can be further improved based on use, such as through using more efficient driving habits and cooperating to improve vehicle efficiency through platooning of vehicles. Platooning involves vehicles traveling together in formation, such as in a “platoon” formation where vehicles typically follow one another in a line. Platooning, as described herein, involves vehicles operating together in a formation to improve overall efficiency of the platooning vehicles, such as through close following and steady-state operating speeds as frequently as possible. However, platooning can be complex and difficult to implement in an efficient manner.
A method, apparatus and computer program product are therefore provided according to an example embodiment of the present disclosure for generating platooning plans for a plurality of vehicles, and identifying appropriate joining points at which the vehicles join to form a platoon along their respective routes. Methods may include: receiving a first trip request associated with a first vehicle including a first trip origin and a first trip destination; receiving a second trip request associated with a second vehicle including a second trip origin and a second trip destination, where the first trip origin is different from the second trip origin; generating a platooning plan that includes a first route associated with the first vehicle and a second route associated with the second vehicle, where the first route and the second route overlap for at least a portion of their respective routes forming an overlapping route; identifying a plurality of fixed points proximate the overlapping route; selecting one of the plurality of fixed points as a joining point where the first vehicle and the second vehicle form a platoon for driving along the overlapping route; and providing the first route to the first vehicle and the second route to the second vehicle, where the first route and the second route each include the joining point as a waypoint.
Methods may include defining a boundary around at least a portion of the overlapping route, where identifying a plurality of fixed points includes identifying fixed points within the boundary where the boundary is defined based on at least one of a distance or travel time from the overlapping route. Methods may include establishing a weight for each of the plurality of fixed points, where the weight is established based on at least one of distance from the overlapping route, distance along the overlapping route from a start of the overlapping route, or time of travel to or from the overlapping route. The weight of each fixed point may be further based on at least one of accessibility or facilities available at the respective fixed point. The boundary may be further defined to extend along the overlapping route until a break point at which it is established that platooning starting at the break point no longer provides an efficiency improvement over not platooning. Methods may include: providing navigational assistance to the first vehicle along the first route to include a scheduled time of arrival at the joining point, and providing navigational assistance to the second vehicle along the second route to include a scheduled time of arrival at the joining point. Identifying a plurality of fixed points proximate the overlapping route may include identifying a plurality of fixed points proximate the overlapping route that satisfy at least one predetermined criteria required by at least one of the first vehicle or the second vehicle. Methods may optionally include generating a list of fixed points suitable for formation of a platoon and updating the list of fixed points suitable for formation of a platoon.
Embodiments provided herein may include an apparatus having at least one processor and at least one memory including computer program code. The at least one memory and the computer program code configured to, with the processor, cause the apparatus to at least: receive a first trip request associated with a first vehicle including a first trip origin and a first trip destination; receive a second trip request associated with a second vehicle including a second trip origin and a second trip destination, where the first trip origin is different from the second trip origin; generate a platooning plan that includes a first route associated with the first vehicle and a second route associated with the second vehicle, where the first route and the second route overlap for at least a portion of their respective routes forming an overlapping route; identify a plurality of fixed points proximate the overlapping route; select one of the plurality of fixed points as a joining point where the first vehicle and the second vehicle form a platoon for driving along the overlapping route; and provide the first route to the first vehicle and the second route to the second vehicle, where the first route and the second route each include the joining point as a waypoint. The apparatus may be caused to define a boundary around at least a portion of the overlapping route, where identifying a plurality of fixed points may include identifying fixed points within the boundary, where the boundary is defined based on at least one of a distance or a travel time from the overlapping route.
According to some embodiments, the apparatus may be caused to establish a weight for each of the plurality of fixed points, where the weight is based on at least one of a distance from the overlapping route, distance along the overlapping route from a start of the overlapping route, or a time of travel to or from the overlapping route. The weight of each fixed point may be based on at least one of accessibility or facilities available at the respective fixed point. The boundary may be defined to extend along the overlapping route until a break point at which it is established that platooning starting at the break point no longer provides an efficiency improvement over not platooning. The apparatus of some embodiments may be caused to: provide navigational assistance to the first vehicle along the first route to include a scheduled time of arrival at the joining point; and provide navigational assistance to the second vehicle along the second route to include a scheduled time of arrival at the joining point. Causing the apparatus to identify a plurality of fixed points proximate the overlapping route may include causing the apparatus to identify a plurality of fixed points proximate the overlapping route that satisfy at least one predetermined criteria required by at least one of the first vehicle and the second vehicle. An apparatus of example embodiments may be caused to generate a list of fixed points suitable for formation of a platoon and update the list of fixed points suitable for formation of a platoon.
Embodiments provided herein may include a computer program product having at least one non-transitory computer-readable storage medium having computer-executable program code portions stored therein. The computer-executable program code portions including program code instructions to: receive a first trip request associated with a first vehicle including a first trip origin and a first trip destination; receive a second trip request associated with a second vehicle including a second trip origin and a second trip destination, where the first trip origin is different from the second trip origin; generate a platooning plan that includes a first route associated with the first vehicle and a second route associated with the second vehicle, where the first route and the second route overlap for at least a portion of their respective routes forming an overlapping route; identify a plurality of fixed points proximate the overlapping route; select one of the plurality of fixed points as a joining point where the first vehicle and the second vehicle form a platoon for driving along the overlapping route; and provide the first route to the first vehicle and the second route to the second vehicle, where the first route and the second route include the joining point as a waypoint.
According to some embodiments, the computer program product may include program code instructions to: define a boundary around at least a portion of the overlapping route, where identifying a plurality of fixed points includes identifying fixed points within the boundary, where the boundary is defined based on at least one of a distance or travel time from the overlapping route. Embodiments may include program code instructions to establish a weight for each of the plurality of fixed points, where the weight is based on at least one of distance from the overlapping route, distance along the overlapping route from a start of the overlapping route, or time of travel to or from the overlapping route. The weight of each fixed point may be based on at least one of accessibility or facilities available at the respective fixed point. The boundary may be further defined to extend along the overlapping route until a break point at which it is established that platooning starting at the break point no longer provides an efficiency improvement over not platooning. Embodiments may include program code instructions to: provide navigational assistance to the first vehicle along the first route to include a scheduled time of arrival at the joining point; and provide navigational assistance to the second vehicle along the second route to include a scheduled time of arrival at the joining point.
Embodiments provided herein may include an apparatus including: means for receiving a first trip request associated with a first vehicle including a first trip origin and a first trip destination; means for receiving a second trip request associated with a second vehicle including a second trip origin and a second trip destination, where the first trip origin is different from the second trip origin; means for generating a platooning plan that includes a first route associated with the first vehicle and a second route associated with the second vehicle, where the first route and the second route overlap for at least a portion of their respective routes forming an overlapping route; means for identifying a plurality of fixed points proximate the overlapping route; means for selecting one of the plurality of fixed points as a joining point where the first vehicle and the second vehicle form a platoon for driving along the overlapping route; and means for providing the first route to the first vehicle and the second route to the second vehicle, where the first route and the second route each include the joining point as a waypoint.
An apparatus of example embodiments may include means for defining a boundary around at least a portion of the overlapping route, where the means for identifying a plurality of fixed points includes means for identifying fixed points within the boundary where the boundary is defined based on at least one of a distance or travel time from the overlapping route. The apparatus may include means for establishing a weight for each of the plurality of fixed points, where the weight is established based on at least one of distance from the overlapping route, distance along the overlapping route from a start of the overlapping route, or time of travel to or from the overlapping route. The weight of each fixed point may be further based on at least one of accessibility or facilities available at the respective fixed point. The boundary may be further defined to extend along the overlapping route until a break point at which it is established that platooning starting at the break point no longer provides an efficiency improvement over not platooning. The apparatus may include means for providing navigational assistance to the first vehicle along the first route to include a scheduled time of arrival at the joining point, and means for providing navigational assistance to the second vehicle along the second route to include a scheduled time of arrival at the joining point. The means for identifying a plurality of fixed points proximate the overlapping route may include means for identifying a plurality of fixed points proximate the overlapping route that satisfy at least one predetermined criteria required by at least one of the first vehicle or the second vehicle.
Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Some example embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments are shown. Indeed, the example embodiments may take many different forms and should not be constructed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout. The terms “data,” “content,” “information,” and similar terms may be used interchangeably, according to some example embodiments, to refer to data capable of being transmitted, received, operated on, and/or stored.
In general, some embodiments presented herein are directed to grouping vehicles together into platoons for travel from an origin to a destination across a transportation network. A route may be defined as a path between a particular origin and a particular destination, where multiple routes may exist between those same origin and destination points. A trip may be a particular route taken by a vehicle between an origin and a destination. Thus, while a route is not vehicle specific, each trip is necessarily specific to the vehicle making that trip. Further, while example embodiments described herein may be directed primarily toward vehicles such as cars, trucks, and buses, traveling along roadways, example embodiments may be implemented for vehicles such as trains, aircraft, boats, or the like. While the benefits of the invention described herein with regard to road-going vehicles supports increased efficiency of vehicles traveling along an existing network of roads, implementations of the invention may provide improved air-traffic safety and a reduction in air-traffic congestion, or similar benefits among water vessels or vehicles traveling along railways.
Grouping vehicles into platoons is a method that may increase the capacity of a network of roadways while also providing benefits to the vehicles of the platoon. A platoon of vehicles may be a group of vehicles that travel with a predefined distance or range of distance between them, and in some cases, vehicles may be coupled to one another via mechanical means or via electrical/computer-based means such as an “electronic tow-bar”. Electrical or computer-based means for coupling vehicles may be performed through partial automation with adaptive cruise control that helps a driver maintain a safe distance from a leading vehicle, or full automation such as with driverless vehicles that follow a lead vehicle without driver input. When groups of vehicles are assembled into platoons, many benefits may be achieved. One benefit may include improved energy efficiency of the vehicles involved through less unnecessary braking resulting in accordion-like fluctuations in traffic and increased fuel efficiency achieved by following vehicles drafting behind leading vehicles (e.g., reducing the forces caused by drag). Road capacity may increase as a result of grouping vehicles into platoons as following distances or time-gaps between vehicles may be reduced, while vehicle speeds may be more consistent (e.g., less stop-and-go). Grouping vehicles into platoons may also increase safety through more consistent traffic flow and less individual driver responsibility.
As noted above, grouping of vehicles into platoons may be achieved in vehicles having no automation, such as conventional, human-driven automobiles, vehicles having partial automation, such as a human driver with driver assistance software features (e.g., adaptive cruise control), vehicles having full automation where they are driven via computer without requiring a driver, or any combination thereof. The maximum benefit of grouping of vehicles may be achieved when vehicles are fully automated to be driven by computers as vehicle-to-vehicle communications may allow shorter following distances between vehicles and communication of vehicles within one platoon to vehicles within another platoon. Example embodiments described herein may use computers and computer program products to facilitate the grouping of vehicles into platoons, and in the case of fully autonomous, driverless vehicles, may also control the vehicles to join them to platoons. In either scenario, an apparatus that supports communication between vehicles may be used to facilitate the joining and departing of vehicles from platoons, along with determining the appropriate platoon for a vehicle to join.
Referring now of
The user devices 10 and 16 may be embodied by a number of different devices including mobile computing devices, such as a personal digital assistant (PDA), mobile telephone, smartphone, laptop computer, tablet computer, vehicle navigation system, infotainment system, in-vehicle computer, or any combination of the aforementioned, and other types of voice and text communications systems. The server 12 may also be embodied by a computing device and, in one embodiment, is embodied by a web server. Additionally, while the system of
Regardless of the type of device that embodies the user devices 10 or 16, the user devices may include or be associated with an apparatus 20 as shown in
In some embodiments, the processor 22 (and/or co-processors or any other processing circuitry assisting or otherwise associated with the processor) may be in communication with the memory device 24 via a bus for passing information among components of the apparatus. The memory device 24 may include, for example, one or more volatile and/or non-volatile memories. In other words, for example, the memory device 24 may be an electronic storage device (e.g., a computer readable storage medium) comprising gates configured to store data (e.g., bits) that may be retrievable by a machine (e.g., a computing device like the processor). The memory device 24 may be configured to store information, data, content, applications, instructions, or the like for enabling the apparatus 20 to carry out various functions in accordance with an example embodiment of the present invention. For example, the memory device 24 could be configured to buffer input data for processing by the processor 22. Additionally or alternatively, the memory device could be configured to store instructions for execution by the processor.
The processor 22 may be embodied in a number of different ways. For example, the processor 22 may be embodied as one or more of various hardware processing means such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing element with or without an accompanying DSP, or various other processing circuitry including integrated circuits such as, for example, an ASIC (application specific integrated circuit), an FPGA (field programmable gate array), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like. As such, in some embodiments, the processor may include one or more processing cores configured to perform independently. A multi-core processor may enable multiprocessing within a single physical package. Additionally or alternatively, the processor 22 may include one or more processors configured in tandem via the bus to enable independent execution of instructions, pipelining and/or multithreading.
In an example embodiment, the processor 22 may be configured to execute instructions stored in the memory device 24 or otherwise accessible to the processor 22. Alternatively or additionally, the processor 22 may be configured to execute hard coded functionality. As such, whether configured by hardware or software methods, or by a combination thereof, the processor 22 may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment of the present invention while configured accordingly. Thus, for example, when the processor 22 is embodied as an ASIC, FPGA or the like, the processor 22 may be specifically configured hardware for conducting the operations described herein. Alternatively, as another example, when the processor 22 is embodied as an executor of software instructions, the instructions may specifically configure the processor 22 to perform the algorithms and/or operations described herein when the instructions are executed. However, in some cases, the processor 22 may be a processor of a specific device (e.g., a head-mounted display) configured to employ an embodiment of the present invention by further configuration of the processor 22 by instructions for performing the algorithms and/or operations described herein. The processor 22 may include, among other things, a clock, an arithmetic logic unit (ALU) and logic gates configured to support operation of the processor 22. In one embodiment, the processor 22 may also include user interface circuitry configured to control at least some functions of one or more elements of the user interface 28.
Meanwhile, the communication interface 26 may include various components, such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data between a computing device (e.g. user device 10 or 16) and a server 12. In this regard, the communication interface 26 may include, for example, an antenna (or multiple antennas) and supporting hardware and/or software for enabling communications wirelessly. Additionally or alternatively, the communication interface 26 may include the circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or to handle receipt of signals received via the antenna(s). For example, the communications interface 26 may be configured to communicate wirelessly with a head-mounted display, such as via Wi-Fi (e.g., vehicular Wi-Fi standard 802.11p), Bluetooth, mobile communications standards (e.g., 3G, 4G, or 5G) or other wireless communications techniques. In some instances, the communication interface 26 may alternatively or also support wired communication. As such, for example, the communication interface 26 may include a communication modem and/or other hardware/software for supporting communication via cable, digital subscriber line (DSL), universal serial bus (USB) or other mechanisms. For example, the communication interface 26 may be configured to communicate via wired communication with other components of a computing device.
The user interface 28 may be in communication with the processor 22, such as the user interface circuitry, to receive an indication of a user input and/or to provide an audible, visual, mechanical, or other output to a user. As such, the user interface 28 may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen display, a microphone, a speaker, and/or other input/output mechanisms. In some embodiments, a display may refer to display on a screen, on a wall, on glasses (e.g., near-eye-display), in the air, etc. The user interface 28 may also be in communication with the memory 24 and/or the communication interface 26, such as via a bus.
The communication interface 26 may facilitate communication between different user devices and/or between the server 12 and user devices 10 or 16. The communications interface 26 may be capable of operating in accordance with various first generation (1G), second generation (2G), 2.5G, third-generation (3G) communication protocols, fourth-generation (4G) communication protocols, Internet Protocol Multimedia Subsystem (IMS) communication protocols (e.g., session initiation protocol (SIP)), and/or the like. For example, a mobile terminal may be capable of operating in accordance with 2G wireless communication protocols IS-136 (Time Division Multiple Access (TDMA)), Global System for Mobile communications (GSM), IS-95 (Code Division Multiple Access (CDMA)), and/or the like. Also, for example, the mobile terminal may be capable of operating in accordance with 2.5G wireless communication protocols General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), and/or the like. Further, for example, the mobile terminal may be capable of operating in accordance with 3G wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), and/or the like. The mobile terminal may be additionally capable of operating in accordance with 3.9G wireless communication protocols such as Long Term Evolution (LTE) or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and/or the like. Additionally, for example, the mobile terminal may be capable of operating in accordance with fourth-generation (4G) wireless communication protocols and/or the like as well as similar wireless communication protocols that may be developed in the future.
Example embodiments described herein may implement a method of grouping vehicles together in a platoon that is facilitated by a server (e.g. a platoon matching exchange server 32 as shown in
In the interest of safety, redundant communication protocols may be used to ensure reliable, consistent communication between devices. For example, while two vehicles may be in communication with each other (e.g., the respective user devices of each vehicle are in communication with one another) via a 4G communication protocol using cellular phone towers as communication access points. Upon entry into a tunnel, the 4G communication may be compromised. A secondary communication protocol, such as a near-field communication protocol (e.g., Bluetooth™) may be used to supplement the 4G communication protocol in the event 4G communications are lost or compromised. In this manner, communication between vehicles may be maintained.
Grouping of vehicles into platoons may require advanced knowledge of an intended destination or waypoint for a vehicle. Routes may be planned in advance in response to a user providing an indication of a destination. An origin can be identified by the current location of a user/vehicle, or independently entered by a user if different than their location when selecting the destination. Embodiments described herein may implement a central, cloud-based platoon matching exchange, which may be hosted by a server (e.g. server 12 or platoon matching exchange server 32), which could continually ingest origins, destinations, and acceptable parameters of a trip for a particular vehicle in order to appropriately match each vehicle with a platoon that would most appropriately and efficiently align with the user's planned trip. Parameters for a trip may include, for example, waypoints, types of roadways (e.g., avoiding interstate highways or preferring interstate highways), other vehicles making the trip associated with the user (e.g., if a company has a fleet of vehicles traveling on a given road network sharing routes of the trips partially or entirely), timing of the trip (e.g., departure or desired arrival) etc. The trip parameters including origin and destination may be used by the platoon matching exchange to align vehicles with suitable platoons. The destination of the vehicle can be inputted or derived from historic vehicle sensor data. Trip parameters for a given vehicle may optionally include a planned route, planned stops, expected speed, current position, fuel economy, vehicle dynamics properties (e.g., size, shape, frontal area, drag coefficient, weight, etc.), and preferences regarding a platoon. Each of these trip preferences may be broadcast to a server (e.g. server 12 or platoon matching exchange server 32) over a secure network link together with the trip requirements (origin, destination, and possibly time of departure or arrival).
Routes for each vehicle of a group may be planned based on a variety of influencing factors to facilitate navigation between an origin and a destination. A route, in the context of this application, is a set of instructions guiding a human or automated driving system from a start location or origin to a destination in a road network. The route may be represented by a sequence of road links, one or more of which compose a segment representing a road segment. A waypoint may be a place, such as a town, point-of-interest, or other location such as a street address through which a user wants to travel or at which a user intends to stop during a journey to an ultimate destination. Waypoints, as described herein, are locations that do not include the origin or destination, but are locations along a route or points along the route at which an event may occur, such as a join event or a leave event to or from a platoon. A route may include any number of waypoints or may include no waypoints.
Routing is the process of computing a route. In the current context, the defined route is intended to be used (driven) by vehicles that depart from the origin in order to arrive at the destination within given time constraints. Identifying a shortest route along a road network is a task that needs to be solved in order to generate a route. This problem is ubiquitous and significant development has occurred to establish efficient algorithms. One such algorithm is the Dijkstra algorithm that solves the shortest path problem with high efficiency. The routing problem may be modelled as finding a path in a graph data structure such that Dijkstra's algorithm can be applied to route computation. The unique structure of road networks and the relatively slow rate of infrastructure change may allow for further optimization by pre-processing the road network data and specialized heuristics. Many variations of the routing problem exist beyond the shortest path routing. Alternative routes may be established to include an optimal order to visit a set of waypoints (e.g., the traveling salesman problem), real-time routing, optimal efficiency routing (e.g., shortest time vs. shortest distance), etc.
A routing engine may include a system or software that receives as inputs a route specification and computes a route matching that specification. Such systems may be hosted on a server (e.g., server 12 or platoon matching exchange server 32) and may provide an application programming interface (API) to access the system. The routing engine may use a database containing detailed information that is required to enable a computer to generate a high-quality driving route between two locations. The information may include items such as road geometry, street names, addresses, speed limits, turn restrictions, one-way restrictions, road levels, and roadway connections.
Vehicle routing is generally ego-centric in that the routing considers factors such as traffic, weather, or other road conditions to determine an optimal route for a single vehicle between a specified origin and destination. Other existing or potential vehicle routes do not influence how the route is computed. While traffic may represent other vehicles driving at a particular time, it is their presence that influences an ego-centric route, and not the route of any other vehicles. In other words, it is not the route of any vehicles traveling among a road network that defines the traffic which influences routing decisions, it is their location on the road network and the volume of vehicles that facilitates traffic-aware routing. Thus, traffic-aware routing does not consider other routes, but instead traffic congestion among the road network. However, for fleets of vehicles, particularly commercial vehicles, embodiments described herein provide benefits of a routing engine operating on a group of vehicles where routing is aware of the other vehicles and their respective origins and destinations. In order to find an efficient route not only for a single vehicle, but for a fleet of vehicles, routes may be optimized for an explicit set of vehicles, while taking into account a collaboration dimension through platoon formations. A routing engine of example embodiments does not focus only on optimizing a single vehicle's route, but instead considers the other vehicles and produces routes that are enhanced by traveling in a platoon with other vehicles.
For commercial vehicles, such as trucks and larger vehicles that generally consume more energy (e.g., gas, electrical, etc.) than a typical passenger vehicle, platooning can significantly reduce the cost of operation due to a multitude of direct factors, such as reduced aerodynamic drag to improve fuel consumption, or due to other indirect factors such as driver cost reduction or improved driver safety due to automation or partial automation. While all vehicles may be able to benefit from platooning, vehicles with higher baseline energy consumption may realize greater absolute efficiency improvements rendering platooning even more viable. Embodiments described herein analyze driving schedules and routes for multiple vehicles in fleets or groups in order to meet and form platoons to maximize efficiency while also meeting routing constraints, such as origin and destinations, available time windows for departure, and available time windows for arrival at the destination.
Embodiments described herein provide a computer system, such as the server 12 of
Embodiments include a system, embodied on a server (e.g., server 12 and/or platoon matching exchange server 32) that receives as input data needed for routing a plurality of vehicles and outputs a set of routes and schedules along with information about meeting and break-up points of vehicles in order to facilitate platoon formation. Embodiments optimize the returned routes and schedules in such a way that the cost savings for the entire system or for parts of the system (e.g., for certain specified fleets) are maximized. The maximization of platooning time and/or distance is presumed to lead to increased cost savings and efficiencies, as observed through fuel or energy savings achieved by vehicles driving in platoons due to reduced drag. Other factors may intervene as well, but may be regulatory and economic decisions, such as decrease of driver costs, insurance premium reductions, etc. These factors, along with other key performance indicators can be used to optimize the routing of the plurality of vehicles such that a symbiotic relationship is achieved among the vehicles, and benefits are realized by individual vehicles and/or by fleet operators that operate multiple vehicles. According to an example embodiment in which a fleet operator operates multiple vehicles that are to be routed together to cooperate in a platoon for at least a portion of the route, one vehicle may not realize any improvement in efficiency or may even see a slight degradation in efficiency at the expense of other vehicles in the platoon which do benefit and see improved efficiencies as a result of the platooning plan. As such, the overall efficiency of the group may be of greater importance than the individual vehicles. This embodiment may further be applied to vehicles that are not part of a fleet, but that are part of a community of vehicles, whereby even if a particular vehicle does not realize efficiency improvements, the community may compensate that vehicle for its contributions to the efficiency improvements to the community, such as through an application which provides payments or credits to a vehicle that sacrificially improved the efficiencies of other vehicles.
A routing request where platooning is not considered, such as a conventional routing request may include where a server receives a route request from a vehicle and consider traffic data, road conditions, weather, etc. The server may further consider routing constraints such as time of departure, time window of arrival, shortest, fewest tolls, road regulation requirements (e.g., hazardous cargo, height restrictions, width restrictions, etc.). A routing engine of the server, such as processor 22, may generate a route for the vehicle individually.
Embodiments described herein operate in a different manner such that the vehicles may cooperate in a symbiotic relationship and provide an improved overall efficiency of the vehicles participating in a platoon for at least a portion of their route. According to an example embodiment, a first vehicle 29 submits a routing request to platoon matching exchange server 32, as shown in
While the example embodiment of the routing plans for the three vehicles of
A platooning plan including routes for vehicles participating in the platooning plan may include routes that are not necessarily the most efficient or fastest for an individual vehicle if it was traveling on its own. For example, the routes shown in
Cooperative routing of multiple vehicles into platoons along portions of their routes may be challenging as timing and schedules of vehicles traveling along the routes may render joining of vehicles to a platoon difficult. While route guidance may enable the requested slowing or speeding up of a vehicle traveling along a route in order to intersect another route at a predefined time at which a platoon may be joined, the speeding up or slowing down of a vehicle may be limited as the vehicle must still travel at a safe speed along the route. As such, embodiments described herein may introduce temporary stops to hold a vehicle at a location in order to ensure arrival of that vehicle at a platoon joining location at a prescribed time.
An example embodiment of a dispatcher workflow is herein described with respect to three vehicles, such as vehicles 29, 30, and 31. While embodiments are described with respect to three vehicles, embodiments may be implemented for any number of vehicles. According to an example embodiment, a fleet dispatcher may be a person that has the role of dispatching vehicles of a fleet in order to transport goods or people to destinations. The fleet dispatcher may plan the routes of three vehicles, such as the first vehicle 29 from point A to point B, the second vehicle 30 from point C to point D, and the third vehicle 31 from point E to point F. As described herein, generating the routes at a server may consider traffic data, road conditions, road topography, weather, etc. The routing may further consider routing constraints such as time window of departure, time window for arrival, etc. Further, the routing may consider road regulations for platooning, such as whether platooning is allowed along a road section or what are the allowed parameters for platooning, such as number of vehicles, total platoon weight, distance between vehicles, etc. Using this input information, a routing request may be submitted for each of the first, second, and third vehicle 29, 30, 31 at the same time to the platoon matching exchange server 32 as shown in
Embodiments described herein may include a planning scenario in which a list of driving routes and schedules for a set of vehicles that, at any given time of the interval covered by the scenario, specifies information about the vehicles including position, direction, speed, etc., and foreseen road information. A state of the system is to be determined according to the following information, including: positions, routes, schedules, and routing constraints of the vehicles, along with road information which may include road conditions, traffic, weather, regulatory constraints, etc. Once the vehicles of a given planning scenario begin to follow their respective routes in the platooning plan, at any given moment the current state of the system is following the state specified within the planning scenario. However, an event can occur which is a deviation of the current state of the system relative to a planning scenario. At a given time, state deviation could mean a deviation such as: road status information has changed (e.g., there is a traffic jam affecting one or more vehicle routes) or new restrictions for platooning are in place. Deviations may include that new vehicles with respective driving routes and schedules may be entered into the system.
An event may trigger the system to recompute a planning scenario in order to maximize the platooning key performance indicators which may be optimized to improve cost savings across the fleet of vehicles. The event may result in one or more of: a new route and/or a new schedule. Further, the system may compute new platooning plans for the affected vehicles that must implement the changes. The system may compute these changes continuously on every event and create or update existing plans until the starting time of one of the vehicles is close enough so that the planning (e.g., the routing and timing details) for a route is locked. On further planning iterations, the route and schedule details of those locked routes will not be changed any further but held fixed. New routes and schedules may be communicated by the system either directly to the vehicles as shown in
Events may optionally include one or more vehicles that are at different points than specified in the platooning plan, such as when a vehicle is late. Embodiments provided herein may continuously or periodically monitor the status of vehicles as to a location, speed, heading, etc. and compare that status with the planned status of the platoon plan generated as described above. In the case of an event, one vehicle that is driving can be re-routed or re-scheduled if the efficiency advantages of the platooning plan would be diminished or lost based on the event. Platooning plans can change based on a preference of a server (e.g. platoon matching exchange server 32) which may be dictated by a fleet operator or by a community of drivers. The preferences may include how to handle different types of events, and to what degree of flexibility may be offered by platooning plans, such as how long one or more vehicles may wait or deviate from an original platooning plan in the event of a delay of another of the vehicles in the platooning plan.
Embodiments described herein provide a mechanism by which platooning may be made more accessible and available for vehicles. By considering the planned routes of a multitude of vehicles, platooning opportunities may be identified and routes may be altered to capitalize on platooning opportunities that would otherwise not be available if a vehicle was routed independently. Therefore, embodiments of the present disclosure may improve the likelihood of platooning through a measurable improvement in efficiency through symbiotic planning of vehicles in a fleet or a community in order to benefit the whole of the fleet or community through cooperation among vehicles.
While the aforementioned examples provide a mechanism by which platooning plans are made in view of cooperative routing, in order to platoon, vehicles need to establish appropriate waypoints at which to form platoons and begin driving as a platoon. A manual mechanism for establishing these joining points or meeting points may include searching maps of a region, communication, and coordination between vehicles, which is time consuming and inefficient. Further, this process must ensure that the selected joining points are located in the right places along the routes and that the vehicles can reach their destinations according to the estimated times of arrival. Platoon formation may include en-route formation where platoons are formed without vehicles stopping, and stand-still formation where vehicles meet at a fixed location and depart the location as a platoon. The establishment of joining points as described below may preferably relate to stand-still platoon formation; however, embodiments may be implemented for en-route formation where joining points are established as portions of a route along which vehicles may join together to form a platoon.
Joining points should satisfy certain criteria to be considered as appropriate joining points for starting a platoon. Factors to consider for joining points may include whether they are accessible and eligible for the considered vehicle type. For example, large trucks may not be able to easily maneuver through narrow roadways or residential areas, and upon arrival may have nowhere to park. Joining points for large trucks may require ample parking and wide roadways for access. Another factor to consider may include proximity to roadways along which the platoon will travel, and accessibility to those roadways in a reasonable time to avoid substantial deviations from a direct route. Joining points may need to offer proper exits and entrances to/from the road in order to allow vehicles in a platoon to maneuver in a safe manner.
Embodiments provided herein may provide a routing engine, such as the routing engine embodied by platoon matching exchange server 32 with the ability to automate the search of such joining points and guide vehicles to the appropriate joining point at the scheduled joining time. These joining points may be pre-defined formation points and can be described as platooning meeting points identified as a type of waypoint. The server of example embodiments may access a collection of formation points which are suitable for platooning purposes which may be stored, for example, in memory 24. The formation points or fixed points may include properties that indicate characteristics of the formation point, such as accessibility and parking availability for large vehicles. Other properties which may be included may provide for conveniences such as restrooms, fuel stations, charging stations, etc. The routing engine of the server may identify candidate formation points for a vehicle along a vehicle's route that corresponds with properties of the vehicle. A database of fixed points may be generated and stored in a memory, where the database may be updated periodically or in response to a trigger, such as based on new potential fixed points found in a region. The routing solution may calculate deviations from the original vehicle routes to the formation points and establish if the formation point is within a predefined limit of distance or time to the original route to be considered as a joining point for that route. The evaluation of whether a formation point may be a joining point may be based on the efficiency realized by joining the platoon and the cost (e.g., distance and time) of reaching the joining point.
Once the platooning plan has been generated, a joining point for the vehicles needs to be identified. The routing engine may identify along the segment 62 formation points that are potential candidates for joining points.
The various routes of different vehicles in a platooning plan may include a plurality of segments of the respective routes, where driving context, regulations, and vehicle control can be different among the different segments of a route. While a vehicle may be driven according to a first set of regulations relating to a road segment along that road segment, once the vehicle joins a platoon the regulations may change, and rules pertaining to the platoon may alter how the vehicle is driven. In order to distinguish the rules and regulations applied to a particular vehicle along a road and in different contexts (e.g., platooning or not platooning), the different segments may require definition. Embodiments described herein provide a route segmentation method that distinguishes segments of a route in order to identify the distinct rules and regulations that may apply along the different segments.
Based on the segmentation points, route segments may be established. The first vehicle 29 traveling between point A and point B includes segment 2 between point A and point G, segment 3 between point G and point H, segment 5 between points H and I, segment 7 between point I and point J, and segment 8 between point J and point B. The route of the second vehicle 30 includes segment 1 between point C and point G, segment 3 between point G and point H, shared with the first vehicle 29, and segment 4 between point H and point D. The route of the third vehicle 31 includes segment 6 between point E and point I, segment 7 between point I and point J, shared by the first vehicle 29, and segment 9 between point J and point F.
Each of the segments of the three vehicles identified in
The data may include a segment identifier, unique to the segment. The data may also include the latitude/longitude of where the segment starts and where the segment ends, link identifiers of road links of the segment and of the start point and end point. Beyond the data and information relating to the road segment itself, data may also include regulations relating to the travel of the vehicle along the route. For example, the segment data may include a platoon plan including identifying vehicles with which a vehicle is platooning along the segment, a vehicle order in the platoon, a minimum and/or maximum separation/following distance between vehicles in the platoon along the segment, maximum number of platooning vehicles permitted along the segment, minimum and/or maximum speed permitted for platoons along the segment, one or more times at which a vehicle is to reach one or more points along the segment, or other data relating to vehicle travel along the respective segment.
Platooning plans may change frequently for a variety of reasons. For example, more vehicles may be added to a platoon which may impact the platooning plan of existing vehicles, weather conditions may influence platooning plans, road conditions, vehicles delayed from participating in the platoon, etc. Embodiments described herein provide an efficient manner of manipulating a platooning plan on a segment level such that platooning plan changes may only be applied to segments that are affected by the changes to the platooning plan.
The differences between road segments may include rules and/or regulations that alter how a road segment is driven. For example, a vehicle may be manually driven or semi-autonomously driven along a first road segment, such as the second vehicle 30 along segment 1 in
As platooning may provide the ability for vehicles to travel in a semi-autonomous or autonomous manner through a virtual link or “electronic tow-bar”, driving or control of the lead vehicle may incur additional responsibility while following or trailing vehicles may rely largely on the actions of the lead vehicle. For example, a lead vehicle may be manually driven or semi-autonomously driven having a driver for feedback and control. Trailing vehicles may use autonomous or semi-autonomous control to maintain following distances and to follow the lead of the vehicle in front of them. This may be performed by one or both of sensors of the trailing vehicle providing information regarding a vehicle they are following, or the vehicle they are following and the lead vehicle may provide information via communication link to the trailing vehicle regarding path, following distance, speed, braking, evasive maneuvers, etc.
As the trailing vehicles in a platoon may require very close following distances to realize their full efficiency improvement, autonomous or semi-autonomous control may be necessary to maintain a close following distance while also being able to brake effectively when a standard following distance/time required by a human may not be available. As the gap between a trailing vehicle and a vehicle being followed may be very narrow, the time required for a human driver to react from the moment a braking event was signaled and acknowledged until the human can apply the brakes reactively may be too long, thereby requiring at least some degree of autonomy for safety. Thus, in a platoon formation, safety actions may be handled by a platoon system and autonomous vehicle controls of a vehicle. Embodiments provided herein provide information to drivers and platoon systems that relate to whether platooning is permitted or recommended, and how platooning should be performed along a road segment.
In order for autonomous vehicle control or semi-autonomous vehicle control in a platoon to be effective, the platoon system may benefit from an awareness of the surrounding road conditions. Embodiments described herein provide platooning systems and vehicles of the platoon with information that is passed to drivers and fleet dispatchers about road conditions and restrictions in order to adapt the platooning drive and formations accordingly. Further, the driving clearance system for platooning described herein may provide input to route coordination and dispatching systems for fleets or for platoon formation optimization, thus helping the optimization of schedules and driven routes.
The driving clearance system for platooning as described herein is a tool that provides information regarding whether platooning is permitted along a given portion of a road network, and if so, the relevant restrictions and rules relating to platooning along the given portion. The information may be processed and used by three target audiences: vehicles that may participate in a platoon, drivers of those vehicles, and dispatch/fleet coordination systems.
Embodiments described herein may provide information relating to road segments and links relating to static information, semi-dynamic information, and dynamic information. Static information may include regulations about platooning on a particular road segment, such as whether platooning is allowed, minimum/maximum speeds of platoons, total platoon length, total platoon weight, minimum/maximum following distances, etc. The static information for a road segment may not change or may very rarely change; however, the static information may be dependent upon other types of information, such as following distances may be different for different contexts, such as longer following distances required at night or during inclement weather, for example. Semi-dynamic information may be any kind of road status information that is persistent for a temporary period and to the extent possible, planned. This information may include road construction, detours, closures, etc. Dynamic information may depend on factors not directly related to the road network itself and that may happen spontaneously, such as traffic density, weather, road surface information, etc.
The static, semi-dynamic, and dynamic information of example embodiments may be used to provide platooning instructions with regard to various aspects of platooning, such as platoon speed, following distance, platoon total weight, platoon total length, number of vehicles in the platoon, etc. Embodiments provided herein aggregate information from a plurality of sources regarding platooning clearance and conditions for a predetermined road (segment or link), along a given route of a vehicle, and within a specified area. This aggregation and analysis of information is used to establish a comprehensive platooning clearance plan to communicate to the vehicles of a platoon.
Embodiments may include a rules engine 112 that may include rules which identify whether platooning is allowed, under what circumstances platooning is allowed, and what platooning parameters are applicable. The rules of the rules engine 112 may be modifiable based on information associated with a road segment, which may be provided, for example, by a municipality or governmental body, such as a department of transportation. An application programming interface (API) 114 may enable external actors 116 to query the system for platooning clearance 118 on a given time and date for a particular road segment, along a given route of a vehicle, and/or within a specified area. The processing circuitry 126 may process the input of the API 114 request to aggregate the relevant information from the existing information sources, query the rules engine to extract the applicable rules for the aggregated data, and articulate a response for the relevant type of data. The aggregated data and rules may be applied by the processor 122 in order to generate a response to the platooning clearance request 118.
The platooning clearance information 124 generated by example embodiments described herein may be provided to a driver or user of an autonomous/semi-autonomous vehicle, and/or to the vehicle itself, such as to an advanced driving assistance system to inform an autonomous or semi-autonomous vehicle regarding the platooning clearance information. When informing a vehicle of the platooning clearance information, the information may not require visualization for presentation as the advanced driver assistance system can interpret the information. However, when communicating the platooning clearance information to a user or driver, such as from a fleet dispatcher, the information may be visually presented to provide meaningful and easily interpreted information to the driver.
As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (e.g., hardware) to produce a machine, such that the resulting computer or other programmable apparatus provides for implementation of the functions specified in the flowchart block(s). These computer program instructions may also be stored in a non-transitory computer-readable storage memory that may direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage memory produce an article of manufacture, the execution of which implements the function specified in the flowchart block(s).
The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide operations for implementing the functions specified in the flowchart block(s). As such, the operations of
Accordingly, blocks of the flowchart support combinations of means for performing the specified functions and combinations of operations for performing the specified functions. It will also be understood that one or more blocks of the flowcharts, and combinations of blocks in the flowcharts, can be implemented by special purpose hardware-based computer systems which perform the specified functions, or combinations of special purpose hardware and computer instructions.
In some embodiments, certain ones of the operations herein may be modified or further amplified as described below. Moreover, in some embodiments additional optional operations may also be included. It should be appreciated that each of the modifications, optional additions or amplifications below may be included with the operations above either alone or in combination with any others among the features described herein.
Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although the foregoing descriptions and the associated drawings describe example embodiments in the context of certain example combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
