and torque converter 16 via clutch 15. Clutch 15 can be implemented as, for example, a multiple disc type hydraulic frictional engagement device whose engagement is controlled by an actuator such as a hydraulic actuator. Clutch 15 may be controlled such that its engagement state is complete engagement, slip engagement, and complete disengagement complete disengagement, depending on the pressure applied to the clutch. For example, a torque capacity of clutch 15 may be controlled according to the hydraulic pressure supplied from a hydraulic control circuit (not illustrated). When clutch 15 is engaged, power transmission is provided in the power transmission path between crankshaft 32 and torque converter 16. On the other hand, when clutch 15 is disengaged, motive power from engine 14 is not delivered to the torque converter 16. In a slip engagement state, clutch 15 is engaged, and motive power is provided to torque converter 16 according to a torque capacity (transmission torque) of the clutch 15.

As alluded to above, vehicle 10 may include electronic control unit 50. Electronic control unit 50 may include circuitry to control various aspects of the vehicle operation. Electronic control unit 50 may include, for example, a microcomputer that includes a one or more processing units (e.g., microprocessors), memory storage (e.g., RAM, ROM, etc.), and I/O devices. The processing units of electronic control unit 50, execute instructions stored in memory to control one or more electrical systems or subsystems 48 in the vehicle. Electronic control unit 50 can include a plurality of electronic control units such as, for example, an electronic engine control module, a powertrain control module, a transmission control module, a suspension control module, a body control module, and so on. As a further example, electronic control units can be included to control systems and functions such as doors and door locking, lighting, human-machine interfaces, cruise control, telematics, braking systems (e.g., ABS or ESC), battery management systems, and so on. These various control units can be implemented using two or more separate electronic control units or using a single electronic control unit.

In the example illustrated in FIG. 2, electronic control unit 50 receives information from a plurality of sensors included in vehicle 10. For example, electronic control unit 50 may receive signals that indicate vehicle operating conditions or characteristics, or signals that can be used to derive vehicle operating conditions or characteristics. These may include, but are not limited to accelerator operation amount, ACC, a revolution speed, N_E, of internal combustion engine 14 (engine RPM), a rotational speed of the motor 22 (motor rotational speed), N_MG, and vehicle speed, V. These may also include torque converter 16 output, N_T(e.g., output amps indicative of motor output), brake operation amount/pressure, B, battery (i.e., the charged amount for battery 44 detected by an system on chip (SOC) sensor). Accordingly, vehicle 10 can include a plurality of sensors 52 that can be used to detect various conditions internal or external to the vehicle and provide sensed conditions to electronic control unit 50 (which, again, may be implemented as one or more individual control circuits). In one embodiment, sensors 52 may be included to detect one or more conditions directly or indirectly such as, for example, fuel efficiency, E_F, motor efficiency, E_MG, hybrid (e.g., ICE 14 and MG 12) efficiency, acceleration, ACC, etc.

Additionally, one or more sensors 52 can be configured to detect, and/or sense position and orientation changes of the vehicle 10, such as, for example, based on inertial acceleration. In one or more arrangements, electronic control unit 50 can obtain signals from vehicle sensor(s) including accelerometers, one or more gyroscopes, an inertial measurement unit (IMU), a dead-reckoning system, a global navigation satellite system (GNSS), a global positioning system (GPS), a navigation system, and/or other suitable sensors. In one or more arrangements, electronic control unit 50 receives signals from a speedometer to determine a current speed of the vehicle 10.

In some embodiments, one or more of the sensors 52 may include their own processing capability to compute the results for additional information that can be provided to electronic control unit 50. In other embodiments, one or more sensors may be data-gathering-only sensors that provide only raw data to electronic control unit 50. In further embodiments, hybrid sensors may be included that provide a combination of raw data and processed data to electronic control unit 50. Sensors 52 may provide an analog output or a digital output. Additionally, as alluded to above, the one or more sensors 52 can be configured to detect, and/or sense in real-time. As used herein, the term “real-time” means a level of processing responsiveness that a user or system senses as sufficiently immediate for a particular process or determination to be made, or that enables the processor to keep up with some external process.

While some sensors can be used to actively detect passive environmental objects, other sensors can be included and used to detect active objects such as those objects used to implement smart roadways that may actively transmit and/or receive data or other information. Accordingly, the one or more sensors 52 can be configured to acquire, and/or sense driving environment data. For example, environment sensors can be configured to detect, quantify and/or sense objects in at least a portion of the external environment of the vehicle 10 and/or information/data about such objects. Such objects can be stationary objects and/or dynamic objects. Further, the sensors can be configured to detect, measure, quantify and/or sense other things in the external environment of the vehicle 10, such as, for example, lane markers, signs, traffic lights, traffic signs, lane lines, crosswalks, curbs proximate the vehicle 10, off-road objects, etc.

Sensors 52 may be included to detect not only vehicle conditions but also to detect external conditions as well. Sensors that might be used to detect external conditions can include, for example, sonar, radar, lidar or other vehicle proximity sensors, and cameras or other image sensors. In some embodiments, cameras can be high dynamic range (HDR) cameras or infrared (IR) cameras. Image sensors can be used to detect, for example, traffic signs indicating a current speed limit, road curvature, obstacles, and so on. Still other sensors may include those that can detect road grade. While some sensors can be used to actively detect passive environmental objects, other sensors can be included and used to detect active objects such as those objects used to implement smart roadways that may actively transmit and/or receive data or other information. Accordingly, the one or more sensors 52 can be configured to acquire, and/or sense driving environment data. For example, environment sensors can be configured to detect, quantify and/or sense objects in at least a portion of the external environment of the vehicle 10 and/or information/data about such objects. Such objects can be stationary objects and/or dynamic objects. Further, the sensors can be configured to detect, measure, quantify and/or sense other things in the external environment of the vehicle 10, such as, for example, lane markers, signs, traffic lights, traffic signs, lane lines, crosswalks, curbs proximate the vehicle 10, off-road objects, etc.

Each of the detected data discussed herein may comprise vehicle-related data. For example, sensors 52 may acquire internal vehicle information, external driving environment data, or any other information described herein. In some examples, sensors 52 may generate the vehicle-related data and/or other vehicle systems illustrated in FIG. 3 may receive the data from sensors 52 to generate the vehicle-related data.

FIG. 3 illustrates an example architecture for assisted traffic management in accordance with one embodiment of the systems and methods described herein. In this example, pre-filtering system 200 includes a pre-filtering circuit 210, the plurality of sensors 52, and one or more vehicle systems 220. Sensors 52 and vehicle systems 220 can communicate with pre-filtering circuit 210 via a wired or wireless communication interface. Although sensors 52 and vehicle systems 220 are depicted as communicating with pre-filtering circuit 210, they can also communicate with each other as well and with other vehicle systems. Pre-filtering circuit 210 can be implemented as an ECU or as part of an ECU such as, for example ECU 50. In other embodiments, pre-filtering circuit 210 can be implemented independently of an ECU.

Pre-filtering circuit 210, in this example, includes a communication circuit 201, a decision circuit 203 (including a processor 206 and memory 208 in this example) and a power supply 212. Components of pre-filtering circuit 210 are illustrated as communicating with each other via a data bus, although other communication in interfaces can be included.

Processor 206 can include a GPU, CPU, microprocessor, or any other suitable processing system. Memory 208 may include one or more various forms of memory or data storage (e.g., flash, RAM, etc.) that may be used to store the calibration parameters, images (analysis or historic), point parameters, instructions and variables for processor 206 as well as any other suitable information. Memory 208 can be made up of one or more modules of one or more different types of memory and may be configured to store data and other information as well as operational instructions that may be used by the processor 206 to control pre-filtering circuit 210.

Although the example of FIG. 3 is illustrated using processor and memory circuitry, as described below with reference to circuits disclosed herein, decision circuit 203 can be implemented utilizing any form of circuitry including, for example, hardware, software, or a combination thereof. By way of further example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up pre-filtering circuit 210.

Communication circuit 201 may be either or both a wireless transceiver circuit 202 with an associated antenna 214 and a wired I/O interface 204 with an associated hardwired data port (not illustrated). As this example illustrates, communications with pre-filtering circuit 210 can include either or both wired and wireless communications circuits 201. Wireless transceiver circuit 202 can include a transmitter and a receiver (not shown) to allow wireless communications via any of a number of communication protocols such as, for example, WiFi, Bluetooth, near field communications (NFC), Zigbee, and any of a number of other wireless communication protocols whether standardized, proprietary, open, point-to-point, networked or otherwise. Antenna 214 is coupled to wireless transceiver circuit 202 and is used by wireless transceiver circuit 202 to transmit radio signals wirelessly to wireless equipment with which it is connected and to receive radio signals as well. These RF signals can include information of almost any sort that is sent or received by pre-filtering circuit 210 to/from other entities such as sensors 52 and vehicle systems 220.

Wired I/O interface 204 can include a transmitter and a receiver (not shown) for hardwired communications with other devices. For example, wired I/O interface 204 can provide a hardwired interface to other components, including sensors 52 and vehicle systems 220. Wired I/O interface 204 can communicate with other devices using Ethernet or any of a number of other wired communication protocols whether standardized, proprietary, open, point-to-point, networked or otherwise.

Power supply 212 can include one or more of a battery or batteries (such as, e.g., Li-ion, Li-Polymer, NiMH, NiCd, NiZn, and NiH2, to name a few, whether rechargeable or primary batteries,), a power connector (e.g., to connect to vehicle supplied power, etc.), an energy harvester (e.g., solar cells, piezoelectric system, etc.), or it can include any other suitable power supply.

Sensors 52 can include, for example, those described above with reference to the example of FIG. 2. Sensors 52 can include additional sensors that may or not otherwise be included on a standard vehicle with which the pre-filtering system 200 is implemented. In the illustrated example, sensors 52 include vehicle acceleration sensors 52A, vehicle speed sensors 52B, wheelspin sensors 52C (e.g., one for each wheel), a tire pressure monitoring system (TPMS) 52G, accelerometers such as a 3-axis accelerometer 52E to detect roll, pitch, and yaw of the vehicle, proximity sensors 52F, and environmental sensors 52H (e.g., to detect precipitation or other environmental conditions). Additional sensors 52I can also be included as may be appropriate for a given implementation of pre-filtering system 200.

Vehicle systems 220 can include any of a number of different vehicle components or subsystems used to control or monitor various aspects of a vehicle, e.g., vehicle 10, and its performance. In this example, vehicle systems 220 include a GPS or other vehicle positioning system 272; motor control circuits 274 (e.g., to control operation of motor/generator 22); engine control circuits 276 (e.g., to control the operation of the engine including internal combustion engine 14); suspension system 280 (e.g., an adjustable-height air suspension system), and other vehicle systems 282.

In operation, pre-filtering circuit 210, by way of communication circuit 201, can receive data from various vehicle sensors 52 regarding vehicle operating conditions, environmental conditions, and/or other conditions relevant to operation of the vehicle, e.g., proximity information regarding road obstacles, neighboring vehicles, etc. Pre-filtering circuit 210 may also receive information relevant to operation of the vehicle via V2X communications, e.g., upcoming traffic information, road speed limit information, and the like. As alluded to above, one or more vehicle systems 220 may also provide information relevant to vehicle operation to pre-filtering circuit 210. As can be appreciated, the amount of data/information available to and generated by the vehicle itself is sizable, especially considering that sensors 52, for example, may be configured to collect information about their respective components/operations continuously, e.g., every 1/100 of a second.

In some embodiments, upon receipt of the aforementioned data and/or information, the data/information may be stored in memory 208, e.g., in a cache or buffer portion of memory 208. Decision circuit 203 may access memory 208 to analyze the received data/information to determine what data/information should be retained and/or transmitted to the edge/cloud for use, e.g., by a cloud server to train an AI model. Afterwards, that pre-filtered data may comprise a pre-filtered data set that is transmitted to the edge/cloud. In some embodiments, a network edge device or the aforementioned cloud server may have a scenario pattern or profile that requires a particular number of data points (e.g., a minimum or threshold number of five data points to generate the scenario profile). In some embodiments, such a scenario pattern or profile may be shared with the pre-filtering circuit 210 so that the requisite number of data points can be extracted by pre-filtering circuit 210 from the received data/information. In some embodiments, a network edge device or cloud server may simply transmit instructions to pre-filtering circuit 210 regarding the number of data points that are required in order for the cloud server or network edge device to extrapolate or interpolate one or more estimated values based on the data points. In still other embodiments, pre-filtering circuit 210 may be pre-programmed with scenario patterns so that pre-filtering circuit 210 can determine, depending on a particular scenario, collect or cull the received or generated data/information accordingly prior to transmission to a network edge device or cloud server.

For example, a cloud server training a predicted safety-response AI model may require five data points regarding vehicle speed while the vehicle is traversing a high velocity curve in the road. Although vehicle speed sensor 52B may collect vehicle speed information every 1/100 of a second resulting in 100 data points per second, the high velocity curve scenario pattern may only require five data points per second in order to allow the cloud server to train the predicted safety-response AI model. Thus, decision circuit 203 effectively performs a data reduction function. In this way, the cloud server, for example, can apply linear extrapolation to the data points received from pre-filtering circuit 210. In some embodiments, pre-filtering circuit 210 may append counter information to the data points to indicate to the cloud server or network edge device how many data points are being sent/have been sent.

In some embodiments, decision circuit 203 of pre-filtering circuit 210 may further reduce the amount of data/information that is sent by simply transmitting or uploading values, e.g., in comma-separated value (CSV) format. That is, for a particular event or series of events, e.g., within a particular time period, the requisite values may be put in a CSV file, e.g., one embodiment of pre-filtered data set 205, for transmission to the cloud server. The cloud server may run an extrapolation process(es) on the values contained in the CSV file, and for example, may run an identification algorithm to determine if the values indicate the same/similar scenario as what was predicted, to analyze the scenario or event(s), or to be used as feedback to make an AI model more accurate. In some embodiments, the results of the AI modeling, training, prediction, etc. can be fed back into one or more of the vehicle systems 220. For example, and following the above example, if the scenario or event(s) represented by the pre-filtered data is the same/similar as the predicted scenario or event(s), a determined response regarding vehicle positioning or re-positioning may be performed by GPS/vehicle positioning system 272. If the scenario or events involved traversal of a high velocity curve, the network edge device or cloud server may respond by instructing suspension system 280 to stiffen the suspension of vehicle 10.

In some embodiments, due to the reduced amount of data that is sent for processing, communication circuit 201 may leverage burst transmissions to the network edge device or cloud server or is able to send all the requisite data in a single transmission or message, for example. Because the network edge device or cloud server has to process, analyze or otherwise address less data, it can perform its analysis or data processing more quickly, resulting in a faster result or output. In turn, that result or output can be more quickly reflected in one or more vehicle systems 220, e.g., in real-time or near-real time.

In accordance with other embodiments, decision circuit 210 may receive first data, e.g., a first sensor data from one or more of sensors 52. Based on pre-programmed or determined scenario patterns, decision circuit 210 may obtain or request second sensor data to be obtained from an additional sensor(s) or additional data from other data sources, based on the first sensor data. That is, a particular scenario pattern may comprise a series of sensor data, and when first sensor data corresponds to one of the series of sensor data in the scenario pattern, decision circuit 203 may trigger data collection regarding other ones of the series of sensor data. In some embodiments, the triggering of “serial” data collection may be prompted by data, e.g., sensor data, whose value relative to a threshold, necessitates additional data collection.

For example, a braking event may be sensed by braking sensor 52D. If the braking sensor 52D senses a braking event, that braking sensor data is transmitted to pre-filtering circuit 210. Decision circuit 203 of pre-filtering circuit 210 may analyze the braking sensor data, and determine that it exceeds a hard braking threshold, at which point, decision circuit 203 triggers data collection from proximity sensor 52F in order to determine whether or not the hard braking event was the result of an upcoming obstacle or neighboring vehicle(s). If proximity sensor 52F transmits data indicating no upcoming obstacle or neighboring vehicle, decision circuit 203 may trigger data collection from the tire pressure sensor 52G to determine if the hard braking event could be attributed to a loss of tire pressure (flat), and so on. In this way, data collection can be predicated on the existence of a particular data element, thereby avoiding conventional data collection that generally occurs in a non-discriminatory fashion, which in turn reduces the amount of data that is ultimately collected and transmitted to a processing or analysis element, such as a network edge device, cloud server, or resident AI system.

In other embodiments, the receipt of first data at pre-filtering circuit 210 that meets, exceeds, or fails to meet a particular threshold, decision circuit 210 may access memory 208 to look for other data instances that have met, exceeded, or failed to meet a related threshold. For example, sensor data may be collected by pre-filtering circuit 210, and stored in a data cache or buffer portion of memory 208. Upon receiving data from wheel spin sensor 52C that exceeds a wheel spin threshold, decision circuit 203 may access memory 208 to search for other data, e.g., roll/pitch/yaw data from sensor 52E whose value(s) relative to a roll/pitch/yaw threshold may indicate the existence or occurrence of a particular event(s) or road/environmental condition.

In some embodiments, the transmission of data to a network edge device, a cloud server, or resident AI system in vehicle 10 can be performed in similarly “serial” fashion. That is, first data or a first set of data may be received by pre-filtering circuit 210, which is then transmitted to a following the above example, upon receipt of data from wheel spin sensor 52C that exceeds a wheel spin threshold, decision circuit 203 may determine that the sensor data from wheel spin sensor 52C is to be sent out. However, in this embodiment, decision circuit 203 will wait for a response from the receiving network edge device, cloud server, or other AI system requesting additional data be obtained. That is, the network edge device, cloud server, or other AI system may, in real-time or within some specified time period (provided data is maintained in memory 208), analyze or process the data from wheel spin sensor 52C and make a determination that additional data is needed. The network edge device, cloud server, or AI system can then respond to the receipt of the wheel sensor data and indicate to decision circuit 203 that it should obtain that additional data, i.e., roll/pitch/yaw data from sensor 52E. Decision circuit 203 can then obtain that data from memory 208.

For example, the network edge device, cloud server, or AI system may make the determination to obtain additional data based on a known or predicted scenario pattern. Alternatively, the network edge device, cloud server, or AI system may make the determination to obtain additional data based on extrapolation/interpolation of the received data not resulting in the desired accuracy, output granularity, etc. Thus, even if the scenario or received data is not yet associated with a known scenario or expected event(s), certain types of data can be focused on. For example, a determination may be made by the network edge device, cloud server, or AI system (or even the decision circuit 203) to obtain additional information from sensors or data sources that are known to be impacted or have an impact on an element from which or with which the first received data is associated. Again, the transmission and analysis of excessive amounts of data can be avoided as a result of this manner of data collection. It should be noted that in some embodiments, for example, this edge/cloud-driven data collection can be used to direct other vehicles' data collection mechanisms. For example, upon a cloud server obtaining five data points per second from a first vehicle regarding some event(s) or scenario, the cloud server may determine that only three data points per second are needed to perform the desired analysis/make a prediction with the requisite accuracy. Accordingly, the cloud server may instruct vehicles neighboring the first vehicle to only collect three data points per second, e.g., by updating a scenario pattern or through direct instruction (vis-à-vis V2X communications).

FIG. 4 is a flow chart illustrating example operations that can be performed to pre-filter data in accordance with one embodiment of the present disclosure. The operations illustrated in FIG. 4 and described herein can be performed by pre-filtering circuit 210, for example.

At operation 410, vehicle-related data is collected. As described above, a vehicle, e.g., vehicle 10, may have various on-board sensors 52, and can receive information from other data sources, such as other vehicles, RSUs, third-party information sources, such as traffic information providers. Data can be collected and stored by pre-filtering circuit 210, in particular, by decision circuit 203 and memory 208, respectively.

At operation 420, a number of data points necessary for performing at least one of an extrapolation and interpolation function is determined. For example, a scenario pattern may be used/referenced to determine the number of data points needed to make a prediction, confirm a scenario or event, or perform any relevant AI or ML analysis of data. In some embodiments, the pre-filtering circuit 210, in particular, the decision circuit 203, may be pre-programmed with information/instructions regarding the requisite number of data points that should be collected for transmission to the entity performing the extrapolation/interpolation function. In other embodiments, that entity may in real-time or within a particular time period, instruct the pre-filtering circuit 210 as to how many data points are needed. In still other embodiments, that entity may update a scenario pattern or adjust its instructions regarding the number of data points that are needed. In this way, even if vehicle sensors are constantly or continuously collecting data, if the vehicle is receiving copious amounts of information, only the requisite data needed for AI/ML use is actually sent.

In some examples, the entity is a network edge device or cloud server that collects the data points and other vehicle-related data remote from vehicle 10. The vehicle-related data may be used to determine a suggested vehicle instruction that can request the operator of the vehicle to alter the operation of the vehicle or perform some other action.

At operation 430, the number of data points commensurate with the necessary number of data points are extracted from the collected vehicle-related data. It should be understood that an AI model, for example, or the scenario pattern may dictate whether the necessary data points are equally (e.g., every X seconds) or non-equally distributed relative to time of collection. In some embodiments, pre-filtering circuit 210 may trigger the collection of vehicle-related data only after determining the number of data points needed for performing the extrapolation/interpolation function at operation 440. In this case, decision circuit 203 may explicitly query a certain data sensor(s) or request data from a particular data source(s) rather than access already-collected data matching a particular time stamp, time period, or other data collection parameter for obtaining the requisite number of data points.

At operation 450, the extracted data points are transmitted to the entity performing the at least one of the extrapolation and interpolation function. Again, the entity may be a network edge device, a cloud server, or some AI/ML system resident on the vehicle. In this way, the amount of data transmitted can be reduced. Moreover, as a result of transmitting less data, the communications resources needed for transmission are occupied less and/or the communication resources need not be as robust as might normally be required when large amounts of data need to be transferred.

FIG. 5 is an example environment in which assisted traffic management using vehicle-related data is performed. In this illustration, a plurality of vehicles 10 are identified on a roadway 502. Some of the plurality of vehicles 10 may be in communication with a network edge device or cloud server 540 (illustrated as first network edge device or cloud server 540A, second network edge device or cloud server 540B, and network edge device or cloud server 540C) that can transmit suggested vehicle instructions to one or more of these vehicles 10.

A cluster of vehicles may be determined by a network edge device or cloud server 540 or data center 550. For example, a cluster of vehicles may be identified using various methods, including identifying clusters of vehicles based on location of each of the vehicles adjacent to a network edge device or cloud server 540 (e.g., within a threshold distance of an edge device corresponding with a timestamp) or identifying clusters of vehicles based on the type of vehicle that may receive instructions from the network edge device or cloud server 540 (e.g., vehicles that incorporate a V2V, V2C, or V2I or operate semi-autonomously).

In this illustration, three clusters are identified, including first cluster of vehicles 510, second cluster of vehicles 520, and third cluster of vehicles 530. The identification of the three clusters of vehicles may be based on the location of the vehicles adjacent to each network edge device or cloud server 540 (illustrated as first edge device 540A, second edge device 540B, and third edge device 540C). The network edge devices or cloud servers 540 may be implemented as one or more edge devices to correspond with multiple physical locations of clusters of vehicles or may be implemented virtually and assigned different locations corresponding with each cluster of vehicles (e.g., co-located in a same building or data center).

Network edge devices or cloud servers 540 may also communicate with data center 550. Data center 550 may collect the sensor data or other vehicle-related data associated with the vehicles in the plurality of clusters of vehicles.

As discussed herein, first network edge device or cloud server 540A may determine and transmit a suggested vehicle instruction to pre-filtering circuit 210 of one or more vehicles in a first cluster of vehicles 510. A first vehicle in first cluster of vehicles 510 may perform the action (e.g., executor) or not perform the action (e.g., non-executor) corresponding with the suggested vehicle instruction. As an illustrative example, the suggested vehicle instruction may comprise an instruction to slow down the vehicle. As discussed herein, the vehicle speed may be sensed by a wheel rotation sensor internal to the vehicle to identify whether the vehicle is slowing down upon receiving the suggested vehicle instruction. Other methods of determining the vehicle speed may also be implemented, including determining a vehicle speed by a radar device that identifies a traveling speed at a first point of time and the second point of time, while the radar device is external to the vehicle.

The proposed traffic management system tracks the suggested vehicle instructions (e.g., speed advisories, lane-change recommendations) transmitted to the vehicles to determine which suggested vehicle instructions are executed and which are not executed (e.g., using vehicle-related data or time series data received from sensors).

This data may be provided as training data to a machine learning (ML) model, which can be implemented at any one of the network edge devices or cloud servers 540 or at data center 550. The ML model may correlate the sensor data, actions, driving behaviors, or other vehicle-related data to determine data that correlates with the one or more species of vehicles, including executors or non-executors of the suggested vehicle instruction. The ML model may continue to learn the most contrasting driving behavior between the different species (e.g., what the executor vehicles implemented and what the non-executor vehicles did not implement). The output from the trained ML model can correlate vehicles and vehicle-related data with which suggested vehicle instructions are executed or are not executed (e.g., as clusters of vehicles).

In some examples, the most contrasting driving behavior between the different species may be transferred other network edge devices or cloud servers 540B, 540C or data center 550. This may help other network edge devices or cloud servers 540B, 540C generate suggested vehicle instructions for vehicles that are predicted to perform actions based on the actions of earlier executors or non-executors. For example, when the system identifies an action that is not performed by the first cluster of non-executors in response to a first instruction, the system can predict that a second cluster of non-executors will fail to perform the same way in response to an identical instruction. The system can adjust the instruction to try to provoke a different response from the second cluster of non-executors and avoid the mistake of providing the same suggested vehicle instruction that will not be followed by the second cluster of non-executors. The system may modify the suggested vehicle instruction for the second cluster of non-executors or generate additional instructions to compensate the inaction of non-executors that was provided by network edge devices or cloud server 540A.

This clustering process in illustrated in FIG. 6. For example, the vehicles may be clustered using the trained ML model that correlates the vehicles and vehicle-related data with which suggested vehicle instructions are executed or are not executed (e.g., as clusters of vehicles). In this example, the first cluster of vehicles 610 is illustrated as comprising vehicles that are located throughout the roadway 502.

To determine the cluster of vehicles, the network edge devices or cloud servers 540 or data center 550 may infer the vehicle-related data that may lead to the vehicles that execute and do not execute the suggested vehicle instruction. The vehicles and vehicle-related data may be provided as input to the trained ML model and the output may identify the vehicles 10 that may form each clusters of vehicles. For example, vehicles in the cluster of vehicles 610 may be predicted to perform a similar action in response to an identical instruction. As such, when the first vehicle in a cluster of vehicles 610 performs the action, the network edge devices or cloud servers 540 or data center 550 may infer the underlying reasons of acceptance and rejection of the suggested vehicle instructions by other vehicles in the cluster of vehicles 610. The inference may identify the underlying reasons of acceptance and rejection for different vehicles in similar clusters would likely perform a same action to an identical instruction (e.g., based on the trained ML model or other similarities identified between the vehicles).

For example, the inference of the underlying reasons of acceptance and rejection of the suggested vehicle instructions may be based on vehicle-related data. In a sample illustration, a first network edge device or cloud server 540A transmits a suggested vehicle instruction to a first set of vehicles (e.g., a first subset of cluster 510) and may also initiate tracking of these vehicles (e.g., received as vehicle-related data). The tracking performed by first network edge device or cloud server 540A may observe the vehicles from cluster 510 that are performing an action. First network edge device or cloud server 540A may correlate the actions of the vehicles, responses provided by the human operators or autonomous vehicles, and other information with the suggested vehicle instruction to form knowledge or analytics associated with the suggested vehicle instruction.

A second set of vehicles may be observed as well (e.g., a second subset of cluster 510 or a second cluster 520), which associates two species of vehicles with first network edge device or cloud server 540A. The first species or subset may perform an action that follows the suggested vehicle instruction and the second species or subset may not. First network edge device or cloud server 540A can learn from these two species (e.g., differences and similarities in actions and vehicle-related data) and infer whether the action is complying with the first vehicle instruction or not executing it. For example, the learning process can run a time series analysis and find the most discriminative driving behavior between the two species or subsets.

Illustrative examples of discriminative driving behavior for these two species under given suggested vehicle instruction can include a lane change in response to a traffic incident. The discriminative driving behavior can identify the non-executors as not performing the suggestion and intentionally slowing down as the vehicle approaches the traffic incident for a better view. First network edge device or cloud server 540A can infers the underlying reason that non-executor did not execute the suggested vehicle instruction is that the human vehicle operator wanted to see the incident (e.g., rubbernecking or a reaction of the human vehicle operator as they pass by the traffic incident or something happening on road 502). Slowing down to see the traffic incident may be identified from the vehicle-related data including the decreased speed by the subject vehicle. First network edge device or cloud server 540A may associate the underlying reason for one of the species of vehicles as non-executors in that they wanted to view the traffic incident instead of following the suggested vehicle instruction. First network edge device or cloud server 540A can transmit this knowledge or analytics to other network edge devices or cloud servers, including second network edge device or cloud server 540B, and request that this device determine an additional suggestion while considering the underlying reason for one of the species of vehicles (e.g., rubbernecking). Second network edge device or cloud server 540B uses this knowledge and comes up with additional suggestions different than the lane change instruction to compensate the non-executors that first network edge device or cloud server 540A identified.

In another example, the action may be inferred based on a set of rules associated with an autonomous vehicle. For example, when the vehicle is a non-executor, the vehicle may reject a given suggestion due to many reasons. The instruction may be marked as risky by the autonomous or ADAS vehicle rules (e.g., the system may have one or more predefined thresholds and the suggested vehicle instruction may violate these thresholds). In another example, the autonomous vehicle may be required to take the approval from a human onsite driver or remote driver and the driver is not responding. In yet another example, the instruction may contradict with the autonomous vehicle reward functions (e.g., the system may try to maximize the speed, but given suggestion reduces the speed). The inference may be related to these or other reasons that may be inferred from the action of the vehicle.

In some examples, the trained ML model may also identify which types of suggested vehicle instructions will likely be followed by the vehicles in a cluster of vehicles. For example, vehicles in the cluster of vehicles 610 may be more likely to follow a speed advisory and slow down the vehicle but not a suggested vehicle instruction to perform a lane change. As another example, vehicles in a second cluster of vehicles may follow a speed advisory and slow down the vehicle upon receiving a compensation action, but may not follow the speed advisory without the compensation action.

As an illustrative example, the suggested vehicle instruction may include an instruction to slow the first vehicle to a slower traveling speed. When the first vehicle in the cluster of vehicles 610 does not comply with the instruction, the system may observe the actions and infer the reasoning why our suggestions are rejected. As such, the vehicles that are behind the first vehicle may be offered compensation to comply with the instruction. For example, the suggested vehicle instruction may be sent to a second vehicle in the cluster of vehicles 610 with the compensation action is offering a monetary value to slow the traveling speed (e.g., a gift card value, a monetary payment to a wallet account, or other compensation).

As another illustrative example, the suggested vehicle instruction may include an instruction to the first vehicle to change lanes. When the first vehicle in the cluster of vehicles 610 does not comply with the instruction, the system may infer that other vehicles in the cluster will not likely follow the instruction either. As such, the vehicles that are behind the first vehicle may be offered compensation to comply with the instruction. For example, the suggested vehicle instruction may be sent to a second vehicle in the cluster of vehicles 610 with the compensation action is offering a monetary value to change lanes (e.g., a gift card value, a monetary payment to a wallet account, or other compensation).

As another illustrative example, the suggested vehicle instruction may include an instruction to the first vehicle to enter a high-occupancy vehicle (HOV) lane. When the first vehicle in the cluster of vehicles 610 does not comply with the instruction, the system may infer that other vehicles in the cluster will not likely follow the instruction either. As such, the vehicles that are behind the first vehicle may be offered compensation to comply with the instruction. For example, the suggested vehicle instruction may be sent to a second vehicle in the cluster of vehicles 610 with the compensation action is offering a monetary value to enter the HOV lane (e.g., a gift card value, a monetary payment to a wallet account, or other compensation).

Using the trained ML model, the system may generate knowledge regarding the underlying reason(s) the non-executing drivers did not follow the suggested vehicle instruction. That knowledge may be shared with other nearby network edge devices or cloud servers 540 serving different regions of the roadway network or different clusters of vehicles. When such a network edge device or cloud server receives knowledge, it can generate additional suggested vehicle instructions accordingly.

The additional suggested vehicle instructions may vary based on several factors (e.g., in order to help improve traffic flow overall). That is, the network edge devices or cloud servers 540 may attempt to compensate for the unexecuted vehicle instructions while achieving an assigned objective (e.g., abate traffic or move traffic away from an accident).

In some examples, the additional suggested vehicle instructions may vary based on an identification of the second vehicle. For example, the first vehicle and the second vehicle may not be part of the same cluster of vehicles. In another example, the first vehicle or the second vehicle are a patrol officer. In this example, the first instruction to the first vehicle may be to adjust operation of the vehicle (e.g., slow down) and, based on the action performed by the first vehicle, the second instruction to the second vehicle (e.g., patrol officer) may be to perform a different action based on the action of the first vehicle (e.g., abate or slow down traffic after the first vehicle).

FIG. 7 is an example environment in which assisted traffic management using vehicle-related data is performed. In this example, a cluster of vehicles is identified as vehicles across the roadway that may perform an similar action and are at different parts of the roadway. The cluster of vehicles may include a first portion 710, second portion 720, and third portion 730. The vehicle-related data for these vehicles in the first portion 710, second portion 720, and third portion 730 of the cluster of vehicles may be provided to network edge device or cloud servers 740 (illustrated as first network edge device or cloud server 740A, second network edge device or cloud server 740B, and network edge device or cloud server 740C) that can transmit suggested vehicle instructions to one or more vehicles, including a first portion 710, second portion 720, and third portion 730 of cluster of vehicles.

The suggested vehicle instructions to the portions of the cluster of vehicles may differ based on the location of the vehicle on the roadway. For example, a first suggested vehicle instruction may be determined and transmitted to the first portion 710 of the cluster of vehicles. A first vehicle may perform an action, and the vehicle-related data associated with the first portion 710 of the cluster of vehicles can be provided as input to the trained ML model to infer the likelihood that the vehicle will performed the action in response to the suggested vehicle instruction.

When the inference is high (e.g., exceeding a threshold value) and the action follows the suggested vehicle instruction, the network edge device or cloud servers 740 may provide the same suggested vehicle instruction to a second vehicle in the second portion 720 of the cluster of vehicles or third portion 730 of the cluster of vehicles.

When the inference is high (e.g., exceeding a threshold value) and the action does not follow the suggested vehicle instruction, the network edge device or cloud servers 740 may provide a compensation amount with the same suggested vehicle instruction to a second vehicle in the second portion 720 of the cluster of vehicles or third portion 730 of the cluster of vehicles.

When the inference is low (e.g., failing to exceed a threshold value) and the action does follow or does not follow the suggested vehicle instruction, the network edge device or cloud servers 740 may provide a compensation amount with the same or different suggested vehicle instruction to a second vehicle in the second portion 720 of the cluster of vehicles or third portion 730 of the cluster of vehicles.

In some examples, the vehicle-related data corresponding with the second vehicle may be provided as input to the trained ML model. However, it may be unlikely that an inference may be generated that correlates a future action performed by the second vehicle and the vehicle-related data. This is because the first vehicle and the second vehicle are grouped in the same cluster of vehicles and may share similar characteristics to perform actions in response to similar instructions (e.g., based on historical actions). As such, a greater compensation amount may be provided to the second vehicle then was provided to the first vehicle, at least based in part on the first vehicle performing are not performing the action.

FIG. 8 is a flow chart illustrating example operations for implementing traffic assistance in accordance with one embodiment. In this example, the process may be performed by various devices described herein, including the network edge devices or cloud servers 540 or data center 550 illustrated in FIGS. 5 and 6, or the network edge device or cloud servers 740 illustrated in FIG. 7.

At block 810, the process may determine if vehicle-related data is received. For example, the vehicle-related data may be received from a network edge device or cloud server. If yes, the process may proceed to block 820. If no, the process may proceed to block 830.

At block 820, the process may leverage the vehicle-related data and generate one or more suggested vehicle instructions. In some examples, the suggested vehicle instruction may include a compensation amount to try to encourage the vehicle to perform an action corresponding to a suggested vehicle instruction that has a high likelihood of remaining unexecuted.

At block 830, the process may generate suggested vehicle instructions for vehicles in a cluster of vehicles and transmit the instructions with the vehicles.

At block 840, the process may determine whether any unexecuted suggested vehicle instructions remain. If yes, the process may proceed to block 850. If no, the process may return back to block 830.

At block 850, the process may analyze the vehicle-related data of vehicles in which given suggested vehicle instructions are executed and not executed.

At block 860, the process may infer contrasting driving behavior between the executors and the non-executor vehicles. For example, the process may perform a time-series analysis of vehicle-related data for vehicles that performed an action in response to the instruction and/or perform a time-series analysis of vehicle-related data for vehicles that did not perform the action in response to the instruction.

At block 870, the process may perform reasoning on top of inferred driving behavior and construct this as vehicle-related data. The process may share the vehicle-related data with other nearby entities (e.g., a first network edge device or cloud server 540A sharing with a second network edge device or cloud server 540B). In some examples, the suggested vehicle instruction may be provided with a suggestion or request to include a compensation action or amount.

FIG. 9 is a flow chart illustrating example operations for implementing traffic assistance in accordance with one embodiment. In this example, the process may be performed by various devices described herein, including the network edge devices or cloud servers 540 or data center 550 illustrated in FIGS. 5 and 6, or the network edge device or cloud servers 740 illustrated in FIG. 7.

At block 910, the process may determine a first vehicle instruction. The first vehicle instruction may be based on vehicle-related data.

At block 920, the process may transmit the first vehicle instruction to a first vehicle.

At block 930, the process may infer whether an action was performed in response to the instruction. For example, when the first vehicle performs the action, the process may infer whether the action is in response to the first vehicle instruction.

At block 940, based on the inference, the process may transmit a second vehicle instruction with a compensation action to a second vehicle.

In some examples, the first vehicle and the second vehicle are grouped in a cluster of vehicles by a trained machine learning (ML) model.

In some examples, the first vehicle instruction is to slow a traveling speed, and when the action performed by the first vehicle does not comply with the first vehicle instruction, the compensation action is offering a monetary value to slow the traveling speed.

In some examples, the first vehicle instruction is to change lanes, and when the action performed by the first vehicle does not comply with the first vehicle instruction, the compensation action is offering a monetary value to change lanes.

In some examples, the first vehicle instruction is to enter a high-occupancy vehicle (HOV) lane, and when the action performed by the first vehicle does not comply with the first vehicle instruction, the compensation action is offering a monetary value to enter the HOV lane.