Methods and systems for managing connected vehicles in mixed traffic

A method includes receiving, from connected vehicles, first locations of a first set of vehicles in an initial vehicle configuration; receiving, from a roadside unit, second locations of a second set of vehicles in the initial vehicle configuration; determining locations of connected vehicles and non-connected vehicles in the initial vehicle configuration based on the first locations and the second locations; determining an optimal vehicle configuration comprising desired locations of the connected vehicles and the non-connected vehicles based on the locations of the connected vehicles and the non-connected vehicles in the initial vehicle configuration, and predetermined optimization criteria; determining driving maneuvers to be performed by the connected vehicles to achieve the optimal vehicle configuration; and transmitting the determined driving maneuvers to the connected vehicles.

TECHNICAL FIELD

The present specification relates to managing connected vehicles, and more particularly, to methods and systems for managing connected vehicles in mixed traffic.

BACKGROUND

Connected vehicles are vehicles that use any of a number of different communication technologies to communicate with systems outside of the vehicle. Connected vehicles may communicate with other vehicles on the road using vehicle-to-vehicle (V2V) communication, or with roadside infrastructure, cloud servers, or other systems using vehicle-to-everything (V2X) communication or other communication protocols. Connected vehicles may transmit and/or receive a wide variety of data including sensor data, map data, weather data, driver intent data, and the like. This data shared by connected vehicles may increase vehicle safety or driving efficiency, may reduce traffic, may increase fuel efficiency, and may have other benefits to drivers and passengers of both the connected vehicles and non-connected vehicles. Connected vehicles may include human driven vehicles, in which data received by a vehicle may be presented to or used to assist the human driver (e.g., through a driving assistance system) and autonomous vehicles, in which the autonomous driving function of the vehicle may be adjusted based on data received by the vehicle.

It is expected that the number of connected vehicles on the road (both human driven and autonomous) will increase around the world in the next several decades. However, it is also expected that non-connected vehicles will continue to be driven in significant numbers. Accordingly, it is expected that mixed traffic (i.e., traffic that involves a combination of connected vehicles and non-connected vehicles) will become more common. As vehicles drive in such mixed traffic situations, there may be certain configurations or formations of connected and non-connected vehicles that lead to improved performance as measured by various metrics (e.g., traffic flow, fuel efficiency, etc.) compared to other vehicle configurations. Accordingly, a need exists for methods and systems for managing connected vehicles in mixed traffic.

SUMMARY

In one embodiment, a method may include receiving, from connected vehicles, first locations of a first set of vehicles in an initial vehicle configuration; receiving, from a roadside unit, second locations of a second set of vehicles in the initial vehicle configuration; determining locations of connected vehicles and non-connected vehicles in the initial vehicle configuration based on the first locations and the second locations; determining an optimal vehicle configuration comprising desired locations of the connected vehicles and the non-connected vehicles based on the locations of the connected vehicles and the non-connected vehicles in the initial vehicle configuration and predetermined optimization criteria; determining driving maneuvers to be performed by the connected vehicles to achieve the optimal vehicle configuration; and transmitting the determined driving maneuvers to the connected vehicles.

In another embodiment, a server may include a controller configured to receive, from connected vehicles, first locations of a first set of vehicles in an initial vehicle configuration; receive, from a roadside unit, second locations of a second set of vehicles in the initial vehicle configuration; determine locations of connected vehicles and non-connected vehicles in the initial vehicle configuration based on the first locations and the second locations; determine an optimal vehicle configuration comprising desired locations of the connected vehicles and the non-connected vehicles based on the locations of the connected vehicles and the non-connected vehicles in the initial vehicle configuration and predetermined optimization criteria; determine driving maneuvers to be performed by the connected vehicles to achieve the optimal vehicle configuration; and transmit the determined driving maneuvers to the connected vehicles.

DETAILED DESCRIPTION

The embodiments disclosed herein include systems and methods for managing connected vehicles in mixed traffic. In mixed traffic situations involving both connected vehicles and non-connected vehicles, there may be certain configurations or formations of the connected and non-connected vehicles that lead to better traffic flow and/or other beneficial outcomes. This may arise because non-connected vehicles have less perception capabilities than connected vehicles, which are able to receive data from other vehicles or other systems. As such, connected vehicles are able to leverage received data in order to improve driving efficiency or other metrics.

For example, connected vehicles may be more aware of upcoming road conditions, weather conditions, traffic patterns, or other factors that may allow the connected vehicles to adjust their driving behavior accordingly. Alternatively, the driving performance of non-connected vehicles is generally limited by the line of sight of the human driver. Thus, human drivers of non-connected vehicles may make sub-optimal driving decisions as compared to connected vehicles, which have more information upon which to make driving decisions.

When a mixed traffic environment comprises both connected vehicles and non-connected vehicles, the overall traffic flow may be affected by the specific configuration or formation of the vehicles. As discussed above, because non-connected vehicles lack the perception capabilities of connected vehicles, drivers of non-connected vehicles tend to make driving errors or perform less efficient driving than human drivers of connected vehicles or autonomous connected vehicles. Furthermore, when several human driven, non-connected vehicles are driven in a row without any connected vehicles between them, the driving errors or inefficiencies made by human drivers tend to be amplified. Alternatively, if one or more connected vehicles are placed between human driven non-connected vehicles in a vehicle configuration, the driving errors or inefficiencies of the human drivers may not be amplified, thereby improving overall traffic flow.

Accordingly, as disclosed herein, connected vehicles and/or roadside units may gather sensor data to determine a current vehicle configuration involving mixed traffic. In particular, the sensor data may be used to determine the current arrangement of vehicles (described herein as a vehicle configuration or a vehicle formation) in a vehicle configuration, including which vehicles are connected vehicles and which vehicles are non-connected vehicles. This data may then be transmitted to an edge server, which may determine an optimal vehicle configuration for the mixed traffic (e.g., by solving an optimization problem to optimize traffic flow or some other metric).

The edge server may determine driving maneuvers for each of the connected vehicles to perform in order to achieve the optimal vehicle configuration. The edge server may then transmit instructions containing the driving maneuvers to be performed by each of the connected vehicles to the respective vehicles. After receiving the instructions, each of the connected vehicles may perform the appropriate driving maneuvers in order to achieve the optimal vehicle configuration.

Turning now to the figures,FIG.1schematically depicts a system for managing connected vehicles in mixed traffic. A system100includes a roadside unit (RSU)102and an edge server104. The RSU102may receive data from one or more connected vehicles, as disclosed herein. In the example ofFIG.1, vehicles106,108, and110drive along road112adjacent to the RSU102. In the example ofFIG.1, vehicle106may be an autonomous connected vehicle, vehicle108may be a human driven, connected vehicle, and vehicle110may be a human driven, non-connected vehicle. However, it should be understood that in other examples, the system100may operate with any number of vehicles, including any number of human driven connected vehicles, any number of autonomous connected vehicles, and any number of non-connected vehicles. Each of the vehicles106,108,110may be an automobile or any other passenger or non-passenger vehicle such as, for example, a terrestrial, aquatic, and/or airborne vehicle including, but not limited to, a bus, a scooter, a drone, and a bicycle.

The RSU102is communicatively coupled to the vehicles106,108. The RSU102may be positioned near the road112such that it can be communicatively coupled to the vehicles,106,108. The system100may include any number of RSUs spaced along the road112such that each RSU covers a different service area. That is, as the vehicles106,108drive along the road112, the vehicles may be in range of different RSUs at different times such that a RSU provides coverage at different locations. Thus, as the vehicles106,108drive along the road112, they may move between coverage areas of different RSUs.

The RSU102may also be communicatively coupled to the edge server104. If the system100comprises a plurality of RSUs, multiple RSUs may be connected to the edge server104. In addition, the system100may include multiple edge servers, with each edge server being communicatively coupled to one or more RSUs. In some examples, the edge server104may be a moving edge server, such as another vehicle on the road112. Another vehicle as the moving edge server may be a lead vehicle of a vehicle platoon. For example, another vehicle and connected vehicles106and108may constitute a vehicle platoon. In some examples, the edge server104may be a cloud-based server.

As connected vehicles drive along the road112, the connected vehicles may gather sensor data and may transmit the sensor data to the edge server104. The RSU102may also gather sensor data regarding vehicles on the road112and may transmit this sensor data to the edge server104. The edge server104may receive the sensor data from the vehicles and from the RSU102and may determine an initial vehicle configuration (e.g., current positions of connected and non-connected vehicles) based on the received data. The edge server104may then determine an optimal vehicle configuration based on the initial vehicle configuration. The edge server104may further determine driving maneuvers to be performed by the connected vehicles in order to achieve the optimal vehicle configuration from the initial configuration based on certain optimization criteria. The edge server104may send instructions containing the driving maneuvers to the appropriate connected vehicles. The connected vehicles may then perform the driving maneuvers contained in the instructions to transform the initial vehicle configuration into the desired vehicle configuration.

In some examples, the system100may not include the RSU102and the functions described herein as being performed by the RSU102may be performed by the edge server104. In other examples, the system100may not include the edge server104and the functions described herein of the edge server104may be performed by the RSU102. Additional details of the connected vehicles, the RSU102, and the edge server104are discussed below.

FIG.2depicts a vehicle system200included in the vehicles106and108ofFIG.1. The vehicle system200includes one or more processors202, a communication path204, one or more memory modules206, a satellite antenna208, one or more vehicle sensors210, a network interface hardware212, and a data storage component214, the details of which will be set forth in the following paragraphs. The vehicle system200may be included in a human driven connected vehicle and in an autonomous connected vehicle.

Each of the one or more processors202may be any device capable of executing machine readable and executable instructions. Accordingly, each of the one or more processors202may be a controller, an integrated circuit, a microchip, a computer, or any other computing device. The one or more processors202are coupled to a communication path204that provides signal interconnectivity between various modules of the system. Accordingly, the communication path204may communicatively couple any number of processors202with one another, and allow the modules coupled to the communication path204to operate in a distributed computing environment. Specifically, each of the modules may operate as a node that may send and/or receive data. As used herein, the term “communicatively coupled” means that coupled components are capable of exchanging data signals with one another such as, for example, electrical signals via conductive medium, electromagnetic signals via air, optical signals via optical waveguides, and the like.

The vehicle system200includes one or more memory modules206coupled to the communication path204. The one or more memory modules206may comprise RAM, ROM, flash memories, hard drives, or any device capable of storing machine readable and executable instructions such that the machine readable and executable instructions can be accessed by the one or more processors202. The machine readable and executable instructions may comprise logic or algorithm(s) written in any programming language of any generation (e.g., 1GL, 2GL, 3GL, 4GL, or 5GL) such as, for example, machine language that may be directly executed by the processor, or assembly language, object-oriented programming (OOP), scripting languages, microcode, etc., that may be compiled or assembled into machine readable and executable instructions and stored on the one or more memory modules206. Alternatively, the machine readable and executable instructions may be written in a hardware description language (HDL), such as logic implemented via either a field-programmable gate array (FPGA) configuration or an application-specific integrated circuit (ASIC), or their equivalents. Accordingly, the methods described herein may be implemented in any conventional computer programming language, as pre-programmed hardware elements, or as a combination of hardware and software components.

Referring still toFIG.2, the vehicle system200comprises a satellite antenna208coupled to the communication path204such that the communication path204communicatively couples the satellite antenna208to other modules of the vehicle system200. The satellite antenna208is configured to receive signals from global positioning system satellites. Specifically, in one embodiment, the satellite antenna208includes one or more conductive elements that interact with electromagnetic signals transmitted by global positioning system satellites. The received signal is transformed into a data signal indicative of the location (e.g., latitude and longitude) of the satellite antenna208, and consequently, the vehicle containing the vehicle system200.

The vehicle system200comprises one or more vehicle sensors210. Each of the one or more vehicle sensors210is coupled to the communication path204and communicatively coupled to the one or more processors202. The one or more sensors210may include, but are not limited to, LiDAR sensors, RADAR sensors, optical sensors (e.g., cameras, laser sensors, proximity sensors, location sensors (e.g., GPS modules)), and the like. In embodiments, the sensors210may monitor the surroundings of the vehicle and may detect other vehicles on the road. In particular, the sensors210may determine locations of other vehicles (which may be connected vehicles and/or non-connected vehicles). For example, in the example ofFIG.1, the sensors210of the vehicle108may detect the vehicles106and110and determine their locations relative to the location of the vehicle108. In some examples, the sensors210may determine other information about detected vehicles (e.g., speeds of vehicles).

For autonomous vehicles, the vehicle system200may include an autonomous driving module (not shown) and the data gathered by the sensors210may be used by the autonomous driving module to autonomously navigate the vehicle. In both autonomous and non-autonomous connected vehicles, the data gathered by the sensors210may be used to manage connected vehicles, as disclosed in further detail below.

Still referring toFIG.2, the vehicle system200comprises network interface hardware212for communicatively coupling the vehicle system200to the edge server104and/or another vehicle system. The network interface hardware212can be communicatively coupled to the communication path204and can be any device capable of transmitting and/or receiving data via a network. Accordingly, the network interface hardware212can include a communication transceiver for sending and/or receiving any wired or wireless communication. For example, the network interface hardware212may include an antenna, a modem, LAN port, Wi-Fi card, WiMax card, mobile communications hardware, near-field communication hardware, satellite communication hardware and/or any wired or wireless hardware for communicating with other networks and/or devices. In one embodiment, the network interface hardware212includes hardware configured to operate in accordance with the Bluetooth® wireless communication protocol. In embodiments, the network interface hardware212of the vehicle system200may transmit sensor data gathered by the sensors210to the edge server104. In other embodiments, the network interface hardware212may transmit sensor data to the RSU102.

Still referring toFIG.2, the vehicle system200comprises a data storage component214. The data storage component214may store data used by various components of the vehicle system200. In addition, the data storage component214may store data gathered by the sensors210.

The vehicle system200may also include an interface (not shown). The interface may allow for data to be presented to a human driver and for data to be received from the driver. For example, the interface may include a screen to display information to a driver, speakers to present audio information to the driver, and a touch screen that may be used by the driver to input information. In other examples, the vehicle system200may include other types of interfaces.

In some embodiments, the vehicle system200may be communicatively coupled to the RSU102by a network (not shown). In one embodiment, the network may include one or more computer networks (e.g., a personal area network, a local area network, or a wide area network), cellular networks, satellite networks and/or a global positioning system and combinations thereof. Accordingly, the vehicle system200can be communicatively coupled to the network via a wide area network, via a local area network, via a personal area network, via a cellular network, via a satellite network, etc. Suitable local area networks may include wired Ethernet and/or wireless technologies such as, for example, wireless fidelity (Wi-Fi). Suitable personal area networks may include wireless technologies such as, for example, IrDA, Bluetooth®, Wireless USB, Z-Wave, ZigBee, and/or other near field communication protocols. Suitable cellular networks include, but are not limited to, technologies such as LTE, WiMAX, UMTS, CDMA, and GSM.

Now referring toFIG.3, the RSU102comprises one or more processors302, one or more memory modules304, network interface hardware306, one or more sensors308and a communication path310. The one or more processors302may be a controller, an integrated circuit, a microchip, a computer, or any other computing device. The one or more memory modules304may comprise RAM, ROM, flash memories, hard drives, or any device capable of storing machine readable and executable instructions such that the machine readable and executable instructions can be accessed by the one or more processors302.

The network interface hardware306can be communicatively coupled to the communication path310and can be any device capable of transmitting and/or receiving data via a network. Accordingly, the network interface hardware306can include a communication transceiver for sending and/or receiving any wired or wireless communication. For example, the network interface hardware306may include an antenna, a modem, LAN port, Wi-Fi card, WiMax card, mobile communications hardware, near-field communication hardware, satellite communication hardware and/or any wired or wireless hardware for communicating with other networks and/or devices. In one embodiment, the network interface hardware306includes hardware configured to operate in accordance with the Bluetooth® wireless communication protocol. The network interface hardware306of the RSU102may transmit and receive data to and from connected vehicles (e.g., vehicles106and108) and may transmit and receive data to and from the edge server104.

The one or more sensors308may include, but are not limited to, LiDAR sensors, RADAR sensors, optical sensors (e.g., cameras, laser sensors, proximity sensors, location sensors (e.g., GPS modules)), and the like. In embodiments, the sensors308may monitor and detect vehicles traveling along a road (e.g., the vehicles106,108,110ofFIG.1). In particular, the sensors308may determine positions of one or more vehicles traveling along a road. In the example ofFIG.1, the sensors308of the RSU102may be positioned along the road112and may use image data (e.g., camera images) to detect the locations of the vehicles106,108,110. In some examples, the RSU102may use other types of sensor data to determine vehicle locations. In some examples, the sensors308may determine other information about detected vehicles (e.g., speeds of vehicles).

The one or more memory modules304include a database312, a sensor data reception module314, and a data transmission module316. Each of the database312, the sensor data reception module314, and the data transmission module316may be a program module in the form of operating systems, application program modules, and other program modules stored in one or more memory modules304. In some embodiments, the program module may be stored in a remote storage device that may communicate with the RSU102. In some embodiments, one or more of the database312, the sensor data reception module314, and the data transmission module316may be stored in the one or more memory modules206of the vehicle system200of a vehicle. Such a program module may include, but is not limited to, routines, subroutines, programs, objects, components, data structures and the like for performing specific tasks or executing specific data types as will be described below.

The database312may temporarily store data collected by the one or more sensors308. The database312may also store other data that may be used by the memory modules304and/or other components of the RSU102.

The sensor data reception module314may receive data captured by the one or more sensors308. In one example, the RSU102may be positioned along a side of a road and the sensor308may comprise a camera. In this example, the sensor308(e.g., a camera) may capture images of the road which may be received by the sensor data reception module314. The sensor data reception module314may identify one or more vehicles in captured images (e.g., using image processing techniques). The sensor data reception module314may also determine locations of identified vehicles based on the data captured by the one or more sensors308(e.g., using image processing or other techniques). The data received by the sensor data reception module314and/or vehicle locations determined by the sensor data reception module314may be stored in the database312.

Referring still toFIG.3, the data transmission module316may transmit data to the edge server104. In particular, the data transmission module316may transmit vehicle location data comprising locations of vehicles determined by the sensor data reception module314. The edge server104may use the vehicle location data to determine an optimal vehicle configuration, as described in further detail below.

Now referring toFIG.4, the edge server104comprises one or more processors402, one or more memory modules404, network interface hardware406, and a communication path408. The one or more processors402may be a controller, an integrated circuit, a microchip, a computer, or any other computing device. The one or more memory modules404may comprise RAM, ROM, flash memories, hard drives, or any device capable of storing machine readable and executable instructions such that the machine readable and executable instructions can be accessed by the one or more processors402.

The network interface hardware406can be communicatively coupled to the communication path408and can be any device capable of transmitting and/or receiving data via a network. Accordingly, the network interface hardware406can include a communication transceiver for sending and/or receiving any wired or wireless communication. For example, the network interface hardware406may include an antenna, a modem, LAN port, Wi-Fi card, WiMax card, mobile communications hardware, near-field communication hardware, satellite communication hardware and/or any wired or wireless hardware for communicating with other networks and/or devices. In one embodiment, the network interface hardware406includes hardware configured to operate in accordance with the Bluetooth® wireless communication protocol. The network interface hardware406of the edge server104may transmit and receive data to and from connected vehicles (e.g., vehicles106and108in the example ofFIG.1) and the RSU102.

The one or more memory modules404include a database410, a data reception module412, a connected vehicle determination module414, a vehicle configuration optimization module416, a vehicle command generation module418, and a vehicle command transmission module420. Each of the database410, the data reception module412, the connected vehicle determination module414, the vehicle configuration optimization module416, the vehicle command generation module418, and the vehicle command transmission module420may be a program module in the form of operating systems, application program modules, and other program modules stored in one or more memory modules404. In some embodiments, the program module may be stored in a remote storage device that may communicate with the edge server104. In some embodiments, one or more of the database410, the data reception module412, the connected vehicle determination module414, the vehicle configuration optimization module416, the vehicle command generation module418, and the vehicle command transmission module420may be stored in the one or more memory modules304of the RSU102. Such a program module may include, but is not limited to, routines, subroutines, programs, objects, components, data structures and the like for performing specific tasks or executing specific data types as will be described below.

Still referring toFIG.4, the database410may temporarily store data received from connected vehicles and/or the RSU102. This data may include vehicle configuration data comprising positions of connected and non-connected vehicles in a vehicle configuration. The database410may also store other data that may be used by the other components of the edge server104.

Still referring toFIG.4, the data reception module412may receive data from connected vehicles and from the RSU102. As explained above, connected vehicles (e.g., vehicles106and108ofFIG.1) and the RSU102may transmit vehicle location data comprising locations of connected and non-connected vehicles in a vehicle configuration as determined by connected vehicles and the RSU102, respectively. This data may be received by the data reception module412. By receiving data from both connected vehicles and the RSU102, the edge server104may combine the received data to more accurately determine locations of vehicles in a vehicle configuration.

In embodiments, the data reception module412may fuse the data received from connected vehicles and from the RSU102into a single coordinate system. For example, if data received by the data reception module412comprises relative locations of vehicles (e.g., with respect to connected vehicles and/or the RSU102), the data reception module412may translate those relative locations into absolute locations based on the relative locations and the locations of the connected vehicles sending the data and the RSU102. As such, the locations of vehicles received from various connected vehicles and from the RSU102may be directly compared and aggregated. In some examples, the edge server104may only receive vehicle location data from connected vehicles. In other examples, the edge server104may only receive vehicle location data from the RSU102.

In some examples, the data reception module412may receive raw sensor data captured by sensors210of a vehicle system200(e.g., image data) and raw sensor data captured by the sensors308of the RSU102. In these examples, the data reception module412may identify vehicles and may determine locations of identified vehicles based on the raw sensor data (e.g., by using image processing techniques). In other examples, the vehicle system200and the RSU102may identify vehicles and determine locations of identified vehicles based on sensor data captured by the sensors210and308, respectively, and may transfer this data to the edge server104, which may be received by the data reception module412. The data received by the data reception module412may be stored in the database410.

In embodiments, the data reception module412may also receive locations of the connected vehicles that are transmitting sensor data (e.g., locations of the connected vehicles as determined by satellite antenna208of the connected vehicles themselves). The locations of the connected vehicles may be used by the connected vehicle determination module414to determine which identified vehicles are connected vehicles, as explained in further detail below.

Still referring toFIG.4, the connected vehicle determination module414may determine which vehicles identified by connected vehicles and/or the RSU102are connected vehicles and which vehicles are non-connected vehicles. In one example, the connected vehicle determination module414may determine which identified vehicles are connected vehicles by comparing the locations of vehicles identified by the sensors210of connected vehicles and the sensors308of the RSU102to the self-identified locations of the connected vehicles (e.g., locations of connected vehicles determined by the satellite antenna208of the connected vehicles themselves), as explained herein.

As explained above, the data reception module412may receive location data of vehicles detected by the sensors210of one or more connected vehicles as well as self-identified locations of each of the connected vehicles transmitting sensor data. As such, the connected vehicle determination module414may crosscheck the self-identified locations of connected vehicles against the vehicle locations determined based on the sensor data collected by the sensors210of connected vehicles and/or the sensors308of the RSU102. If a self-identified location of a connected vehicle matches a location of an identified vehicle determined based on sensor data, the connected vehicle determination module414may determine that the identified vehicle is a connected vehicle. Alternatively, if a location of an identified vehicle determined based on sensor data does not match any self-identified locations of connected vehicles, the connected vehicle determination module414may determine that identified vehicle is a non-connected vehicle.

Thus, the connected vehicle determination module414may determine which identified vehicles are connected vehicles and which identified vehicles are non-connected vehicles. This may allow for a determination of a vehicle configuration comprising one or more connected vehicles and one or more non-connected vehicles. For example,FIG.9shows a vehicle configuration900comprising connected vehicles A, B, C, D and E and non-connected vehicles a, b, c, d, e, f and g, which may be determined by the connected vehicle determination module414. In other examples, other methods of determining which identified vehicles are connected vehicles and which identified vehicles are non-connected vehicles may be used (e.g., making the determination directly from sensor data).

Still referring toFIG.4, the vehicle configuration optimization module416may determine an optimal vehicle configuration based on a current vehicle configuration received by the data reception module412. That is, given a current vehicle configuration comprising a number of connected vehicles and non-connected vehicles, the vehicle configuration optimization module416may determine an optimal vehicle configuration comprising the connected and non-connected vehicles. In particular, the vehicle configuration optimization module416may determine an optimal vehicle configuration such that certain constraints are maximized, as disclosed herein.

As explained above, certain vehicle configurations involving mixed traffic (i.e., a combination of connected vehicles and non-connected vehicles) may have improved traffic flow compared to other configurations. In addition, certain vehicle configurations involving mixed traffic may show improvements in other metrics (e.g., fuel efficiency).

For example,FIG.10shows three different vehicle configurations involving six vehicles. Each of the vehicle configurations ofFIG.10comprises three connected vehicles A, B and C and three non-connected vehicles a, b and c. In vehicle configuration1000, the three connected vehicles A, b and C are positioned together consecutively and the three non-connected vehicles a, b and c are positioned together consecutively. As such, configuration1000is sub-optimal with respect to traffic flow because the three non-connected vehicles being clumped together may tend to magnify driving inefficiencies caused by human drivers without connected vehicle assistance.

In vehicle configuration1002, non-connected vehicles b and are positioned together consecutively but non-connected vehicle a is separated from the other non-connected vehicles by connected vehicles A and B. As such, vehicle configuration1002may tend to have better performance with respect to traffic flow than vehicle configuration1000because there are only two non-connected vehicles together. As such, human driving inefficiencies are less likely to be magnified.

In vehicle configuration1004, each of the non-connected vehicles a, b and c is separated from each other by a connected vehicle. As such, vehicle configuration1004may be an optimal configuration for a set of vehicles comprising three connected vehicles and three non-connected vehicles.

The vehicle configuration optimization module416may utilize a variety of techniques to determine an optimal vehicle configuration, as disclosed herein. In one example, the vehicle configuration optimization module416may determine a number of candidate vehicle configurations that may be achieved from a current vehicle configuration, and may perform a simulation of each candidate vehicle configuration to measure one or more performance metrics (e.g., traffic flow, fuel efficiency, etc.). For example, given a current vehicle configuration comprising three connected vehicles and three non-connected vehicles, the vehicle configuration optimization module416may determine vehicle configurations1000,1002, and1004ofFIG.10as candidate vehicle configurations. The vehicle configuration optimization module416may consider additional arrangements of the six vehicles A, B, C, a, b and c ofFIG.10as other candidate configurations. The vehicle configuration optimization module416may then perform a simulation of each of the candidate vehicle configurations1000,1002,1004(or other additional candidate configurations) to determine one or more performance metrics. The simulation results may then return determined performance metrics associated with each of the simulations. In embodiments, each simulation result may return a numerical value of one or more performance metrics associated with each simulation (e.g., an amount of time for the vehicle configuration to travel a certain distance as a measure of traffic flow). In some examples, the simulations may be performed remotely from the edge server104(e.g., by a cloud-based server).

In other examples, the vehicle configuration optimization module416may compare candidate vehicle configurations to a database of known vehicle configurations. Each known vehicle configuration may have one or more predetermined performance metrics associated with it. For example, the vehicle configurations1000,1002, and1004may all be stored in a database along with one or more numerical values comprising values of one or more performance metrics associated with each vehicle configuration (e.g., traffic flow, fuel efficiency, etc.). In these examples, the vehicle configuration optimization module416may determine a number of candidate vehicle configurations and may compare each candidate configuration to the known vehicle configurations in the database. The vehicle configuration optimization module416may, for each candidate configuration, determine which known vehicle configuration is most similar to the candidate configuration. The vehicle configuration optimization module416may then assign the performance metrics associated with the most similar known configuration to the candidate configuration. As such, the vehicle configuration optimization module416may estimate performance metrics for each of a number of candidate configurations. In some examples, a database of known candidate configurations may be stored in the database410in the edge server104. In other examples, the database of known candidate configurations may be stored remotely from the edge server104(e.g., in a cloud-based server).

In some examples, the vehicle configuration optimization module416may utilize one of the above techniques to determine an optimal vehicle configuration given a current vehicle configuration. In one example, the vehicle configuration optimization module416may select a vehicle configuration that maximizes a particular performance metric (e.g., traffic flow or fuel efficiency). In other examples, the vehicle configuration optimization module416may weight different performance metrics and may select a vehicle configuration that maximizes a weighted value of multiple performance metrics. For example, the vehicle configuration optimization module416may assign a certain weight to traffic flow and another weight to fuel efficiency. The vehicle configuration optimization module416may then determine which vehicle configuration among a plurality of candidate configurations maximizes a combination of traffic flow and fuel efficiency given the assigned weights. Alternatively, in some examples, the vehicle configuration optimization module416may also consider costs of achieving vehicle configurations, as discussed below.

While it may be most desirable to achieve the most optimal vehicle configuration given a current vehicle configuration, there may be certain configurations that are more difficult to achieve than other configurations given a current vehicle configurations. For example, referring toFIG.11, an initial vehicle configuration1100is shown comprising connected vehicles A, B and C and non-connected vehicles a, b, and c. Two candidate configuration1102and1104are shown as well. Given the initial vehicle configuration1100, vehicle configuration1102can be achieved by having connected vehicle A move into the left lane, slow down to allow non-connected vehicle a to pass it, and then re-join the right lane behind non-connected vehicle a. Alternatively, achieving vehicle configuration1104from configuration1100requires connected vehicle B to move into the left lane, accelerate to pass non-connected vehicle b, and then re-join the right lane between non-connected vehicles b and c. Thus, it is more difficult to achieve vehicle configuration1104from initial vehicle configuration1100than it is to achieve vehicle configuration1102from initial vehicle configuration1100since achieving vehicle configuration1104requires additional acceleration by a connected vehicle and a more challenging lane change. As such, vehicle configuration1102has a higher proximity to configuration1100and vehicle configuration1104has a lower proximity to configuration1100.

If one configuration is easier to achieve than another configuration, given a current vehicle configuration, it may be desirable to achieve the easier to achieve configuration rather than the more difficult configuration, even if the easier to achieve configuration is less optimal. This is because achieving a particular vehicle configuration requires certain costs (e.g., vehicle accelerations that use more fuel, possibility of error or accident, etc.). Accordingly, in some examples, the vehicle configuration optimization module416may consider the costs of achieving a vehicle configuration when determining a desired final vehicle configuration given an initial vehicle configuration.

In embodiments, the vehicle configuration optimization module416may determine a cost associated with achieving each of a plurality of candidate vehicle configurations given an initial vehicle configuration. The determined cost may comprise a number of factors. For example, the cost may comprise a total number of lane changes that need to be performed, a total amount of acceleration that needs to be performed across all vehicles (e.g., a total amount of energy that must be used), and the like. The vehicle configuration optimization module416may then weight one or more performance metrics and one or more costs associated with each of a plurality of a candidate vehicle configurations and determine an optimal vehicle configuration from among the candidate vehicle configurations based on the weighted performance metrics and the weighted costs.

In some examples, the vehicle configuration optimization module416may determine a feasibility of achieving a particular candidate vehicle configuration. In embodiments, the vehicle configuration optimization module416may determine feasibility based on one or more costs of achieving a particular vehicle configuration, as discussed above. For example, if achieving a particular vehicle configuration given an initial vehicle configuration requires a large amount of vehicles to perform complicated vehicle maneuvers, it may be desirable to instead select a different vehicle configuration that may be less optimal (in terms of traffic flow or other vehicle metrics) but that is easier to achieve. In some examples, the vehicle configuration optimization module416may determine that it is not feasible to achieve a particular vehicle configuration given an initial vehicle configuration if the costs of achieving that vehicle configuration (such as the costs discussed above) is above a predetermined threshold value.

In some examples, the vehicle configuration optimization module416may determine the costs of achieving a particular vehicle configuration based on the performance capabilities of one or more of the connected vehicles that would be required to perform vehicle maneuvers. For example, the vehicle configuration optimization module416may determine the acceleration capabilities of a connected vehicle when determining the costs associated with that vehicle perform certain vehicle maneuvers. In these examples, the connected vehicles may transmit performance capabilities to the RSU102, which may be relayed to the edge server104. The vehicle configuration optimization module416may consider vehicle performance when determining costs of achieving a vehicle configuration.

Referring back toFIG.4, the vehicle command generation module418may determine one or more vehicle maneuvers to be performed by one or more connected vehicles to achieve an optimal vehicle configuration, as determined by the vehicle configuration optimization module416, given a current vehicle configuration. For example,FIG.12shows an initial vehicle configuration1200comprising four connected vehicles, A, B, C and D and four non-connected vehicles a, b, c and d.FIG.12also shows a desired vehicle configuration1202that may be determined by the vehicle configuration optimization module416.

FIG.13shows a procedure that may be followed such that the vehicles A, B, C, D, a, b, c and may transition from the vehicle configuration1200to the vehicle configuration1202inFIG.12. As shown inFIG.13, the procedure may involve connected vehicle D using the left lane to merge between non-connected vehicles c and d, connected vehicle C using the left lane to merge between non-connected vehicles b and c, connected vehicle B using the left land to merge between non-connected vehicles a and b, and connected vehicle A staying in its current lane and maintaining a specified speed. As such, the vehicle command generation module418may determine this procedure comprising instructions (e.g., vehicle maneuvers) for each of the connected vehicles A, B, C and D.FIG.14shows the initial vehicle configuration1200and the final desired vehicle configuration1202ofFIG.12, and an intermediate configuration1201that may be achieved while the connected vehicles A, B, C and D are performing vehicle instructions determined by the vehicle command generation module418.

Referring back toFIG.4, the vehicle command transmission module420may transmit the vehicle instructions determined by the vehicle command generation module418to the appropriate vehicles. That is, after the vehicle command generation module418determines driving instructions for each connected vehicle of an initial vehicle configuration, as described above, the vehicle command transmission module420may transmit each of these driving instructions to the appropriate connected vehicles to perform the driving maneuvers contained in the instructions. In some examples, the vehicle command transmission module420of the edge server104may transmit the vehicle instructions to the RSU102, which may then relay the instructions to the appropriate vehicles.

FIG.5depicts a flowchart for managing connected vehicles in mixed traffic that may be performed by a human-driven connected vehicle having the vehicle system200ofFIG.2. In step500, the one or more sensors210of the vehicle system200may collect sensor data comprising information about the surroundings of the vehicle. The data captured by the sensors210may be used by the vehicle system200and/or the edge server104to identify locations of one or more vehicles on a road such that a vehicle configuration comprising one or more connected vehicles and/or one or more non-connected vehicles may be determined.

In step502, the network interface hardware212may transmit the sensor data detected by the sensors210to the edge server104. The network interface hardware212may also transmit a position of the connected vehicle to the edge server104. The edge server104may use the sensor data to determine locations of vehicles in a vehicle configuration and the RSU102may use the position of the connected vehicles (along with positions received from other connected vehicles) to determine which vehicles in a vehicle configuration are connected vehicles and which are non-connected vehicles.

In step504, the network interface hardware212may receive driving instructions from the edge server104. The driving instructions may comprise driving maneuvers to be performed by the connected vehicle in order to achieve a desired vehicle configuration determined by the edge server104.

In step506, the driving instructions received by the network interface hardware212may be displayed such that they can be seen by the human driver. In some examples, the driving instructions may be displayed on a screen (e.g., a navigation system). In other examples, the driving instructions may be audibly read to the driver (e.g., by an audio navigation system). In other examples, the received driving instructions may be otherwise conveyed to the driver. The driver may then perform the driving maneuvers contained in the driving instructions in order to achieve the desired vehicle configuration determined by the edge server.

FIG.6depicts a flowchart for managing connected vehicles in mixed traffic that may be performed by an autonomous connected vehicle having the vehicle system200ofFIG.2. In step600, the one or more sensors210of the vehicle system200may collect sensor data comprising information about the surroundings of the vehicle. In step602, the network interface hardware212may transmit the sensor data detected by the sensors210to the edge server104. The network interface hardware212may also transmit a position of the connected vehicle to the edge server104.

In step604, the network interface hardware212may receive driving instructions from the edge server104, which may comprise driving maneuvers to be performed by the connected vehicle in order to achieve a desired vehicle configuration determined by the edge server104. In step606, the driving maneuvers contained in the driving instructions may be performed by the autonomous vehicle. As such, the vehicle may autonomously perform the driving maneuvers to achieve the desired vehicle configuration determined by the edge server.

FIG.7depicts a flowchart for managing connected vehicles in mixed traffic that may be performed by the RSU102. In step700, the one or more sensors308of the RSU102may collect sensor data comprising information about vehicles traveling along a road portion. The sensor data may be received by the sensor data reception module314. The sensor data reception module314may identify locations of one or more vehicles based on the received sensor data.

In step702, the data transmission module316may transmit the sensor data received by the sensor data reception module314and/or vehicle locations determined by the sensor data reception module314to the edge server104.

FIG.8depicts a flowchart for managing connected vehicles in mixed traffic that may be performed by the edge server104. In step800, the data reception module412of the edge server104may receive sensor data from one or more connected vehicles and from the RSU102. The received sensor data may comprise locations of one or more vehicles in a vehicle configuration. The data reception module412may also receive self-identified positions of the connected vehicles transmitting sensor data. In some examples, the edge server104receives sensor data only from connected vehicles and in other examples, the edge server104receives sensor data only from the RSU102.

In step802, the connected vehicle determination module414may determine which vehicles identified in the data received by the data reception module412are connected vehicles and which vehicles are non-connected vehicles. The connected vehicle determination module414may make this determination based on the locations of identified vehicles received by the data reception module412and the self-identified locations of connected vehicles received by the data reception module412. In some examples, the data received by the data reception module412may directly identify which vehicles are connected and non-connected vehicles and, in these examples, step802may be omitted.

In step804, the vehicle configuration optimization module416may determine an optimal vehicle configuration for the vehicles identified in the sensor data received by the data reception module412based on the initial vehicle configuration and one or more optimization criteria. The optimization criteria may include one or more performance metrics to be achieved by the optimal vehicle configuration and one or more costs required to achieve the optimal vehicle configuration from the initial vehicle configuration. Accordingly, the vehicle configuration optimization module416may formulate an optimization problem based on the optimization criteria and may then solved the optimization problem to determine the optimal vehicle configuration. As explained above, the vehicle configuration optimization module416may solve the optimization problem by simulating candidate vehicle configurations, comparing candidate vehicle configurations to known configurations in a look-up table, or using other methods.

In step806, the vehicle command generation module418may determine driving instructions comprising vehicle maneuvers to be performed by the connected vehicles in the initial vehicle configuration to reach the desired optimal vehicle configuration. Then, in step808, the vehicle command transmission module420may transmit the determined driving instructions to the appropriate connected vehicles.

FIG.15shows an example situation of managing connected vehicles in mixed traffic involving a freeway1500comprising lanes1502,1504, and1506and an on-ramp1508. In the example ofFIG.15, a connected vehicle A, a connected vehicle B, and one non-connected vehicle are driving in lane1504and a plurality of non-connected vehicles are driving in lane1506. In addition, a connected vehicle C, a connected vehicle D, and a plurality of non-connected vehicles are attempting to merge onto the freeway1500using the on-ramp1508.

In the example ofFIG.1500, the vehicle configuration optimization module416may determine a desired vehicle configuration to minimize the time required for the vehicles to merge onto the freeway1500to ensure a high flow of traffic on the freeway1500. Accordingly, the vehicle configuration optimization module416may use the above techniques to determine an optimal configuration. In the example ofFIG.15, the vehicle configuration optimization module416may determine that the optimal configuration is to insert connected vehicles A and B into the lane1506. Then, the connected vehicles A and B may be able to adjust their speed to allow for the merging vehicles to easily merge onto the freeway1500. Thus,FIG.16shows an initial vehicle configuration1600, corresponding to the vehicle configuration ofFIG.15, and a desired vehicle configuration1602that may be determined by the vehicle configuration optimization module416.

FIG.17shows a visualization of driving maneuvers that may be performed by connected vehicles A and B to achieve the desired vehicle configuration1602from the initial vehicle configuration1600. Namely, connected vehicles A and B should merge into lane1506from lane1504. Accordingly, the vehicle command generation module418may determine these driving maneuvers to be performed by vehicles A and B and the vehicle command transmission module420may transmit these driving instructions to vehicles A and B.

FIG.18shows the connected vehicles A and B in the initial vehicle configuration1600and in the desired vehicle configuration1602. Once the connected vehicles A and B are in the optimal vehicle configuration, they may adjust their speed in order to allow for the connected vehicles C and D and the non-connected vehicles merging onto the freeway1500to easily merge, thereby increasing traffic flow.

It should now be understood that embodiments described herein are directed to methods and systems for managing connected vehicles in mixed traffic. Connected vehicles may gather sensor data to identify other vehicles on the road. A roadside unit may also gather sensor data to identify vehicles on the road. The connected vehicles and the roadside unit may transfer the gathered sensor data to an edge server. The edge server may determine an initial vehicle configuration based on the received sensor data. The initial vehicle configuration may comprise a particular arrangement of connected and non-connected vehicles.

The edge server may then determine an optimal vehicle configuration of the connected and non-connected vehicles in the initial vehicle configuration that optimizes certain optimization criteria. The optimization criteria may include one or more performance metrics of a final vehicle configuration (e.g., traffic flow) and one or more costs required to achieve the final vehicle configuration (e.g., total amount of accelerations to be performed by connected vehicles in reaching the final vehicle configuration). The edge server may solve an optimization problem to determine an optimal final vehicle configuration based on the initial vehicle configuration and the optimization criteria.

After determining an optimal vehicle configuration, the edge server may determine driving maneuvers to be performed by the connected vehicles in the initial vehicle configuration to reach the optimal vehicle configuration. The edge server may transmit driving instructions comprising the determined driving maneuvers to the appropriate connected vehicles. The connected vehicles may receive the driving instructions and may perform the driving maneuvers contained therein. For autonomous connected vehicles, the vehicles may perform the driving maneuvers autonomously. For human driven connected vehicles, the vehicles may display the driving maneuvers to a driver who may perform the displayed driving maneuvers. After all of the connected vehicles have performed the appropriate driving maneuvers, the optimal vehicle configuration may be achieved.