Consensus-Based Monitoring of Driving Behavior in Connected Vehicle Systems

Abstract

The method for monitoring and providing feedback on vehicle traffic behavior includes: The method includes collecting vehicle sensor data from a set of vehicles operating in a traffic environment, wherein each vehicle communicates its sensor data over a communications network to a processor to form a consensus block of aggregated data, wherein the aggregated data is generated from individual vehicle sensor data from each vehicle in the set of vehicles, and the processor discards duplicate and repetitive data from the consensus block. The method also includes detecting vehicle motion patterns in the consensus block, wherein the vehicle motion patterns deviate from a threshold by more than a tolerance, mapping the vehicle motion patterns to specific vehicles in the set of vehicles, and generating a feedback response based on the mapping.

Description

[Technical field]

[0001] The present invention relates generally to methods, computer program products and systems in the field of vehicular traffic behavior. More specifically, the present invention relates to methods, computer program products and systems for consensus-based driving behavior monitoring in connected vehicle systems. [Background technology]

[0002] Vehicle traffic accidents impose a large cost in life and property loss worldwide. Analysis of traffic accidents reveals several patterns. In many cases, accidents are caused by careless drivers or drivers who are unaware of local road conditions. Additionally, areas with non-dedicated or weak traffic management show a greater likelihood of accidents. In addition to automobile accidents, vehicle accidents also occur between ships and watercraft on waterways, between aircraft and service vehicles on airport taxiways, between two aircraft on the ground, and between a person driving a motorized scooter and a personal transportation device.

[0003] Modern personal vehicles, including automobiles, are already equipped with a variety of sensors, including, but not limited to, motion sensors, still cameras, event recorders, video cameras, proximity detectors, lane detectors, speed sensors, precipitation sensors, turn signal sensors, etc. As vehicle technology develops, personal vehicles will use additional sensors, including video sensors and sensors used in maintaining speed and spacing within a traffic lane. Additionally, the advent of autonomous vehicles will also closely align vehicles with a multitude of motion, proximity, and status sensors.

[0004] Today's modern vehicles use various sensors to monitor and report vehicle status and also vehicle motion, which the vehicle reports or transmits back to the personal driver. Feedback can include the vehicle's mechanical status, and can also include approach alerts, over-speed alerts, pedestrians in the travel path, etc. Personal vehicles, such as automobiles, also use diagnostic and driver assistance sensors and systems. In one example, some commercially available vehicles available today use automatic braking systems and local approach sensors to prevent or minimize collisions with vehicles in front of the traveling vehicle. When activated, the automatic braking system applies the brakes in an effort to stop the vehicle before it hits an object. In another example, some automobiles can shut off the engine if a mechanical failure is detected to prevent mechanical damage. In some vehicles, sensor systems can assist with parallel parking, lane following, variable speed cruise control, and the ability to detect a driver trying to fall asleep. Some vehicles can also provide automatic feedback in response to sensor data, such as automatically braking the vehicle without driver input, automatically steering the vehicle during parking maneuvers, and automatically steering to maintain lane spacing.

[0005] It is also evident that public arteries such as roads and airports are using more and more video cameras as part of an effort to improve safety, security, and to record events of interest to parties such as government, first responders, and traffic monitoring organizations. This has resulted in roads being monitored by a variety of sensors and cameras.

[0006] Current technology allows individual vehicles to receive and respond to events using their own sensor data. However, the current driving environment lacks a community-based or consensus-based driver assistance method and system where a vehicle traveling in a common environment with other vehicles uses all of the sensors currently in the vicinity of the vehicle, including the vehicle itself, nearby vehicle and traffic cameras, and external sensors such as building security cameras. Vehicles using multiple intrinsic and external sensors should use consensus of available sensor data.

[0007] In the current driving environment, vehicles pass through the sensor range of various sensors, many of which are not available to a particular vehicle. Thus, many different types of sensor data are generated and currently unused as vehicles pass through a common environment. This collection of available data is called “consensus data” and represents the sum of data collected from many sensors monitoring roads, sea routes, etc. Each sensor provides data that feeds into the consensus data, reporting on events occurring from that sensor’s individual perspective. A consensus data block is therefore an accumulation of data from many individual sensors to provide an unbiased picture of events occurring from the perspective of several individual sensors.

[0008] In the current environment, individual driving behaviors sometimes contribute to accidents, injure people, and cause property damage. Drivers, pilots, captains, etc. are often distracted by the myriad of data flowing to them, distractions from cell phones, external sounds, weather events, road conditions, fatigue, or the presence of objects that improve or hinder the driver's response to the evolving driving situation. Driver distraction is likely to increase as technology continues to develop, vehicles become more complex, and major roads become more congested. In addition, some drivers sometimes deliberately decide not to behave in a defensive manner (by following the rules), however, instead choose more extreme driving behaviors to achieve certain effects, such as getting through faster, saving time, or avoiding stops and delays. The present disclosure can help protect the lives of other traffic drivers and pedestrians by warning them about detected inappropriate behaviors, and also by providing immediate, personalized feedback to have a positive effect on the misbehaving driver. In another example, an autonomous vehicle may not comply with traffic rules due to a programming error. Unbiased external sensor feedback can help correct such programming problems.

[0009] One developing trend for personal vehicles is the ability to wirelessly connect to local cell sites, satellite services, and wireless communications originating from the vehicle itself. Some personal devices, such as cell phones, laptops, and tablets, can also act as wireless access points. Thus, in many instances, vehicles traveling on the road are often exposed to a variety of options for wirelessly connecting to the Internet, the cloud, and the like.

[0010] In many cases, accidents are caused by localized situations that the driver of the vehicle does not notice, such as a traffic jam, a pedestrian in the road, a construction site, an accident around a curve, etc. However, other vehicle sensors, or fixed cameras, or both, and other sensors may have already detected the situation but are currently unable to alert the driver to get out of danger. Summary of the Invention

[0011] An exemplary embodiment provides a method for monitoring and providing feedback on vehicular traffic behavior, the method including collecting vehicular sensor data from a set of vehicles operating in a traffic environment, each vehicle communicating the sensor data over a communication network to a processor, forming a consensus block of aggregated data, the aggregated data generated from the individual vehicular sensor data from each vehicle in the set of vehicles, and the processor discarding duplicate and repetitive data from the consensus block. The method also includes detecting a vehicular motion pattern in the consensus block, the vehicular motion pattern deviating from a threshold value by more than a tolerance, mapping the vehicular motion pattern to a particular vehicle in the set of vehicles, and generating a feedback response based on the mapping.

[0012] An embodiment includes a computer program product for monitoring and providing feedback on vehicular traffic behavior, the computer program product including one or more computer readable storage media and program instructions collectively stored on the one or more computer readable storage media, the program instructions including: collecting vehicular sensor data from a set of vehicles operating in a traffic environment, each vehicle communicating its sensor data over a communication network to a processor; forming a consensus block of aggregated data, the aggregated data generated from individual vehicular sensor data from each vehicle in the set of vehicles, and the processor discarding duplicate and repetitive data from the consensus block. The program instructions also include program instructions for detecting, in the consensus block, a vehicular motion pattern, where the vehicular motion pattern deviates from a threshold value by more than a tolerance; mapping the vehicular motion pattern to a particular vehicle in the set of vehicles; and generating a feedback response based on the mapping.

[0013] An embodiment includes a computer system including a processor, a computer readable memory, a computer readable recording device, and program instructions stored on the recording device for execution by the processor via the memory, the program instructions including: collecting vehicle sensor data from a set of vehicles operating in a traffic environment, each vehicle communicating its sensor data over a communication network to the processor, forming a consensus block of aggregated data, the aggregated data generated from individual vehicle sensor data from each vehicle in the set of vehicles, and the processor discarding duplicate and repetitive data from the consensus block. The program instructions also include program instructions for detecting vehicle motion patterns in the consensus block, the vehicle motion patterns deviating from a threshold value by more than a tolerance, mapping the vehicle motion patterns to specific vehicles in the set of vehicles, and generating a feedback response based on the mapping.

[0014] Certain novel features believed to be characteristic of the invention are set forth in the appended claims. The invention itself, however, and preferred modes of use, together with further objects and advantages thereof, will best be understood by reference to the following detailed description of illustrative embodiments when read in connection with the accompanying drawings. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 is a block diagram of a network of data processing systems in which illustrative embodiments may be implemented. [Diagram 2] FIG. 2 is a block diagram of a data processing system in which illustrative embodiments may be implemented. [Diagram 3]FIG. 3 illustrates a functional diagram of a group of vehicles in a common environment with each vehicle sending motion data to a computer network in accordance with an exemplary embodiment. [Figure 4] FIG. 4 illustrates a functional diagram of a group of vehicles in a common environment, where some vehicles send motion data and some vehicles are not connected to a computer network, in accordance with an exemplary embodiment. [Diagram 5] FIG. 5 illustrates a functional diagram where a group of vehicles is monitored by a computer network for traffic-related behavior in accordance with an exemplary embodiment. [Figure 6] FIG. 6 illustrates a functional diagram of a group of vehicles traveling in a common environment, where the group can be members of several groups simultaneously, according to an exemplary embodiment. [Figure 7] FIG. 7 illustrates a flowchart of an exemplary process for monitoring a group of vehicles traveling within a common environment for traffic-related behavior in accordance with an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] The illustrative embodiments recognize the need for consensus-based monitoring of driving behavior of connected vehicle systems, including personal vehicles, commercial vehicles, aircraft, ships and other watercraft, and transportation devices of all types.

[0017] The exemplary embodiments are described using specific code, designs, architectures, protocols, layouts, schemes, and tools as examples only, and are not intended to limit the exemplary embodiments. Furthermore, the exemplary embodiments are described in some examples using specific software, tools, and data processing environments that are examples only for clarity of explanation. The exemplary embodiments may be used in combination with other compatible or similar purpose structures, systems, applications, or architectures. For example, other compatible mobile devices, structures, systems, applications, or architectures therefor may be used in combination with such embodiments of the present invention within the scope of the present invention. The exemplary embodiments may be implemented in hardware, software, or a combination thereof.

[0018] The examples in this disclosure are used only for clarity of explanation and do not limit the exemplary embodiments. Additional data, operations, acts, tasks, activities, and manipulations are contemplated from this disclosure, and the same will be considered to be within the scope of the exemplary embodiments.

[0019] Any advantages listed herein are exemplary only and are not intended to limit the example embodiments. Additional or different advantages may be realized by certain example embodiments. Moreover, certain example embodiments may have some, none, or all of the advantages listed above.

[0020] 1 is a block diagram of a network of data processing systems in which an exemplary embodiment may be implemented. Data processing environment 100 is a network of computers in which an exemplary embodiment may be implemented. Data processing environment 100 includes network 102. Network 102 is a medium used to provide communications links between various interconnected devices and computers within data processing environment 100. Network 102 may include connections such as wired, wireless communications links, or fiber optic cables.

[0021] Client or server are only exemplary roles for certain data processing systems connected to network 102 and are not intended to exclude other configurations or roles for these data processing systems. Server 104 and server 106 are connected to network 102, along with storage unit 108. Software applications may run on any computer in data processing environment 100. Clients 110, 112, and 114 are also connected to network 102. A data processing system, such as server 104 or 106 or client 110, 112, or 114, may contain data and have software applications or software tools running thereon.

[0022] By way of example only, and without implying any limitation to such architecture, FIG. 1 illustrates certain components that may be used to implement example embodiments. For example, servers 104 and 106 and clients 110, 112, 114 are described as servers and clients by way of example only, and are not meant to be limited to a client-server architecture. As another example, the embodiments may be distributed across several data processing systems and data networks, but in another embodiment may be implemented on a single data processing system within the scope of the exemplary embodiment. Data processing systems 104, 106, 110, 112, and 114 also represent example nodes in clusters, partitions, and other configurations suitable for implementing the embodiments.

[0023] Device 132 is an example of a device described herein. For example, device 132 may take the form of a smart phone, a tablet computer, a laptop computer, a fixed or portable form of client 110, a wearable computing device, or any suitable device. Any software applications described in FIG. 1 as executing in another data processing system may be configured to execute in device 132 in a similar manner. Any data or information stored or generated in another data processing system of FIG. 1 may be configured to be stored or generated in device 132 in a similar manner.

[0024] Servers 104 and 106, storage unit 108, and clients 110, 112, 114, and device 132 may connect to network 102 using wired connections, wireless communication protocols, or any other data connections. Clients 110, 112, 114 may be, for example, personal computers or network computers. Application 105 implements the embodiments described herein.

[0025] In the illustrated embodiment, server 104 may provide data such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 may be clients to server 104 in this embodiment. Clients 110, 112, and 114, or some combination thereof, may include their own data, boot files, operating system images, and applications. Data processing environment 100 may include additional servers, clients, and other devices not shown.

[0026] In the depicted example, data processing environment 100 may be the Internet. Network 102 represents a collection of networks and gateways that use Transmission Control Protocol / Internet Protocol (TCP / IP) and other protocols to communicate with one another. At the heart of the Internet is a backbone of data communications links between major nodes, or host computers, including thousands of commercial, government, educational, and other computer systems, that route data and messages. Of course, data processing environment 100 may also be implemented as many different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIGURE 1 is intended as an example, and not an architectural limitation for the different illustrative embodiments.

[0027] Among other uses, the data processing environment 100 can be used to implement a client-server environment in which the exemplary embodiments can be implemented. A client-server environment allows for the distribution of software applications and data across a network so that applications function by using interactions between client and server data processing systems. The data processing environment 100 can also use a service-oriented architecture in which interoperable software components distributed across a network are packaged together as a cohesive business application. The data processing environment 100 can also take the form of a cloud and use a cloud computing model of service delivery that allows convenient, 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 are rapidly provisioned and released with minimal administrative effort or interaction with the service provider.

[0028] Referring to Figure 2, this drawing illustrates a block diagram of a data processing system in which the exemplary embodiments may be implemented. Data processing system 200 is an example of another type of device in which computer-usable program code or instructions implementing a computer or process, such as servers 104 and 106 or clients 110, 112, and 114 in Figure 1, may be located for the exemplary embodiments.

[0029] Data processing system 200 is also illustrative of a data processing system, such as classical processing system 104 of FIG. 1, or an internal configuration thereof, in which computer usable program code or instructions that implement the processes of the illustrative embodiments may be located. Data processing system 200 is described as a computer by way of example only, and not by way of limitation. Implementations in the form of other devices, such as device 132 of FIG. 1, may modify data processing system 200, such as adding a touch interface and removing certain illustrated components from data processing system 200, without departing from the general description of the operation and functionality of data processing system 200 described herein.

[0030] In the illustrated embodiment, data processing system 200 uses a hub architecture including a north bridge and memory controller hub (NB / MCH) 202 and a south bridge and 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 memory controller hub (NB / MCH) 202. The 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. The graphics processor 210 may be connected to the NB / MCH 202 via an Accelerated Graphics Port (AGP) in certain implementations.

[0031] In the illustrated embodiment, a local area network (LAN) adapter 212 is connected to the south bridge and I / O controller hub (SN / ICH) 204. An audio adapter 216, a keyboard and mouse adapter 220, a modem 222, a read-only memory (ROM) 224, a universal serial bus (USB) and other ports 232, and PCI / PCIe devices 234 are connected to the south bridge and I / O controller hub 204 via a bus 238. A hard disk drive (HDD) or solid state drive (SSD) 226 and a CD-ROM 230 are connected to the south bridge and I / O controller hub 204 via a bus 240. The PCI / PCIe devices 234 may include, for example, an Ethernet adapter, a notebook computer add-in card, and a PC card. PCI uses a card bus controller, whereas PCIe does not. ROM 224 may be, for example, a flash binary input / output system (BIOS). Hard disk drive 226 and CD-ROM 230 may use, for example, Integrated Drive Electronics (IDE), Serial Advanced Technology Attachment (SATA) interfaces, or variations such as External SATA (eSATA) and Micro SATA (mSATA). Super I / O (SIO) device 236 may be connected to South Bridge and I / O Controller Hub (SB / ICH) 204 through bus 238.

[0032] Memories such as main memory 208, ROM 224, or flash memory (not shown) are some examples of computer usable storage devices. Hard disk drives or solid state drives 226, CD-ROM 230, and other similarly usable devices are some examples of computer usable storage devices that include computer usable recording media.

[0033] An operating system runs on the processing unit 206. The operating system coordinates and provides control for the various components within the data processing system 200 of 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 devices. An artificially oriented, or other type of programming system, may run in combination with the operating system and invoke the operating system from programs or applications to run on the data processing system 200.

[0034] Instructions for an operating system, an artificially directed programming system, and applications or programs, such as application 105 in FIG. 1, may be located on a storage device, such as in the form of code 226A on a hard disk drive 226, and loaded into at least one of the one or more memories, such as main memory 208, for execution by the processor unit 206. The processes of the exemplary embodiments may be performed by the processing unit 206 using computer-implemented instructions, which may be located in a memory, such as the main memory 208, the read-only memory 224, or in one or more peripheral devices.

[0035] Additionally, in one case, the code 226A can be downloaded over the network 201A from a remote system 201B, where similar code 201C is stored on a storage device 201D, and in another case, the code 226A can be downloaded over the network 201A to a remote system 201B, where the downloaded code 201C is stored on a storage device 201D.

[0036] The hardware depicted in Figures 1-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, may be used in addition to or in place of the hardware depicted in Figures 1-2. In addition, the processes of the illustrative embodiments may be applied to multiprocessor data processing systems.

[0037] In some example embodiments, data processing system 200 may be a personal digital assistant (PDA), which is typically configured with flash memory providing non-volatile memory for storing operating system files, user generated data, or both. The 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 communication facility or architecture that provides for a transfer of data between different components or devices connected to the facility or architecture.

[0038] The communications unit may include one or more devices used to send and receive data, such as a modem or a network adapter. The memory may be, for example, main memory 208 or a cache, such as a cache found in north bridge and memory controller hub 202. The processing unit may include one or more processors or CPUs.

[0039] 1-2 and described above are not meant to imply architectural limitations. For example, data processing system 200 may also take the form of a tablet computer, a laptop computer, or a telephone device in addition to taking the form of a mobile or wearable device.

[0040] 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 operates in the manner of data processing system 200 using a virtualized embodiment of some or all of the components depicted 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 some number of hardware processing units 206 available in the host data processing system, main memory 208 is embodied as a virtualized instance of all or some portion of main memory 208 available in the host data processing system, and disk 226 is embodied by a virtualized instance of all or some portion of disk 226 available in the host data processing system. The host data processing system in such a case is represented by data processing system 200.

[0041] Referring to FIG. 3, the diagram illustrates a functional diagram of a group of vehicles 310, 320, 330, 340, 350 (labeled C1-C5, respectively) in a first common environment 300, where, according to an exemplary embodiment, each vehicle transmits motion data 302 over a computer network 102 to a database, such as database 109 of FIG. 1. In the first common environment 300, each vehicle 310, 320, 330, 340, 350 has on-board internal sensors that report mechanical conditions and motion as the vehicle travels along a road. As the vehicles 310, 320, 330, 340, 350 travel along the first common environment 300, the sensors within each vehicle collect and communicate the motion and condition data over a communications network, such as wireless network 102 of FIG. 1, where the sensor data is stored in database 109. A central processing unit, such as processor system 104 (processor), collects, stores, and combines the sensor data 302 from each vehicle 310, 320, 330, 340, 350 to form a collection of data, or aggregated data, referred to as a “consensus block” of data. The processor 104 then detects vehicle motion patterns within the consensus data that exceed a given threshold that indicates the vehicle may be entering a high-risk maneuver or has otherwise demonstrated behavior inconsistent with established driving safety guidelines.

[0042] In an effort to avoid false positive data stored in the agreement block, as well as to establish the reliability and consistency of the data itself, a minimum number (quorum) of vehicles 310, 320, 330, 340, 350 having on-board sensors in the first common environment 300 must be present in the first common environment 300. The quorum of vehicles can vary in a given situation. In one embodiment, a quorum of five vehicles is required, while in another embodiment, a quorum of three vehicles is sufficient to establish redundancy and reliability in the data stored in the agreement block. According to some embodiments, one vehicle 310 in the common environment is of interest to the monitoring authority, and the other vehicles 320, 330, 340, 350 act as witnesses to the driving behavior of the vehicle 310. In FIG. 3, the quorum of vehicles is three and there are five vehicles. In a quorum-determined situation (e.g., there are too few vehicles in the first common environment 300), the agreement block is not updated because the data sent by each vehicle 310, 320, 330, 340, 350 cannot be verified to be at a satisfactory level.

[0043] According to some embodiments, external sensors not mounted on the vehicles 310, 320, 330, 340, 350 can also register sensor data 302 to the database 109, where the external sensors are not included in the quorum of vehicles in the first common environment 300. External sensors can include, but are not limited to, moving or stationary vehicles (not included in the quorum), traffic cameras, video and audio from smart phones, drone sensors, security cameras mounted on buildings, toll booth sensors, etc. Other sensors are possible and are not limited to these examples. According to some embodiments, sensor data from external sensors can also be sent to the database 109 for inclusion in the agreement block, as described herein.

[0044] According to some embodiments, each quorum of vehicles in the first common environment 300 and each external sensor transmits their sensor data to the database 109 via an ad-hoc wireless network, such as the network 102 of Figure 1. The range of the elements in the ad-hoc network 102 need not be large, as a range sufficient to cover normal traffic conditions is adequate. Some traffic conditions may include, but are not limited to, congestion conditions, cars passing across lines, speed, etc.

[0045] According to some embodiments, each vehicle 310, 320, 330, 340, 350 shares sensor data with other vehicles 310, 320, 330, 340, 350 via the ad-hoc network 102. In this way, a current image of the event can be collected and sent to the database 109 to form an unbiased consensus block for later analysis. Each vehicle 310, 320, 330, 340, 350 in the quorum can detect slightly different versions of the same event, thus providing a unique view from each vehicle 310, 320, 330, 340, 350 as seen from that vehicle's perspective. Once collected in this way, only the aggregated data that makes up the consensus block is used for further analysis and possible action by the monitoring authority. In some embodiments, vehicle motion greater than the tolerance for a given threshold causes the processor 104 to map the vehicle's identity as a specific vehicle. According to some embodiments, the monitoring authority monitors the agreement block to determine when vehicle motion greater than a given tolerance crosses a threshold, thus triggering a feedback (response), where the response may be a positive or negative response.

[0046] In one embodiment, a responsible party or monitoring authority, such as a law enforcement or traffic monitoring authority, analyzes the consensus block for inappropriate driving behavior. Once an undesirable driving behavior is detected, the processor 104 may decide to generate a feedback action. The feedback action includes both positive feedback and negative feedback. Positive feedback includes assistance to the driver in the form of sending a message to the driver of the vehicle, such as, but not limited to, via an audio system, cellular communication, vehicle vibration, etc. Negative feedback includes, but is not limited to, limiting the motion of the vehicle through the use of brakes, inhibiting engine power, correcting steering errors, or assisting in the effort of providing assistance to the driver and notifying the monitoring authority for assistance if necessary to ensure the safety of the first common environment 300.

[0047] In some embodiments, the consensus block of sensor data is sent to an external authority, which filters the incoming consensus block, discards duplicate data, and updates the remaining blocks into the overall blockchain, and stores the consensus block in an immutable database to be used as evidence in any further proceedings. The consensus block thus contains all necessary information related to a given driving situation in the first common environment 300 at a given time period.

[0048] Referring to FIG. 4, the diagram illustrates a functional diagram of a group of vehicles 310, 320, 330, 340, 350 in a second common environment 400, where some of the vehicles 320, 330, 340, 350 are sending motion data and vehicle 310 is not connected to the computer network 102, according to an exemplary embodiment. The second common environment 400 is similar to the first common environment 300, except that there is one vehicle 310 that is not connected to the ad-hoc network 102. However, since there are four other vehicles 320, 330, 340, 350, a quorum is still established and sensor data can be collected. Thus, 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 is still able to monitor the second common environment 400, but is unable to send or receive sensor data or feedback of any kind, either positive or negative.

[0049] Examples of driving behaviors that either generate no feedback response at all or generate positive feedback responses include maintaining a safe following distance from other vehicles, using turn signals, allowing other vehicles to merge, stopping outside restricted lanes, and yielding to pedestrians on the right side of the road. Examples of driving behaviors that generate negative feedback responses include following at an unsafe following distance, illegally passing vehicles, causing nearby vehicles to brake suddenly, not using turn signals when changing lanes, not yielding to pedestrians on the right side of the road, etc. Other embodiments are possible and are not limited to these embodiments.

[0050] Referring to FIG. 5, the diagram illustrates a functional diagram of a group of vehicles 511, 512, 513, 514, 515 (labeled 1-5) monitored by a computer network for traffic-related behavior initiates a feedback event 500 according to an exemplary embodiment. The group of vehicles 511, 512, 513, 514, 515 form a quorum of vehicles and are monitored by both vehicle sensors internally and traffic sensors as part of a roadway 502 monitoring system. In this embodiment, the quorum sends vehicle motion data 302 to database 109 as described herein. Once an agreement block is formed from the aggregated data, elements 504 of the agreement block are sent back over computer network 102 to be shared by each of the vehicles 511, 512, 513, 514, 515. In this manner, all elements 504 of the agreement block are shared by each vehicle 511, 512, 513, 514, 515 and the agreement block is constructed using available data from each vehicle 511, 512, 513, 514, 515 to form a reliable, targeted snapshot of road conditions at a given period of time.

[0051] Continuing with FIG. 5, a quorum histogram chart 550 is disclosed in which the total count of vehicles is shown on the y-axis 554 and time is displayed on the x-axis 552. The resulting graph 556 shows two vehicles in the quorum at time T1, three vehicles at quorum time T2, and so on. Thus, using the example previously discussed, a quorum of vehicles is not present at times T1 and T5, but is present at times T2-T4. Continuing with the example in FIG. 5, with vehicle 513 accelerating towards the rear of vehicle 511. Each vehicle 511, 512, 513, 514, 515 in the quorum reports its sensor data as collected from each vehicle's unique perspective and sends these data to database 109 to augment the consensus block. Once the traffic control monitoring authority processor detects that vehicle 513 is in danger of colliding with vehicle 511, a feedback response is generated and sent to vehicle 513. As previously disclosed, feedback can be positive or negative. Feedback responses for this embodiment can include, but are not limited to, alerting the driver of the vehicle 513 using an audio or visual signal, having the vehicle apply its brakes, alerting a local first responsible party that erroneous driving behavior is occurring from the vehicle 513. Other responses or combinations of positive and negative feedback responses are possible and are not limited to this embodiment.

[0052] Referring to FIG. 6, this figure shows a functional diagram in which several groups of vehicles 511, 512, 513, 514, 515, 560, 570 (labeled 1-7) monitored by a computer network for traffic-related behavior initiate a feedback event 600. In this embodiment, it is illustrated that several different quorums are defined simultaneously within a single group of vehicles 511, 512, 513, 514, 515, 560, 570. In this embodiment, a first quorum 602 can be defined, for example, as three vehicles that are first moving away from a traffic light, and a second quorum 604 as vehicles 511, 512, 513, 514, 515, 569, 570 that are driving below a proposed speed limit. Regardless of the participation of each vehicle 511, 512, 513, 514, 515, 560, 570 in a given quorum, the sensor data of each vehicle can be sent via the ad hoc network 102 to the database to update the consensus block as described herein.

[0053] Referring to FIG. 7, the drawing shows a flow chart of an example process 700 for monitoring a group of vehicles traveling in a common environment for traffic-related behavior, according to an exemplary embodiment. Process 700 begins at block 702, where a quorum of vehicles in the common environment exists in a given ad-hoc wireless network, such as network 102, as disclosed herein. Next, at decision block 704, the processor determines whether a quorum exists. A minimum number of vehicles must be present to form a quorum. Additionally, a given vehicle can be a member of more than one quorum at the same time. If the answer to the decision block is "No," the process returns and waits for additional vehicles. If the answer is "Yes," the process continues at block 706, where the vehicle sensors and external sensors send data to a database, such as database 109, to form a consensus block of aggregated data. Once the consensus block is formed, the consensus block is shared with each connected vehicle, allowing all vehicles to access the same data. The processor then analyzes the agreement block to determine whether abnormal driving behavior was detected in one of the vehicles in the quorum at decision block 708. If "No", the process 700 returns to form an additional quorum of vehicles at block 702. If "Yes", the processor generates a feedback action, either a positive or negative response, and sends the response back to the vehicle or another authority for further action or to the first responsible party.

[0054] Thus, computer-implemented methods, computer program products, and systems are provided in exemplary embodiments for consensual driving behavior monitoring in connected vehicle systems and other related features, functions, and operations. Where an embodiment, or a portion thereof, is described in terms of a type of device, the computer-implemented method, computer-implemented program product, or system, or a portion thereof, is adapted or configured for use with a suitable and compatible embodiment of that type of device.

[0055] When embodiments are described as being implemented in an application, it is contemplated that distribution of the application in a “Software as a Service” (SaaS) model is within the scope of the exemplary embodiments. In a SaaS model, an application implementing an embodiment is provided to a user by running the application in a cloud infrastructure. The user can access the application using a variety of client devices through a thin interface such as a web browser (e.g., web-based email) or a lightweight client application. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage of the cloud infrastructure. In some cases, the user may not even be able to manage or control the capabilities of the SaaS application. In some other cases, the SaaS implementation of the application may allow limited user-specific exceptions to application configuration settings.

[0056] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product includes a computer-readable recording medium (or media) having computer-readable program instructions thereon for causing a processor to perform features of the present disclosure.

[0057] A computer readable recording medium may be a tangible device capable of holding and storing a plurality of instructions for use by an instruction execution device. A computer readable medium may be, for example, but not limited to, an electrical recording device, a magnetic recording device, an optical recording device, an electro-magnetic recording device, a semiconductor recording device, or any suitable combination thereof. More specific examples of computer readable recording media include the following: a portable computer disk, 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 disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a punch card, or a mechanically encoded device having protruding structures within a groove having instructions recorded therein, and any suitable combination thereof. As used herein, a computer-readable recording medium is not to be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves such as wave guides or other communications media (e.g., light pulses passing through fiber optic cable), or electrical signals communicated through wires.

[0058] The computer program instructions described herein can be downloaded from a computer readable recording medium into each computing / processing device, or can be downloaded to an external computer or external recording device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, and combinations thereof. The network can include copper cables, fiber optics, wireless networks, routers, firewalls, switches, gateway computers, and edge servers, and combinations thereof. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions into a computer readable recording medium in each computing / processing device for storage.

[0059] The computer readable program instructions for carrying out the operations of the present invention may be either source code or artifact code written in any combination of programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or one or more conventional procedural programming languages, such as Smalltalk®, object oriented programming languages ​​such as C++, the “C” programming language, or similar programming languages. The computer readable program instructions may be executed entirely on the user computer, partially on the user computer as a stand-alone software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user computer through any type of network, including a local area network (LAN), a wide area network (WAN), or the connection may be to an external computer (e.g., through an Internet service provider). In some embodiments, computer readable program instructions may be executed by electrical circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), and state information of the computer readable program instructions may be used to personalize the electrical circuitry to perform features of the present invention.

[0060] Aspects of the invention described herein have been described with reference to flowchart instructions and / or block diagrams of methods, apparatus (systems), and computer-readable storage media and computer program products according to embodiments of the invention. It will be understood that any combination of flowchart illustrations and / or block diagrams and / or blocks in flowchart illustrations and / or block diagrams can be implemented by computer-readable program instructions.

[0061] The computer-readable program instructions can be provided to a general purpose computer, a special purpose computer, or other processor or other programmable data processing device to produce a machine, which when executed by the processor of the computer or other programmable data processing device produces means for implementing the functions / operations specified in the block or blocks of the flowcharts and block diagrams, or a combination thereof. These computer-readable program instructions that direct a computer, programmable data processing device, and other device, or a combination thereof, to function in a particular manner can also be stored on a computer-readable recording medium, and the computer-readable recording medium having instructions stored therein constitutes an article of manufacture including instructions that implement the functional / operational features specified in the block or blocks of the flowcharts and block diagrams, or a combination thereof.

[0062] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device and cause a computer implemented process to perform a series of operational steps on the computer, other programmable apparatus, or other device to implement the functions / acts specified in the blocks of the flowcharts and block diagrams or in a combination thereof.

[0063] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and possible implementations of the system, method, and computer program product for consensual driving behavior monitoring in connected vehicles according to various embodiments of the present invention. In this respect, the flowcharts or block diagrams may represent modules, segments, or portions of instructions, which include one or more executable instructions for implementing a particular logical function (or functions). In some alternative implementations, the functions described in the blocks may be performed other than as illustrated. For example, two blocks shown in succession may be performed in a practically single step, may be performed simultaneously, substantially simultaneously, partially or completely overlapped in time, or the blocks may be performed in reverse order, depending on the functions involved. It is also noted that the illustration of the blocks in the block diagrams and / or the illustration of the flowcharts or combinations thereof may be implemented by a system based on special purpose hardware that performs a particular function or operation or performs special purpose hardware and computer instructions.

Claims

1. 1. A computer-implemented method for vehicular traffic behavior monitoring and feedback, comprising: collecting vehicular sensor data from a set of vehicles operating in a traffic environment, each vehicle communicating the sensor data over a communications network to a processor; aggregating the sensor data to form a consensus block of aggregated data when the set of vehicles includes sufficient vehicles to form a quorum, the aggregated data including individual vehicle sensor data from each vehicle in the set of vehicles, and the processor discarding duplicate and repetitive data from the consensus block; detecting a vehicle motion pattern in the agreement block, the vehicle motion pattern deviating from a threshold by more than a tolerance; mapping the vehicle motion patterns to specific vehicles in the set of vehicles to identify vehicles that are greater than the tolerance; and generating a feedback response based on said mapping; The method includes:

2. moreover, The method of claim 1 , further comprising updating the agreement block with data from a non-vehicle sensor.

3. 3. The method of claim 1 or 2, wherein the agreement block is stored as immutable data in a blockchain database.

4. The method of any one of claims 1 to 3, wherein the feedback response comprises alerting a driver of the mapped vehicle.

5. The method of any one of claims 1 to 4, wherein the feedback response comprises alerting the first responsible person.

6. A method according to any preceding claim, wherein the feedback response comprises alerting drivers of other vehicles in the set of vehicles.

7. The method of any preceding claim, wherein the feedback response comprises commanding the mapped vehicle to perform an action.

8. moreover, Sending said consensus block to an external authority. The method according to any one of claims 1 to 7, comprising:

9. The method according to any one of the preceding claims, wherein at least one of the vehicles of the set of vehicles is automatically controlled.

10. The method of any one of claims 1 to 9, wherein the set of vehicles comprises at least one of the following: road vehicles, aircraft, ships, and trains.

11. moreover, transmitting, by the processor, the agreement block to all vehicles in the set of vehicles. The method according to any one of claims 1 to 10, comprising:

12. A computer program product for causing a computer to carry out the method according to any one of claims 1 to 11 for monitoring and feedback of vehicle traffic behaviour.

13. 1. A computer system comprising: A processor; a computer readable memory; a computer readable recording device; and program instructions stored on the storage device for execution by the processor via the memory, the program instructions comprising: program instructions for collecting vehicular sensor data from a set of vehicles operating in a traffic environment, each vehicle communicating the sensor data over a communications network to a processor; program instructions for aggregating the sensor data to form a consensus block of aggregated data if the set of vehicles includes sufficient vehicles to form a quorum, the aggregated data including individual vehicle sensor data from each vehicle in the set of vehicles, and the processor discarding duplicate and repetitive data from the consensus block; program instructions for detecting a vehicle motion pattern in the agreement block, the vehicle motion pattern deviating from a threshold by more than a tolerance; program instructions for mapping the vehicle motion patterns to particular vehicles in the set of vehicles to identify vehicles that are greater than the tolerance; and program instructions for generating a feedback response based on the mapping 1. A computer system comprising:

14. moreover, 14. The computer system of claim 13, further comprising program instructions for updating the agreement block with data from non-vehicle sensors.

15. 15. The computer system of claim 13 or 14, wherein the feedback response comprises commanding the mapped vehicle to perform an action.

Images