Vehicle-to-Everything (V2X) fraud detection using a local dynamic map data model

Abstract

Embodiments include a method performed by a processor of a vehicle-to-everything (V2X) system in a vehicle for detecting a misbehavior condition by comparing information received in a V2X message to local dynamic map data. Various embodiments may include receiving a V2X message from another V2X system participant, determining whether a misbehavior condition is detected by comparing data included in the received V2X message to information in a locally maintained or stored local dynamic map data model, and detecting the misbehavior condition and generating a misbehavior report identifying the misbehavior condition in response to a discrepancy or inconsistency between any data in the received V2X message and the local dynamic map.

Description

Technical Field

[0001] Related Applications This application claims the benefit of priority of U.S. Provisional Application No. 63 / 138,909, filed on January 19, 2021, entitled "Vehicle-to-Everything (V2X) Misbehavior Detection Using an LDM Data Model", the entire content of which is incorporated herein by reference for all purposes.

Background Art

[0002] The Cellular Vehicle-to-Everything (C-V2X) protocol serves as a foundation for vehicle-based wireless communications and can be used to support intelligent highways, autonomous vehicles, and semi-autonomous vehicles, as well as to improve the overall efficiency and safety of highway traffic systems. C-V2X defines two transmission modes that together provide enhanced road safety and 360° beyond-line-of-sight awareness and a higher level of predictability for autonomous driving. The first transmission mode includes Direct C-V2X, which includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P) and provides extended communication range and reliability within the 5.9 gigahertz (GHz) spectrum of a dedicated intelligent transport system (ITS) independent of the cellular network. The second transmission mode includes vehicle-to-vehicle (V2N) communication in mobile broadband systems and technologies such as third-generation wireless mobile communication technology (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) system, Code Division Multiple Access (CDMA) 2000 system, etc.), fourth-generation wireless mobile communication technology (4G) (e.g., Long-Term Evolution (LTE) system, LTE Advanced system, Mobile Worldwide Interoperability for Microwave Access (Mobile WiMAX) system, etc.), and fifth-generation wireless mobile communication technology (e.g., 5G NR system). Other V2X wireless technologies are also under consideration in different regions of the world. The techniques described in this patent are applicable to any V2X wireless technology.

[0003] Several regions around the world are developing standards for vehicle-based communication systems and functions, such as the IEEE 1609 standard and the SAE standard developed for use in North America, or the ETSI and CEN standards developed for use in Europe. Part of these systems is the ability of vehicles to broadcast Basic Safety Messages (BSM) in North America, or Cooperative Awareness Messages (CAM) in Europe, which can be received and processed by other vehicles to improve traffic safety. Processing of such messages in the transmitting and receiving vehicles is carried out in on-board equipment that provides V2X functionality (referred to herein as "V2X on-board equipment"). [Overview of the Initiative] [Means for solving the problem]

[0004] Various embodiments include methods performed by a fraud management system running on a V2X device processor to detect fraudulent conditions in an received V2X message by comparing the data in the received V2X message with data contained in a locally maintained or stored Local Dynamic Map (LDM) data model. This LDM aggregates and synthesizes information received by the V2X system participant from all relevant inputs (including, but not limited to, V2X messages and local sensor inputs) to create a model of the local environment around the V2X system participant. The LDM can be updated based on the observed dynamics of objects tracked within the LDM, as well as on new inputs.

[0005] Various embodiments may include the steps of: receiving a V2X message from another V2X system participant, the V2X message containing data relating to the environment surrounding the vehicle; comparing the data contained in the received V2X message with data in a locally maintained or stored local dynamic map (LDM) data model in order to detect a cheating condition; generating a cheating report that identifies the cheating condition in response to the detection of a cheating condition based on the comparison; and transmitting the generated cheating report to a cheating control body.

[0006] Some embodiments may include the steps of monitoring a plurality of sensors within a vehicle to collect additional data about the environment surrounding the vehicle, generating an LDM data model representing the environment surrounding the vehicle, at least in part, based on the aggregation of the additional data collected from the plurality of sensors, and maintaining or storing the LDM data model in local memory.

[0007] Some embodiments may further include, in response to a determination that no infringing condition is detected, the steps of: performing a calculation based on at least one of the observed dynamics of an object in the LDM data model or a new data input received from a V2X message; modifying the LDM data model to incorporate the calculation and the data contained in the received V2X message; and replacing the LDM data model maintained or stored in memory with the modified LDM model.

[0008] In some embodiments, the step of sending a generated fraud report to a fraud control authority may include the step of sending a representation of the LDM data model.

[0009] In some embodiments, the representation of the LDM data model may include an incomplete dataset for the LDM data model.

[0010] Some embodiments may further include a step of receiving feedback from a fraud control body, the feedback including corrective actions to mitigate the fraudulent condition.

[0011] In some embodiments, data about the vehicle's surrounding environment included in the received V2X message may include traffic information. In some embodiments, data about the vehicle's surrounding environment included in the received V2X message may include location information of adjacent vehicles based on Global Navigation Satellite System (GNSS) (e.g., Global Positioning System (GPS)) data. In some embodiments, data about the vehicle's surrounding environment included in the received V2X message may include map data specifying road geometry and street fixtures.

[0012] In some embodiments, the step of comparing data contained in an received V2X message with a locally maintained or stored LDM data model in order to detect fraudulent activity may include determining whether any of the data contained in the received V2X message is inconsistent with information in the locally maintained or stored LDM data model.

[0013] In some embodiments, the step of comparing data contained in an received V2X message with a locally maintained or stored LDM data model in order to detect a fraudulent condition may include the steps of selecting a subset of data elements in the locally maintained or stored LDM data model for comparison with the data contained in the received V2X message, and determining whether any of the data contained in the received V2X message is inconsistent with the selected subset of data elements in the locally maintained or stored LDM data model.

[0014] In some embodiments, the step of comparing data contained in an received V2X message with a locally maintained or stored LDM data model in order to detect fraudulent activity may include determining whether the status or location information of the adjacent vehicle that sent the received V2X message is inconsistent with the status or location information of the adjacent vehicle in the locally maintained or stored LDM data model.

[0015] Further embodiments may include a V2X device having a processor configured to perform one or more operations of the method summarized above. Further embodiments may include a non-temporary processor-readable storage medium storing processor-executable instructions configured to cause the processor of the V2X device to perform operations of the method summarized above. Further embodiments may include a V2X device having means for performing the functions of the method summarized above.

[0016] The accompanying drawings incorporated herein and constituting part thereof illustrate exemplary embodiments of the claims and, together with the general description given above and the embodiments for carrying out the invention below, are useful in illustrating the features of the claims. [Brief explanation of the drawing]

[0017] [Figure 1A] This is a component block diagram showing a vehicle suitable for implementing various embodiments. [Figure 1B] This is a component block diagram showing a vehicle suitable for implementing various embodiments. [Figure 1C] This is a component block diagram showing vehicle components suitable for implementing various embodiments. [Figure 1D] This schematic block diagram shows a subset of V2X communication systems suitable for implementing various embodiments. [Figure 2A] This is a component block diagram showing the components of an exemplary vehicle management system according to various embodiments. [Figure 2B]A component block diagram showing the components of another exemplary vehicle management system according to various embodiments [Figure 3] A block diagram showing the components of a system-on-chip for use in a vehicle according to various embodiments. [Figure 4] A component block diagram showing a system configured to generate local dynamic map data according to various embodiments [Figure 5] A process flow diagram showing the operations of a method executed by a processor of a V2X device to detect an improper state in a V2X message by comparing the data in the received V2X message with the data in the LDM data model according to various embodiments [Figure 6] A process flow diagram showing the operations of a method for comparing the data in a received V2X message with the data in the LDM data model according to various embodiments [Figure 7] A component block diagram showing an exemplary mobile computing device suitable for use with various embodiments [Figure 8] A component block diagram showing an exemplary mobile computing device suitable for use with various embodiments [Figure 9] A component block diagram showing an exemplary server suitable for use with various embodiments **DETAILED DESCRIPTION OF THE INVENTION**

[0018] Various embodiments will be described in detail with reference to the accompanying drawings. Whenever possible, the same reference numbers are used throughout the drawings to refer to the same or similar parts. References made to specific examples and implementations are for purposes of illustration and are not intended to limit the scope of the claims.

[0019] In V2X communication, it is important to detect such inaccurate data in order to prevent the spread of inaccurate, corrupted, or hacked (i.e., bad) data. If a V2X device is sending inaccurate, corrupted, or hacked (i.e., bad) data, the consequences can be merely minor inconveniences and traffic jams, but can also be life-threatening. Therefore, in order to ensure that any such misbehavior state is reliably detected, it is desirable to subject the detection of the misbehavior state to a rigorous analysis of a comprehensive set of information.

[0020] As used herein, the term "mobile device" refers to any one or all of a similar electronic device including a wireless router device, a wireless appliance, a cellular phone, a smartphone, a portable computing device, a personal or mobile multimedia player, a laptop computer, a tablet computer, a smartbook, an ultrabook, a palmtop computer, a wireless email receiver, a multimedia Internet-enabled cellular phone, a medical device and instrument, a biosensor / device, a smartwatch, a smart closure, a smart glass, a smart list band, a smart jewelry (e.g., a smart ring, a smart bracelet, etc.), a wearable device, an entertainment device (e.g., a wireless game controller, a music and video player, a satellite radio, etc.), a smart meter / sensor, an industrial manufacturing device, a large and small machine and appliance for home or enterprise use, an Internet of Things (IoT) device with a wireless network connection, a wireless communication element in an autonomous and semi-autonomous vehicle, a mobile device fixed or incorporated into various mobile platforms, a global positioning system device, as well as a memory, a wireless communication component, and a programmable processor.

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

[0022] The term “System in Package” (SIP) may be used herein to refer to a single module or package that includes multiple resources, computing units, cores, and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged on a unifying substrate. A SIP may also include multiple independent SOCs that are coupled to each other via a high-speed communication circuit configuration and packaged in very close proximity, such as on a single motherboard or within a single mobile device. The proximity of the SOCs facilitates high-speed communication, as well as the sharing of memory and resources.

[0023] As used in this application, terms such as “component,” “system,” “unit,” and “module” include, but are not limited to, computer-related entities such as hardware, firmware, hardware-software combinations, software, or running software, configured to perform a particular operation or function. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As an example, both an application running on a communication device and the communication device itself may be referred to as a component. One or more components may reside within a process and / or an execution thread, and components may be localized on one processor or core and / or distributed among two or more processors or cores. In addition, these components may be executed from various non-temporary computer-readable media having various instructions and / or data structures stored thereon. Components may communicate by local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known computer, processor, and / or process-related communication methods.

[0024] Generally, various embodiments include methods and mechanisms for detecting infidelity conditions by a V2X system participant by comparing an received V2X message with the vehicle's local dynamic map (LDM) data model and determining whether there is an inconsistency between the data received in the V2X message and the locally maintained or stored LDM data model.

[0025] Vehicle-to-vehicle (V2X) systems and technologies are quite promising for improving traffic flow and vehicle safety by enabling vehicles to share information about their location, speed, direction of travel, braking, and other factors that may be useful to other vehicles for collision avoidance and other safety functions. Vehicles equipped with V2X / V2V onboard equipment will transmit that vehicle information frequently (e.g., up to 20 times per second) in packets called Basic Safety Messages (BSM) or CAMs. If all V2X-equipped vehicles transmit such BSM / CAM messages, all receiving vehicles will have the information necessary to control their own speed and direction in order to avoid collisions and to position vehicles efficiently and safely relative to one another. It is envisioned that V2X-equipped vehicles may be able to improve traffic flow by safely reducing separation distances, platooning several vehicles together, and avoiding vehicles experiencing breakdowns.

[0026] For ease of reference, some embodiments are described in this application using a fraud management system operating within the V2X terminology. However, it should be understood that the various embodiments encompass one or all of the V2X / V2V or vehicle-based communication standards, messages, or technologies. Therefore, nothing in this application should be construed as limiting the claims to V2X / V2V systems unless expressly stated as such in the claims. In addition, the embodiments described herein describe in-vehicle equipment for performing V2X / V2V communication. In a V2X / V2V system, system participant equipment may include, but is not limited to, in-vehicle equipment, mobile devices, and roadside units (RSUs). RSUs may include fixed devices such as traffic signals, roadside beacons, and traffic cameras. Each system participant device may broadcast information to other system participant devices. V2X communication between system participant devices can enable applications running on each system participant device to provide safety applications (for example, applications that can determine imminent dangers, such as a vehicle suddenly braking or rapidly emerging from a blind intersection) or mobility applications (planning for changes in traffic signals) to vehicles, or to provide other useful functions within the vehicle traffic system as a whole.

[0027] A Local Dynamic Map (LDM) is typically a data model constructed by a mobile device to support navigation within its environment. A mobile device acquires information about its environment from one or more sensors and may receive other LDM data from other mobile devices (e.g., via a V2X communication system) or from network elements such as cloud-based servers, and uses such data to construct its LDM. An LDM can be a dynamic data model that occurs over time, not through messages from other V2X system participants, but via dead reckoning, even when no new data is received to update the positions of those other V2X system participants. This LDM data model can aggregate and synthesize information received by the V2X system participant from all relevant inputs (including, but not limited to, V2X messages and sensor inputs) to create a model of the local environment around the V2X system participant. The LDM may be updated based on the observed dynamics of objects tracked within the LDM, as well as based on new inputs.

[0028] A cheating management system operating on a V2X participant's equipment may construct LDM by aggregating information obtained from one or more sensors on the host vehicle (e.g., cameras, radar, LiDAR, etc.), one or more other mobile devices or vehicles received via V2X messages, and / or remote data sources such as roadside units, and network elements such as cloud-based servers. The vehicle V2X system may process this information to generate and update locally maintained or stored LDM data in a usable or presentable form, such as a digital map. Parts of the LDM map may also be received from external sources, such as computing devices capable of performing intensive processing operations. Such an LDM data model may contain many types of information that can be structured or organized in several layers or data elements. For example, an LDM data model may include data layers such as physical maps of roads downloaded from map databases, data layers of observed road conditions (e.g., rough or smooth, wet, dry or icy), data layers of observed other vehicle positions and speeds, data layers of network-reported road modifications (e.g., construction, closed lanes), data layers of nearby traffic signals (e.g., signal cycle times at traffic lights ahead of the vehicle), and other information useful for autonomous driving, collision avoidance, and general safety features (e.g., driver alerts).

[0029] The information used by fraud control systems is typically limited to data that can be maintained or stored in memory (e.g., static maps) and data from on-board sensors. LDM data received from on-board sensors and other mobile devices may be limited by the sensitivity, field of view, and perceptual limitations of each sensor. LDM data received from distant network elements typically does not include very recent changes in the environment close to the vehicle of the mobile device and may therefore not reflect highly dynamic environmental conditions (e.g., road closures, construction, accidents). By combining all sources of information about the road ahead for the vehicle and other vehicles in the vicinity, a vehicle system (e.g., a fraud control system) can generate a more comprehensive LDM data model that is useful for complex processes such as autonomous driving and semi-autonomous driver assistance functions.

[0030] LDM data models can be structured in various types that reflect the degree to which such information can change dynamically. For example, LDM data may be classified (for example, in the relevant ETSI standard) as follows: Type 1 for persistent static information such as road locations and geographical features, which may be considered map data; Type 2 for transient static information, which may include signals not included in map data such as speed limits; Type 3 for transient dynamic information such as weather, traffic congestion, and other traffic condition information; and Type 4 for highly dynamic information such as vehicle sensor data, the locations of other moving vehicles, pedestrians, parked vehicles, traffic signal status, and other highly transient conditions. Examples of LDM implementations have been reported, including PG-LDM by Bosch® and Tele Atlas®, and NAVTEQ-LDM by NAVTEQ®. The PG-LDM implementation employs PostgreSQL as its database engine and provides PostGIS stored procedures and spatial operations. On the other hand, the NAVTEQ-LDM implementation uses SQLite as its database engine.

[0031] In various embodiments, a fraud management system operating on a V2X device processor may receive initial LDM data from one or more data sources other than V2X system participants, which may include adjacent vehicles, mobile devices, and data sources capable of transmitting RSU, CAM messages, or Decentralized Environmental Notification Message (DENM) messages, as well as various internet or cloud-based resources. In some embodiments, the received initial LDM data may be Type 4 information, i.e., "highly dynamic" information that reflects highly transient conditions. In some embodiments, the received LDM data may be acquired from sensors or other information sources within a threshold time period, such as 2 seconds, 1 second, 250 milliseconds, or another preferred threshold or time window. In some embodiments, the initial LDM data may include data collected by multiple sensors mounted on the vehicle and mobile devices. Such sensor data may include data such as speed, temperature, revolutions per minute, GPS location, image data, audio data, or vehicle / device operating status data. The fraud management system can aggregate all collected sensor data along with the received V2X message data to generate an LDM data model representing the environment surrounding the V2X participant. For ease of reference, various embodiments will be described by referring to the environment surrounding the V2X participant as the environment surrounding the vehicle, but the V2X participant may be other devices outside the vehicle, such as the RSU and other fixed equipment.

[0032] The LDM data model generated in this way can be useful for evaluating the accuracy or precision of the information contained in the received V2X message. Since the LDM data model can consist of data received from various information sources, it may contain one or more data elements related to the information provided in the V2X message. However, not all information contained in the LDM data model is necessarily related to the information in the V2X message that is being verified or confirmed.

[0033] Various embodiments may be implemented in various vehicles, and an exemplary vehicle 101 of various vehicles is shown in Figures 1A and 1B. Referring to Figures 1A and 1B, vehicle 101 may include a control unit 140, and a plurality of sensors 144-170, including a satellite geopositioning system receiver 142, occupancy sensors 144, 146, 148, 150, 152, tire pressure sensors 154, 156, cameras 158, 160, microphones 162, 164, impact sensor 166, radar 168, and lidar 170. The plurality of sensors 144-170, which are located inside or on the vehicle, may be used for various purposes such as autonomous and semi-autonomous navigation and control, crash avoidance, and positioning, and to provide sensor data about objects and people inside or on the vehicle 101. Sensors 144-170 may include one or more of a wide variety of sensors capable of detecting various information useful for navigation and collision avoidance. Each of the sensors 144-170 may be in wired or wireless communication with the control unit 140 and with each other. In detail, the sensors may include one or more cameras 158, 160, or other optical or photooptic sensors. The sensors may further include other types of object detection and ranging sensors, such as radar 168, lidar 170, IR sensors, and ultrasonic sensors. The sensors may further include tire pressure sensors 154, 156, humidity sensors, temperature sensors, satellite geopositioning sensors 142, control input sensors 145, accelerometers, vibration sensors, gyroscopes, gravimeters, shock sensors 166, intensity meters, stress meters, strain sensors, fluid sensors, chemical sensors, gas content analyzers, pH sensors, radiation sensors, Geiger counters, neutron detectors, biomaterial sensors, microphones 162, 164, occupancy sensors 144, 146, 148, 150, 152, proximity sensors, and other sensors.

[0034] The vehicle control unit 140 may consist of processor-executable instructions for performing navigation and collision avoidance actions using information received from various sensors, particularly cameras 158 and 160. In some embodiments, the control unit 140 may supplement the processing of camera images using distance and relative position (e.g., relative azimuth) which may be obtained from radar 168 and / or lidar 170 sensors. The control unit 140 may be further configured to control the steering, braking, and speed of the vehicle 101 when operating in autonomous or semi-autonomous mode, using information about other vehicles determined using various embodiments.

[0035] Figure 1C is a component block diagram showing a communication system 100 of components and support systems suitable for implementing various embodiments. Referring to Figures 1A to 1C, the vehicle 101 may include a control unit 140, which may include various circuits and devices used to control the operation of the vehicle 101. In the example shown in Figure 1C, the control unit 140 includes a processor 140a, memory 140b, input module 140c, output module 140d, and wireless module 140e. The control unit 140 may be coupled to and configured to control the driving control components 172a, navigation components 172b, and one or more sensors 172c of the vehicle 101. The processor 140a may consist of processor-executable instructions for controlling the steering, navigation, and / or other operations of the vehicle 101, including the operations of various embodiments. The processor 140a may be coupled to memory 140b.

[0036] The wireless module 140e may be configured for wireless communication. The wireless module 140e may exchange signals (e.g., command signals for controlling steering, signals from the navigation system, etc.) with a network transceiver (e.g., base station 110) via the communication link 122 and may provide signals to the processor 140a and / or the navigation unit 172b. In some embodiments, the wireless module 140e may enable the vehicle 101 to communicate with a wireless communication device 120 via the wireless communication link 124. The wireless communication link 124 may be a bidirectional or unidirectional communication link and may use one or more communication protocols as described.

[0037] The input module 140c may receive sensor data from one or more vehicle sensors 172c, as well as electronic signals from other components, including the driving control component 172a and the navigation component 172b. The output module 140d may communicate with or activate various components of the vehicle 101, including the driving control component 172a, the navigation component 172b, and the sensors 172c.

[0038] The control unit 140 may be coupled to the driving control components 172a to control the physical elements of the vehicle 101 related to the operation and navigation of the vehicle, such as the engine, motor, throttle, steering elements, steering device elements, and braking or deceleration elements. The driving control components 172a may also include components for controlling other devices of the vehicle, including environmental controls (e.g., air conditioning and heating), exterior lighting and / or interior lighting, interior information displays and / or exterior information displays (which may include display screens or other devices for displaying information), safety devices (e.g., tactile devices, audible alarms, etc.), and other similar devices.

[0039] The control unit 140 may be coupled to the navigation component 172b and may receive data from the navigation component 172b, and may be configured to use such data to determine the current position and orientation of the vehicle 101, as well as a suitable course to the destination. The navigation component 172b may include, or be coupled to, a GNSS receiver system (e.g., one or more GPS receivers) that enables the vehicle 101 to determine its current position using GNSS signals. Alternatively or additionally, the navigation component 172b may include a radio navigation receiver for receiving navigation beacons or other signals from radio nodes such as Wi-Fi access points, cellular network sites, radio stations, remote computing devices, or other vehicles. Through the control of the driving control element 172a, the processor 140a may control the vehicle 101 for navigation and steering. The processor 140a and / or navigation component 172b may be configured to communicate with network elements such as servers within a communication network (e.g., core network 132) via wireless communication links 122, 126 to receive commands for controlling the steering, receive data useful in navigation, provide real-time position reports, and assess other data.

[0040] The control unit 140 may be coupled to one or more sensors 172c. Sensors 172c may include sensors 144-170 as described above and may be configured to provide various data to the processor 140a.

[0041] Although the control unit 140 is described as including separate components, in some embodiments some or all of the components (for example, the processor 140a, memory 140b, input module 140c, output module 140d, and wireless module 140e) may be integrated in a single device or module, such as a system-on-chip (SOC) processing device. Such an SOC processing device may be configured for use in a vehicle and, once installed in the vehicle, may consist of processor-executable instructions, etc., that are executed in the processor 140a to perform navigation and collision avoidance actions using LDM data.

[0042] Figure 1D shows a portion of a V2X system 103, including three vehicles 12, 14, and 16. In the illustrated example, each vehicle 12, 14, and 16 includes V2X on-board equipment 102, 104, and 106, respectively, configured to periodically broadcast basic safety messages 30, 40, and 50 for reception and processing by on-board equipment (e.g., 102, 104, and 106) in other vehicles. By sharing vehicle location, speed, direction, braking, and other information, vehicles can maintain safe separation and identify and avoid potential collisions. For example, a following vehicle 12 receiving a basic safety message 40 from a preceding vehicle 16 can determine the speed and location of vehicle 16, thereby enabling vehicle 12 to then match its speed and maintain a safe separation distance 20. When the preceding vehicle 16 brakes, the V2X device 102 in the following vehicle 12 is notified via a basic safety message 40, allowing it to brake simultaneously and maintain a safe separation distance 20 even when the preceding vehicle 16 suddenly stops. As another example, the V2X device 104 in the truck vehicle 14 may receive basic safety messages 30, 50 from the two vehicles 12, 16, and therefore be notified that the truck vehicle 14 should stop at the intersection to avoid a collision. Each of the vehicle V2X onboard devices 102, 104, and 106 may communicate with each other using any of the various close-range communication protocols. In addition, the vehicles may transmit data and information regarding detected basic safety messages and detected misconduct reports to the original equipment manufacturers (OEMs) (70, 72) and / or remote misconduct control agencies 74 via communication links 60, 62 through a communication network 18 (e.g., cellular, WiFi, etc.). The MBR may be transmitted directly to the Fraud Control Agency 74 (for example, via communication links 64, 66). In other embodiments, the MBR may first be transmitted via communication links 64, 66 to an MBR preprocessing unit, such as an OEM server 70, 72, for preprocessing. The preprocessed MBR may then be transmitted from the MBR preprocessing servers 70, 72 to the Fraud Control Agency 74 via communication links 64, 66.

[0043] Figure 2A is a component block diagram showing the components of an exemplary fraud management system 200. The vehicle management system 200 may include various subsystems, communication elements, computing elements, computing devices, or computing units that may be used within the vehicle 101. Referring to Figures 1A to 2A, the various computing elements, computing devices, or computing units within the fraud management system 200 may be implemented within a system of interconnected computing devices (i.e., subsystems) that communicate data and commands with each other (indicated, for example, by arrows in Figure 2A). In some implementations, the various computing elements, computing devices, or computing units within the fraud management system 200 may be implemented within a single computing device, such as a separate thread, process, algorithm, or computing element. Thus, each subsystem / computation element shown in Figure 2A is also generally referred to herein as a "layer" within the computing "stack" that constitutes the fraud management system 200. However, the use of the terms layer and stack when describing various embodiments does not imply or require that the corresponding functions be implemented within a single autonomous (or semi-autonomous) vehicle management system computing device, although this is a possible implementation embodiment. Rather, the use of the term "layer" is intended to encompass subsystems with independent processors and computational elements (e.g., threads, algorithms, subroutines, etc.) that run within a combination of one or more computing devices and subsystems and computational elements.

[0044] The fraud control system stack may include a radar perception layer 202, a camera perception layer 204, a positioning engine layer 206, a map fusion and arbitration layer 208, a route planning layer 210, a sensor fusion and road world model (RWM) management layer 212, a traffic planning and control layer 214, and a behavior planning and prediction layer 216. Layers 202-216 are just examples of some of the layers in one exemplary configuration of the fraud control system stack 200. Other configurations may include additional layers for other perception sensors (e.g., a LiDAR perception layer), additional layers for planning and / or control, additional layers for modeling, and / or some of layers 202-216 may be excluded from the fraud control system stack 200. Each of layers 202-216 may exchange data, calculation results, and commands as illustrated by the arrows in Figure 2A. Furthermore, the cheating management system stack 200 may receive and process data from sensors (e.g., radar, lidar, cameras, inertial measurement units (IMUs), etc.), navigation systems (e.g., GPS receivers, IMUs, etc.), vehicle networks (e.g., Controller Area Network (CAN) bus), and databases in memory (e.g., digital map data). The cheating management system stack 200 may output vehicle control commands or signals to a drive-by-wire (DBW) system / control unit 220, which is a system, subsystem, or computing device that directly interfaces with vehicle steering, throttle, and brake controls. The configuration of the cheating management system stack 200 and DBW system / control unit 220 shown in Figure 2A is illustrative only, and other configurations of the vehicle management system and other vehicle components may be used.For example, the configuration of the fraud management system stack 200 and the DBW system / control unit 220 shown in Figure 2A may be used in a vehicle configured for autonomous or semi-autonomous operation, but a different configuration may be used in a non-autonomous vehicle.

[0045] The radar perception layer 202 may receive data from one or more detection and ranging sensors, such as radar (e.g., 168) and / or lidar (e.g., 170), and may process that data to recognize and determine the location of other vehicles and objects in the vicinity of vehicle 101. The radar perception layer 202 may include the use of neural network processing and artificial intelligence methods for recognizing objects and vehicles, and may transmit such information to the sensor fusion and RWM management layer 212.

[0046] The camera perception layer 204 may receive data from one or more cameras, such as cameras 158, 160, and process that data to recognize and determine the locations of other vehicles and objects in the vicinity of vehicle 100. The camera perception layer 204 may include the use of neural network processing and artificial intelligence methods for recognizing objects and vehicles and may transmit such information to the sensor fusion and RWM management layer 212.

[0047] The positioning engine layer 206 may receive data from various sensors and process that data to determine the position of the vehicle 100. These various sensors may include, but are not limited to, GPS sensors, IMUs, and / or other sensors connected via the CAN bus. The positioning engine layer 206 may also utilize input from one or more cameras, such as cameras (e.g., 158, 160), and / or any other available sensors, such as radar or LiDAR.

[0048] The fraud management system 200 may include or be coupled to a vehicle wireless communication subsystem 230. The wireless communication subsystem 230 may be configured to communicate with other vehicle computing devices and highway communication systems via vehicle-to-vehicle (V2V) communication links, etc., and with remote information sources such as cloud-based resources via cellular wireless communication systems such as 5G networks. In various embodiments, the wireless communication subsystem 230 may communicate with other V2X system participants via wireless communication links to receive LDM data.

[0049] The map fusion and arbitration layer 208 may access LDM data received from other V2X system participants, receive output from the positioning engine layer 206, and process the data to further determine the location of the vehicle 101 on the map, such as its location within a lane or its position within a street map. The LDM data may be maintained or stored in the vehicle's memory (e.g., memory 432). For example, the map fusion and arbitration layer 208 may convert latitude and longitude information from GPS into locations on a ground map of roads within the LDM data. GPS positioning involves errors, and therefore the map fusion and arbitration layer 208 may function to determine the best estimated location of the vehicle within a road based on arbitration between GPS coordinates and LDM data. For example, GPS coordinates may pinpoint the vehicle's location near the center of a two-lane road in the LDM data, but the map fusion and arbitration layer 208 may determine, based on the direction of travel, that the vehicle is most likely to be aligned in a lane that coincides with the direction of travel. The map fusion and arbitration layer 208 may pass map-based location information to the sensor fusion and RWM management layer 212.

[0050] The route planning layer 210 may utilize LDM data, as well as input from the operator or dispatcher, to plan a route to be followed by the vehicle 101 to a specific destination. The route planning layer 210 may pass map-based location information to the sensor fusion and RWM management layer 212. However, the use of conventional maps by other layers, such as the sensor fusion and RWM management layer 212, is not required. For example, when perception data is received, other stacks may construct lanes, boundaries, and concepts of a local map to operate and / or control the vehicle based solely on the perception data without using the provided map.

[0051] The sensor fusion and RWM management layer 212 may receive data and outputs generated by the radar perception layer 202, camera perception layer 204, map fusion and arbitration layer 208, and route planning layer 210, and may use some or all of such inputs to estimate or improve the location and state of vehicle 101 in relation to roads, other vehicles on the road, and other objects in the vicinity of vehicle 100. For example, the sensor fusion and RWM management layer 212 may combine image data from the camera perception layer 204 with arbitrated map location information from the map fusion and arbitration layer 208 to improve the determined position of the vehicle within a traffic lane. As another example, the sensor fusion and RWM management layer 212 may combine object recognition and image data from the camera perception layer 204 with object detection and ranging data from the radar perception layer 202 to determine and improve the relative positions of other vehicles and objects in the vicinity of the vehicle. As another example, the sensor fusion and RWM management layer 212 may receive information about the position and direction of other vehicles from vehicle-to-vehicle (V2V) communication (such as via a CAN bus), and may combine this information with information from the radar perception layer 202 and camera perception layer 204 to improve the location and operation of other vehicles. The sensor fusion and RWM management layer 212 may output the improved location and status information of vehicle 100, as well as the improved location and status information of other vehicles and objects in the vicinity of the vehicle, to the operation planning and control layer 214 and / or the behavior planning and prediction layer 216.

[0052] As a further example, the sensor fusion and RWM management layer 212 may use dynamic traffic control commands to instruct the vehicle 101 to change speed, lane, direction of travel, or other navigation elements, and may combine this information with other received information to determine improved location and state information. The sensor fusion and RWM management layer 212 may output the improved location and state information of the vehicle 101, as well as the improved location and state information of other vehicles and objects in the vicinity of the vehicle 101, to the operation planning and control layer 214, the behavior planning and prediction layer 216, and / or to devices remote from the vehicle 101, such as a data server or other vehicles, via wireless communication, such as a C-V2X connection or other wireless connections.

[0053] As a further example, the sensor fusion and RWM management layer 212 may analyze conditions in the vehicle sensor data by monitoring perceptual data from various sensors, such as perceptual data from the radar perception layer 202, camera perception layer 204, and other perception layers, and / or data from one or more sensors themselves. The sensor fusion and RWM management layer 212 may be configured to detect conditions in the sensor data, such as whether a sensor measurement is at, above, or below a threshold, or whether several types of sensor measurements are being taken, and may output the sensor data to the behavior planning and prediction layer 216, and / or via wireless communication, such as a C-V2X connection or other wireless connections, as part of improved location and status information of the vehicle 101, provided from the vehicle 100 to remote devices such as a data server or other vehicles.

[0054] Improved location and status information includes vehicle specifications (e.g., size, weight, color, onboard sensor type, etc.), vehicle position, speed, acceleration, direction of travel, attitude, orientation, destination, fuel / power level, and other status information, vehicle emergency status (e.g., whether the vehicle is an emergency vehicle or a private individual in an emergency), vehicle constraints (e.g., heavy / wide load, turning constraints, high occupancy vehicle (HOV)). Vehicle descriptors relating to the vehicle and the vehicle owner and / or vehicle operator may include vehicle authorizations, vehicle capabilities (e.g., all-wheel drive, four-wheel drive, snow tires, chains, supported connection types, on-board sensor operating status, on-board sensor resolution level, etc.), equipment problems (e.g., low tire pressure, weak brakes, sensor malfunction, etc.), owner / operator's travel preferences (e.g., preferred lanes, roads, routes and / or destinations, preference to avoid tolls or highways, preference to seek the fastest route, etc.), authorization to provide sensor data to a data agency server (e.g., 184), and / or owner / operator identification information.

[0055] The behavior planning and prediction layer 216 of the autonomous vehicle system stack 200 may use the improved location and state information of vehicle 101, as well as the location and state information of other vehicles and objects, output from the sensor fusion and RWM management layer 212, to predict the future behavior of other vehicles and / or objects. For example, the behavior planning and prediction layer 216 may use such information to predict the future relative position of other vehicles in the vicinity of the vehicle, based on its own vehicle position and velocity, as well as the positions and velocities of other vehicles. Such predictions may take into account information from LDM data and route planning to anticipate changes in relative vehicle positions as the host and other vehicles travel along the road. The behavior planning and prediction layer 216 may output the behavior and location predictions of other vehicles and objects to the operation planning and control layer 214. Additionally, the behavior planning and prediction layer 216 may use object behavior in combination with location predictions to plan and generate control signals to control the operation of vehicle 101. For example, based on route planning information, improved location information in road information, and the relative location and movement of other vehicles, the behavior planning and prediction layer 216 may determine that vehicle 101 needs to change lanes and accelerate in order to maintain or achieve a minimum distance from other vehicles and / or prepare for a U-turn or exit. As a result, the behavior planning and prediction layer 216 may calculate or otherwise determine changes to the steering angle relative to the wheels and throttle settings, which should be commanded to the operation planning and control layer 214 and the DBW system / control unit 220, along with various parameters necessary to achieve such lane changes and acceleration. One such parameter may be the calculated steering wheel command angle.

[0056] The operation planning and control layer 214 may receive data and information outputs from the sensor fusion and RWM management layer 212 and the behavior of other vehicles and objects, as well as location predictions from the behavior planning and prediction layer 216. Using this information, it may plan and generate control signals to control the operation of vehicle 101, and verify that such control signals meet safety requirements for vehicle 100. For example, based on route planning information, improved locations in road information, and the relative locations and movements of other vehicles, the operation planning and control layer 214 may verify various control commands or instructions and pass them to the DBW system / control unit 220.

[0057] The DBW system / control unit 220 may receive commands or instructions from the operation planning and control layer 214 and convert such information into mechanical control signals to control the wheel angles, brakes, and throttle of the vehicle 100. For example, the DBW system / control unit 220 may respond to the calculated steering wheel command angle by transmitting the corresponding control signal to the steering wheel controller.

[0058] In various embodiments, the wireless communication subsystem 230 may communicate with other V2X system participants via a wireless communication link to transmit sensor data, location data, vehicle data, and data collected by on-board sensors about the environment surrounding the vehicle. Such information may be used by other V2X system participants to update LDM data for relaying to them.

[0059] In various embodiments, the tampering management system stack 200 may include functions to perform safety checks or supervision of various commands, planning or other decisions at various layers, which may affect vehicle and occupant safety. Such safety check or supervision functions may be implemented in a dedicated layer or distributed across various layers and included as part of a function. In some embodiments, various safety parameters may be stored in memory, and the safety check or supervision function may compare determined values ​​(e.g., relative distance to nearby vehicles, distance from the road centerline, etc.) with the corresponding safety parameters and may issue a warning or command if the safety parameter is violated or will be violated. For example, a safety or supervisory function in the behavior planning and prediction layer 216 (or in a separate layer) may determine the current or future separation distance between another vehicle and that vehicle (as defined by the sensor fusion and RWM management layer 212) (for example, based on an improved world model by the sensor fusion and RWM management layer 212), compare that separation distance to a safety separation distance parameter stored in memory, and if the current or predicted separation distance violates the safety separation distance parameter, may issue a command to accelerate, decelerate, or turn to the operation planning and control layer 214. As another example, a safety or supervisory function in the operation planning and control layer 214 (or in a separate layer) may compare a determined or commanded steering wheel command angle to a safety wheel angle limit or parameter, and in response to a commanded angle exceeding the safety wheel angle limit, may issue an override command and / or alarm.

[0060] Some safety parameters stored in memory may be static (i.e., unchanging over time), such as maximum vehicle speed. Other safety parameters stored in memory may be dynamic, in that the parameters may be continuously or periodically determined or updated based on vehicle state information and / or environmental conditions. Non-exclusive examples of safety parameters include maximum safe speed, maximum brake pressure, maximum acceleration, and safe wheel angle limits, all of which may be functions of road and weather conditions.

[0061] Figure 2B shows an example of a subsystem, computing element, computing device, or computing unit within the vehicle management system 250 that may be used within the vehicle 101. Referring to Figures 1A to 2B, in some embodiments, layers 202, 204, 206, 208, 210, 212, and 216 of the fraud management system stack 250 may be the same as those described with reference to Figure 2A, and the fraud management system stack 250 may operate similarly to the fraud management system stack 200, except that the fraud management system stack 250 may pass various data or instructions to the vehicle safety and crash avoidance system 252 instead of the DBW system / control unit 220. For example, the configuration of the fraud management system stack 250 and the vehicle safety and crash avoidance system 252 shown in Figure 2B may be used within a non-autonomous vehicle.

[0062] In various embodiments, the behavior planning and prediction layer 216 and / or the sensor fusion and RWM management layer 212 may output data to the vehicle safety and crash avoidance system 252. For example, the sensor fusion and RWM management layer 212 may output sensor data as part of improved location and status information of vehicle 101, which is provided to the vehicle safety and crash avoidance system 252. The vehicle safety and crash avoidance system 252 may use the improved location and status information of vehicle 101 to make safety decisions regarding the occupants of vehicle 101 and / or vehicle 100. As another example, the behavior planning and prediction layer 216 may output behavior models and / or predictions relating to the operation of other vehicles to the vehicle safety and crash avoidance system 252. The vehicle safety and crash avoidance system 252 may use behavior models and / or predictions relating to the operation of other vehicles to make safety decisions regarding vehicle 101 and / or the occupants of vehicle 101.

[0063] In various embodiments, the vehicle safety and crash avoidance system 252 may include functions to perform safety inspections or supervision of various commands, various layers of planning or other decisions, and human driver actions that may affect the safety of the vehicle and occupants. In some embodiments, various safety parameters may be stored in memory, and the vehicle safety and crash avoidance system 252 may compare determined values ​​(e.g., relative distance to a nearby vehicle, distance from the road centerline, etc.) with the corresponding safety parameters and issue warnings or commands if the safety parameters are violated or will be violated. For example, the vehicle safety and crash avoidance system 252 may determine the current or future separation distance between its vehicle and another vehicle (e.g., based on an improved world model by the sensor fusion and RWM management layer 212), compare that separation distance with safety separation distance parameters stored in memory, and issue commands to the driver to accelerate, decelerate, or turn if the current or predicted separation distance violates the safety separation distance parameters. As another example, the vehicle safety and crash avoidance system 252 may compare human driver changes in steering wheel angle to a safety wheel angle limit or parameter and may issue override commands and / or warnings in response to steering wheel angles exceeding the safety wheel angle limit.

[0064] Figure 3 shows an exemplary SOC architecture of a processing device system-on-chip (SOC) 300 suitable for implementing various embodiments in a vehicle. Referring to Figures 1A to 3, the processing device SOC 300 may include several 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 may also include one or more coprocessors 310 (e.g., vector coprocessors) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, and 317. Each processor may include one or more cores and an independent / internal clock. Each processor / core may operate independently of the other processors / cores. For example, the processing device SOC300 may include a processor running a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor running a second type of operating system (e.g., Microsoft Windows). In some embodiments, the application processor 308 may be the main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. of the SOC300. The graphics processor 306 may be a graphics processing unit (GPU).

[0065] The processing device SOC300 may include analog and custom circuit configurations 314 for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations such as processing encoded audio and video signals for rendering in a web browser. The processing device SOC300 may further include system components and resources 316, such as a processor and software clients (e.g., a web browser) running on the computing device, including voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components.

[0066] The processing device SOC300 also includes a dedicated circuit configuration for a camera operation and management processor 305, which includes, provides, controls, and / or manages the operation of one or more cameras 158, 160 (e.g., primary camera, webcam, 3D camera, etc.), video display data from camera firmware, image processing, video preprocessing, video front-end (VFE), inline JPEG, high-definition video codecs, and more. The camera operation and management processor 305 may be an independent processing unit and / or may include an independent or internal clock.

[0067] In some embodiments, the image and object recognition processor 306 may be configured with processor-executable instructions and / or dedicated hardware configured to perform image processing and object recognition analysis involved in various embodiments. For example, the image and object recognition processor 306 may be configured to perform operations that process images received from cameras (e.g., 158, 160) via the camera operation and management processor 305 in order to perform, in a different way, the functions of the camera perception layer 204, such as recognizing and / or identifying and describing other vehicles. In some embodiments, the processor 306 may be configured to process radar data or lidar data and perform functions of the radar perception layer 202, such as describing.

[0068] The system components and resources 316, analog and custom circuit configurations 314, and / or the camera operation and management processor 305 may include circuit configurations for interfaced with peripheral devices such as cameras 158, 160, radar 168, lidar 170, electronic displays, wireless communication devices, and external memory chips. Processors 303, 304, 306, 307, and 308 may be interconnected to one or more memory elements 312, system components and resources 316, analog and custom circuit configurations 314, the camera operation and management processor 305, and the RPM processor 317 via an interconnect / bus module 324 which includes an array of reconfigurable logic gates and / or may implement a bus architecture (e.g., CoreConnect, AMBA). Communication may be provided by advanced interconnects, such as a high-performance network on chip (NoC).

[0069] The processing device SOC300 may further include input / output modules (not shown) for communicating with resources outside the SOC, such as a clock 318 and a voltage regulator 320. These external resources (e.g., clock 318, voltage regulator 320) may be shared by two or more of the internal SOC processors / cores (e.g., a DSP 303, a modem processor 304, a graphics processor 306, an application processor 308, etc.).

[0070] In some embodiments, the processing device SOC300 may be contained within a control unit (e.g., 140) for use in a vehicle (e.g., 101). The control unit may include communication links for communication with a telephone network (e.g., 180), the Internet, and / or a network server (e.g., 184), as described.

[0071] The processing device SOC300 may 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, touchscreen displays, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., location, direction, movement, orientation, vibration, pressure, etc.), cameras, compasses, GPS receivers, communication circuit configurations (e.g., Bluetooth®, WLAN, WiFi, etc.), and other well-known components of modern electronic devices.

[0072] Figure 4 is a block diagram of components showing a system 400 configured to generate a local dynamic map data model in various embodiments. In some embodiments, the system 400 may include one or more computing platforms 402 of V2X devices and / or one or more other V2X system participants 404. Referring to Figures 1A to 4 and Figures 7 to 9, the V2X device 402 may include processors (e.g., 434, 702, 802). The V2X device 402 may consist of machine-executable instructions 406. The machine-executable instructions 406 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of the following: an LDM data receiving module 408, an LDM data integration module 410, an LDM data determination module 412, an LDM data providing module 414, a map generation module 416, a map transmission module 418, and / or other instruction modules.

[0073] The LDM data receiving module 408 may be configured to receive fresh LDM data for a fraud management system running on the V2X device processor. In some embodiments, the LDM data receiving module 408 may be configured to receive registration messages from other V2X system participants 404. In some embodiments, the LDM data receiving module 408 may be configured to receive planned route information from other V2X system participants 404. In some embodiments, the LDM data receiving module 408 may be configured to receive mobile device kinematics information from other V2X system participants 404. In some embodiments, the LDM data receiving module 408 may be configured to receive data from other V2X system participants 404, such as sensor data, image data, audio data, or operational status data acquired by other V2X system participants 404.

[0074] The LDM data integration module 410 can be configured to integrate fresh LDM data into the LDM data model.

[0075] The LDM data determination module 412 may be configured to determine LDM data for an LDM data model related to another specific V2X system participant 404. In some embodiments, the LDM data determination module 412 may be configured to determine LDM data related to another specific V2X system participant 404 based on information contained in the registration message. In some embodiments, the LDM data determination module 412 may be configured to determine LDM data related to another specific V2X system participant based on planned route information. In some embodiments, the LDM data determination module 412 may be configured to determine LDM data related to another specific V2X system participant 404 based on kinematic information. In some embodiments, the LDM data determination module 412 may be configured to determine information related to LDM data from received data.

[0076] The LDM data provision module 414 may be configured to provide the determined relevant LDM data to other V2X system participants 404. In some embodiments, the determined relevant LDM data may include highly dynamic LDM information.

[0077] The map generation module 416 may be configured to generate a digital map that encompasses an area within a predetermined distance of other V2X system participants. In some embodiments, the map transmission module 418 may be configured to transmit the digital map to other V2X system participants 404. The digital map may be generated and transmitted in a format suitable for use in the autonomous navigation of the other V2X system participants 404.

[0078] In some implementations, the V2X device 402, other V2X system participant devices 404, and / or external resources 430 may be operationally linked via one or more electronic communication links. For example, such electronic communication links may be established at least partially via a network such as the Internet and / or other networks. It should be understood that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which the V2X device 402, other V2X system participants 404, and / or external resources 430 may be operationally linked via several other communication media.

[0079] Each of the other V2X system participants 404 may include one or more processors configured to run a computer program module. The computer program module may be configured to enable an expert or user associated with a given V2X system participant 404 to interface with system 400 and / or external resources 430, and / or to provide other functions attributed to the other V2X system participants 404 as herein.

[0080] External resources 430 may include sources of information outside of the V2X system 400, external entities participating in the V2X system 400, and / or other resources. In some implementations, some or all of the functions attributed to external resources 430 herein may be provided by resources included within the system 400.

[0081] The V2X device 402 may include an electronic storage device 432, one or more processors 434, and / or other components. The V2X device 402 may include communication lines or ports to enable the exchange of information with a network and / or other computing platform. The examples of the V2X device 402 in Figure 4 are not intended to be limiting. The V2X device 402 may include multiple hardware, software, and / or firmware components that work together to provide the functionality attributed to the V2X device 402 as described herein. For example, the V2X device 402 may be implemented by a cloud of a computing platform that operates the V2X device 402 together.

[0082] The electronic storage device 432 may include a non-temporary storage medium for electronically storing information. The electronic storage medium of the electronic storage device 432 may include one or both of the following: system storage integrated with the V2X device 402 (i.e., substantially inremovable), and / or removable storage that can be detachably connected to the V2X device 402 via, for example, a port (e.g., a Universal Serial Bus (USB) port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage device 432 may include one or more of the following: optically readable storage medium (e.g., optical discs, etc.), magnetically readable storage medium (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage medium (e.g., EEPROM, RAM, etc.), solid-state storage medium (e.g., flash drives, etc.), and / or other electronically readable storage mediums. The electronic storage device 432 may include one or more virtual memory resources (e.g., cloud storage, a virtual private network, and / or other virtual memory resources). The electronic storage device 432 may store software algorithms, information determined by the processor 434, information received from the V2X device 402, information received from other V2X system participants 404, and / or other information that enables the V2X device 402 to function as described herein.

[0083] The processor 434 may be configured to provide information processing capabilities within the V2X device 402. Thus, the processor 434 may include one or more of the following: a digital processor, an analog processor, digital circuits designed to process information, analog circuits designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor 434 is shown as a single entity in Figure 4, this is for illustrative purposes only. In some implementations, the processor 434 may include multiple processing units. These processing units may be physically located within the same device, or the processor 434 may represent the processing capabilities of multiple devices working together. The processor 434 may be configured to run modules 408, 410, 412, 414, 416, 418, and / or other modules. Processor 434 may be configured to execute modules 408, 410, 412, 414, 416, 418, and / or other modules by software, hardware, firmware, or some combination of software, hardware, and / or firmware, and / or other mechanisms for configuring the processing capabilities on processor 434. As used herein, the term “module” may refer to any component or set of components that perform the function attributable to the module. This may include one or more physical processors executing processor-readable instructions, processor-readable instructions, circuit configurations, hardware, storage media, or any other components.

[0084] While modules 408-418 are shown in Figure 4 as being implemented within a single processing unit, please note that in implementations where the processor 434 includes multiple processing units, one or more of modules 408-418 may be implemented remotely from other modules. The descriptions of the functions provided by the various modules 408-418 below are illustrative and not intended to be limiting, as any of modules 408-418 may provide more or fewer functions than those described. For example, one or more of modules 408-418 may be excluded, and some or all of their functions may be provided by others within the same module. As another example, the processor 434 may be configured to run one or more additional modules that may perform some or all of the functions attributed to one of the following modules 408-418.

[0085] Figure 5 is a process flow diagram illustrating the operation of Method 500, which is performed by the processor of the observation vehicle's V2X instrument to detect a misconduct condition by comparing the received V2X message with the vehicle's local dynamic map (LDM) data model and determining whether there is an inconsistency between the data received in the V2X message and the locally maintained or stored LDM data model. Referring to Figures 1 to 5, the operation of Method 500 may be performed by the processor of the observation vehicle's V2X instrument (for example, vehicle 12 in Figure 1D).

[0086] In block 502, the processor may monitor several vehicle sensors related to the control of the observation vehicle's (e.g., vehicle 12) steering, navigation, and / or other operations. By monitoring data from the vehicle's own sensors, the fraud management system running on the observation vehicle's V2X instrument 402 may begin collecting data that can be used to generate an LDM data model representing the environment surrounding the observation vehicle. This may include information about suspicious vehicles sending V2X messages with data indicating fraudulent activity. In addition, the LDM data model may include information about neighboring vehicles.

[0087] In block 504, an LDM data model representing the environment surrounding the observation vehicle may be generated by the V2X instrument 402, at least in part, based on the aggregation of additional data collected from multiple sensors, as described above with respect to Figures 2A to 4. The LDM data model may include type 1 to 4 data. In block 506, the generated LDM data model may be maintained or stored locally in memory (e.g., electronic storage device 432).

[0088] In block 508, the fraud management system operating on the V2X device processor may receive a V2X message from another V2X system participant 404. The V2X message may include traffic information, GPS information of the reporting vehicle and other adjacent vehicles calculated from the reporting vehicle's onboard equipment and / or provided by the adjacent vehicle itself, and / or map data specifying road geometry and street fixtures.

[0089] In decision block 510, in a V2X message, the fraud management system operating on the V2X device processor may determine whether the received V2X message contains data indicating a fraudulent state by comparing the data contained in the received V2X message with a locally maintained or stored LDM data model in order to detect a fraudulent state. For example, the vehicle (referred to as the observation vehicle) may receive a V2X message containing data indicating that another vehicle (referred to as the reporting vehicle) may be passing between two adjacent vehicles. In some embodiments, the reporting vehicle and the two adjacent vehicles may all be V2X system participants. However, in some situations, neither the reporting vehicle nor the two adjacent vehicles are V2X system participants. In other situations, the reporting vehicle and some of the two adjacent vehicles may be V2X system participants, while others are not.

[0090] In this example, the observation vehicle can acquire information about the location / position, direction of travel, speed, and operation of the reporting vehicle and the two adjacent vehicles through its own sensors, such as a camera and a LiDAR installed on the vehicle. In addition, the observation vehicle can receive V2X messages from any and / or all of the reporting vehicle and the two adjacent vehicles. Such received V2X messages may include camera and / or LiDAR information that confirms the observation vehicle's observations regarding the location / position, direction of travel, speed, and operation of the reporting vehicle and the two adjacent vehicles. In addition, V2X messages from the reporting vehicle or either of the two adjacent vehicles may include GPS location / position information, speedometer data, etc. Further camera and LiDAR information about the reporting vehicle or either of the two adjacent vehicles may be received from RSU V2X system participants.

[0091] Any or all of this data received within various V2X messages can supplement a locally maintained LDM data model created by the observation vehicle to represent the environment surrounding the observation vehicle. Therefore, the observation vehicle's LDM data model may include data regarding the location / position, direction of travel, and speed of the reporting vehicle and two adjacent vehicles. The observation vehicle can detect infringement conditions by comparing the data contained in the received V2X messages with the data in the observation vehicle's LDM data model. For example, a V2X message received from a reporting vehicle might indicate that the reporting vehicle is passing between two adjacent vehicles. However, based on all other information collected by the observation vehicle, the observation vehicle's LDM data model might indicate that there is insufficient space for the reporting vehicle to pass between the two adjacent vehicles. Thus, the infringement management system running on the observation vehicle's V2X instrument processor may identify the V2X message received from the reporting vehicle as containing or evidence of infringement conditions. Any of the data received from the reporting vehicle within a V2X message, such as location / position, speed, or direction of travel, may be inaccurate, corrupted, or deliberately altered.

[0092] Based on the comparison in block 510, in response to the determination that the V2X message received from the reporting vehicle contains data indicating a misbehavior condition (i.e., determination 510 = Yes), the misbehavior management system operating in the observation vehicle's V2X instrument 402 may generate a misbehavior report (MBR) in block 512 that identifies the misbehavior condition and the suspected vehicle that sent the V2X message.

[0093] In block 514, the misbehavior management system operating within the observation vehicle's V2X instrument 402 may transmit an MBR to the misbehavior managing authority (MA) for further analysis, reporting, and corrective action. For example, the MA may send a message to a suspected vehicle indicating that its sensors require servicing or replacement. To perform an accurate and comprehensive analysis of the misbehavior condition, the MA may utilize data within the LDM data model so that a holistic analysis of the circumstances giving rise to the misbehavior condition can be determined. In addition, by analyzing the data within the LDM data model, more appropriate and efficient corrective actions can be taken to mitigate the misbehavior condition. To enable this, several embodiments include a misbehavior management system that provides better quality misbehavior detection (e.g., providing fewer false negative detections) and improves the robustness and resilience of the V2X system 103.

[0094] However, as more and more vehicles are equipped with V2X devices, the amount of cheating that can be detected is increasing exponentially. In addition, given the bandwidth limitations for transmitting a large number of MBRs, the amount of data that can be contained in an MBR can be extremely large. To address this, and to reduce the amount of data that can be transmitted with an MBR, in some embodiments, the cheating management system may transmit only a representation of the LDM data model to the MA. In some embodiments, when the cheating management system transmits an MBR to the MA, it may transmit an incomplete dataset for the LDM data model, such as including only the data most relevant to the detected cheating condition and / or excluding data irrelevant to the cheating condition.

[0095] In block 514, after transmitting the MBR to the MA, the tampering management system operating within the observation vehicle's V2X instrument 402 may repeat the operation in block 502 to continue monitoring the observation vehicle's sensors in order to collect data about the environment surrounding the observation vehicle.

[0096] In response to a decision that the data contained in the received V2X message does not indicate a cheating condition (i.e., decision 510 = No), the cheating management system may perform calculations based on at least one of the observed dynamics of an object in the LDM data model or new data inputs received from the V2X message, and then, in block 516, modify the LDM data model to incorporate the calculations and the data based on and contained in the received V2X message in order to augment, improve, or otherwise update the LDM data model of the observation vehicle, and then, in block 506, store the updated LDM data. Thus, the cheating management system operating in the observation vehicle's V2X instrument 402 can continuously improve the LDM data model. The updated LDM data model may include additional data from the V2X message that improves and / or improves the LDM data model representing the environment surrounding the observation vehicle. The updated LDM data model may be maintained or stored locally in memory in block 506.

[0097] Following the transmission of the MBR to the MA in block 514, or the storage of the updated LDM data model in block 506, the tampering control system operating within the observation vehicle's V2X instrument 402 may continue to receive other V2X messages in block 508, as described.

[0098] In some embodiments, the fraud management system operating within the observation vehicle's V2X instrument 402 may also periodically perform operations in block 502 to continuously monitor the observation vehicle's sensors to collect data about the environment surrounding the observation vehicle. In this way, the universe of data representing the environment surrounding the observation vehicle can be continuously expanded to improve and update the LDM so that fraud conditions can be detected more accurately.

[0099] Figure 6 is a process flow diagram illustrating exemplary operation that may be performed as part of block 510 of method 500, which determines whether a fraudulent condition is detected in an received V2X message. Referring to Figures 1A to 6, the operation of block 510 may be performed by a fraudulent management system operating within the V2X equipment 402 of the observation vehicle.

[0100] After receiving a V2X message in block 508 of method 500, the fraud control system may, in block 518, retrieve selected data (e.g., location / position, speed, direction of travel, temperature, etc.) from the received V2X message. As part of the operation in block 518, the identifier of the originating transmitter of the received V2X message may be retrieved.

[0101] In any block 519, the fraud management system may select data elements, or data elements within the LDM data model, to use in determining whether the information reported in the V2X message indicates or is a product of fraud. As described, the LDM data model will contain numerous data elements that define the environment surrounding the vehicle and other vehicles in the vicinity, and these numerous elements may be useful in assessing the accuracy or reliability of the information received in the V2X message. Thus, in some embodiments, the fraud management system may select several data elements (e.g., a subset of information) within the LDM data model that will be used to verify or confirm the received V2X message. In some embodiments, the fraud management system may select information or elements within the LDM data model based on or in response to the type of information in the received V2X message. For example, if a V2X message contains location information about another vehicle, a road hazard, or a situation ahead of the vehicle, the fraud control system may select location-related data elements within the LDM data model for use when reviewing the V2X message, avoiding access to data elements related to speed, weather conditions, road conditions, or location behind the vehicle. As another example, if a V2X message contains dynamic information about another vehicle (e.g., turning angle, speed, braking status), static or outdated data elements within the LDM data model would be unhelpful when evaluating the V2X message. By selecting and accessing a subset of information within the LDM data model relevant to reviewing or verifying information in an received V2X message, the fraud control system may conserve processing resources and memory utilization, enabling it to evaluate the message faster than if all data in the LDM data model were used in the message evaluation process.

[0102] In block 520, the fraud control system operating within the observation vehicle's V2X instrument may compare the parsed data contained in the received V2X message with data in an LDM data model maintained or stored in the observation vehicle's memory (e.g., storage device 432).

[0103] In decision block 522, the fraud management system may determine whether any of the parsed data contained in the received V2X message is inconsistent with or inconsistent with data in the LDM data model maintained or stored in the observation vehicle's memory (e.g., storage device 432).

[0104] For example, in decision block 522, the fraud management system may analyze the location information of the vehicle issuing the received V2X message in order to determine whether the information reported in the V2X message is inconsistent with or contradicts the location information in the LDM data model (for example, indicating a location corresponding to the location of another vehicle in the LDM).

[0105] Another example of a possible infringement condition that can be detected using LDM data in decision block 522 is that the observation vehicle may be tracking an adjacent vehicle through its sensors. The adjacent vehicle may not be a V2X system participant. The suspicious vehicle may send a V2X message to the observation vehicle implying that it is located at a location that overlaps with the location of the tracked adjacent vehicle, as observed and determined by the observation vehicle's sensors. In other words, the suspicious vehicle may send a V2X message to the observation vehicle implying that the location of the suspicious vehicle coincides with the location of the tracked adjacent vehicle, as observed and determined by the observation vehicle's sensors (e.g., cameras). In such a case, the V2X message received by the observation vehicle from the suspicious vehicle contains data that is inconsistent or unrelated to the data in the observation vehicle's LDM data model. Thus, the observation vehicle may generate an MBR indicating the infringement condition of the suspicious vehicle.

[0106] Another example of a possible misconduct condition that can be detected using LDM data in decision block 522 is an obstacle in the road. For example, a sofa being transported may fall off a flatbed truck. The observation vehicle may detect the obstacle through its sensors. The observation vehicle may receive a V2X message from the suspected vehicle that implies the suspected vehicle maintained its direction and speed, as if it had driven over the obstacle without slowing down. In such a case, the V2X message received by the observation vehicle from the suspected vehicle contains data that is inconsistent with or contradicts the data in the observation vehicle's LDM data model. Therefore, the observation vehicle may generate an MBR indicating a misconduct condition of the suspected vehicle.

[0107] Another example of a possible infidelity condition that can be detected using LDM data in decision block 522 is that the observation vehicle may be tracking an adjacent vehicle through its sensors. The adjacent vehicle may not be a V2X system participant. The view of the adjacent vehicle may be temporarily obstructed from the observation side (i.e., something obstructs it for a short time so that the observation vehicle cannot directly see the AV), and then become trackable again. During the time of the obstruction, the suspicious vehicle may send a V2X message to the observation vehicle about the direction of travel (i.e., track) of the suspicious vehicle. The observation vehicle may reconstruct the possible route the adjacent vehicle may have taken while it was out of sight. Based on this information, the observation vehicle may realize that all possible routes imply a collision between the suspicious vehicle and the adjacent vehicle. Since the collision was not recorded by the observation vehicle, the V2X message received by the observation vehicle from the suspicious vehicle contains data that is inconsistent or contradictory with the data in the observation vehicle's LDM data model. Therefore, the observation vehicle may generate an MBR indicating the fraudulent status of the suspicious vehicle.

[0108] Another example of a possible misconduct condition that can be detected using LDM data in decision block 522 is that the observation vehicle may receive a V2X traffic signal message from the RSU indicating that the traffic signal light is red. The observation vehicle may also receive a V2X message from the suspected vehicle indicating that the suspected vehicle is moving through an intersection. While the suspected vehicle may actually be driving through a red light, the V2X message received by the observation vehicle from the suspected vehicle will, at first glance, contain data that is inconsistent with or inconsistent with the data in the observation vehicle's LDM data model. Therefore, the observation vehicle may generate an MBR indicating a misconduct condition of the suspected vehicle.

[0109] Another example of a possible infringing condition that can be detected using LDM data in decision block 522 is when the observation vehicle receives a V2X message from the RSU indicating that road construction is causing a lane change. The lane change is not shown in the static map available to the observation vehicle. However, based on the incoming V2X message, the observation vehicle notices that all adjacent vehicles behave as if a lane change were in place, i.e., all adjacent vehicles change one lane to the left at a particular location. The suspicious vehicle may send a V2X message implying that the suspicious vehicle does not observe the lane change, i.e., that it appears to be driving straight even though it should be visible to the driver that other adjacent vehicles are performing lane changes. This implied message is that the suspicious vehicle has that message, which was remotely generated from the actual location by an attacker who is unaware of the lane change. In such a case, the V2X message received by the observation vehicle from the suspicious vehicle contains data that is inconsistent or contradictory with the data in the observation vehicle's LDM data model. Therefore, the observation vehicle may generate an MBR indicating the fraudulent status of the suspicious vehicle.

[0110] In response to a determination (i.e., determination 522 = Yes) that the parsed data contained in the received V2X message is inconsistent with or inconsistent with the data in the LDM data model maintained or stored in the observation vehicle's memory (e.g., storage device 432), the fraud control system operating in the observation vehicle's V2X instrument 402 may perform the operation in block 512 of method 500 to generate the MBR, as described.

[0111] In response to a determination (i.e., determination 522 = No) that the parsed data contained in the received V2X message is consistent with or inconsistent with the data in the LDM data model maintained or stored in the observation vehicle's memory (e.g., storage device 432), the fraud control system operating in the observation vehicle's V2X instrument 402 may perform the actions in block 516 to modify or update the LDM data model, as described.

[0112] Various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1A to 6) may be implemented in a wide variety of computing systems, including in-vehicle equipment and mobile computing devices, and an example of a mobile computing device suitable for use with various embodiments is shown in Figure 7. The mobile computing device 700 may include a processor 702 coupled to a touchscreen controller 704 and internal memory 706. The processor 702 may be one or more multi-core integrated circuits designated for general-purpose or specific processing tasks. The internal memory 706 may be volatile memory or non-volatile memory, and may also be secure memory and / or encrypted memory or non-secure memory and / or unencrypted memory, or any combination thereof. Examples of memory types that may be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 704 and processor 702 may also be coupled to the touchscreen panel 712, such as a resistive touchscreen, a capacitive touchscreen, or an infrared touchscreen. Additionally, the display of the mobile computing device 700 does not need to have touchscreen functionality.

[0113] The mobile computing device 700 may have one or more radio signal transceivers 708 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) for transmitting and receiving communications, coupled to each other and / or to the processor 702, and an antenna 710. The transceivers 708 and antenna 710 may be used in conjunction with the circuit configuration described above to implement various wireless transmission protocol stacks and interfaces. The mobile computing device 700 may include a cellular network wireless modem chip 716 that enables communication over a cellular network and is coupled to the processor.

[0114] The mobile computing device 700 may include a peripheral device connectivity interface 718 coupled to the processor 702. The peripheral device connectivity interface 718 may be configured to accept one type of connection on its own, or it may be configured to accept various common or proprietary types of physical and communication connections, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connectivity interface 718 may also be coupled to a similarly configured peripheral device connectivity port (not shown).

[0115] The mobile computing device 700 may also include a speaker 714 for providing audio output. The mobile computing device 700 may also include a housing 720 made of plastic, metal, or a combination of materials for housing all or some of the components described herein. Those skilled in the art will recognize that the housing 720 may be the dashboard console of a vehicle in an in-vehicle embodiment. The mobile computing device 700 may include a power supply 722 coupled to the processor 702, such as a disposable battery or a rechargeable battery. The rechargeable battery may also be coupled to a peripheral device connection port to receive charging current from an external source to the mobile computing device 700. The mobile computing device 700 may also include a physical button 724 for receiving user input. The mobile computing device 700 may also include a power button 726 for turning the mobile computing device 700 on and off.

[0116] Various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1A to 6) may be implemented in a wide variety of computing systems, including a laptop computer 800, an example of which is shown in Figure 8. Many laptop computers include a touch surface 817 of a touchpad that acts as the computer's pointing device and can therefore receive drag, scroll, and flick gestures similar to those implemented on the aforementioned computing devices equipped with touchscreen displays. The laptop computer 800 typically includes a processor 802 coupled with volatile memory 812 and large-capacity non-volatile memory such as a flash memory disk drive 813. In addition, the computer 800 may have one or more antennas 808 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or cellular telephone transceiver 816 coupled to the processor 802. The computer 800 may also include a floppy disk drive 814 and a compact disk (CD) drive 815 coupled to the processor 802. In a notebook configuration, the computer housing includes a touchpad 817, a keyboard 818, and a display 819, all coupled to the processor 802. Other configurations of the computing device, as is well known, may include a computer mouse or trackball coupled to the processor (for example, via a USB input), which may also be used in conjunction with various embodiments.

[0117] Various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1A to 6) may also include fraud control organizations that utilize a fixed computing system, such as one of various commercially available servers. An exemplary server 900 is shown in Figure 9. Such a server 900 typically includes one or more multicore processor assemblies 901 coupled to volatile memory 902 and large-capacity non-volatile memory such as disk drives 904. As shown in Figure 9, the multicore processor assemblies 901 may be added to the server 900 by inserting them into a rack of assemblies. The server 900 may also include network access ports 907 coupled to the multicore processor assembly 901 for establishing network interface connections with networks 908, such as local area networks, the Internet, public switched telephone networks, and / or cellular data networks (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular data network), coupled to other broadcast system computers and servers.

[0118] Several different cellular and mobile communication services and standards are available or planned for the future, all of which implement and benefit from various embodiments. Such services and standards include the Third Generation Partnership Project (3GPP®), Long-Term Evolution (LTE) systems, Third Generation Wireless Mobile Communication Technology (3G), Fourth Generation Wireless Mobile Communication Technology (4G), Fifth Generation Wireless Mobile Communication Technology (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General-Purpose Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (cdmaOne, CDMA1020®, etc.), GSM Evolutionary High-Speed ​​Data Rate (EDGE), Advanced Mobile Phone Systems (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), and Digital Enhanced Cordless Telecommunications (DECT). This includes telecommunications, worldwide interoperability for microwave access (WiMAX), wireless local area networks (WLAN), Wi-Fi protected access I & II (WPA, WPA2), and integrated digital extension networks (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. Any references to terms and / or technical details relating to individual telecommunications standards or technologies are for illustrative purposes only and should not be understood as limiting the claims to any particular communication system or technology unless specifically stated in the language of the claims.

[0119] Examples of implementations are described in the following paragraphs. Some of the following examples of implementations are described in terms of exemplary methods, but further exemplary implementations may include exemplary methods described in the following paragraphs, implemented by a fraud management system running on a V2X device processor which may be an in-vehicle unit, a mobile device unit, a mobile computing unit, or a fixed roadside unit, and which includes a processor configured with processor-executable instructions for performing the operations of the methods of the following implementations; exemplary methods described in the following paragraphs, implemented by a V2X device which includes means for performing the functions of the methods of the following implementations; and exemplary methods described in the following paragraphs, implemented as a non-temporary processor-readable storage medium storing processor-executable instructions configured to cause the processor of the V2X device to perform the operations of the methods of the following implementations.

[0120] Example 1. A method for detecting a cheating condition in a vehicle-to-everything (V2X) system executed by a vehicle processor, comprising: receiving a V2X message from another V2X system participant, wherein the V2X message contains data relating to the environment surrounding the vehicle; comparing the data contained in the received V2X message with a locally maintained or stored local dynamic map (LDM) data model in order to detect a cheating condition; generating a cheating report that identifies the cheating condition in response to the detection of the cheating condition based on the comparison; and transmitting the generated cheating report to a cheating control body.

[0121] Example 2. The method of Example 1, further comprising the steps of monitoring multiple sensors within a vehicle to collect additional data about the environment surrounding the vehicle, generating an LDM data model representing the environment surrounding the vehicle based at least in part on the aggregation of the additional data collected from the multiple sensors, and storing the LDM data model in memory.

[0122] Example 3. Any method of Example 1 or 2, further comprising the steps of: performing a calculation based on at least one of the observed dynamics of an object in the LDM data model or a new data input received from a V2X message, in response to a decision that no fraudulent activity has been detected; modifying the LDM data model to incorporate the calculation and the data contained in the received V2X message; and replacing the LDM data model maintained or stored locally in memory with the modified LDM model.

[0123] Example 4. Any method from Examples 1 to 3, wherein the step of sending a generated fraud report to a fraud control body includes the step of sending a representation of the LDM data model.

[0124] Example 5. The method of Example 4, where the representation of the LDM data model includes an incomplete dataset for the LDM data model.

[0125] Example 6. Any method of Examples 1 to 5, further comprising the step of receiving feedback from a fraud control body, wherein the feedback includes corrective actions to mitigate the fraudulent condition.

[0126] Example 7. Data about the vehicle's surrounding environment included in the received V2X message, including traffic information, using any of the methods described in Examples 1 through 6.

[0127] Example 8. The data about the environment surrounding the vehicle included in the received V2X message includes location information of adjacent vehicles based on GNSS (e.g., GPS) data, using any of the methods in Examples 1 to 7.

[0128] Example 9. The data about the vehicle's surrounding environment included in the received V2X message includes map data specifying road geometry and street fixtures, using any of the methods in Examples 1 through 8.

[0129] Example 10. Any method of Examples 1 to 9, wherein the step of comparing data contained in an received V2X message with a locally maintained or stored LDM data model in order to detect a fraudulent condition includes the step of determining whether any data contained in the received V2X message is inconsistent with information in the locally maintained or stored LDM data model.

[0130] Example 11. Any method from Examples 1 to 10, wherein the step of comparing data contained in an received V2X message with a locally maintained or stored LDM data model in order to detect a fraudulent state includes the steps of selecting a subset of data elements in the locally maintained or stored LDM data model for comparison with the data contained in the received V2X message, and determining whether any of the data contained in the received V2X message is inconsistent with the selected subset of data elements in the locally maintained or stored LDM data model.

[0131] Example 12. Any method from Examples 1 to 11, wherein the step of comparing data contained in an received V2X message with a locally maintained or stored LDM data model in order to detect fraudulent activity includes determining whether the location of a first adjacent vehicle contained in the received V2X message matches the location of a second adjacent vehicle in the locally maintained or stored LDM data model.

[0132] Example 13. Any method of Examples 1 to 12, wherein the step of comparing data contained in the received V2X message with the locally maintained or stored LDM data model in order to detect fraudulent activity includes determining whether the status information of the adjacent vehicle that sent the received V2X message is inconsistent with the status information of the adjacent vehicle in the locally maintained or stored LDM data model.

[0133] The various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the embodiment in question, but may be used in conjunction with or in combination with other embodiments shown and described. Furthermore, the claims shall not be limited by any one exemplary embodiment.

[0134] The above-described method and process flow diagram are provided only as illustrative examples and do not require or imply that the operations of the various embodiments must be performed in the order presented. As will be understood by those skilled in the art, the order of operations in the above-described embodiments may be performed in any order. Words such as “then,” “next,” and “then” do not limit the order of operations and are used to guide the reader throughout the description of the method. Furthermore, any reference to a claim element in the singular form using, for example, the articles “a,” “an,” or “the” should not be interpreted as limiting the element to the singular form.

[0135] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in relation to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly demonstrate this hardware- and software compatibility, the various exemplary components, blocks, modules, circuits, and operations have generally been described above in terms of their functions. Whether such functions are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functions in various ways for each specific application, but the determination of such embodiments should not be construed as resulting in a departure from the claims.

[0136] The hardware used to implement the various exemplary logics, logic blocks, modules, and circuits described in relation to the embodiments disclosed herein may be implemented or run using general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver smart objects, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuit configurations specific to a given function.

[0137] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-temporary computer-readable storage medium or a non-temporary processor-readable storage medium. The operation of the methods or algorithms disclosed herein may be embodied in processor-executable software modules or processor-executable instructions that may reside on a non-temporary computer-readable or processor-readable storage medium. A non-temporary computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. Such non-temporary computer-readable or processor-readable storage medium may include, but are not limited to, RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and may be accessed by a computer. The terms "disk" and "disc" as used herein include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy disks, and Blu-ray® discs, where a disk typically reproduces data magnetically, and a disc reproduces data optically using a laser. The above combinations also fall within the scope of non-temporary computer-readable media and non-temporary processor-readable media. Furthermore, the operation of a method or algorithm may exist as one or any combination or set of codes and / or instructions on a non-temporary processor-readable storage medium and / or non-temporary computer-readable storage medium that can be incorporated within a computer program product.

[0138] The foregoing description of the embodiments disclosed is provided to enable any person skilled in the art to construct or use the claims. Various modifications to these embodiments will be readily apparent to a person skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the claims. Accordingly, this disclosure is not intended to be limited to the embodiments shown herein, but should be given the broadest scope that corresponds to the following claims and the principles and novel features disclosed herein. [Explanation of symbols]

[0139] 12 vehicles, following vehicles 14 vehicles, trucks 16 vehicles, preceding vehicle 18. Communication Networks 20 Safe separation distance 30, 40, 50 Basic Safety Messages 60, 62, 64, 66 Communication Links 70, 72 Original Equipment Manufacturers (OEMs), OEM Servers, MBR Preprocessing Servers 74. Fraud Control Agency 100 Communication Systems 101 vehicles 102, 104 V2X in-vehicle equipment, V2X equipment, vehicle V2X in-vehicle equipment 103 V2X System 106 V2X In-Vehicle Equipment, Vehicle V2X In-Vehicle Equipment 110 base station 120 Wireless Communication Devices 122 Communication links, wireless communication links 124, 126 Wireless communication links 132 Core Network 140 Control Unit, Vehicle Control Unit 140a, 434, 702, 802 processors 140b memory 140c Input Module 140d Output Module 140e Wireless Module 142 Satellite geographic positioning system receivers, satellite geographic positioning sensors 144, 146, 148, 150, 152 Occupancy Sensors 144-170 sensors 145 Control Input Sensor 154, 156 Tire pressure sensor 158, 160 Camera 162, 164 microphones 166 Impact Sensor 168 Radar 170 Rider 172a Operation control components, operation control elements 172b Navigation components, navigation units 172c sensor, vehicle sensor 200 Fraudulent Activity Management Systems, Vehicle Management Systems, Fraudulent Activity Management System Stacks, Autonomous Vehicle System Stacks 202 Radar perception layer, layer 204 Camera Perception Layer, Layer 206 Positioning Engine Layer, Layer 208 Map Fusion and Arbitration Layer, Layer 210 Route Planning Layer, Layer 212 Sensor Fusion and Road World Model (RWM) Management Layer, Layer, Sensor Fusion and RWM Management Layer 214 Operation planning and control layer, layer 216 Behavior planning and prediction layer, layer 220 Drive-by-Wire (DBW) System / Control Unit, DBW System / Control Unit 230 Vehicle Wireless Communication Subsystem, Wireless Communication Subsystem 250 Vehicle Management Systems, Fraudulent Activity Management System Stack 252 Vehicle safety and crash avoidance systems 300 Processing device system-on-chip (SOC), processing device SOC, SOC 303 Digital signal processor (DSP), heterogeneous processor, processor, DSP 304 Modem processor, heterogeneous processor, processor 305 Camera Operation and Management Processor 306 Image and object recognition processors, heterogeneous processors, graphics processors, processors 307 Mobile display processor, heterogeneous processor, processor 308 Application processors, heterogeneous processors, processors 310 coprocessors 312 memory elements 314 Analog circuit configurations and custom circuit configurations, analog and custom circuit configurations 316 System Components and Resources 317 Resource and Power Management (RPM) processors, heterogeneous processors, RPM processors 318 Clock 320 Voltage Regulator 324 Interconnection / Bus Modules 400 System, V2X System 402 Computing Platforms, V2X Equipment 404 Other V2X system participants, other specific V2X system participants, another specific V2X system participant, other V2X system participant devices, given V2X system participant, another V2X system participant 406 Machine-Executable Instructions 408 LDM data receiving module, module 410 LDM Data Integration Module, Module 412 LDM Data Determination Module, Module 414 LDM data provision module, module 416 Map generation module, module 418 Map transmission module, module 430 External Resources 432 Memory, electronic storage devices, storage devices 700 Mobile Computing Devices 704 Touchscreen Controller 706 internal memory 708 Wireless signal transceiver, transceiver 710, 808 antennas 712 Touchscreen Panel 714 Speakers 716 Cellular Network Wireless Modem Chip 718 Peripheral device connection interface 720 Housing 722 Power supply 724 Physical Buttons 726 Power button 800 Laptop Computers, Computers 812, 902 volatile memory 813, 904 disk drives 814 Floppy disk drive 815 Compact Disc (CD) Drive 816 Wireless Data Link and / or Cellular Telephone Transceiver 817 Touch surface of the touchpad, touchpad 818 keyboard 819 displays 900 servers 901 Multicore Processor Assembly 907 Network access port 908 Network

Claims

1. A method for detecting an inappropriate behavior condition in a vehicle-to-everything (V2X) system executed by the vehicle's processor, A step of receiving a V2X message from another V2X system participant, wherein the V2X message includes data relating to the environment surrounding the vehicle. Steps to detect fraudulent activity include comparing data contained in the received V2X message with a locally maintained or stored local dynamic map (LDM) data model, wherein the LDM data model is constructed by the vehicle's processor based at least on data relating to the environment surrounding the vehicle; A step of generating a fraud report that identifies a fraudulent activity in response to the detection of the fraudulent activity based on the comparison, wherein the fraudulent activity report includes a representation of the LDM data model. The steps include sending the generated fraud report to the fraud control body and A method that includes this.

2. The steps include monitoring multiple sensors within the vehicle in order to collect additional data regarding the environment surrounding the vehicle, The steps include generating the LDM data model representing the environment surrounding the vehicle, based at least in part on the aggregation of the additional data collected from the plurality of sensors, The steps include storing the LDM data model in memory and The method according to claim 1, further comprising:

3. In response to the decision that no misconduct was detected, The steps include performing calculations based on at least one of the observed dynamics of an object in the LDM data model or new data inputs received from the V2X message, The steps include modifying the LDM data model to incorporate the calculations and the data contained in the received V2X message, The steps include replacing the LDM data model maintained or stored in memory with the modified LDM data model. The method according to claim 1, further comprising:

4. The method according to claim 1, wherein the representation of the LDM data model includes an incomplete dataset for the LDM data model.

5. The method according to claim 1, further comprising the step of receiving feedback from the fraud control body, wherein the feedback includes corrective actions to mitigate the fraudulent condition.

6. The method according to claim 1, wherein the data relating to the environment surrounding the vehicle included in the received V2X message includes traffic information.

7. The method according to claim 1, wherein the data relating to the environment surrounding the vehicle included in the received V2X message includes location information of adjacent vehicles based on global navigation satellite system data.

8. The method according to claim 1, wherein the data relating to the environment surrounding the vehicle included in the received V2X message includes map data specifying road geometry and street fixtures.

9. The method according to claim 1, wherein the step of comparing data contained in the received V2X message with a locally maintained or stored LDM data model in order to detect fraudulent activity includes determining whether any of the data contained in the received V2X message is inconsistent with information in the locally maintained or stored LDM data model.

10. To detect fraudulent activity, the process involves comparing the data contained in the received V2X message with the locally maintained or stored LDM data model. The steps include selecting a subset of data elements in the locally maintained or stored LDM data model for comparison with the data contained in the received V2X message, The steps include determining whether any of the data contained in the received V2X message is inconsistent with the selected subset of data elements in the locally maintained or stored LDM data model. The method according to claim 1, including the method described in claim 1.

11. The method according to claim 1, wherein the step of comparing data contained in the received V2X message with a locally maintained or stored LDM data model in order to detect fraudulent activity includes determining whether the status or location information of the adjacent vehicle that sent the received V2X message is inconsistent with the status or location information of the adjacent vehicle in the locally maintained or stored LDM data model.

12. A vehicle-to-everything (V2X) processing device, A processor is provided, and the processor is Receiving a V2X message from another V2X system participant, wherein the V2X message includes data relating to the environment surrounding the vehicle on which the V2X processing device is installed. To detect fraudulent activity, the system compares the data contained in the received V2X message with a locally maintained or stored local dynamic map (LDM) data model, wherein the LDM data model is constructed by the processor based on at least data relating to the environment surrounding the vehicle. Based on the above comparison, in response to the detection of the fraudulent activity status, generate a fraudulent activity report that identifies the fraudulent activity status, wherein the fraudulent activity report includes a representation of the LDM data model, and Send the generated fraud report to the fraud control body. A V2X processing device consisting of processor-executable instructions for performing the following.

13. The V2X processing device according to claim 12, further configured to perform the method described in any one of claims 2 to 11.

14. A non-temporary computer-readable recording medium storing processor-executable instructions configured to cause the processor of a V2X device to perform the method according to any one of claims 1 to 11.

Images