Consensus-based monitoring of driving behavior in connected vehicle systems

Abstract

A method for monitoring vehicle traffic behavior and providing feedback, comprising: collecting vehicle sensor data from a set of vehicles (310, 320, 330, 340, 350) operating in a traffic environment (300), each vehicle forming a data transmission network (102) with other vehicles within range over which network it sends vehicle sensor data to a processor (104); determining whether to analyze the vehicle sensor data by determining whether the set of vehicles includes sufficient vehicles to form a quorum; forming, in response to determining that the set of vehicles forms a quorum, a consensus block of aggregated data, the aggregated data comprising individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor discards duplicate and repetitive data from the consensus block;Detecting a vehicle movement pattern in the consensus block, wherein the vehicle movement pattern deviates from a threshold by more than a tolerance; associating the vehicle movement pattern with a specific vehicle in the set of vehicles; and generating a feedback response based on the association, wherein the vehicles in the quorum each detect different versions of the same event.

Description

TECHNICAL FIELDThe present invention relates generally to a method, computer program product and system in the vehicle traffic behavior field. More particularly, the present invention relates to a method, computer program product, and system for consensus-based monitoring of driving behavior in associated vehicle systems.BACKGROUNDVehicle traffic accidents are costly to life and damage worldwide. Traffic accident analysis discloses several patterns. In many cases, accidents are caused by distracted drivers or drivers who are unknown to local road conditions. In addition, regions with less effective or rather rare traffic controls show a greater probability of more accidents. In addition to motor vehicle accidents, vehicle accidents also occur with ships and watercraft on waterways, between aircraft and service vehicles on airport runways, between two aircraft on the ground and between people when driving motor scooters and passenger transport devices.Modern passenger vehicles, including automobiles, are already being supplied with a variety of sensors including, but not limited to, motion sensors, still cameras, event recorders, video cameras, proximity detectors, lane detectors, speed sensors, rain sensors, turn signal sensors, and the like. As vehicle technology has evolved, it is likely that individual vehicles will use more sensors and include video sensors and sensors that serve to maintain speed and distance within a lane. Further, the emerging autonomous vehicles are also highly consistent with vehicles having a variety of motion, proximity, and state sensors.Modern vehicles today use a variety of sensors to monitor and report vehicle condition as well as vehicle motion, with the vehicle reporting or sending feedback back to the individual driver. The feedback may include the mechanical state of the vehicle or may include proximity warnings, excessive speed warnings, pedestrians in the path of travel, and the like. Passenger vehicles, such as motor vehicles, also use diagnostic and driving assistance sensors and systems. In one example, multiple commercially available vehicles currently available utilize an automatic braking system and a local proximity sensor to prevent or minimize collisions with a vehicle in front of the moving vehicle. When the automatic braking system is activated, it actuates the brakes and attempts to stop the vehicle before encountering an object. In another example, some motor vehicles may shut down the engine when a mechanical fault is detected to prevent mechanical damage. In some vehicles, a sensor system may assist in parallel parking, lane following, variable speed cruise control, and the ability to detect a falling driver. Some vehicles may also provide autonomous feedback in response to sensor data, such as automatically braking the vehicle without driver actuation, automatically steering the vehicle during parking maneuvers, and automatically steering to maintain the distance on the roadway.It is also apparent that more and more video cameras are used on public driving roads such as roads and airports as part of an effort to improve safety and record events of interest to interested parties such as governments, emergency responders, and traffic monitoring organizations. The result is travel paths monitored by a variety of sensors and cameras.Current technology allows a single vehicle to receive and respond to events based on that vehicle's sensor data. However, in the current driving environment, there is a lack of a community or consensus based driver assistance method and system in which a vehicle that travels with other vehicles in a common environment uses all sensors currently located near that vehicle, and the vehicle itself, near vehicles, and external sensors such as traffic cameras and safety cameras on buildings are included. A vehicle that uses many internal and external sensors is said to use a consensus of available sensor data.In the current driving environment, a vehicle is traveling within the sensor range of a variety of sensors, many of which are not available for a particular vehicle. Therefore, although many different types of sensor data are generated while a vehicle is traveling through a common environment, this sensor data is not currently used. This collection of available data is referred to as "consensus-based data" and represents the sum of data collected from many sensors monitoring a road, a ship channel, and the like. Each sensor that provides data to the consensus based data reports events that occurred from the individual view angle of that sensor. A consensus-based data block is thus a collection of data from many individual sensors to provide an unpredicted image of events that take place from the perspective of multiple independent sensors.In the present environment, individual driving behavior sometimes contributes to accidents and causes injury to persons and damage to things. Drivers, pilots, ship captans, and the like are often distracted by a plethora of data entering them, distracted by cellular phones, external sounds, weather events, road conditions, and tiredness or the presence of substances that improve or impede the driver's responses to evolving driving conditions. Driver distractions are likely to increase as technology develops, vehicles become more complex, and road operators become more densely driven. In addition, some drivers sometimes choose not to intentionally behave deflexively (by following the rules), but instead choose a more aggressive driving behavior to gain certain advantages, such as driving faster, saving time, or avoiding stops and delays. This disclosure may help to rescue other drivers and pedestrians from living in traffic by alerting them of the detected improper behavior and also by having a positive effect on the misbehaving driver by providing immediate personal feedback. In another example, autonomous cars could potentially fail to adhere to traffic rules due to programming errors. Unpredictable feedback from an external sensor may be helpful to address such programming issues.An increasing trend in passenger vehicles is the ability to wirelessly connect to local cell towers, satellite service, and wireless networks from the vehicles themselves. Some personal devices such as mobile phones, laptops, and tablets may also function as a wireless access point. Therefore, in many cases, a vehicle traveling along a road is often subject to a variety of options to wirelessly connect to the Internet, the cloud, and the like.In many cases, accidents are caused by local conditions that a driver of a vehicle does not know, such as congested traffic, pedestrians on the road, construction sites, an accident behind a curve, and the like. However, it is possible that the sensors of other vehicles and / or stationary cameras and other sensors have already detected the conditions, but are currently unable to warn approaching drivers.The document DE 10 2016 004 292 A1 relates to a method for operating a vehicle. The method provides that a route-specific driving profile of the vehicle is determined and supplied to a central computer unit and stored on the latter, wherein an ideal driving profile and a critical driving profile are determined on the basis of driving profiles of a plurality of vehicles, which are made available to the vehicle ( 2) by means of vehicle-to-vehicle communication or by means of vehicle-to-infrastructure communication and to further vehicles for determining an optimum driving mode or a driving-critical state.The document DE 10 2015 205 158 A1 relates to a control device for a vehicle having an interface to at least one sensor of the vehicle for determining vehicle data, having an evaluation device for evaluating vehicle data detected by the sensor for determining a hazardous situation of the vehicle and having an interface to an output unit for outputting a warning related to the hazardous situation, characterized by an interface to a first communication device in the vehicle for establishing a wireless communication connection to a second communication device outside the vehicle in the event that, after a predefined time after outputting the warning related to the hazardous situation, persistence of the hazardous situation is detected by the evaluation device.SUMMARYThe illustrative embodiments provide a method for vehicle traffic behavior and feedback, comprising collecting vehicle sensor data from a set of vehicles operating in a traffic environment, each vehicle sending vehicle sensor data to a processor over a communication network, and forming a consensus block of aggregated data, wherein the aggregated data consists of individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor sorts duplicate data and repetitive data from the consensus block. The method also includes detecting a vehicle motion pattern in the consensus block where the vehicle motion pattern deviates from a threshold by more than a tolerance, associating the vehicle motion pattern with a particular vehicle in the set of vehicles, and generating a feedback response based on the associating.An embodiment includes a computer program product for monitoring vehicle traffic behavior and feedback, the computer program product comprising one or more computer readable storage media and program instructions stored in common on the one or more computer readable storage media comprising program instructions comprising program instructions for acquiring vehicle sensor data from a set of vehicles operated in a traffic environment, each vehicle sending vehicle sensor data to a processor via a communication network, and program instructions for forming a consensus block of aggregated data, wherein the aggregated data comprises individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor sorts duplicate data and repetitive data from the consensus block. The program instructions also include program instructions for detecting a vehicle motion pattern in the consensus block where the vehicle motion pattern deviates from a threshold by more than a tolerance, program instructions for associating the vehicle motion pattern with a particular vehicle in the set of vehicles, and generating a feedback response based on the associating.An embodiment includes a computer system comprising a processor, a computer readable memory, a computer readable storage unit, and program instructions stored in the storage unit for execution by the processor via the memory, the stored program instructions comprising program instructions for acquiring vehicle sensor data from a set of vehicles travelling in a traffic environment, each vehicle sending vehicle sensor data to a processor via a communication network, and program instructions for forming a consensus block of aggregated data, wherein the aggregated data comprises individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor sorts duplicate data and repetitive data from the consensus block. The program instructions also include program instructions for detecting a vehicle motion pattern in the consensus block where the vehicle motion pattern deviates from a threshold by more than a tolerance, program instructions for associating the vehicle motion pattern with a particular vehicle in the set of vehicles, and generating a feedback response based on the associating.BRIEF DESCRIPTION OF THE DRAWINGSCertain novel features which are considered characteristic of the invention are set forth in the appended claims. The invention itself, as well as its preferred mode of use, other objects and advantages, will, however, be best understood by reference to the following detailed description of the illustrative embodiments when read in conjunction with the accompanying drawings, wherein: FIG. 1 illustrates a block diagram of a network of data processing systems in which illustrative embodiments may be implemented; FIG. 2 illustrates a block diagram of a data processing system in which illustrative embodiments may be implemented; FIG. 3 illustrates a functional diagram of a group of vehicles in a common environment, each vehicle transmitting motion data to a computer network, according to an illustrative embodiment; FIG. 4 illustrates a functional diagram of a group of vehicles in a common environment, where some vehicles transmit motion data and some vehicles are not connected to a computer network, according to an illustrative embodiment; FIG. 5 illustrates a functional diagram in which a group of vehicles is monitored for traffic related behavior by a computer network, according to an illustrative embodiment; FIG. 6 illustrates a functional diagram in which a group of vehicles traveling in a common environment may be simultaneously a member of multiple groups, according to an illustrative embodiment; and FIG. 7 illustrates a dataflow diagram of an example process for monitoring a group of vehicles traveling in a common environment for traffic related behavior according to an illustrative embodiment.DETAILED DESCRIPTIONThe illustrative embodiments recognize that there is a need for consensus driving behavior monitoring in connected vehicle systems to include passenger vehicles, commercial vehicles, aircraft, ships, and other watercraft and transport units of all types.The illustrative embodiments are described using particular program code, structures, architectures, protocols, layouts, schematics, and tools for example only and do not limit the illustrative embodiments. Further, the illustrative embodiments are described in some examples using particular software, tools, and computing environments for clarity of description only as an example. The illustrative embodiments may be used in conjunction with other structures, systems, applications, or architectures that may be similar or intended for similar purposes. For example, other comparable mobile units, structures, systems, applications, or architectures therefor may be used within the scope of the invention in connection with such an embodiment of the invention. An illustrative embodiment may be implemented in hardware, software, or a combination thereof.The examples in this disclosure are for clarity of description only and do not limit the illustrative embodiments. Additional data, operations, actions, tasks, activities, and manipulations are envisioned from this disclosure and are considered to be within the scope of the illustrative embodiments.Advantages listed herein are merely examples and are not intended to limit the illustrative embodiments. Additional or other advantages may be realized by specific illustrative embodiments. Further, a particular illustrative embodiment may have some, all, or none of the advantages listed above.FIG. 1 illustrates a block diagram of a network of data processing systems in which illustrative embodiments may be implemented. A computing environment 100 is a network of computers in which the illustrative embodiments may be implemented. The computing environment 100 includes a network 102. Network 102 is the medium that serves to establish communications links between various devices and computers interconnected in computing environment 100. The network 102 may include connections such as wired and wireless communication links or fiber optic cables.Clients or servers are only exemplary roles of particular computing systems connected to the network 102, and are not intended to exclude other configurations or roles for that computing system. A server 104 and a server 106 are connected to the network 102 together with a storage unit 108. Software applications may be executed on each computer in the computing environment 100. Clients 110, 112 and 114 are also connected to the network 102. A data processing system such as server 104 or 106 or client 110, 112 or 114 may contain data and include software applications or software tools executing thereon.By way of example only and not limitation, FIG. 1 illustrates certain components usable in an example implementation of an embodiment. For example, servers 104 and 106 and clients 110, 112, 114 are shown as servers and clients only by way of example and do not suggest a limitation to a client-server architecture. In another example, within the scope of the illustrative embodiments, one embodiment may be distributed among multiple data processing systems and a data network as shown, while another embodiment may be implemented on a single data processing system. Computing systems 104, 106, 110, 112, and 114 also represent example nodes in a cluster, partitions, and other configurations suitable for implementing an embodiment.A unit 132 is an example of a unit described herein. For example, the device 132 may take the form of a smartphone, a tablet computer, a laptop computer, a client 110 in fixed or portable form, a wearable computing device, or any other suitable device. Each software application described as executing on another data processing system in FIG. 1 may be configured to execute in a similar manner in unit 132. Each data unit or information stored or generated in another data processing system in FIG. 1 may be configured to be similarly stored in unit 132.Servers 104 and 106, storage device 108, and clients 110, 112, and 114, and device 132 may be connected to network 102 via wired connections, wireless communication protocols, or other suitable data connectivity. Clients 110, 112 and 114 may be, for example, personal computers or network computers. An application 105 implements an embodiment described herein.In the illustrated example, the server 104 may provide data such as boot files, operating system images, and applications to the clients 110, 112, and 114. Clients 110, 112, and 114 may be clients of server 104 in this example. Clients 110, 112, 114, or some combinations thereof, may include their own data, boot files, operating system images, and applications. Computing environment 100 may include additional servers, clients, and other entities, not shown.In the illustrated example, the computing environment 100 may be the Internet. The network 102 may represent a collection of networks and gateways that use Transmission Control Protocol / Internet Protocol (TCP / IP) and other protocols to exchange data with one another. In the center of the Internet is a central connection (backbone) of communications links between master nodes or host computers, including thousands of private, state, educational, and other computer systems that route data and messages. Of course, the computing environment 100 may also be implemented as a number of different types of networks, such as an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended to be illustrative, not limiting of the architecture for the various illustrative embodiments.Among other uses, the computing environment 100 may serve to implement a client-server environment in which the illustrative embodiments may be implemented. A client-server environment allows software applications and data to be distributed over a network, such that an application functions by utilizing interactivity between a client computing system and a server computing system. The computing environment 100 may also use a service-oriented architecture in which network-distributed, functionally matched software components are bundled as coherent business applications in a package. Computing environment 100 may also take the form of a cloud and utilize a service provisioning cloud computing model to enable smooth, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that may be quickly provided and enabled with minimal management effort or interaction with a provider of the service.Referring to FIG. 2, this figure illustrates a block diagram of a data processing system in which illustrative embodiments may be implemented. The data processing system 200 is an example of a computer, such as servers 104 and 106, or clients 110, 112, and 114 in FIG. 1, or another type of device in which computer usable program code or instructions that implement the processes may reside for the illustrative embodiments.The data processing system 200 is also representative of a data processing system or configuration therein, such as the classical processing system 104 in FIG. 1, in which computer usable program code / instructions that implement the processes may be for the illustrative embodiments. The data processing system 200 is described as a computer only by way of example, without being limited thereto. Implementations in the form of other devices, such as device 132 in FIG. 1, may alter data processing system 200, such as by adding a touch control interface, and even omit some illustrated components from data processing system 200, without departing from the general description of the operations and functions of data processing system 200 described herein.In the illustrated example, the data processing system 200 uses a node architecture with north bridge (north bridge) and memory controller hub (memory controller hub) (NB / MCH) 202 and south bridge (south bridge) and input / output (I / O) controller hub (input / output (I / O) controller hub) (SB / ICH) 204. A processing unit 206, a main memory 208, and a graphics processor 210 are connected to the north bridge and the memory controller hub (NB / MCH) 202. Processing unit 206 may include one or more processors and may be implemented using one or more heterogeneous processor systems. The processing unit 206 may be a multi-core processor. Graphics processor 210, in certain implementations, may be connected to NB / MCH 202 via an accelerated graphics port (AGP).In the illustrated example, a local area network (LAN) adapter 212 is connected to the southbridge and the I / O controller hub (SB / ICH) 204. Audio adapter 216, keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224, universal serial bus (USB), and other ports 232, and PCI / PCIe devices 234 connect to south bridge and I / O controller hub 204 via bus 238. A hard disk drive (HDD) or solid state drive (SSD) 226 and a CD-ROM drive 230 are connected to the southbridge and the I / O controller hub 204 via a bus 240. The PCI / PCIe devices 234 may include, for example, Ethernet adapters, add-in cards, and notebook computer PC cards. PCI uses a card bus controller, but PCIe does not. The ROM 224 may be, for example, a binary input / output system (BIOS) flash memory. Hard disk drive 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or a serial advanced technology attachment (SATA) interface, or variants such as external SATA (eSAA) and micro-SATA (mSAA). A super I / O (SIO) unit 236 may be connected to south bridge and I / O controller hub (SB / ICH) 204 via bus 238.Memory such as main memory 208, ROM 224, or flash memory (not shown) are some examples of computer usable storage devices. Hard disk drive or solid state medium 226, CD-ROM 230, and other similarly usable devices are some examples of computer usable storage devices, including a computer usable storage medium.An operating system runs on the processing unit 206. The operating system coordinates and provides control to various components within the data processing system 200 in FIG. 2. The operating system may be a commercially available operating system for any type of computing platform, including, but not limited to, server systems, personal computers, and mobile units. An artifact-oriented or other type of programming system may operate in conjunction with the operating system and provide prompts to the operating system of programs or applications executing in data processing system 200.Instructions for the operating system, artifact-oriented programming system, and applications or programs, such as application 105 in FIG. 1, reside on storage devices, such as code 226A on hard disk drive 226, and may be loaded into at least one or more memories, such as main memory 208, for execution by processing device 206. The processes of the illustrative embodiments may be performed by the processing unit 206 using computer-implemented instructions that may reside in memory, such as main memory 208, read-only memory 224, or one or more peripheral devices.Further, in one case, code 226A may be downloaded over network 201A from remote system 201B where similar code 201C is stored on storage unit 201D. In another case, code 226A may be downloaded via network 201A to remote system 201B where downloaded code 201C is stored on storage unit 201D.The hardware in FIGS. 1 to 2 may vary depending on the implementation. Other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory or optical disk drives, and the like may be used in addition to or in place of those depicted in Figures 1-2. In addition, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system.In some illustrative examples, the data processing system 200 may be a personal digital assistant (PDA) that is generally configured with flash memory to provide non-volatile memory for storing operating system files and / or user generated data. A bus system may include one or more buses such as a system bus, an I / O bus, and a PCI bus. Of course, the bus system may be implemented using any type of data transfer fabric or architecture that provides for data transfer between various components or units coupled to the fabric or architecture.A communication device may include one or more devices used to send and receive data, e.g., a modem or network adapter. The memory may be, for example, a main memory 208 or a cache, e.g., the cache in the north bridge and the memory controller hub 202. A processing unit may include one or more processors or central processing units.The illustrated examples in FIGS. 1-2 and the examples described above are not intended to indicate limitations on the architecture. In addition to being able to take the form of a mobile or wearable device, the computing system 200 may also be a tablet, laptop, or telephone device.When a computer or data processing system is described as a virtual machine, virtual device, or virtual component, the virtual machine, virtual device, or virtual component functions in the manner of data processing system 200 utilizing virtualized execution of some or all of the components represented in data processing system 200. For example, in a virtual machine, virtual device, or virtual component, processing unit 206 is embodied as a virtualized instance of all or a number of hardware processing units 206 available in a host computing system, main memory 208 is embodied as a virtualized instance of all or a portion of main memory 208 that may be available in the host computing system, and storage disk 226 is embodied as a virtualized instance of all or a portion of storage disk 226 that may be available in the host computing system. The host data processing system is represented by data processing system 200 in such cases.Referring to FIG. 3, this figure illustrates a functional diagram of a group of vehicles 310, 320, 330, 340, 350 (each labeled C1to C5) in a first common environment 300 according to an illustrative embodiment, wherein each vehicle sends movement data 302 to a database, such as database 109 of FIG. 1, via a computer network 102. In a common environment 300, each of the vehicles 310, 320, 330, 340, 350 has internal sensors on board that report mechanical condition and motion as the vehicle travels along a road. As the vehicle 310, 320, 330, 340, 350 travels in the first common environment 300, sensors in each vehicle acquire and transmit motion and state data through a communication network, such as the wireless network 102 of FIG. 1, in which the sensor data is stored in the database 109. A central processor, such as the processor system 104 (processor), acquires, stores, and assembles the sensor data 302 from each vehicle 310, 320, 330, 340, 350 to form a collection of data, referred to as a "consensus block" of data. The processor 104 then detects vehicle motion patterns in the consensus data that exceed a certain threshold, which indicates a vehicle that may have begun a high-risk maneuver or otherwise exhibited behavior that does not match established driving safety policies.In an effort to avoid storing false positives in the consensus block and also to establish high reliability and consistency in the data itself, there must be a minimum number (quorum) of vehicles 310, 320, 330, 340, 350 with onboard sensors in the first common environment 300. The quorum of vehicles may vary in a particular situation. In one example, a quorum of five vehicles is required, while in another example, a quorum of three vehicles is sufficient to establish redundancy and reliability of the data stored in the consensus block. According to some embodiments, a vehicle 310 in the common environment is of interest to a monitoring agency, where the other vehicles 320, 330, 340, 350 function as vehicles for the driving behavior of the vehicle 310. In FIG. 3, there is a quorum of three vehicles, with five vehicles present. In a situation where a quorum is not reached (e.g., there are too few vehicles in the first common environment 300), the consensus block is not updated because the data sent by each vehicle 310, 320, 330, 340, 350 cannot be verified to a satisfactory extent.Also, in accordance with some embodiments, external sensors not on board a vehicle 310, 320, 330, 340, 350 may also provide sensor data 302 to a database 109, where external sensors are defined as sensors not included in the quorum of vehicles in the first common environment 300. External sensors may include, but are not limited to, video cameras located in mobile or immobile (non-quorum) vehicles, traffic cameras, smart phone video and audio functions, drone sensors, component mounted security cameras, toll station sensors, and the like. Other sensors are possible and are not limited to these examples. In some embodiments, sensor data from external sensors may also be sent to database 109 to be included in the consensus block as described herein.According to some embodiments, each quorum of vehicles and each external sensor in the first common environment 300 send their sensor data to the database 109 over an ad hoc wireless network such as the network 102 of FIG. 1. the selection of elements within the ad hoc network 102 need not be large, as a selection sufficient to cover a normal traffic situation would be sufficient. Some example traffic situations may include, but are not limited to, high traffic volume, cars crossing lane lines, speed overshoot, and the like.According to some embodiments, each vehicle 310, 320, 330, 340, 350 shares the sensor data with each other vehicle 310, 320, 330, 340, 350 over the ad hoc network 102. In this way, an objective view of events over time may be captured and sent to database 109 to form an uncaptured consensus block for later analysis. It is possible that the vehicles 310, 320, 330, 340, 350 in the quorum each capture slightly different versions of the same event and thus provide a unique perspective of each vehicle 310, 320, 330, 340, 350 as viewed from that vehicle's view. Thus, only the aggregated data forming the consensus block is combined for further analysis and possible action by a monitoring authority. In some embodiments, vehicle motion greater than a tolerance for a particular threshold results in the processor 104 associating (associating) the identity of the vehicle with a particular vehicle. In some embodiments, the monitoring authority monitors the consensus block and determines when a vehicle motion greater than a certain tolerance exceeds a threshold and thus triggers a feedback (response), the response being a positive response or a negative response.In one embodiment, a responsible party or monitoring agency, such as a law enforcement or traffic flow monitoring agency, analyzes the consensus block for improper driving behavior. Once undesirable driving behavior is detected, the processor 104 may make a decision to generate a feedback action. Feedback actions include both positive and negative feedback. Positive feedback includes, but is not limited to, providing assistance to the driver in the form of sending a message to the driver of the vehicle via the audio system, cellular communication, vibration by the vehicle, and the like. Negative feedback includes restricting vehicle motion by applying brakes or throttling engine power, correcting steering errors, or reporting to a monitoring authority to assist in aiding the driver as necessary and assist to ensure that the first common environment 300 is safe.In some embodiments, the consensus block of sensor data is sent to an external agency, where the external agency filters the incoming consensus blocks, sorts out duplicate data, and updates the remaining block into an entire blockchain, and thus stores the consensus block in an invariable database to serve as evidence in any other methods. The consensus block thus contains all necessary information in connection with a specific driving condition in a first common environment 300 in a specific period of time.Referring to FIG. 4, this figure illustrates a functional diagram of a group of vehicles 310, 320, 330, 340, 350 in a second common environment 400 according to an illustrative embodiment, where some vehicles 320, 330, 340, 350 transmit motion data and a vehicle 310 is not connected to a computer network 102. The second common environment 400 is similar to the first common environment 300 except that there is a vehicle 310 that is not connected to the ad hoc network. However, since 4 other vehicles 320, 330, 340, 350 are present, a quorum is still satisfied and acquisition of sensor data is possible. Therefore, each connected vehicle 320, 330, 340, 350 continues to send sensor data 302 to the database 109 and a consensus block of sensor data is formed and stored. In this embodiment, the vehicle 310 may still be monitored while within the second common environment 400, but may not transmit or receive sensor data or feedback of any type, either positive or negative.Examples of driving behaviors that either do not generate a feedback response or a positive feedback response include keeping a safety margin when driving behind other vehicles, operating the turn signal indicator, allowing other cars to merge, avoiding narrowed lanes, and considering the preference of pedestrians. Examples of driving behaviors that generate a negative feedback response include, but are not limited to, not considering safety margins, prohibited passing of a car, causing nearby vehicles to abruptly brake, no operation of the turn signal indicator in lane change, no giving priority to pedestrians, and the like. Other examples are possible and are not limited to these examples.Referring to FIG. 5, this figure illustrates a functional diagram in accordance with an illustrative embodiment in which a group of vehicles 511, 512, 513, 514, 515 (labeled 1-5) monitored for traffic related behavior by a computer network starts a feedback event 500. The group of vehicles 511, 512, 513, 514, 515 form a quorum of vehicles and are monitored by both internal vehicle sensors and traffic sensors as parts of the road monitoring system 502. In the present embodiment, the quorum sends vehicle motion data 302 to database 109 as disclosed herein. Once the consensus block is formed from the aggregated data, elements 504 of the consensus block are returned via the computer network 102 to be shared with each vehicle 511, 512, 513, 514, 515. In this way, all elements 504 of the consensus block are shared by each vehicle 511, 512, 513, 514, 515, and the consensus block is constructed by using portable data from each of the vehicles 511, 512, 513, 514, 515 to provide a reliable and objective snapshot of the conditions on the road 502 during a particular time period.Continuing with FIG. 5, a quorum histogram 550 is disclosed that shows the total number of vehicles on the Y-axis 554 and the time represented on the X-axis 552. The resulting diagram 556 discloses two vehicles in quorum at time T 1, three vehicles present in quorum at time T 2, etc. Therefore, using the examples discussed above, a quorum of vehicles was not present at times T 1 and T 5, but present at times T 2 to T 4. In FIG. 5, the example continues with the vehicle 513 accelerating toward the rear of the vehicle 511. Each vehicle 511, 512, 513, 514, 515 in the quorum reports this sensor data as acquired from the unique view of each vehicle and sends the data to database 109 to augment the consensus block. Once the processor recognizes at the traffic monitoring agency that the vehicle 513 is in danger of encountering the vehicle 511, a feedback response is generated and sent to the vehicle 513. The feedback may be positive or negative as explained above. The feedback responses for this example may include, but are not limited to, warning the driver of vehicle 513 using audible or visual signals, commanding the vehicle to apply its brakes, or warning local emergency responders that an erratic driving behavior is emanating from vehicle 513. Another response or a combination of a positive and a negative response is possible and is not limited to this example.Referring to FIG. 6, this figure illustrates a functional diagram in which multiple groups of vehicles 511, 512, 513, 514, 515, 560, 570 (labeled 1-7) monitored for traffic-related behavior by a computer network starts a feedback event 600. In this embodiment, it is shown that multiple different quors may be defined simultaneously within a single group of vehicles 511, 512, 513, 514, 515, 560, 570. In this embodiment, a first quorum 602 may be defined, for example, while the first three vehicles are starting at a traffic light, while a second quorum 604 may be defined as those vehicles 511, 512, 513, 514, 515, 560, 570 traveling below the rejected speed limit. Regardless of the involvement of each vehicle 511, 512, 513, 514, 515, 560, 570 in a particular quorum, the sensor data of each vehicle may be sent to the database over the ad hoc network 102 to update the consensus block as disclosed herein.Referring to FIG. 7, this figure illustrates a dataflow diagram of an example process 700 for monitoring multiple groups of vehicles traveling in a common environment for traffic related behavior according to an illustrative embodiment. The process 700 begins at block 702, where a quorum of vehicles is within a common environment within a particular ad hoc wireless network, such as the network 102, as disclosed herein. Next, at decision block 704, the processor determines whether a quorum is present. To form a quorum, there must be a minimum number of vehicles. Additionally, a particular vehicle may be simultaneously member in more than one quorum. If the answer at decision block is "no", the process returns to await additional vehicles. If the answer is "yes", the process continues at block 706, where vehicle sensors and external sensors send data to the database, such as database 109, to form a aggregate data consensus block. When the consensus block is formed, the consensus block is shared with each connected vehicle to ensure that all vehicles have access to the same data. Next, at decision block 708, the processor analyzes the consensus block to detect whether a different driving behavior has been detected in one of the vehicles in the quorum. If "no", the process 700 returns to form an additional quorum of vehicles at block 702. If "yes", the processor generates either a positive or negative response feedback action and returns the response to the vehicle, other authority, or emergency responders for further action.Thus, a computer implemented method, program product, and system are provided in the illustrative embodiments for consensus-based monitoring of driving behavior in associated vehicle systems and other related features, functions, and operations. When an embodiment or part thereof is described in relation to a type of device, the computer implemented method, program product or system implemented by a computer, or part thereof, are adapted or configured for use with a suitable and comparable manifestation of that type of device.When an embodiment is described as being implemented in an application, the delivery of the application in a software as a service (SaaS) model is deemed to be within the scope of the illustrative embodiments. In a SaaS model, the function of the application implementing an embodiment is provided to a user by executing the application in a cloud infrastructure. The user may access the application using various client devices via a thin client interface, such as a web browser (e.g., web-based eMail) or other lightweight client applications. The customer does not manage or control the underlying cloud infrastructure with network, servers, operating systems, or storage of the cloud infrastructure. In some cases, the user may not even manage or control the function of the SaaS application. In some other cases, the SaaS implementation of the application may allow a possible exception to the limited user-specific settings of the application configuration.The present invention can be a system, a method and / or a computer program product at any possible technical level of integration. The computer program product may comprise a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.The computer readable storage medium may be a physical device that can retain and store instructions for use by a system for executing instructions. The computer readable storage medium may be, for example, but is not limited to, an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions stored thereon, and any suitable combination thereof. A computer readable storage medium, as used herein, is not intended to be transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through an optical fiber cable), or electrical signals transmitted through a wire.Computer readable program instructions described herein may be downloaded from a computer readable storage medium to respective data processing / processing devices or via a network such as the Internet, a local area network, a wide area network, and / or a wireless network to an external computer or storage device. The network may include copper transmission cables, lightwave transmission conductors, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the corresponding computing / processing unit.Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or either source code or artifact code written in any combination of one or more programming languages, including artifact oriented programming languages such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuits to perform aspects of the present invention.Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It is noted that each block of the flowcharts and / or the block diagrams, as well as combinations of blocks in the flowcharts and / or the block diagrams, may be executed by computer readable program instructions.These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed via the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / steps specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored on a computer readable storage medium that can control a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored thereon comprises an article of manufacture including instructions that implement aspects of the function / step specified in the flowchart and / or block diagram block or blocks.The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer or other programmable apparatus or other device to produce a computer executed process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / steps specified in the flowchart and / or block diagram block or blocks.The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products for consensus-based monitoring of driving behavior in connected vehicle systems according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions that include one or more executable instructions for executing the particular logical function(s). In some alternative implementations, the functions indicated in the blocks may occur in a different order than shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order depending on the appropriate functionality. It is further noted that each block of the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or steps, or perform combinations of special purpose hardware and computer instructions.

Claims

A method for monitoring vehicle traffic behavior and feedback, comprising: acquiring vehicle sensor data from a set of vehicles (310, 320, 330, 340, 350) operating in a traffic environment (300), each vehicle forming a communication network (102) with other ones of the vehicles within range, via which it sends vehicle sensor data to a processor (104); determining whether to analyze the vehicle sensor data by determining whether the set of vehicles comprises sufficient vehicles to form a quorum; In response to determining that the set of vehicles constitutes a quorum, forming a consensus block of aggregated data, wherein the aggregated data comprises individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor sorts duplicate data and repetitive data from the consensus block; detecting a vehicle motion pattern in the consensus block, wherein the vehicle motion pattern deviates from a threshold by more than a tolerance; associating the vehicle motion pattern with a particular vehicle in the set of vehicles; and generating a feedback response based on the associating, wherein the vehicles in the quorum each detect different versions of the same event.The method of claim 1, further comprising: updating the consensus block with data from non-vehicle sensors.The method of claim 1, wherein the consensus block is stored as invariable data in a blockchain database.The method of claim 1, wherein the feedback response comprises alerting a driver in the associated vehicle.The method of claim 1, wherein the feedback response comprises alerting emergency responders.The method of claim 1, wherein the feedback response comprises alerting drivers of other vehicles in the set of vehicles.The method of claim 1, wherein the feedback response comprises instructing the associated vehicle to perform an action.The method of claim 1, further comprising: sending the consensus block to an external agency.The method of claim 1, wherein at least one of the vehicles in the set of vehicles is autonomously controlled.The method of claim 1, wherein the set of vehicles comprises pedestrians utilizing road vehicles and / or aircraft and / or ships and / or trains and / or movement aids.The method of claim 1, further comprising: sending, by the processor, the consensus block to all vehicles of the set of vehicles.A computer program product for monitoring vehicle traffic behavior and feedback, the computer program product comprising: one or more computer readable storage media; and program instructions executable by a processor and collectively stored on one or more computer readable storage media, the program instructions comprising: program instructions for acquiring vehicle sensor data from a set of vehicles operating in a traffic environment, each vehicle forming with other ones of the vehicles in range a communication network via which it sends vehicle sensor data to a processor; program instructions for determining whether to analyze the vehicle sensor data by determining whether the set of vehicles comprises sufficient vehicles to form a quorum; Program instructions for forming, in response to determining that the set of vehicles forms a quorum, a consensus block of aggregated data, wherein the aggregated data comprises individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor sorts duplicate data and repetitive data from the consensus block; program instructions for detecting a vehicle motion pattern in the consensus block, wherein the vehicle motion pattern deviates from a threshold by more than a tolerance; program instructions for associating the vehicle motion pattern with a particular vehicle in the set of vehicles; and program instructions for generating a feedback response based on the associating, wherein the vehicles in the quorum each detect different versions of the same event.The computer program product of the preceding claim, further comprising: program instructions for updating the consensus block with data from non-vehicle sensors.The computer program product of claim 12, wherein the consensus block is stored as fixed data in a blockchain database.The computer program product of claim 12, wherein the feedback response comprises instructing the associated vehicle to perform an action.The computer program product of claim 12, wherein the computer usable code is stored in a computer readable storage device in a data processing system, and wherein the computer usable code is transmitted over a network from a remote data processing system.The computer program product of claim 12, wherein the computer usable code is stored in a computer readable storage unit in a server data processing system, and the computer usable code is downloaded over a network to a remote data processing system for use in a computer readable storage unit associated with the remote data processing system.A computer system comprising: a processor; a computer readable memory; a computer readable storage unit; and program instructions stored in the storage unit for execution by the processor via the memory, the stored program instructions comprising: program instructions for acquiring vehicle sensor data from a set of vehicles operating in a traffic environment, each vehicle forming a communication network with others of the vehicles in range, via which it sends vehicle sensor data to a processor; program instructions for determining whether to analyze the vehicle sensor data by determining whether the set of vehicles comprises sufficient vehicles to form a quorum; Program instructions for forming, in response to determining that the set of vehicles forms a quorum, a consensus block of aggregated data, wherein the aggregated data comprises individual vehicle sensor data from each vehicle in the set of vehicles, and wherein the processor sorts duplicate data and repetitive data from the consensus block; program instructions for detecting a vehicle motion pattern in the consensus block, wherein the vehicle motion pattern deviates from a threshold by more than a tolerance; program instructions for associating the vehicle motion pattern with a particular vehicle in the set of vehicles; and program instructions for generating a feedback response based on the associating, wherein the vehicles in the quorum each detect different versions of the same event.The computer system of claim 18, further comprising program instructions for updating the consensus block with data from non-vehicle sensors.The computer system of claim 18, wherein the response comprises instructing the associated vehicle to perform an action.

Images