Managing improper behavior report amounts

Abstract

Various embodiments include methods and systems for managing an amount of improper behavior reports. In various embodiments, a vehicle processing system may: identify one or more improper behavior observations from a plurality of improper behavior observations made by the vehicle processing system based on one or more quantity management criteria for improper behavior report generation; generating an improper behavior report including information about the identified improper behavior observations; and sending the generated improper behavior report to the network computing device.

Description

[0001] Related applications

[0002] This application claims the benefit of priority to U.S. nonprovisional application No. 18 / 353,011, filed July 14, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Vehicle-to-everything (V2X) systems can be configured to detect incorrect or intentionally erroneous information in V2X messages received from other vehicles or from network elements of an Intelligent Transportation System (ITS). Such V2X systems can be configured to detect improper V2X behavior, generate reports of the detected misbehavior, and send these reports to the appropriate network elements. However, the generation of misbehavior reports incurs computational and storage costs in each V2X system. Furthermore, the transmission of misbehavior reports consumes the ITS's wireless communication and computational resources. The generation and transmission of unnecessary misbehavior reports degrades the efficiency and performance of V2X systems and network elements within the ITS. Summary of the Invention

[0004] The aspects include methods for managing the volume of misconduct reports, which can be performed by a vehicle handling system. These aspects may include: identifying one or more misconduct observations from multiple misconduct observations conducted by the vehicle handling system based on one or more volume management criteria for generating misconduct reports; generating a misconduct report including information about the identified misconduct observations; and sending the generated misconduct report to a network computing device.

[0005] In some aspects, the quantity management criteria may include a predefined time window. In some aspects, the quantity management criteria may include a predefined time window and one or more additional selection criteria. In some aspects, the quantity management criteria may include a predefined time window and a critical weight assigned to each observation of misconduct.

[0006] In some respects, identifying one or more misconduct observations from the plurality of misconduct observations made by the vehicle handling system based on one or more quantitative management standards for generating misconduct reports may be performed in response to determining that the number of misconduct observations made by the vehicle handling system has reached a threshold number of misconduct observations.

[0007] In some aspects, identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on the one or more quantity management criteria for inappropriate behavior report generation can include: responsive to determining that a number of inappropriate behavior observations made by the vehicle processing system within a predefined time window reaches a threshold number of inappropriate behavior observations, identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on the one or more quantity management criteria for inappropriate behavior report generation.

[0008] In some aspects, identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on the one or more quantity management criteria for inappropriate behavior report generation can include: responsive to determining that a number of inappropriate behavior observations made by the vehicle processing system within a predefined time window reaches a threshold number of inappropriate behavior observations, identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on the one or more quantity management criteria for inappropriate behavior report generation; and selecting inappropriate behavior observations from the number of inappropriate behavior observations made by the vehicle processing system within the predefined time window based on one or more additional selection criteria.

[0009] In some aspects: identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on the one or more quantity management criteria for inappropriate behavior report generation can include grouping two or more inappropriate behavior observations related to similar inappropriate behavior operations based on a similarity criterion; and generating the inappropriate behavior report including information about the identified inappropriate behavior observations can include generating one inappropriate behavior report for the similar inappropriate behavior operations.

[0010] In some aspects: identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on the one or more quantity management criteria for inappropriate behavior report generation can include grouping two or more inappropriate behavior observations related to the same inappropriate behavior vehicle; and generating the inappropriate behavior report including information about the identified inappropriate behavior observations can include generating one inappropriate behavior report for the two or more inappropriate behavior observations related to the same inappropriate behavior vehicle.

[0011] Some aspects can further include selecting the one or more quantity management criteria for inappropriate behavior report generation based on one or more of an amount of available memory storage, a processor heat threshold, an amount of available processor cycles or computing resources, or an amount of available hardware security module (HSM) cycles or computing resources.

[0012] Further aspects include a vehicle processing system that includes a memory and a processor configured to perform the operations of any of the methods outlined above. Further aspects can include a vehicle processing system having various means for performing the functions corresponding to any of the methods outlined above. Further aspects can include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a vehicle processing system to perform various operations corresponding to any of the methods outlined above. BRIEF DESCRIPTION OF DRAWINGS

[0013] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate exemplary embodiments of the claims and, together with the general description and detailed description given below, serve to explain features of the present disclosure.

[0014] Figure 1A is a system block diagram illustrating an example communication system suitable for implementing various embodiments.

[0015] Figure 1B is a system block diagram illustrating an example disaggregated base station architecture suitable for implementing various embodiments.

[0016] Figure 1C is a system block diagram illustrating a communication system suitable for implementing various embodiments.

[0017] Figure 2 is a component diagram of an example vehicle processing system suitable for implementing various embodiments.

[0018] Figure 3 is a block diagram illustrating example components of a system on chip (SOC) for use in a vehicle processing system, in accordance with various embodiments.

[0019] Figure 4 is a component block diagram illustrating elements of a vehicle processing system configured in accordance with various embodiments.

[0020] Figure 5A is a process flow diagram of an example method for managing misbehavior report volume performed by a processor of a vehicle processing system, in accordance with various embodiments.

[0021] Figures 5B to 5H is a process flow diagram of example operations that can be performed by a processor of a computing device as part of a method for managing misbehavior report volume, in accordance with various embodiments. DETAILED DESCRIPTION

[0022] Various embodiments will be described in detail with reference to the drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

[0023] Various embodiments include methods for managing the volume of misbehavior reports sent by vehicles and vehicle processing systems implementing the methods. In various embodiments, a vehicle processing system can identify one or more misbehavior observations from a plurality of misbehavior observations made by the vehicle processing system based on one or more volume management criteria for misbehavior report generation. The vehicle processing system can generate a misbehavior report including information about the identified misbehavior observations. The vehicle processing system can send the generated misbehavior report to a network computing device.

[0024] As used herein, the term “vehicle” generally refers to any one of a car, a motorcycle, a truck, a bus, a train, a boat, and any other type of vehicle V2X-capable system that can be configured to manage the sending of misbehavior reports.

[0025] The term “system on a chip” (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and / or processors integrated on a single substrate. A single SOC can contain circuits for digital, analog, mixed-signal, and radio-frequency functions. A single SOC can also include any number of general-purpose and / or specialized processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). An SOC can also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0026] The term “system in a package” (SIP) can be used herein to refer to a single module or package that contains multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP can include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP can include one or more multi-chip modules on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP can also include multiple independent SOCs that are coupled together via high-speed communication circuitry and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high-speed communication as well as sharing of memory and resources.

[0027] A vehicle processing system can be configured to detect incorrect or intentionally false information in V2X messages received from another vehicle or from intelligent transportation system (ITS) infrastructure equipment, such as roadside units (RSUs), overhead units, and other suitable computing devices. Such inaccurate or intentionally false information in V2X messages can be referred to as “V2X misbehavior.” Detection of V2X misbehavior by a vehicle processing system can be referred to as a “misbehavior observation.” The vehicle processing system can be configured to generate and send, to a misbehavior authority (“MA”) network computing device, a report of such detected incorrect or intentionally false information, such as a misbehavior report, based on one or more misbehavior observations.

[0028] However, the vehicle processing system can result in computational and storage costs for generating misbehavior reports. A general misbehavior report can include an identifier of a misbehavior type and one or more V2X messages received by the vehicle processing system that are flagged as suspicious V2X misbehavior or evidence of V2X misbehavior. The misbehavior report can also include additional V2X messages, third party information such as map information related to a location of the suspected or detected V2X misbehavior, additional information from the reporting vehicle processing system (e.g., vehicle sensor data), and cryptographic or security information such as a digital signature. Furthermore, sending of misbehavior reports can consume wireless communication resources and computing resources of the ITS. Generation and sending of unnecessary misbehavior reports can reduce the efficiency and performance of the reporting vehicle processing system and network elements in the ITS.

[0029] Various embodiments overcome such limitations by enabling a vehicle processing system to manage the quantity of misbehavior reports, thereby managing the sending of misbehavior reports. Various embodiments include methods for managing the quantity of misbehavior reports and vehicle processing systems implementing the methods. In various embodiments, a vehicle processing system can identify one or more misbehavior observations from a plurality of misbehavior observations made by the vehicle processing system based on one or more quantity management criteria for misbehavior report generation. The vehicle processing system can generate a misbehavior report including information about the identified misbehavior observations. The vehicle processing system can send the generated misbehavior report to a network computing device.

[0030] In various embodiments, the quantity management criteria can include one or more elements or aspects of a misbehavior report generation policy. In some embodiments, the vehicle processing system can select a misbehavior report generation policy to apply to the selection of misbehavior observations. In some embodiments, the vehicle processing system can receive a message or instruction from a network computing device, such as a misbehavior authority, specifying a misbehavior report generation policy for the vehicle processing system to use.

[0031] In some embodiments, the quantity management criteria can include a predefined time window. In some embodiments, the vehicle processing system can identify one or more observations of misbehavior by the vehicle processing system that were made within the predefined time window from a plurality of observations of misbehavior that were made outside of the predefined time window.

[0032] In some embodiments, the quantity management criteria can include a predefined time window and one or more additional selection criteria. In such embodiments, the vehicle processing system can select one or more observations of misbehavior from observations of misbehavior that were made within the predefined time window. Such additional selection criteria can include first-in, first-out (FIFO) and / or last-in, first-out (LIFO). In some embodiments, the vehicle processing system can randomly select one or more observations of misbehavior from observations of misbehavior that were made within the predefined time window.

[0033] In some embodiments, the vehicle processing system can select one or more observations of misbehavior based on available memory storage of the vehicle processing system, such that the selected observations of misbehavior do not exceed the available memory storage. In some embodiments, the vehicle processing system can select one or more observations of misbehavior based on a thermal threshold of the vehicle processing system (e.g., a thermal threshold of a processor, a thermal threshold of a system-on-a-chip, or another suitable thermal threshold). In some embodiments, the vehicle processing system can select one or more observations of misbehavior based on available or unused processor (e.g., CPU) cycles or other computing resources. In some embodiments, the vehicle processing system can select one or more observations of misbehavior based on available or unused hardware security module (HSM) cycles or other computing resources. For example, as the number of selected observations of misbehavior increases, the computational and storage burden associated with each observation of misbehavior and the resulting waste heat can all increase, as a result of, for example, processing and storing each observation of misbehavior, identifying and storing relevant evidence of each observed misbehavior (such as information from received V2X messages and / or vehicle sensor data), encrypting some or all of such information, generating digital signatures, and other suitable operations performed by the vehicle processing system.

[0034] In some embodiments, the quantity management criteria can include a pre-defined time window and a criticality weight assigned by the vehicle processing system to each misbehavior observation. In some embodiments, the vehicle processing system can identify the criticality weight for each misbehavior observation based on a data structure such as a lookup table that associates information about misbehavior observations with criticality weights. In some embodiments, the vehicle processing system can identify the criticality weight for each misbehavior observation by applying information about each misbehavior observation to a trained machine learning (ML) model and receiving the criticality weight for each misbehavior observation as output from the trained model.

[0035] In some embodiments, the vehicle processing system can identify a misbehavior observation from the plurality of misbehavior observations made by the vehicle processing system in response to determining that the number of misbehavior observations made by the vehicle processing system reaches a threshold number of misbehavior observations. In some embodiments, the vehicle processing system can identify a misbehavior observation from the plurality of misbehavior observations made by the vehicle processing system based on one or more quantity management criteria for misbehavior report generation in response to determining that the number of misbehavior observations made by the vehicle processing system within a pre-defined time window reaches a threshold number of misbehavior observations.

[0036] In such embodiments, the vehicle processing system can select a misbehavior observation from the number of misbehavior observations made by the vehicle processing system within the pre-defined time window based on one or more additional selection criteria. In some embodiments, such additional selection criteria can include FIFO, LIFO, available memory storage, a hot threshold, available central processing unit (CPU) cycles or computing resources, available HSM cycles or computing resources, and / or other suitable additional selection criteria.

[0037] In some embodiments, the vehicle processing system can group two or more misbehavior observations related to similar misbehavior operations based on a similarity criterion. In such embodiments, the vehicle processing system can generate one misbehavior report for similar misbehavior operations. In some embodiments, the vehicle processing system can generate a misbehavior report that includes information related to or describing two or more similar misbehavior observations, related V2X messages received by the vehicle processing system, and other suitable information.

[0038] In some embodiments, the vehicle processing system can group two or more misbehavior observations related to the same misbehaving vehicle. In such embodiments, the vehicle processing system can generate one misbehavior report for the two or more misbehavior observations related to the same misbehaving vehicle. In some embodiments, the vehicle processing system can generate a misbehavior report that includes additional information configured to enable identification of the misbehaving vehicle, such as sensor data, images or video of the misbehaving vehicle, V2X messages sent by the misbehaving vehicle, and other suitable information.

[0039] In some embodiments, the vehicle processing system can dynamically select one or more quantity management criteria. For example, the vehicle processing system can dynamically select one or more quantity management criteria based on available memory storage, thermal thresholds, available CPU cycles or computing resources, available HSM cycles or computing resources, and / or other suitable additional factors. In some embodiments, the vehicle processing system can receive a message or instruction from a network computing device (e.g., a MA, RSU, network operator, or another suitable trusted third party) indicating one or more quantity management criteria for the vehicle processing system to use.

[0040] Various embodiments improve the efficiency and performance of vehicle processing systems and communication systems by enabling vehicle processing systems to manage the quantity of misbehavior reports that the vehicle processing systems generate and send in a communication network. By enabling vehicle processing systems to reduce redundant or similar misbehavior reports, various embodiments improve the efficiency and performance of communication systems in which such vehicle processing systems operate by reducing unnecessary consumption of vehicle computing and communication resources, wireless network communication resources, and network processing resources.

[0041] Figure 1A is a system block diagram illustrating an example communication system 100 suitable for implementing various embodiments. The communication system 100 includes a 5G New Radio (NR) network, an Intelligent Transportation System (ITS) V2X wireless network, and / or any other suitable network, such as a Long Term Evolution (LTE) network. References in the following description to 5G networks and 5G network elements are for illustrative purposes and are not intended to be limiting.

[0042] The communication system 100 can include a heterogeneous network architecture that includes a core network 140, a number of base stations 110, and various mobile devices including a vehicle 102 equipped with a vehicle processing system 104 (e.g., a V2X processing system or on-board unit) that includes wireless communication capabilities. The base stations 110 can communicate with the core network 140 over wired communication links 126. The communication system 100 can also include roadside units 112 that support V2X communications with the vehicle 102 via V2X wireless communication links 124.

[0043] The base stations 110 are network elements of a wireless communication system that communicate with wireless devices (e.g., the V2X processing system 104 of the vehicle 102) via wireless communication links 122 and can be referred to as NodeBs, LTE evolved NodeBs (eNodeBs or eNBs), access points (APs), radio heads, transmission reception points (TRPs), New Radio Base Stations (NR BS), 5G NodeBs (NBs), Next Generation NodeBs (gNodeBs or gNBs), etc. Each base station 110 can provide communication coverage for a particular geographic area, or “cell,” A cell can be spatially related to a base station and / or base station subsystem that serves the cell, or a combination thereof, depending on the context in which the term is used. The core network 140 can be any type of core network such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, a reference Figure 1B The described disaggregated network, etc.

[0044] The roadside units 112 can communicate with the core network 140 via wired or wireless communication links 128. The roadside units 112 can communicate with vehicles 102 equipped with vehicle processing systems via V2X wireless communication links 124 for downloading information useful to the autonomous and semi-autonomous driving functions of the vehicle processing systems, as well as for receiving information from the vehicle processing systems 104, such as misbehavior reports.

[0045] A misbehavior authority network computing device (MA) 132 can communicate with the core network 140 via wired or wireless communication links 127. The MA 132 can receive misbehavior reports from the vehicle processing systems 104 that can be sent from time to time by the vehicle processing systems 104.

[0046] Wireless communication links 122 can include multiple carrier signals, frequencies, or frequency bands, each of which can include multiple logical channels. Wireless communication links 122 and 124 can utilize one or more radio access technologies (RATs). Examples of RATs that can be used in wireless communication links include 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile telephone communication technologies cellular RATs. Other examples of RATs that can be used in one or more of the various wireless communication links within communication system 100 include medium range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

[0047] Figure 1B FIG. 1 is a system diagram illustrating an example disaggregated base station 160 architecture, in accordance with any of the various embodiments, which can be part of a V2X and / or 5G network (e.g., communication system 100). Referring to Figure 1A and Figure 1B , the disaggregated base station 160 architecture can include one or more central units (CU) 162, which can communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more disaggregated base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-RT RIC 168 associated with a service management and orchestration (SMO) framework 166, or both. The CU 162 can communicate with one or more distributed units (DU) 170 via respective fronthaul links, such as an Fl interface. The DU 170 can communicate with one or more radio units (RU) 172 via respective front-haul links. The RU 172 can communicate with respective UEs 120 via one or more radio frequency (RF) access links. In some implementations, a user equipment (UE) such as V2X processing system 104 can be served by multiple RUs 172 simultaneously.

[0048] Each of the units (i.e., CU 162, DU 170, RU 172), as well as the near-RT RIC 164, non-RT RIC 168, and SMO framework 166, can include one or more interfaces, or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller providing instructions to the communication interfaces of these units, can be configured to communicate with one or more of the other units via the transmission medium. For example, the units can include a wired interface configured to receive or transmit signals to one or more of the other units over a wired transmission medium. Additionally, the units can include a wireless interface, which can include a receiver, a transmitter, or a transceiver (such as a radio frequency (RF) transceiver), configured to receive or transmit signals to one or more of the other units over a wireless transmission medium, or both.

[0049] In some aspects, the CU 162 can host one or more higher layer control functions. Such control functions can include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function can utilize an interface configured to communicate signals with other control functions hosted by the CU 162. The CU 162 can be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some implementations, the CU 162 can be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bi-directionally with the CU-CP units via an interface, such as an El interface. The CU 162 can be implemented in communication with the DU 170, as needed, for network control and signaling.

[0050] The DU 170 can correspond to a logical unit that includes one or more base station functions for controlling operation of one or more RUs 172. In some aspects, the DU 170 can host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) in accordance with, at least in part, a functional split, such as those defined by the 3rd Generation Partnership Project (3GPP). In some aspects, the DU 170 can further host one or more low PHY layers. Each layer (or module) can be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 170 or with control functions hosted by the CU 162.

[0051] Lower layer functionality can be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DU 170 can correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, or physical random access channel (PRACH) extraction and filtering, etc.) or both based, at least in part, on a functional split, such as a lower layer functional split. In such an architecture, the RUs 172 can be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some implementations, real-time and non-real-time aspects of control plane and user plane communications with the RUs 172 can be controlled by the corresponding DU 170. In some scenarios, this configuration can enable the DUs 170 and the CU 162 to be implemented in a cloud-based radio access network (RAN) architecture, such as a vRAN architecture.

[0052] The SMO framework 166 can be configured to support RAN deployment and orchestration of non-virtualized network elements and virtualized network elements. For non- virtualized network elements, the SMO framework 166 can be configured to support deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operations and maintenance interface, such as an Ol interface. For virtualized network elements, the SMO framework 166 can be configured to interact with a cloud computing platform, such as Open Cloud (O-Cloud) 176, to perform network element lifecycle management, such as to instantiate virtualized network elements, via a cloud computing platform interface, such as an 02 interface. Such virtualized network elements can include, but are not limited to, CUs 162, DUs 170, RUs 172, and near-RT RICs 164. In some implementations, the SMO framework 166 can communicate with hardware aspects of a 4G RAN, such as Open eNBs (O-eNBs) 174, via the Ol interface. Additionally, in some implementations, the SMO framework 166 can communicate directly with one or more RUs 172 via the Ol interface. The SMO framework 166 can also include a non-RT RIC 168 configured to support functionality of the SMO framework 166.

[0053] The non-RT RIC 168 can be configured to include logical functions that enable near real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and update, or policy-based direction of applications / features in the near-RT RIC 164. The non-RT RIC 168 can be coupled to, or in communication with, the near-RT RIC 164, such as via an Al interface. The near-RT RIC 164 can be configured to include logical functions that enable near real-time control and optimization of RAN elements and resources via data collection and actions through an interface, such as via an E2 interface, that connects one or more CUs 162, one or more DUs 170, or both, and an O-eNB with the near-RT RIC 164.

[0054] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 164, the non-RT RIC 168 can receive parameters or external enrichment information from an external server. Such information can be utilized by the near-RT RIC 164 and can be received at the SMO framework 166 or the non-RT RIC 168 from non-network data sources or from network functions. In some examples, the non-RT RIC 168 or the near-RT RIC 164 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 can monitor long-term trends and patterns of performance and employ AI / ML models to perform corrective actions through the SMO framework 166, such as via reconfiguration of Ol, or via creation of RAN management policies, such as Al policies.

[0055] Figure 1C is a system block diagram illustrating a communication system 103 suitable for implementing various embodiments. Referring to Figures 1A to 1C , the communication system 103 can include three vehicles 12, 14, 16. Each vehicle 12, 14, 16 can include a vehicle processing system 104, 106, 108, respectively, each configured to periodically broadcast V2X messages 30, 40, 50, such as BSMs, CAMs, MCMs, MAPs, SRMs, and other types of V2X messages for reception and processing by V2X processing systems (e.g., 104, 106, 108) of other vehicles.

[0056] By sharing vehicle location, speed, direction, braking, and other information, vehicles can maintain a safe separation and identify and avoid potential collisions. For example, a following vehicle 12 receiving V2X messages 40 from a leading vehicle 16 can determine the speed and location of the vehicle 16, which in turn enables the vehicle 12 to match speed and maintain a safe separation distance 20.

[0057] By being notified through V2X messages 40 when a leading vehicle 16 applies brakes, a vehicle processing system 104 in a following vehicle 12 can simultaneously apply brakes to maintain a safe separation distance 20, even when the leading vehicle 16 stops suddenly. As another example, a vehicle processing system 106 within a truck vehicle 14 can receive V2X messages 30, 50 from two vehicles 12, 16 and thus be informed that the truck vehicle 14 should stop at an intersection to avoid a collision.

[0058] Each of the vehicle processing systems 104, 106, 108 can communicate with each other using any of a variety of proximity communication protocols. In addition, the vehicles are able to send data and information about detected V2X messages and misbehavior reports about detected V2X misbehavior via the communication links 60, 61, 62 over the communication network 18 to original equipment manufacturers (OEMs) (70, 72) and / or the MA 74 (e.g., 132). The misbehavior reports can be sent to the MA 74, for example, via the communication links 64, 66.

[0059] In some embodiments, the misbehavior reports can be sent first to a misbehavior report pre-processing unit, such as the OEM servers 70, 72, for pre-processing over the communication links 64, 66. The pre-processed misbehavior reports can then be sent from the misbehavior report pre-processing unit 70, 72 to the MA 74 over the communication links 64, 66.

[0060] In some embodiments, the misbehavior reports can be received at the MA 74 from vehicles, such as from the vehicle 16. The MA 74 relays the received misbehavior reports from the vehicle 16 to the OEM servers 70, 72 via the communication links 64, 66. In addition, the OEM servers 70, 72 can provide confirmation reports to the MA 74 via the communication links 64, 66.

[0061] Figure 2 is a component diagram of an example vehicle processing system 200 suitable for implementing various embodiments. Referring to Figures 1A to 2 , the processing system 200 can include a vehicle 102 that includes a vehicle processing system 104. The vehicle processing system 104 can communicate with various systems and devices, such as an in-vehicle network 210, an infotainment system 212, various sensors 214, various actuators 216, and a radio module 218 coupled to an antenna 219. The vehicle processing system 104 can also communicate with a road-side unit 112, a cellular communication network base station 110, and other external devices.

[0062] The vehicle processing system 104 can include a processor 205, a memory 206, an input module 207, an output module 208, and a radio module 218. The processor 205 can be coupled to the memory 206 (i.e., a non-transitory storage medium) and can be configured with processor-executable instructions stored in the memory 206 to perform the operations of the methods according to the various embodiments described herein. In addition, the processor 205 can be coupled to the output module 208 (which can control an in-vehicle display) and to the input module 207 to receive information from vehicle sensors as well as driver inputs.

[0063] The vehicle processing system 104 can include a V2X antenna 219 coupled to a radio module 218 that is configured to communicate with one or more ITS participants (e.g., stations), roadside units 112, and base stations 110 or another suitable network access point. The V2X antenna 219 and radio module 218 can be configured to receive dynamic traffic flow feature information via vehicle-to- everything (V2X) communications. In various embodiments, the vehicle processing system 104 can receive information from a plurality of information sources, such as the in-vehicle network 210, the infotainment system 212, various sensors 214, various actuators 216, and the radio module 218. The vehicle processing system 104 is configured to use map data in addition to sensor data to perform automated or semi-automated driving functions.

[0064] Examples of in-vehicle networks 210 include controller area networks (CAN), local interconnect networks (LIN), networks using the FlexRay protocol, media oriented systems transport (MOST) networks, and automotive Ethernet networks. Examples of vehicle sensors 214 include position determination systems such as global navigation satellite system (GNSS) systems, cameras, radar, lidar, ultrasonic sensors, infrared sensors, and other suitable sensor devices and systems. Examples of vehicle actuators 216 include various physical control systems such as for steering, brakes, engine operation, lights, turn signals, and the like.

[0065] Figure 3 is a block diagram illustrating example components of a system on chip (SOC) 300 for use in a vehicle processing system, in accordance with various embodiments. Referring to Figures 1A to 3 The processing device SOC 300 can include a number of heterogeneous processors, such as a digital signal processor (DSP) 303, a modem processor 304, an image and object recognition processor 306, a mobile display processor 307, an application processor 308, and a resource and power management (RPM) processor 317. The processing device SOC 300 can also include one or more co-processors 310 (e.g., vector co-processor) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, 317. The processing device SOC 300 can also include a hardware security module (HSM) 311 configured to perform one or more security operations for V2X communications.

[0066] Each of these processors can include one or more cores and an independent / internal clock. Each processor / core can operate independently of the other processors / cores. For example, the processing device SOC 300 can include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows). In some embodiments, the application processor 308 can be a main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. of the SOC 300. The graphics processor 306 can be a graphics processing unit (GPU).

[0067] The processing device SOC 300 can include analog and custom circuitry 314 for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations such as processing encoded audio and video signals for rendering in a web browser. The processing device SOC 300 can also include system components and resources 316 such as voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting the processors and software clients (e.g., web browsers) running on the computing device.

[0068] The processing device SOC 300 can also include a custom circuit for camera actuation and management (CAM) 305 that includes, provides, controls, and / or manages the operation of one or more cameras (e.g., a main camera, a web camera, a 3D camera, etc.), video display data from camera firmware, image processing, video pre-processing, a video front end (VFE), an embedded JPEG, a high-definition video codec, etc. The CAM 305 can be a separate processing unit and / or include a separate or internal clock.

[0069] In some embodiments, the image and object recognition processor 306 can be configured with processor-executable instructions and / or specialized hardware configured to perform image processing and object recognition analysis involved in various embodiments. For example, the image and object recognition processor 306 can be configured to perform operations to process images received from cameras via the CAM 305 to recognize and / or identify other vehicles, as well as otherwise perform the functions of the camera perception layer 224 as described. In some embodiments, the processor 306 can be configured to process radar or lidar data and perform the functions of the radar and / or lidar perception layer 222 as described.

[0070] The system components and resources 316, analog and custom circuitry 314, and / or CAM 305 can include circuitry to interface with peripherals such as cameras, radar, lidar, electronic displays, wireless communication devices, external memory chips, etc. The processors 303, 304, 306, 307, 308 can be interconnected with one or more memory elements 312, system components and resources 316, analog and custom circuitry 314, CAM 305, RPM processor 317, and HSM 311 via interconnect / bus module 324, which can include reconfigurable logic gate arrays and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications can be provided by an advanced interconnect such as a high-performance network on chip (NoC).

[0071] The processing device SOC 300 can further include an input / output module (not illustrated) for communicating with resources external to the SOC, such as a clock 318 and voltage regulator 320. Resources external to the SOC (e.g., clock 318, voltage regulator 320) can be shared by two or more internal SOC processors / cores (e.g., DSP 303, modem processor 304, graphics processor 306, application processor 308, etc.).

[0072] In some embodiments, the processing device SOC 300 can be included in a control unit (e.g., 140) for use in a vehicle (e.g., 100). The control unit can include a communication link for communicating with a telephone network (e.g., 180), the Internet, and / or a network server (e.g., 184), as described.

[0073] The processing device SOC 300 can also include additional hardware and / or software components suitable for collecting sensor data from sensors including motion sensors (e.g., accelerometers and gyroscopes of an IMU), user interface elements (e.g., input buttons, touch screen displays, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., position, direction, motion, orientation, vibration, pressure, etc.), cameras, compasses, GNSS receivers, communication circuitry (e.g., Bluetooth ® , WLAN, WiFi, etc.), and other well-known components of modern electronic devices.

[0074] Figure 4 is a component block diagram illustrating elements of a vehicle processing system 104 configured in accordance with various embodiments. Referring to Figures 1A to 4 , a vehicle processing system 104 of a vehicle (e.g., 102) can be configured to communicate with a road side unit 112, a cellular network base station 110, and / or one or more other vehicles 12, 14, 16.

[0075] The vehicle processing system 104 can include one or more processors 205, a memory 206, a radio 218, and other components. The vehicle processing system 104 can include a plurality of hardware, software, and / or firmware components that operate together to provide functionality attributed herein to the processor 205.

[0076] The memory 206 can include a non-transitory storage medium that electronically stores information. The electronic storage medium of the memory 206 can include one or both of system storage that is provided integrally (i.e., substantially non-removable) with the vehicle processing system 104, and / or removable storage that can be removably connected to the vehicle processing system 104 via, for example, a port (such as a universal serial bus (USB) port, a firewire port, etc.) or a drive (such as a disk drive, etc.). In various embodiments, the memory 206 can include one or more of charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., a flash drive, etc.), optically readable storage media (e.g., an optical disc, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy disk drive, etc.), and / or other electronically readable storage media.

[0077] The memory 206 can include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). The memory 206 can store software algorithms, information determined by the processor 205, information received from one or more other vehicles 12, 14, 16, information received from a roadside unit 112, information received from a base station 110, and / or other information that enables the vehicle processing system 104 to function as described herein.

[0078] The processor 205 can include one of a plurality of local processors that can be configured to provide information processing capabilities in the vehicle processing system 104. As such, the processor 205 can include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor 205 is shown in Figure 3 The processor 205 is shown as a single entity in FIG. B for illustrative purposes. In some embodiments, the processor 205 can include multiple processing units. These processing units can be physically located within the same device, or the processor 205 can represent processing functionality of a plurality of devices operating in coordination. The processor 205 can be configured to process information for the vehicle processing system 104.

[0079] The vehicle processing system 104 can be configured by machine-readable instructions 432, which can include one or more instruction modules. The instruction modules can include computer program modules. In various embodiments, the instruction modules can include at least one or more of an inappropriate behavior observation module 434, a quantity management module 436, an inappropriate behavior report module 438, and a transmit / receive (TX / RX) module 440.

[0080] The inappropriate behavior observation module 434 can be configured to identify one or more inappropriate behavior observations from a plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation.

[0081] The quantity management module 436 can be configured to provide or apply one or more quantity management criteria for identifying one or more inappropriate behavior observations. The quantity management module 436 can be configured to select one or more quantity management criteria for inappropriate behavior report generation based on one or more selection criteria, which can include available memory storage quantity, processor heat threshold, available processor cycles or computing resources, or available hardware security module (HSM) cycles or computing resources.

[0082] The inappropriate behavior report module 438 can be configured to generate an inappropriate behavior report including information about the identified inappropriate behavior observation.

[0083] The TX / RX module 440 can be configured to transmit the generated inappropriate behavior report to a network computing device. The TX / RX module 440 can be configured to control and / or handle other aspects of wireless communication by the vehicle processing system 104, such as receiving one or more V2X messages from one or more other vehicles 12, 14, 16, road-side units 112, and / or base stations 110. The TX / RX module 440 can be configured to control operation of a communication device of the vehicle processing system, such as the radio module 218.

[0084] The processor 205 can be configured to execute the modules 432-344 and / or other modules by software, hardware, firmware, some combination of software, hardware, and / or firmware, and / or other mechanisms for configuring processing capabilities on the processor 205.

[0085] The description of functionality provided by the different modules 434-440 is for illustrative purposes, and is not intended to be limiting, as any of modules 434-440 can provide more or less functionality than described. For example, one or more of modules 434-440 can be eliminated, and some or all of its functionality can be provided by other modules in modules 434-440. As another example, processor 205 can be configured to execute one or more additional modules that can perform some or all of the functionality attributed below to one of modules 434-440.

[0086] Figure 5A is a process flow diagram of an example method 500a for managing a quantity of misbehavior reports sent by a vehicle, performed by a processor of a vehicle processing system, in accordance with various embodiments. Referring to Figures 1A to 5A , method 500a can be performed by one or more processors (e.g., 205, 300) of a vehicle processing system, which can be implemented in hardware elements, software elements, or a combination of hardware and software elements. Means for performing operations of method 500a include a vehicle processing system (e.g., 104), which can include one or more processors (e.g., 205, 300) that implement or control one or more modules (e.g., 434-440). To encompass any of the processors, hardware elements, and software elements that can perform operations of method 500a, the element or subsystem that performs method operations is generally referred to as a “processor.”

[0087] In block 502, the processor can identify one or more misbehavior observations from a plurality of misbehavior observations made by the vehicle processing system based on one or more quantity management criteria for misbehavior report generation. In some embodiments, the quantity management criteria can include a predefined time window. In some embodiments, the quantity management criteria can include a predefined time window and one or more additional selection criteria. In some embodiments, the quantity management criteria can include a predefined time window and a criticality weight assigned to each misbehavior observation. In some embodiments, the processor can identify a misbehavior observation from a plurality of misbehavior observations made by the vehicle processing system based on one or more quantity management criteria for misbehavior report generation in response to determining that a quantity of misbehavior observations made by the vehicle processing system reaches a threshold quantity of misbehavior observations.

[0088] In block 504, the processor can generate a misbehavior report including information about the identified misbehavior observation.

[0089] In block 506, the processor can send the generated misbehavior report to a network computing device.

[0090] Figures 5B to 5H is a process flow diagram of example operations 500b-500h that can be performed by a processor of a computing device as part of a method 500a for managing the volume of misbehavior reports, in accordance with various embodiments. Reference is made to Figures 1A to 5H , the operations 500b-500h can be performed by one or more processors (e.g., 205, 300) of a vehicle processing system, which can be implemented in hardware elements, software elements, or a combination of hardware and software elements. Means for performing operations 500b-500h include a vehicle processing system (e.g., 104), which can include one or more processors (e.g., 205, 300) that implement or control one or more modules (e.g., 434-440). To cover any of the processors, hardware elements, and software elements that can perform operations 500b-500h, the elements or subsystems that perform such operations are generally referred to as “processors.”

[0091] Reference is made to Figure 5B In block 510, the processor can identify one or more misbehavior observations from the plurality of misbehavior observations made by the vehicle processing system within the predefined time window. In some embodiments, the processor can identify one or more misbehavior observations from the plurality of misbehavior observations made by the vehicle processing system within the predefined time window and based on one or more additional criteria. In some embodiments, the processor can identify one or more misbehavior observations from the plurality of misbehavior observations made by the vehicle processing system within the predefined time window and based on a criticality weight assigned to each misbehavior observation. In some embodiments, the processor can apply one or more additional criteria and a criticality weight assigned to each misbehavior observation.

[0092] As described, the processor can generate a misbehavior report that includes information about the identified misbehavior observation in block 504 of the method 500a.

[0093] Reference is made to Figure 5C In block 520, the processor can identify misbehavior observations from the plurality of misbehavior observations made by the vehicle processing system based on one or more volume management criteria for misbehavior report generation in response to determining that the number of misbehavior observations made by the vehicle processing system reaches the threshold number of misbehavior observations.

[0094] As described, the processor can generate a misbehavior report that includes information about the identified misbehavior observation in block 504 of the method 500a.

[0095] Reference is made to Figure 5DIn block 540, the processor can identify, from the plurality of observations of misconduct conducted by the vehicle processing system, observations of misconduct based on one or more quantity management criteria for generation of a report of misconduct in response to determining that the number of observations of misconduct conducted by the vehicle processing system within the predefined time window reaches the threshold number of observations of misconduct.

[0096] As described, the processor can generate a report of misconduct including information about the identified observation of misconduct in block 504 of method 500a.

[0097] Referring to Figure 5E In block 540, the processor can identify, from the plurality of observations of misconduct conducted by the vehicle processing system, observations of misconduct based on one or more quantity management criteria for generation of a report of misconduct in response to determining that the number of observations of misconduct conducted by the vehicle processing system within the predefined time window reaches the threshold number of observations of misconduct.

[0098] In block 542, the processor can select, from the number of observations of misconduct conducted by the vehicle processing system within the predefined time window, observations of misconduct based on one or more additional selection criteria.

[0099] As described, the processor can generate a report of misconduct including information about the identified (and selected) observation of misconduct in block 504 of method 500a.

[0100] Referring to Figure 5F In block 550, the processor can group two or more observations of misconduct related to similar misconduct operations based on a similarity criterion (or two other similarity criteria). For example, the processor can assign one or more values to each observation of misconduct based on one (or more) characteristics of the observation of misconduct. In some embodiments, the processor can characterize an observation of misconduct according to one or more of a type of misconduct, a location of the misconduct, a type of vehicle associated with the observed misconduct, an identifier of the vehicle associated with the observed misconduct, and / or another suitable characteristic. In some embodiments, the processor can determine that one or more values based on one or more characteristics of the observed misconduct are within a similarity threshold.

[0101] In block 552, the processor can generate one report of misconduct for similar misconduct operations.

[0102] As described, in block 506 of method 500a, the processor can transmit the generated report of misconduct to a network computing device.

[0103] Referring to Figure 5GIn block 560, the processor can group two or more misbehavior observations related to the same misbehaving vehicle. In some embodiments, the processor can identify misbehaving vehicles according to an identifier of the vehicle, a type of the vehicle, a location of the vehicle, and / or another suitable factor or information.

[0104] In block 562, the processor can generate one misbehavior report for the two or more misbehavior observations related to the same misbehaving vehicle.

[0105] As described, in block 506 of method 500a, the processor can send the generated misbehavior report to a network computing device.

[0106] Reference is made to Figure 5H In block 570, the processor can select one or more quantity management criteria for misbehavior report generation based on one or more of an amount of available memory storage, a processor heat threshold, an amount of available processor cycles or computing resources, or an amount of available hardware security module (HSM) cycles or computing resources.

[0107] The processor can identify one or more misbehavior observations from a plurality of misbehavior observations made by a vehicle processing system based on one or more quantity management criteria for misbehavior report generation in block 502 of method 500a as described.

[0108] The various embodiments illustrated and described are provided as examples only. The features shown and described with respect to any given embodiment need not be limited to the associated embodiment and can be used or combined with other embodiments shown and described. Moreover, the claims are not intended to be limited to any one example embodiment. For example, one or more of the operations in methods and operations 500a-500h can replace or be combined with one or more of the operations of methods or operations 500a-500h.

[0109] The following paragraphs describe specific implementation examples. While some of the following implementation examples are described in the form of example methods, further example implementations can include: example methods discussed in the following paragraphs implemented by a computing device including a processor configured with processor-executable instructions to perform operations of the methods of the following implementation examples; example methods discussed in the following paragraphs implemented by a computing device including components to perform functions of the methods of the following specific implementation examples; and example methods discussed in the following paragraphs can be implemented as non-transitory processor-readable storage media having stored thereon processor-executable instructions configured to cause a processor of a computing device to perform operations of the methods of the following specific implementation examples.

[0110] Example 1. A method performed by a vehicle processing system for managing a volume of misconduct reports, the method comprising: identifying one or more misconduct observations from a plurality of misconduct observations made by the vehicle processing system based on one or more volume management criteria for misconduct report generation; generating a misconduct report comprising information about the identified misconduct observations; and transmitting the generated misconduct report to a network computing device.

[0111] Example 2. The method of example 1, wherein the volume management criteria comprises a predefined time window.

[0112] Example 3. The method of example 1, wherein the volume management criteria comprises a predefined time window and one or more additional selection criteria.

[0113] Example 4. The method of example 1, wherein the volume management criteria comprises a predefined time window and a criticality weight assigned to each misconduct observation.

[0114] Example 5. The method of any one of examples 1-4, wherein identifying one or more misconduct observations from the plurality of misconduct observations made by the vehicle processing system based on one or more volume management criteria for misconduct report generation is performed in response to determining that a number of misconduct observations made by the vehicle processing system reaches a threshold number of misconduct observations.

[0115] Example 6. The method of any one of examples 1-4, wherein identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation comprises: in response to determining that a number of the inappropriate behavior observations made by the vehicle processing system within a predefined time window reaches a threshold number of inappropriate behavior observations, identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation.

[0116] Example 7. The method of any one of examples 1-4, wherein identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation comprises: in response to determining that a number of the inappropriate behavior observations made by the vehicle processing system within a predefined time window reaches a threshold number of inappropriate behavior observations, identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation; and selecting an inappropriate behavior observation from the number of the inappropriate behavior observations made by the vehicle processing system within the predefined time window based on one or more additional selection criteria.

[0117] Example 8. The method of any one of examples 1-4, wherein: identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation comprises grouping two or more inappropriate behavior observations related to similar inappropriate behavior operations based on a similarity criterion; and generating the inappropriate behavior report including information about the identified inappropriate behavior observations comprises generating one inappropriate behavior report for the similar inappropriate behavior operations.

[0118] Example 9. The method of any one of examples 1-4, wherein: identifying one or more inappropriate behavior observations from the plurality of inappropriate behavior observations made by the vehicle processing system based on one or more quantity management criteria for inappropriate behavior report generation comprises grouping two or more inappropriate behavior observations related to the same inappropriate behavior vehicle; and generating the inappropriate behavior report including information about the identified inappropriate behavior observations comprises generating one inappropriate behavior report for the two or more inappropriate behavior observations related to the same inappropriate behavior vehicle.

[0119] Example 10. The method of any one of Examples 1-9, further comprising: selecting the one or more quantity management criteria for misbehavior report generation based on one or more of available memory storage, processor heat thresholds, available processor cycles or computing resources, or available hardware security module (HSM) cycles or computing resources.

[0120] The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the foregoing embodiments can be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Furthermore, any reference to claim elements in the singular, for example, using the articles "one," "the," or "said," is not to be construed as limiting the

[0121] The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0122] The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field

[0123] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operation of the methods or algorithms disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operation of a method or algorithm may reside as a single line of code and / or instruction, or any combination or set of code and / or instructions, on a non-transitory processor-readable medium and / or computer-readable medium that may be incorporated into a computer program product.

[0124] The above description of the disclosed embodiments is provided to enable any person skilled in the art to implement or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of the claims. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but should be granted the broadest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for managing the volume of misconduct reports, executed by a vehicle handling system, the method comprising: One or more misconduct observations are identified from multiple misconduct observations conducted by the vehicle handling system based on one or more quantitative management standards used for generating misconduct reports; Generate misconduct reports that include information about the observed misconduct; as well as Reports of any misconduct will be sent to the network computing device.

2. The method according to claim 1, wherein the quantity management standard includes a predefined time window.

3. The method of claim 1, wherein the quantity management criteria include a predefined time window and one or more additional selection criteria.

4. The method of claim 1, wherein the quantity management criteria include a predefined time window and a critical weight assigned to each observation of misbehavior.

5. The method of claim 1, wherein identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports is performed in response to determining that the number of misconduct observations performed by the vehicle handling system has reached a threshold number of misconduct observations.

6. The method of claim 1, wherein identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports comprises: In response to determining that the number of misconduct observations made by the vehicle handling system within a predefined time window reaches a threshold number of misconduct observations, one or more misconduct observations are identified from the plurality of misconduct observations made by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports.

7. The method of claim 1, wherein identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports comprises: In response to determining that the number of misbehavior observations made by the vehicle handling system within a predefined time window reaches a threshold number of misbehavior observations, one or more misbehavior observations are identified from the plurality of misbehavior observations made by the vehicle handling system based on one or more quantitative management criteria for generating misbehavior reports; as well as Misbehavior observations are selected from the number of misbehavior observations conducted by the vehicle handling system within the predefined time window based on one or more additional selection criteria.

8. The method according to claim 1, wherein: Identifying one or more misconduct observations from the plurality of misconduct observations conducted by the vehicle handling system based on one or more quantitative management criteria used for generating misconduct reports includes: grouping two or more misconduct observations related to similar misconduct operations based on similarity criteria; and Generating a misconduct report that includes information about the identified misconduct observations includes: generating a misconduct report for the similar misconduct operation.

9. The method according to claim 1, wherein: Identifying one or more misconduct observations from the plurality of misconduct observations conducted by the vehicle handling system based on one or more quantitative management criteria used for generating misconduct reports includes: grouping two or more misconduct observations related to the same misconduct vehicle; and Generating a misconduct report that includes information about the identified misconduct observations includes generating one misconduct report for two or more misconduct observations related to the same misconduct vehicle.

10. The method according to claim 1, wherein the method further comprises: The one or more quantity management criteria used for generating misconduct reports are selected based on one or more of the following: available memory storage, processor thermal threshold, available processor cycles or computing resources, or available hardware security module (HSM) cycles or computing resources.

11. A vehicle handling system, the vehicle handling system comprising: Memory; and One or more processors, said one or more processors being coupled to the memory and configured to: One or more misconduct observations are identified from multiple misconduct observations conducted by the vehicle handling system based on one or more quantitative management standards used for generating misconduct reports; Generate misconduct reports that include information about the observed misconduct; as well as Reports of any misconduct will be sent to the network computing device.

12. The vehicle handling system of claim 11, wherein the volume management standard includes a predefined time window.

13. The vehicle handling system of claim 11, wherein the volume management criteria include a predefined time window and one or more additional selection criteria.

14. The vehicle handling system of claim 11, wherein the volume management criteria include predefined time windows and critical weights assigned to each observation of misbehavior.

15. The vehicle handling system of claim 11, wherein the one or more processors are further configured to identify an inappropriate behavior observation from the plurality of inappropriate behavior observations performed by the vehicle handling system in response to determining that the number of inappropriate behavior observations performed by the vehicle handling system reaches a threshold number of inappropriate behavior observations.

16. The vehicle handling system of claim 11, wherein the one or more processors are further configured to identify an inappropriate behavior observation from the plurality of inappropriate behavior observations performed by the vehicle handling system in response to determining that the number of inappropriate behavior observations performed by the vehicle handling system within a predefined time window reaches a threshold number of inappropriate behavior observations.

17. The vehicle handling system of claim 11, wherein the one or more processors are further configured to identify misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports: In response to determining that the number of misconduct observations made by the vehicle handling system within a predefined time window reaches a threshold number for misconduct observations, one or more misconduct observations are identified from the plurality of misconduct observations made by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports; and Misbehavior observations are selected from the number of misbehavior observations conducted by the vehicle handling system within the predefined time window based on one or more additional selection criteria.

18. The vehicle handling system of claim 11, wherein the one or more processors are further configured to: By grouping two or more misconduct observations related to similar misconduct operations based on similarity criteria, misconduct observations are identified from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria used for misconduct reporting; and The misconduct report is generated by producing a misconduct report in response to the aforementioned misconduct, thereby producing information about the observed misconduct.

19. The vehicle processing system of claim 11, wherein the one or more processors are further configured to: By grouping two or more misconduct observations associated with the same misconduct vehicle, misconduct observations are identified from the plurality of misconduct observations performed by the vehicle processing system based on one or more quantitative management criteria used for misconduct reporting; and The misconduct report is generated by producing a misconduct report that includes information about the identified misconduct observations, by generating a misconduct report from two or more misconduct observations related to the same misconduct vehicle.

20. The vehicle processing system of claim 11, wherein the one or more processors are further configured to select the one or more quantity management criteria for generating misconduct reports based on one or more of the following: available memory storage, processor thermal threshold, available processor cycles or computing resources, or available hardware security module (HSM) cycles or computing resources.

21. A vehicle handling system, the vehicle handling system comprising: Components for identifying one or more misconduct observations from multiple misconduct observations performed by the vehicle handling system based on one or more quantitative management standards used for generating misconduct reports; Components used to generate misconduct reports that include information about the observed misconduct; as well as Components used to send reports of misconduct to network computing devices.

22. The vehicle handling system of claim 21, wherein the volume management standard includes a predefined time window.

23. The vehicle handling system of claim 21, wherein the volume management criteria include predefined time windows and critical weights assigned to each observation of misbehavior.

24. The vehicle handling system of claim 21, wherein the component for identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management standards for generating misconduct reports comprises: A component for identifying the misbehavior observation in response to determining that the number of misbehavior observations made by the vehicle handling system has reached a threshold number of misbehavior observations.

25. The vehicle handling system of claim 21, wherein the component for identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports comprises: A component for identifying the misbehavior observation from the plurality of misbehavior observations made by the vehicle handling system in response to determining that the number of misbehavior observations made by the vehicle handling system within a predefined time window has reached a threshold number of misbehavior observations.

26. The vehicle handling system of claim 21, wherein the component for identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management standards for generating misconduct reports comprises: A component for identifying one or more misbehavior observations from the plurality of misbehavior observations made by the vehicle handling system in response to determining that the number of misbehavior observations made by the vehicle handling system within a predefined time window has reached a threshold number of misbehavior observations, based on one or more quantitative management criteria for generating misbehavior reports; as well as A component for selecting observations of misbehavior from the number of misbehavior observations performed by the vehicle handling system within the predefined time window based on one or more additional selection criteria.

27. The vehicle handling system according to claim 21, wherein: The component for identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management criteria for generating misconduct reports includes: a component for grouping two or more misconduct observations related to similar misconduct operations based on similarity criteria; and The component for generating the misconduct report, which includes information about the observed misconduct, includes: a component for generating a misconduct report for the similar misconduct operation.

28. The vehicle handling system according to claim 21, wherein: The component for identifying one or more misconduct observations from the plurality of misconduct observations performed by the vehicle handling system based on one or more quantitative management standards for generating misconduct reports includes: a component for grouping two or more misconduct observations associated with the same misconducting vehicle; and The component for generating the misconduct report, which includes information about the identified misconduct observations, includes: a component for generating a misconduct report for two or more misconduct observations related to the same misconduct vehicle.

29. The vehicle handling system according to claim 21, further comprising: Components for selecting one or more quantity management criteria for generating misconduct reports based on one or more of the following: available memory storage, processor thermal threshold, available processor cycles or computing resources, or available hardware security module (HSM) cycles or computing resources.

30. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a vehicle handling system to perform operations including: One or more misconduct observations are identified from multiple misconduct observations conducted by the vehicle handling system based on one or more quantitative management standards used for generating misconduct reports; Generate misconduct reports that include information about the observed misconduct; as well as Reports of any misconduct will be sent to the network computing device.

Images