Detecting Misbehavior Conditions in Vehicle-to-Everything (V2X) Messages

Abstract

Disclosed are embodiments that include systems and methods performed by vehicle-to-everything (V2X) system participants to determine whether a misbehavior condition may have occurred based on generation and / or reception of V2X messages. Detection of a misbehavior condition may occur when V2X messages are generated and / or received too frequently or not frequently enough. Additionally, a misbehavior condition may be detected if the generated and / or received V2X messages include proper security credentials.

Description

[Technical field]

[0001] Related Applications

[0001] This application claims the benefit of priority to U.S. Non-provisional Application No. 17 / 213,049, filed March 25, 2021, the entire contents of which are incorporated herein by reference. [Background technology]

[0002]

[0002] Intelligent Transportation Systems (ITS) aim to provide services related to different modes of transportation and traffic management, to enable users to be better informed, and to make a safer, more coordinated and "smarter" use of transportation networks. These transportation networks include advanced telematics and hybrid communications, including Internet Protocol (IP)-based communications, as well as ad-hoc direct communications between vehicles and between vehicles and infrastructure. The evolving Cooperative ITS (C-ITS) aims to improve road safety and pave the way for the realization of fully autonomous driving, based on the exchange of information via direct wireless short-range communications dedicated to C-ITS and Road Transport and Traffic Telematics (RTTT). A key ITS element, called Vehicle-to-Everything (V2X), covers not only vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, but also vehicle-to-pedestrian (V2P) and vehicle-to-network (V2N) communications.

[0003]

[0003] Several regions of the world are developing standards for vehicle-based communication systems and functions. For example, standards are being developed at the Institute of Electrical and Electronics Engineers (IEEE) and the Society of Automotive Engineers (SAE) for use in North America, or at the European Telecommunications Standards Institute (ETSI) and the European Committee for Standardization (CEN) for use in Europe. Part of the system is the ability for vehicles to broadcast Basic Safety Messages (BSM) in North America, or Cooperative Awareness Messages (CAM) in Europe, which other vehicles can receive and process to improve road safety. The processing of such BSM messages in the transmitting and receiving vehicles is performed in on-board equipment (referred to herein as "V2X on-board equipment") that provides the Vehicle-to-Everything (V2X) function.

[0004]

[0004] The first ITS was based on Dedicated Short Range Communications (DSRC), but specifications have evolved and are now following 3GPP-defined standards such as C-V2X and 5G-based cellular communication methods that require both technical and certification testing. As a result, testing workload and costs are increasing due to the increasing number of communication technologies supported as well as the need for road testing. The cellular vehicle-to-everything (C-V2X) protocol is one such protocol being developed as a basis for vehicle-based wireless communications that can be used to support intelligent highways, autonomous and semi-autonomous vehicles, and improve the overall efficiency and safety of highway transportation systems.

[0005]

[0005] The C-V2X protocol defines two transmission modes, which together provide 3° non-line-of-sight awareness and a higher level of predictability for enhanced road safety and 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 in a dedicated Intelligent Transportation System (ITS) 5.9 gigahertz (GHz) spectrum that does not rely on cellular networks. The second transmission mode includes vehicle-to-network communications (V2N) in mobile broadband systems and technologies such as third generation wireless cellular communications technologies (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) systems, Code Division Multiple Access (CDMA) 2000 systems, etc.), fourth generation wireless cellular communications technologies (4G) (e.g., Long Term Evolution (LTE) systems, LTE-Advanced systems, Mobile Worldwide Interoperable Microwave Access (Mobile WiMAX) systems, etc.), fifth generation wireless cellular communications technologies (e.g., 5G NR systems, etc.). Other V2X wireless technologies are also under consideration in different regions of the world. Summary of the Invention

[0006]

[0006] Various aspects include a method performed by a processor of a V2X system participant to detect a misbehavior condition resulting from generation of a vehicle-to-everything (V2X) message in a V2X system. Various aspects may include retrieving a V2X message profile including a threshold deviation value for sensor data, comparing current sensor data to sensor data included in a previous vehicle-to-everything (V2X) message to calculate a deviation value for each of the sensor data, determining whether the deviation value for each of the sensor data from the sensor data included in the previous V2X message exceeds the threshold deviation value included in the V2X message profile, and generating and transmitting a V2X message including the current sensor data in response to determining that the threshold deviation value for each of the sensor data from the sensor data included in the previous V2X message does not exceed the threshold deviation value for each of the sensor data.

[0007]

[0007] Some aspects may further include generating and transmitting a fraud report to a fraud management authority in response to determining that a deviation value in the sensor data from the sensor data included in a previous V2X message exceeds a threshold deviation value.

[0008]

[0008] Some aspects may further include identifying the misconduct condition in the misconduct report as a production violation and appending an index of the V2X message profile or a pre-agreed V2X message profile to the misconduct report.

[0009]

[0009] Some aspects may further include applying security credentials to the generated V2X message, determining whether the applied security credentials are appropriate for the V2X message, and in response to determining that the applied security credentials are appropriate, transmitting the V2X message to another V2X system participant, and in response to determining that parameters of the applied security credentials do not match security credentials parameters included in the V2X message profile, generating and transmitting an abuse report.

[0010]

[0010] Some aspects may further include determining a type of V2X message to be generated, and retrieving the V2X message profile includes retrieving the V2X message profile based on the determined V2X message type.

[0011]

[0011] Some aspects may further include determining a current geographical area, such that retrieving the V2X message profile may include retrieving the V2X message profile based on the determined current geographical area, and the security certification parameters included in the V2X message profile may include a signature algorithm, a signature algorithm parameters, an encryption algorithm, an encryption algorithm parameters, a security certification certificate type, a full security certification certificate addition rate, a security certification header field, a security certification header check, and an anonymous modification strategy, and may further include determining that parameters of the applied security certification match the security certification parameters included in the V2X message profile in response to determining that at least one of the security certification parameters of the applied security certification type matches the security certification parameters included in the V2X message profile.

[0012]

[0012] Some aspects may further include determining a communication technology that the V2X system participants are using to send and receive V2X messages, where the threshold deviation value included in the V2X message profile is based on the determined communication technology.

[0013]

[0013] In some aspects, the V2X message profile may include a threshold for a maximum frequency of messages, a threshold for a minimum frequency of messages, a heading deviation threshold, a position deviation threshold, and a velocity deviation threshold.

[0014] In some aspects, the security credential certificate type may be one of an authentication certificate digest, an authentication full certificate, or an authentication chain.

[0015]

[0015] Some aspects may further include determining whether the current sensor spatial data value matches a threshold spatial data value included in the V2X message profile, such that generating and transmitting a V2X message including the current sensor data in response to determining that a deviation value for each of the sensor data from the sensor data included in the previous V2X message does not exceed the threshold deviation value for each of the sensor data further includes generating and transmitting a V2X message in response to determining that the current sensor spatial data value matches the threshold spatial data value included in the V2X message profile.

[0016]

[0016] Some aspects may further include determining whether the current sensor event data value matches a threshold event data value included in the V2X message profile, such that generating and transmitting a V2X message including the current sensor data in response to determining that a deviation value for each of the sensor data from the sensor data included in the previous V2X message does not exceed the threshold deviation value for each of the sensor data further includes generating and transmitting a V2X message in response to determining that the current sensor event data value matches a threshold event data value included in the V2X message profile.

[0017]

[0017] Various aspects include a method performed by a V2X system that detects a misconduct condition based on a received V2X message. Various aspects may include retrieving a V2X message profile including a threshold deviation value for sensor data, receiving a first V2X message from another V2X system participant, storing a time of receipt of the first V2X message, receiving a second V2X message from the other V2X system participant, determining whether an elapsed time between a time of receipt of the second V2X message and a time of receipt of the first V2X message exceeds a threshold time value included in the V2X message profile, and in response to determining that the elapsed time between a time of receipt of the second V2X message and a time of receipt of the first V2X message exceeds the threshold time value included in the V2X message profile, transmitting a misconduct report to a misconduct management authority.

[0018]

[0018] Some aspects may further include comparing the sensor data included in each of the first V2X message and the second V2X message to determine whether there was a deviation in the sensor data that exceeded a threshold deviation value included in the V2X message profile, and in response to determining that the deviation in the sensor data exceeds the threshold deviation value, sending a fraud report to a fraud management agency.

[0019]

[0019] Some aspects may further include identifying the misconduct condition in the misconduct report as a reception violation and attaching a V2X message profile to the misconduct report.

[0020]

[0020] Some aspects may further include obtaining applied security credentials included in the first V2X message, if present, obtaining applied security credentials included in the second V2X message, if present, determining whether parameters of the applied security credentials match security credentials parameters included in the V2X message profile, and generating and transmitting a misconduct report in response to determining that the parameters of the applied security credentials do not match the security credentials parameters included in the V2X message profile.

[0021] Some aspects may further include determining a V2X message type of the first and second V2X messages, and retrieving a V2X message profile including the threshold time value based on the determined message type. Some aspects may further include determining a current geographic area, and determining that parameters of the applied security credentials match the security credentials parameters included in the V2X message profile in response to determining that at least one of the security credentials parameters of the applied security credentials type match the security credentials parameters included in the V2X message profile, where the V2X message profile is retrieved based on the determined geographic area, and the security credentials parameters included in the V2X message profile may include a signature algorithm, a signature algorithm parameter, an encryption algorithm parameter, a security credentials credential type, a full security credentials credential append rate, a security credentials header field, a security credentials header check, and an anonymous modification strategy.

[0022]

[0022] A further aspect may include a V2X system having a processor configured to perform one or more operations of any of the methods summarized above. A further aspect may include a V2X system having means for performing the functions of any of the methods summarized above. A further aspect may include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a V2X system processor to perform the operations of any of the methods summarized above.

[0023]

[0023] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain the features of the claims. [Brief description of the drawings]

[0024] [Figure 1A] FIG. 1 is a component block diagram illustrating a vehicle suitable for implementing various embodiments. [Figure 1B] FIG. 1 is a component block diagram illustrating a vehicle suitable for implementing various embodiments. [Figure 1C]

[0025] FIG. 1 is a component block diagram illustrating vehicle components suitable for implementing various embodiments. [Figure 1D]

[0026] FIG. 1 is a schematic block diagram illustrating a subset of a V2X communication system suitable for implementing various embodiments. [Figure 2A]

[0027] FIG. 1 is a component block diagram illustrating components of an exemplary V2X system participant management system in accordance with various embodiments. [Figure 2B]

[0028] FIG. 1 is a component block diagram illustrating components of another example V2X system participant management system in accordance with various embodiments. [Diagram 3]

[0029] FIG. 1 is a block diagram illustrating components of a system-on-chip for use in a V2X system participant in accordance with various embodiments. [Figure 4]

[0030] Diagram showing the ITS model stack architecture for a V2X system. [Figure 5A]

[0031] FIG. 2 is a process flow diagram illustrating the operation of a method for detecting a misconduct condition related to the generation of a V2X message, according to various embodiments disclosed herein. [Figure 5B]

[0032] FIG. 2 is a process flow diagram illustrating the operation of a method for detecting a misbehavior condition occurring during generation of a V2X message, according to various embodiments disclosed herein. [Figure 5C]

[0033] FIG. 2 is a process flow diagram illustrating the operation of a method for detecting a misbehavior condition including security credential detection related to generation of a V2X message, according to various embodiments disclosed herein. [Figure 5D]

[0034] FIG. 2 is a process flow diagram illustrating the operation of a method for detecting a misbehavior condition based on security proofs applied to V2X messages, according to various embodiments disclosed herein. [Figure 5E]

[0035] FIG. 2 is a process flow diagram illustrating the operation of a method for applying security attestations to generated V2X messages in accordance with various embodiments disclosed herein. [Figure 6A]

[0036] FIG. 2 is a process flow diagram illustrating the operation of a method for detecting a misbehavior condition occurring during reception of a V2X message, in accordance with various embodiments disclosed herein. [Figure 6B]

[0037] FIG. 2 is a process flow diagram illustrating the operation of a method for detecting a misbehavior condition including security credential detection related to receipt of a V2X message, in accordance with various embodiments disclosed herein. [Figure 7]

[0038] 1 is a component block diagram illustrating an exemplary mobile computing device suitable for use with the various embodiments. [Figure 8]

[0039] 1 is a component block diagram illustrating an exemplary mobile computing device suitable for use with the various embodiments. [Figure 9]

[0040] FIG. 9 is a component block diagram illustrating an exemplary server suitable for use with the various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025]

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

[0026]

[0042] Various embodiments include methods and systems for detecting possible misbehavior conditions that may arise due to improper generation and / or reception of V2X messages.

[0027]

[0043] The term "mobile device" is used herein to refer to any one or all of wireless router devices, wireless appliances, cellular telephones, smartphones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, palmtop computers, wireless email receivers, multimedia Internet-enabled cellular telephones, medical devices and equipment, biometric sensors / devices, wearable devices including smart watches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings, smart bracelets, etc.), entertainment devices (e.g., wireless gaming controllers, music and video players, satellite radios, etc.), wireless network-enabled Internet of Things (IoT) devices including smart meters / sensors, industrial manufacturing equipment, large and small machinery and appliances for home or business use, wireless communication elements in autonomous and semi-autonomous vehicles, mobile devices fixed or embedded in various mobile platforms, global positioning system devices, and similar electronic devices that include memory, wireless communication components, and programmable processors.

[0028]

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

[0029]

[0045] The term "system in package" (SIP) may be used herein to refer to a single module or package containing 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 into a unified substrate. A SIP may also include multiple independent SOCs packaged in close proximity, coupled to each other via high-speed communication circuits, such as on a single motherboard or in a single mobile device. The proximity of the SOCs facilitates high-speed communication and sharing of memory and resources.

[0030]

[0046] As used in this application, terms such as "component," "system," "unit," "module," and the like are intended to include computer-related entities, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, configured to perform certain operations or functions. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. As an example, both an application running on a communication device and the communication device may be referred to as a component. One or more components may reside within a process and / or thread of execution, and a component may be localized on one processor or core and / or distributed among two or more processors or cores. Furthermore, these components may execute from various non-transitory computer-readable media having various instructions and / or data structures stored thereon. The components may communicate via local and / or remote process, function or procedure calls, electronic signals, data packets, memory read / write, and other known computer, processor, and / or process related communication methods.

[0031]

[0047] V2X systems and technologies hold great promise for improving traffic flow and vehicle safety by allowing vehicles to share information about their location, speed, heading, braking, and other factors that may be useful to other vehicles for collision prevention and other safety functions. Vehicles equipped with V2X / V2V on-board equipment transmit their vehicle information frequently (e.g., up to 20 times per second) in packets called Basic Safety Messages (BSM) or Cooperative Awareness Messages (CAM). Once all V2X-equipped vehicles transmit such BSM / CAM messages, all receiving vehicles have the necessary information to control their own speed and direction to avoid collisions and to efficiently and safely position vehicles relative to one another. It is envisioned that V2X-equipped vehicles may be able to improve traffic flow by safely reducing separation distances, allowing some vehicles to platoon with one another, and avoiding vehicles experiencing breakdowns.

[0032]

[0048] For ease of reference, some of the embodiments are described in this application as being performed by a V2X system participant operating within V2X terminology. However, it should be understood that various embodiments encompass any or all of V2X / V2V or vehicle-based communication standards, messages, or technologies. Thus, nothing in this application should be construed as limiting the claims to a V2X / V2V system unless expressly recited as such in the claims. Additionally, the embodiments described herein describe on-board equipment for performing V2X / V2V communications. In a V2X / V2V system, the system participants may include, but are not limited to, vehicle on-board equipment, mobile devices, and roadside units (RSUs). RSUs may include fixed devices such as traffic signals, roadside beacons, traffic cameras, etc. Each of the system participants may broadcast information to other system participants. For example, a vehicle may include on-board / in-dash equipment and sensors that report vehicle status (e.g., position, orientation, speed, dimensions, etc.). A mobile device carried by a pedestrian or vehicle rider (e.g., motorcycle, car, bicycle rider) may include sensors that report on pedestrian conditions (e.g., location, orientation, speed, dimensions, etc.). Each of the vehicles, pedestrians, and RSUs may be a V2X system participant. A processor included in an in-dash / on-board unit or a mobile device may be considered a V2X system participant processor. V2X communication between V2X system participants may enable applications running on each V2X system participant to provide safety applications (e.g., applications that may determine imminent dangers such as sudden braking of a vehicle or speeding from a crossroad with poor visibility) or mobility (planning for traffic signal changes) to vehicles and pedestrians, or other useful functions within the vehicular transportation system as a whole. For ease of reference, the various embodiments described below describe vehicles (e.g., cars). Such descriptions are not intended to limit any of the embodiments for use with vehicles.Rather, the embodiments described herein may be used by any V2X system participant to detect misconduct conditions resulting from the generation and / or receipt of V2X messages that do not conform to message characteristics defined by a communication standard. Such communication standards may be geographically and / or time dependent. Stated another way, message characteristics may vary from location to location and from time to time.

[0033]

[0049] Intelligent Transportation Systems (ITS) aim to provide services related to different modes of transportation and traffic management, to enable users to be better informed, and to make a safer, more coordinated, and "smarter" use of the transportation network. Consistency and predictability are the basis of such a safe transportation system. For example, by knowing the individual destinations of the vehicles operating within the ITS, traffic can be optimized. The number and timing of vehicles traveling on a particular route can be manipulated so that the route is not overwhelmed, overcrowded, or suffers from traffic congestion. Furthermore, by knowing the operating state of each vehicle participating in the ITS, the unpredictability of failures and / or unsafe vehicle operating states can be avoided. For example, drivers of vehicles that are not operating safely can be warned to change their operation. In addition, the possibility of failures and malfunctioning equipment (e.g., a failed braking system) can be avoided by notifying drivers in advance to repair their vehicles, or at least by notifying drivers of nearby vehicles to avoid vehicles that may be failing or operating in an unsafe manner.

[0034]

[0050] To facilitate this consistency and predictability, ITS relies on reliable communications between the various participants of the ITS. These communications may be V2X messages exchanged between system participants. Such V2X communications may include the exchange of BSM / CAMs between participating ITS entities that create and maintain awareness of each other and support the cooperative performance of vehicles using the road network. The BSM / CAM contains the status and attribute information of the originating system participant. The content varies depending on the type of system participant. For a vehicle system participant, the status information includes time, location, motion state, activated systems, etc., while the attribute information includes data on dimensions, vehicle type, and role in road traffic, etc. Upon receiving the BSM / CAM, the receiving system participant recognizes the presence, type, and status of the originating system participant. The received information may be used by the receiving system participant to support several ITS applications. For example, by comparing the status of the originating system participant with its own status, the receiving system participant can estimate the collision risk with the originating system participant and, if necessary, inform the vehicle driver via a man-machine interface (HMI).

[0035]

[0051] The BSM / CAM may include information regarding vehicle position, heading, speed, and other information regarding the vehicle's status and projected path. Other ITS messages may include single phase and timing (SPAT), decentralized environmental notification message (DENM), collective perception message (CPM), map data (MAP), and others. Each of these messages may be collectively referred to as a V2X message.

[0036]

[0052] Misbehavior reporting is an important part of the security system for V2X communications. In misbehavior reporting, field devices, i.e., vehicles or roadside units (RSUs), observe V2X messages, detect when the content of those V2X messages does not match the ensemble of V2X system participants sensor and observation data, and generate misbehavior reports (MBRs) that can be sent to a misbehavior management authority. In instances where the V2X messages do not match the ensemble of vehicle sensors and observation data, a misbehavior condition can be detected and an MBR can be generated. The misbehavior management authority may aggregate MBRs received from different reporting V2X system participants from across the misbehavior management authority's area of ​​responsibility and determine possible responses to the MBR. There can be a wide range of potential responses including, among others, determining that the MBR is not in fact reporting a valid misbehavior condition; determining that the reported MBR is an actual misbehavior condition but is causing little disruption and will cost more to resolve the problem or condition than allowing it to continue; determining that the reporting V2X participant has bad software and needs to be updated; and determining that a signing key associated with the V2X participant has been extracted from V2X system participants and used to launch a nation-wide attack of bad messages and therefore the device key needs to be revoked so that no one will trust it further.

[0037]

[0053] In most conventional V2X systems, the misbehavior detection system (MBDS) is concerned with the accuracy and consistency of the data contained within the V2X message. A misbehavior condition may be detected when the detection system determines that the data contained within the V2X message is inconsistent with other collected data. The MBDS may detect misbehavior by using a set of algorithms that rely solely on V2X data. Each of the V2X messages may be subjected to analysis for misbehavior conditions. For example, a V2X message may include sensor data that supports its intended message (e.g., destination, operational data, etc.). Analysis of this data may result in the detection of a misbehavior condition if any of the sensor data is outside of normal operating parameters. For example, an engine temperature records 1000 degrees Celsius or the vehicle speed is 1000 miles per hour. Data that is clearly outside of normal operating parameters may indicate that a sensor is malfunctioning or the vehicle is operating in an unintended manner. Such misbehavior condition information may be beneficial, as the vehicle operator may be notified to take corrective action to ensure safe operation of the vehicle. For example, sensors may be replaced or repaired, or new software may be installed.

[0038]

[0054] In some situations, malicious actors may also attempt to corrupt the ITS by hacking the vehicle's communication or sensor systems, introducing inaccurate or erroneous data into the system. For example, a malicious actor may report an incorrect destination or sensor speed to cause corruption of the ITS. Therefore, most fraud detection systems focus on the data contained in the V2X messages to determine if a fraud condition has occurred.

[0039]

[0055] In general, various embodiments include methods and systems for detecting possible misbehavior conditions that may arise due to improper generation and / or reception of V2X messages. While sensor data contained within V2X messages may be the focus of most misbehavior condition detection systems, in some instances, the generation or reception of a V2X message itself may indicate a misbehavior condition. As discussed above, consistency and predictability are the basis of such a secure transportation system. Such consistency and predictability may extend to the timing at which V2X messages should be generated and received. To accommodate communication for a large number of participants within the limited communication resources of an ITS, various V2X systems may set operational thresholds regarding the number, size, and frequency of messages that a V2X system participant may transmit. Generation and / or reception of a V2X message outside of these operational thresholds may indicate a misbehavior condition.

[0040]

[0056] As a sender example, a V2X system participant On-Board Unit (OBU) may generate V2X messages without following the requirements related to message generation (or not generate them at all). The cause of this issue may be incorrect code specification or the injection of malicious code or programs that modify / force / prevent message generation. Such high frequency of message generation may force the sender OBU to focus on message generation and divert resources from other functions.

[0041]

[0057] As an example on the receiver side, a V2X system participant OBU that receives V2X messages at a higher than normal frequency may process V2X messages sent from a misbehaving V2X system participant. Current misbehavior detection systems classify the content of each message (and therefore the entire communication) as normal. Traditionally, despite the high frequency of V2X messages generated and / or received, there may be no reason to generate a misbehavior status report as long as the content of the V2X messages matches the totality of vehicle sensor and observation data. Thus, current misbehavior detection systems do not report that a malicious sender is generating V2X messages at an abnormal rate.

[0042]

[0058] As another example, a transmitter may improperly generate V2X messages less frequently than defined in the standard. As a result of message generation delays, expected changes in heading, position, and / or speed may exceed thresholds. Such large deviations in any of these values ​​may cause a misbehavior detection system to improperly identify a misbehavior condition, as such large deviations may indicate inconsistent vehicle operation.

[0043]

[0059] As another example, the inclusion of improper security credentials may result in a V2X message of very large size. The increased message size may cause communication traffic congestion. Thus, similar to high frequency message generation, the generation of unexpectedly large size messages may also impair the efficiency and reliability of the ITS. In the ITS, the data included in the V2X message should be accurate, but the generation and characteristics of the message itself should also be consistent with the characteristics defined in the communication standard to ensure stable operation. Deviations of the message characteristics defined in the communication standard, in addition to the inaccuracy of the data included in the message, may indicate a misbehavior condition. Thus, various embodiments include a method of detecting a misbehavior condition based on the characteristics of the V2X message itself, but not necessarily based on the data included therein.

[0044]

[0060] Various embodiments may be implemented within various V2X system participants, an example vehicle 101 of which is shown in Figures 1A and 1B. With reference to Figures 1A and 1B, the vehicle 101 may include a control unit 140 and a number of sensors 144-170, including a satellite geo-positioning system receiver 142, occupancy sensors 144, 146, 148, 150, 152, tire pressure sensors 154, 156, cameras 158, 160, microphones 162, 164, impact sensors 166, radar 168, and lidar 170. The multiple sensors 144-170 disposed on or within the vehicle may be used for a variety of purposes, such as for autonomous and semi-autonomous navigation and control, crash avoidance, position determination, etc., as well as to provide sensor data regarding objects and people on or within the vehicle 101. The sensors 144-170 may include one or more of a wide variety of sensors capable of detecting a variety of 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 particular, the sensors may include one or more cameras 158, 160 or other optical or photo-optical 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, gravitational meters, shock sensors 166, force meters, stress meters, strain sensors, fluid sensors, chemical sensors, gas composition analyzers, pH sensors, radiation sensors, Geiger counters, neutron detectors, biological material sensors, microphones 162, 164, occupancy sensors 144, 146, 148, 150, 152, proximity sensors, and other sensors.

[0045]

[0061] Vehicle control unit 140 may be configured with processor-executable instructions for performing navigation and collision avoidance operations using information received from various sensors, particularly cameras 158, 160. In some embodiments, 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. Control unit 140 may be further configured to control steering, braking, and speed of vehicle 101 when operating in autonomous or semi-autonomous mode using information about other vehicles determined using various embodiments.

[0046]

[0062] FIG. 1C is a component block diagram illustrating a communication system 100 of components and support systems suitable for implementing various embodiments. With reference to FIGS. 1A-1C, a 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 FIG. 1D, the control unit 140 includes a processor 140a, a memory 140b, an input module 140c, an output module 140d, and a 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 be configured with processor-executable instructions for controlling the steering, navigation, and / or other operations of the vehicle 101, including the operation of various embodiments. The processor 140a may be coupled to the memory 140b.

[0047]

[0063] The radio module 140e may be configured for wireless communication. The radio module 140e may exchange signals (e.g., command signals to inhibit steering, signals from navigation equipment, etc.) with a network transceiver (e.g., base station 110) over communication link 122 and provide signals to the processor 140a and / or navigation unit 172b. In some embodiments, the radio module 140e may enable the vehicle 101 to communicate with the wireless communication device 120 through 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.

[0048]

[0064] 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.

[0049]

[0065] The control unit 140 may be coupled to driving control components 172a for controlling the physical elements of the vehicle 101 related to the steering and navigation of the vehicle, such as the engine, motors, throttle, steering elements, flight control elements, braking or deceleration elements, etc. 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 and / or interior lighting, interior and / or exterior information displays (which may include display screens or other devices for displaying information), safety devices (e.g., haptic devices, audible alarms, etc.), and other similar devices.

[0050]

[0066] The control unit 140 may be coupled to the navigation component 172b and may be configured to receive data from the navigation component 172b and use such data to determine the current position and orientation of the vehicle 101 and an appropriate course towards a destination. The navigation component 172b may include or be coupled to a Global Navigation Satellite System (GNSS) receiver system (e.g., one or more Global Positioning System (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 wireless navigation receiver for receiving navigation beacons or other signals from wireless nodes such as Wi-Fi access points, cellular network sites, radio stations, remote computing devices, other vehicles, etc. Through control of the drive control element 172a, the processor 140a may control the vehicle 101 to navigate and steer. The processor 140a and / or navigation component 172b may be configured to communicate with network elements, such as servers in a communications network (e.g., core network 132) via wireless communications links 122, 126 to receive commands for controlling navigation, receive data useful in navigation, provide real-time position reports, and assess other data.

[0051]

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

[0052]

[0068] Although control unit 140 is described as including separate components, in some embodiments, some or all of the components (e.g., processor 140a, memory 140b, input module 140c, output module 140d, and wireless module 140e) may be integrated into a single device or module, such as a system-on-chip (SOC) processing device. Such a SOC processing device may be configured for use in a vehicle to perform navigation and collision avoidance operations using local dynamic map (LDM) data when installed in the vehicle, and may be configured with processor-executable instructions executing on processor 140a, etc.

[0053]

[0069] FIG. 1D illustrates a portion of a V2X system 103 including three vehicles 12, 14, 16. In the illustrated example, each vehicle 12, 14, 16 includes V2X on-board equipment 102, 104, 106, respectively, configured to periodically broadcast basic safety messages 30, 40, 50 for receipt and processing by the other vehicle's on-board equipment (e.g., 102, 104, 106). By sharing the vehicle's location, speed, direction, braking, and other information, the vehicles can maintain a safe separation and identify and avoid potential collisions. For example, a following vehicle 12 receiving a basic safety message 40 from a leading vehicle 16 can determine the speed and location of the vehicle 16, which allows the vehicle 12 to match speed and maintain a safe separation distance 20. By being notified through the basic safety message 40 when the leading vehicle 16 brakes, the V2X equipment 102 in the following vehicle 12 can simultaneously brake to maintain a safe separation distance 20 even when the leading vehicle 16 suddenly stops. As another example, the V2X equipment 104 in the truck vehicle 14 may receive basic safety messages 30, 50 from the two vehicles 12, 16 and thus be notified that the truck vehicle 14 should stop at an intersection to avoid a collision. Each of the vehicle V2X on-board equipment 102, 104, 106 may communicate with each other using any of a variety of proximity communication protocols. In addition, the vehicles may be capable of transmitting data and information regarding the detected basic safety messages as well as the detected misconduct reports to the original equipment manufacturer (OEM) (70, 72) and / or a remote misconduct management agency 74 via communication links 60, 62 through the communication network 18 (e.g., cellular, WiFi, etc.). The MBR may be transmitted directly to the misconduct management agency 74 (e.g., through communication links 64, 66). In other embodiments, the MBR may be first transmitted through communication links 64, 66 to an MBR pre-processing unit such as the OEM server 70, 72 for pre-processing. The pre-processed MBR may then be transmitted from the MBR pre-processing servers 70 , 72 to a fraud management authority 74 via communications links 64 , 66 .In other embodiments, the MBR may be received from a vehicle, such as vehicle 16, at a remote fraud management authority 74. The remote fraud management authority 74 may relay the MBR received from the vehicle 16 to the OEM servers 70, 72 via communications links 64, 66. Additionally, the OEM servers 70, 72 may provide a confirmation report to the remote fraud management authority 74 via communications links 64, 66.

[0054]

[0070] FIG. 2A is a component block diagram illustrating components of an exemplary fraud management system 200. The vehicle management system 200 may include various subsystems, communication elements, computational elements, computing devices, or units that may be utilized within the vehicle 101. With reference to FIGS. 1A-2A, the various computational elements, computing devices, or 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 one another (e.g., as indicated by the arrows in FIG. 2A). In some implementations, the various computational elements, computing devices, or units within the fraud management system 200 may be implemented within a single computing device, such as separate threads, processes, algorithms, or computational elements. Thus, each subsystem / computational element depicted in FIG. 2A is also generally referred to herein as a "layer" within the computational "stack" that comprises the fraud management system 200. However, the use of the terms layer and stack in describing various embodiments does not imply or require that the corresponding functionality is implemented within a single autonomous (or semi-autonomous) vehicle management system computing device, although this is a potential implementation embodiment. Instead, use of the term "layer" is intended to encompass subsystems with independent processors, computational elements (e.g., threads, algorithms, subroutines, etc.) operating in one or more computing devices, and combinations of subsystems and computational elements.

[0055]

[0071] The fraud management 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 motion planning and control layer 214, and a behavior planning and prediction layer 216. Layers 202-216 are only examples of some layers in one exemplary configuration of the fraud management system stack 200. In other configurations, other layers may be included, such as additional layers for other perception sensors (e.g., a LIDAR perception layer, etc.), additional layers for planning and / or control, additional layers for modeling, and / or some of the layers 202-216 may be excluded from the fraud management system stack 200. Each of the layers 202-216 may exchange data, computations, and commands as indicated by the arrows in FIG. 2A. Additionally, the fraud management system stack 200 may receive and process data from sensors (e.g., radar, lidar, camera, inertial measurement unit (IMU), etc.), navigation systems (e.g., GPS receiver, IMU, etc.), vehicle networks (e.g., controller area network (CAN) bus), and databases in memory (e.g., digital map data). The fraud 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 braking controls. The configuration of the fraud management system stack 200 and DBW system / control unit 220 shown in FIG. 2A is merely an exemplary configuration, and other configurations of the vehicle management system and other vehicle components may be used. As an example, the configuration of the fraud management system stack 200 and DBW system / control unit 220 shown in FIG. 2A may be used in a vehicle configured for autonomous or semi-autonomous operation, while a different configuration may be used in a non-autonomous vehicle.

[0056]

[0072] The radar perception layer 202 may receive data from one or more detection and ranging sensors, such as radar (e.g., 132) and / or lidar (e.g., 138), and process the data to recognize and determine the location of other vehicles and objects within the vicinity of the vehicle 100. The radar perception layer 202 may include the use of neural network processing and artificial intelligence methods to recognize objects and vehicles and pass such information to the sensor fusion and RWM management layer 212.

[0057]

[0073] The camera perception layer 204 may receive data from one or more cameras, such as cameras (e.g., 158, 160), and process the data to recognize and determine the location of other vehicles and objects within the vicinity of the vehicle 100. The camera perception layer 204 may include the use of neural network processing and artificial intelligence methods to recognize objects and vehicles and pass such information to the sensor fusion and RWM management layer 212.

[0058]

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

[0059]

[0075] The misconduct management system 200 may include or be coupled to a vehicle wireless communications subsystem 230. The wireless communications subsystem 230 may be configured to communicate with other vehicle computing devices and highway communications systems, such as via vehicle-to-vehicle (V2V) communications links, and / or to remote information sources, such as cloud-based resources, via cellular wireless communications systems, such as 5G networks. In various embodiments, the wireless communications subsystem 230 may communicate with other V2X system participants via wireless communications links to receive V2X messages, as well as sensor data that may support a conclusion that a misconduct condition has been detected.

[0060]

[0076] The map fusion and arbitration layer 208 may access sensor data received from other V2X system participants and receive output received from the positioning engine layer 206 and process the data to further determine the location of the vehicle 101 in a map, such as a location in a traffic lane, a location in a street map, and the sensor data may be stored in a memory (e.g., memory 312). For example, the map fusion and arbitration layer 208 may convert latitude and longitude information from a GPS to a location in a road surface map included in the sensor data. A GPS position fix contains errors, and therefore the map fusion and arbitration layer 208 may function to determine a best guess location of the vehicle in the road based on arbitration between the GPS coordinates and the sensor data. For example, the GPS coordinates may place the vehicle near the center of a two-lane road in the sensor data, while the map fusion and arbitration layer 208 may determine from the heading that the vehicle is most likely aligned with the heading lane that matches the heading. The map fusion and arbitration layer 208 may pass the map-based location information to the sensor fusion and RWM management layer 212.

[0061]

[0077] The route planning layer 210 may utilize sensor data, as well as input from an operator or dispatcher, to plan a route for the vehicle 101 to follow to a particular 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 prior maps by other layers, such as the sensor fusion and RWM management layer 212, is not required. For example, other stacks may operate and / or control the vehicle based solely on sensory data without maps, construction lanes, boundaries being provided, and local map opinions as sensory data being received.

[0062]

[0078] The sensor fusion and RWM management layer 212 receives data and outputs generated by the radar perception layer 202, the camera perception layer 204, the map fusion and arbitration layer 208, and the route planning layer 210, and may use some or all of such inputs to estimate or refine the location and state of the vehicle 101 with respect to roads, other vehicles on the roads, and other objects within the vicinity of the 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 refine a determined position of the vehicle within a lane of traffic. 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 refine 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 from vehicle-to-vehicle (V2V) communications (such as via a CAN bus) regarding other vehicle positions and headings and combine that information with information from the radar perception layer 202 and the camera perception layer 204 to refine the location and movement of other vehicles. The sensor fusion and RWM management layer 212 may output refined location and state information of the vehicle 100, as well as refined location and state information of other vehicles and objects in the vicinity of the vehicle, to the motion planning and control layer 214 and / or the behavior planning and prediction layer 216.

[0063]

[0079] 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, heading, or other navigational elements and combine that information with other received information to determine improved location and status information. The sensor fusion and RWM management layer 212 may output improved location and status information of the vehicle 101, as well as improved location and status information of other vehicles and objects in the vicinity of the vehicle 100, to the motion planning and control layer 214, the behavior planning and prediction layer 216, and / or to devices remote from the vehicle 101, such as data servers, other vehicles, etc., via wireless communication over a C-V2X connection, other wireless connections, etc.

[0064]

[0080] As yet a further example, the sensor fusion and RWM management layer 212 may monitor perception data from various sensors, such as from the radar perception layer 202, the camera perception layer 204, other perception layers, etc., and / or data from one or more sensors themselves, to analyze conditions in the vehicle sensor data. The sensor fusion and RWM management layer 212 may be configured to detect conditions in the sensor data, such as a sensor measurement being at, above or below a threshold, some type of sensor measurement occurring, etc., and may output the sensor data as part of improved location and status information for the vehicle 101 provided to the behavior planning and prediction layer 216 and / or devices, such as data servers, other vehicles, etc., remote from the vehicle 100, via wireless communication over a C-V2X connection, other wireless connections, etc.

[0065]

[0081] The improved location and status information may include vehicle descriptors associated with the vehicle and vehicle owner and / or operator, such as vehicle specifications (e.g., size, weight, color, on-board sensor type, etc.), vehicle location, speed, acceleration, heading, attitude, orientation, destination, fuel / power levels, and other status information, vehicle emergency status (e.g., whether the vehicle is an emergency vehicle or a private individual in an emergency), vehicle restrictions (e.g., heavy / wide load, turning restrictions, high occupancy vehicle (HOV) clearance, etc.), vehicle capabilities (e.g., all-wheel drive, four-wheel drive, snow tires, chains, supported connection types, on-board sensor operational status, on-board sensor resolution level, etc.), equipment issues (e.g., low tire pressure, weak brakes, sensor outages, etc.), owner / operator travel preferences (e.g., preferred lanes, roads, routes, and / or destinations, preference to avoid tolls or highways, preference for fastest route, etc.), permission to provide sensor data to a data agency server (e.g., 184), and / or owner / operator identification information.

[0066]

[0082] The behavior planning and prediction layer 216 of the autonomous vehicle system stack 200 may use the improved location and state information of the vehicle 101 output from the sensor fusion and RWM management layer 212 and the location and state information of other vehicles and objects to predict future behavior of other vehicles and / or objects. For example, the behavior planning and prediction layer 216 may use such information to predict future relative positions of other vehicles in the vicinity of the vehicle based on the vehicle's own position and speed and the positions and speeds of the other vehicles. Such predictions may take into account information from the LDM data and route planning to anticipate changes in relative vehicle positions as the host vehicle and other vehicles follow the road. The behavior planning and prediction layer 216 may output behavior and location predictions of other vehicles and objects to the motion planning and control layer 214. Additionally, the behavior planning and prediction layer 216 may use object behaviors in combination with location predictions to plan and generate control signals to control the movement of the vehicle 101. For example, based on the route planning information, the refined location in the road information, and the relative locations and movements of other vehicles, the behavior planning and prediction layer 216 may determine that the vehicle 101 needs to change lanes and accelerate, such as to maintain or achieve a minimum separation from other vehicles and / or prepare for a turn or exit. As a result, the behavior planning and prediction layer 216 may calculate or otherwise determine wheel steering angles and throttle setting changes to be commanded to the motion planning and control layer 214 and the DBW system / control unit 220, along with such various parameters necessary to effectuate such lane changes and acceleration. One such parameter may be the calculated steering wheel command angle.

[0067]

[0083] The motion planning and control layer 214 may receive data and information output from the sensor fusion and RWM management layer 212 and other vehicle and object behavior and location predictions from the behavior planning and prediction layer 216, and use this information to plan and generate control signals for controlling the movement of the vehicle 101 and verify that such control signals meet safety requirements for the vehicle 100. For example, based on the route planning information, refined location on road information, and the relative locations and movements of other vehicles, the motion planning and control layer 214 may verify and pass various control commands or instructions to the DBW system / control unit 220.

[0068]

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

[0069]

[0085] In various embodiments, the wireless communications subsystem 230 may communicate with other V2X system participants over wireless communications links to transmit sensor data, location data, vehicle data, and data collected by on-board sensors about the environment around the vehicle. Such information may be used by the other V2X system participants to update stored sensor data for relay to the other V2X system participants.

[0070]

[0086] In various embodiments, the fraud management system stack 200 may include functionality to perform safety checking or oversight of various commands, planning or other decisions of various layers that may affect the safety of the vehicle and occupants. Such safety checking or oversight functionality may be implemented in a dedicated layer or distributed among the various layers and included as part of the functionality. In some embodiments, various safety parameters may be stored in memory, and the safety checking or oversight functionality may compare determined values ​​(e.g., relative spacing to nearby vehicles, distance from road centerline, etc.) with corresponding safety parameters and issue warnings or commands if a safety parameter is 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 a current or future separation distance between another vehicle (defined by the sensor fusion and RWM management layer 212) and a vehicle (e.g., based on a world model refined by the sensor fusion and RWM management layer 212), compare the separation distance to a safe separation distance parameter stored in memory, and issue a command to the motion planning and control layer 214 to speed up, slow down, or turn if the current or predicted separation distance violates the safe separation distance parameter. As another example, a safety or supervisory function in the motion planning and control layer 214 (or in a separate layer) may compare a determined or commanded steering wheel command angle to a safe wheel angle limit or parameter, and issue an override command and / or an alarm in response to the commanded angle exceeding the safe wheel angle limit.

[0071]

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

[0072]

[0088] 2B illustrates an example of a subsystem, computational element, computing device, or unit in a vehicle management system 250 that may be utilized in a vehicle 101. With reference to FIGS. 1A-2B, in some embodiments, layers 202, 204, 206, 208, 210, 212, and 216 of the misconduct management system stack 200 may be similar to those described with respect to FIG. 2A, and the misconduct management system stack 250 may operate similarly to the misconduct management system stack 200, except that the misconduct management system stack 250 may pass various data or instructions to the vehicle safety and crash avoidance system 252 rather than the DBW system / control unit 220. For example, the configuration of the misconduct management system stack 250 and the vehicle safety and crash avoidance system 252 illustrated in FIG. 2B may be used in a non-autonomous vehicle.

[0073]

[0089] 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 state information of the vehicle 101 provided to the vehicle safety and crash avoidance system 252. The vehicle safety and crash avoidance system 252 may use the improved location and state information of the vehicle 101 to make safety decisions regarding the vehicle 101 and / or the occupants of the vehicle 100. As another example, the behavior planning and prediction layer 216 may output behavior models and / or predictions related to the movement of other vehicles to the vehicle safety and crash avoidance system 252. The vehicle safety and crash avoidance system 252 may use the behavior models and / or predictions related to the movement of other vehicles to make safety decisions regarding the vehicle 101 and / or the occupants of the vehicle 101.

[0074]

[0090] In various embodiments, vehicle safety and crash avoidance system 252 may include functionality to perform various commands, planning, or other decisions of various layers that may affect the safety of the vehicle and its occupants, as well as safety inspection or oversight of the actions of the human driver. In some embodiments, various safety parameters may be stored in memory, and vehicle safety and crash avoidance system 252 may compare determined values ​​(e.g., relative spacing to nearby vehicles, distance from road centerline, etc.) to corresponding safety parameters and issue warnings or commands if the safety parameters are violated or will be violated. For example, vehicle safety and crash avoidance system 252 may determine a current or future separation distance between another vehicle (defined by sensor fusion and RWM management layer 212) and a vehicle (e.g., based on a world model improved by sensor fusion and RWM management layer 212), compare the separation distance to safe separation distance parameters stored in memory, and issue commands to the driver to speed up, slow down, or turn if the current or predicted separation distance violates the safe separation distance parameters. As another example, the vehicle safety and crash avoidance system 252 may compare a human driver's changes in steering wheel angle to safe wheel angle limits or parameters and issue an override command and / or an alarm in response to the steering wheel angle exceeding the safe wheel angle limits.

[0075]

[0091] FIG. 3 illustrates an exemplary system-on-chip (SOC) architecture of a processing device SOC 300 suitable for implementing various embodiments in a vehicle. With reference to FIGS. 1A-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 co-processors 310 (e.g., vector co-processors) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, 317. Each of the processors may include one or more cores and an independent / internal clock. Each processor / core may perform operations independently of the other processors / cores. For example, processing device SOC 300 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows). In some embodiments, application processor 308 may be a main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. of SOC 300. Graphics processor 306 may be a graphics processing unit (GPU).

[0076]

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

[0077]

[0093] The processing device SOC 300 also includes dedicated circuitry for camera actuation and management (CAM) 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 pre-processing, video front end (VFE), in-line JPEG, high definition video codec, etc. The CAM 305 may be a separate processing unit and / or may include a separate or internal clock.

[0078]

[0094] In some embodiments, the image and object recognition processor 306 may be configured with processor-executable instructions and / or dedicated hardware configured to perform the 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 to process images received from the cameras (e.g., 158, 160) via the CAM 305 to recognize and / or identify other vehicles as described and to otherwise perform the functions of the camera perception layer 204. In some embodiments, the processor 306 may be configured to process radar or lidar data as described and to perform the functions of the radar perception layer 202.

[0079]

[0095] The system components and resources 316, analog and custom circuits 314, and / or CAM 305 may include circuitry for interfacing with peripheral devices such as cameras 158, 160, radar 168, lidar 170, electronic displays, wireless communication devices, external memory chips, etc. The processors 303, 304, 306, 307, 308 may be interconnected to one or more memory elements 312, system components and resources 316, analog and custom circuits 314, CAM 305, and RPM processor 317 via an interconnect / bus module 324 that may include an array of reconfigurable logic gates and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects such as high performance networks on chips (NoCs).

[0080]

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

[0081]

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

[0082]

[0098] The processing device SOC 300 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, touch screen display, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., location, direction, movement, orientation, vibration, pressure, etc.), cameras, compasses, GPS receivers, communication circuitry (e.g., Bluetooth, WLAN, WiFi, etc.), as well as other well-known components of modern electronic devices.

[0083]

[0099] To determine whether a misconduct condition may have occurred, a misconduct detection module of the V2X system may determine whether generation and / or receipt of a V2X message indicates a misconduct condition.

[0084]

[0100] FIG. 4 shows an ITS model stack architecture for a V2X system. The ITS model stack follows the principles of the Open Systems Interconnection (OSI) model stack for layered communication protocols. The ITS model stack 400 may reuse existing radio and lower layers, such as the physical (PHY) layer 401 and media access control (MAC) layer 403, and existing networking and transport layers, such as the radio link control (RLC) layer 405 and packet data convergence protocol (PDCP) layer 407, and user datagram protocol (UDP) / transmission control protocol (TCP) 413. The internet layer may include internet protocol version 6 (IPv6) 411. The application layer may include ITS applications 417. The V2X protocol 409 may provide an interface between the upper layer 404 and the lower layer 402 in the communication protocol stack.

[0085]

[0101] In operation, the ITS application 417 may make a request to generate a V2X message. The request to generate a V2X message may be based on several factors. For example, the ITS application may seek to generate a V2X message at a known frequency to report the location, speed, heading, etc. of a V2X system participant. In other cases, when certain sensor data exceeds a pre-configured threshold, the ITS application may set a criteria for generating and reporting such a condition through a V2X message. The ITS application 417 may make its request to the message / facilities layer 419 to initiate generation of a V2X message. Upon receiving a request to generate a V2X message, the message / facilities layer 419 may assemble the V2X message to include any relevant sensor data. Additionally, the message / facilities layer 419 may communicate with the security services module 415 to apply any appropriate security credentials that may be required by the particular V2X system in which the participant is operating. Once the security credentials are applied to the V2X message, the V2X message may propagate through the ITS model stack for transmission to other V2X system participants. Additionally, the V2X protocol 409 may include a misconduct module that monitors the V2X message to detect if a misconduct condition is indicated in the V2X message. Additionally, the V2X protocol 409 may determine if the generation or receipt of a V2X message may indicate if a misconduct condition has occurred. In response to determining that a misconduct condition has occurred, the V2X protocol 409 may generate and transmit a misconduct report to a misconduct management authority or some other entity. In response to determining that a misconduct condition has not occurred, the V2X protocol 409 may allow the generation and transmission of the V2X message to other V2X system participants. An ITS model stack architecture may exist in each V2X system operating in each V2X system participant device.Thus, received V2X messages may also be applied to the ITS model stack in the reverse order that the messages are received. However, in both generating and receiving V2X messages, the V2X protocol 409 may monitor the V2X messages for misbehavior conditions.

[0086]

[0102] 5A illustrates operations of a method for detecting a misconduct condition 500a related to generation of a V2X message, consistent with various embodiments. With reference to FIGS. 1-5A, operations of the method 500a may be performed by a V2X processing device in a V2X node (e.g., 200).

[0087]

[0103] At block 501, the V2X system processor may receive a request from an ITS application to generate a V2X message. As described above, the ITS application may attempt to generate V2X messages at a known frequency to report the location, speed, heading, etc. of a V2X system participant. In other instances, when certain sensor data exceeds a pre-configured threshold, the ITS application may attempt to generate and report such a condition through a V2X message.

[0088]

[0104] At block 503, the V2X system processor may retrieve sensor data from a previously generated V2X message as part of a V2X misconduct detection routine dictated by the V2X protocol. The sensor data from the previously generated V2X message may include a timestamp indicating the time of the previously generated V2X message. In addition, the sensor data from the previously generated V2X message may include speed, position, and heading data.

[0089]

[0105] At block 505, the V2X processor may determine a deviation value for each of the sensor data. For example, the V2X processor may calculate the following deviation values:

[0090]

number

[0091] Time deviation value associated with a V2X message

[0092]

number

[0093] Direction deviation value

[0094]

number

[0095] Position deviation value

[0096]

number

[0097] Speed ​​deviation value Where: τ is the generation time of the V2X message; θ is the direction of travel of the V2X system participants, P is the position vector of the V2X system participants, v is the velocity vector of a V2X system participant.

[0098]

[0106] For example, to calculate the time deviation value (also referred to as the minimum and / or maximum frequency thresholds), the V2X processor may calculate the absolute value of the difference between the time of generation of the instantaneous V2X message and the previously generated V2X message. In a similar manner, each of the heading deviation, position deviation, and speed deviation values ​​may be calculated.

[0099]

[0107] At block 513, the V2X system processor may retrieve a V2X message profile. In some embodiments, the V2X profile may be a default profile stored in local memory. In some embodiments, as described in more detail below, the V2X profile (and the V2X message parameters included therein) may change as a V2X system participant moves from one geographical region to another. By retrieving the V2X profile, the V2X system processor may reference parameter values ​​stored for valid V2X messages. The V2X message profile may include various parameter values. These parameter values ​​may include sensor deviation thresholds, security credential parameter values, sensor spatial thresholds, and / or threshold event data values. For example, the V2X profile may include sensor deviation thresholds. As described above, various sensor deviation values ​​(e.g., time, heading, position, speed) may be calculated. The sensor thresholds ensure that the status of a V2X system participant (e.g., vehicle) does not change significantly between subsequent V2X messages. In other words, the time between V2X messages, vehicle heading, vehicle position, and vehicle speed do not change significantly between V2X messages.

[0100]

[0108] In addition, the V2X profile may identify conditions that may be characteristics of a valid V2X message. These conditions may be spatial-based conditions and / or event-based conditions.

[0101]

[0109] Some V2X systems may mandate that a V2X system participant be in a particular spatial location when generating a V2X message. For example, a V2X system may mandate that a V2X system participant be at a traffic light (or within a certain distance to a stationary V2X participant, such as a road sign, traffic light, etc.) when generating a valid V2X message. Thus, in some embodiments, GPS location data of the V2X system participant at the time of V2X message generation may be obtained and appended to the generated V2X message. This appended GPS sensor data may be compared to a threshold spatial data value included in the V2X message profile to ensure that the V2X system participant is within a spatial distance to a landmark or acceptable position / location when the V2X message is generated.

[0102]

[0110] In some embodiments, the V2X profile may identify event conditions that may be characteristics of a valid V2X message. Some V2X systems may mandate that a V2X system participant experiences a particular event when generating a V2X message. For example, a V2X system may mandate that a V2X system participant generates a V2X message in adverse weather conditions. Thus, a V2X system may mandate that windshield wipers, headlights, and fog lights may be activated when generating a valid V2X message. To address this, in some embodiments, a V2X system participant may obtain sensor data regarding vehicle system status, such as the status of headlights, windshield wipers, or fog lights, as an indicator of an event occurring, and such vehicle event data may be appended to the generated V2X message. This appended vehicle event data may be compared to a threshold event data value included in the V2X message profile to ensure that a V2X system participant experiences a particular event when the V2X message is generated.

[0103]

[0111] In some embodiments, a V2X message profile may include security credential parameters that characterize valid security credentials that may be applied to a V2X message. For example, security credential parameters included in a V2X message profile may identify a particular type of security credential credential type, or the frequency with which a full security credential credential is appended to a V2X message. Various security credential parameters are described in more detail herein.

[0104]

[0112] In decision block 515, the V2X system processor may determine whether any of the calculated deviation values ​​exceed a predetermined threshold. For example, in a particular V2X system, there may be a maximum and a minimum time frequency for V2X message generation. In other words, the V2X system expects each V2X system participant to generate V2X messages within a range of times such that the V2X message generation is neither too fast nor too slow. Too fast V2X message generation may cause congestion on the communication channel or overload the receiving V2X processor. However, too slow V2X message generation may not sufficiently update the status of the V2X system participant. In instances where too much time passes between V2X messages, heading, position, or speed may deviate far beyond acceptable thresholds. In each of these situations, a misbehavior condition may be indicated. The sensor deviation value thresholds may be hard-coded into the V2X system processor or may be retrieved from a V2X message profile as described in more detail below.

[0105]

[0113] Thus, in response to the V2X processor determining that none of the calculated deviation values ​​exceed the respective threshold deviation value (i.e., decision block 515=no), the V2X processor may generate a V2X message in block 517 and transmit the generated V2X message to other V2X system participants in block 523.

[0106]

[0114] However, in response to the V2X processor determining that any of the calculated deviation values ​​exceed the respective threshold deviation values ​​(i.e., decision block 515=yes), the V2X processor may generate a misbehavior report (MBR) in block 525.

[0107]

[0115] In some embodiments, the V2X processor may identify the detected misbehavior condition as a violation of a production rule. To support the determination of the misbehavior condition as a violation of a production rule, the V2X system processor may append a V2X message profile or append an index of a pre-agreed V2X message profile to the MBR in optional block 527. In some embodiments, the amount of data transmitted or received in the MBR may be reduced by appending an index value of the pre-agreed V2X message profile that may be appended to the MBR, the index referencing a particular profile in a list or database of pre-agreed V2X message profiles that may be stored in a memory in or accessible by the V2X processor. Once received, the V2X processor may retrieve the pre-agreed V2X message profile by using the index value to identify or look up the correct profile from the list or database of pre-agreed V2X message profiles.

[0108]

[0116] In block 529, the V2X processor may send the MBR directly to the fraud control authority 74 or indirectly through the OEM servers 70, 72 in block 529.

[0109]

[0117] 5B illustrates in more detail operations that may be performed as part of decision block 515 of whether any of the calculated deviation values ​​exceed a predetermined threshold. With reference to FIGS. 1-5B, operations of method 500a may be performed by a V2X processing device in a V2X node (e.g., 200).

[0110]

[0118] After performing the operations of block 505 of method 500a (or block 513 of method 500b (FIG. 5C)), the V2X processor may make a series of decisions regarding whether any of the calculated deviation values ​​exceed a predetermined threshold for each respective value. For example, the time thresholds may include both a minimum frequency time threshold and a maximum frequency time threshold. As described above, the V2X system may attempt to avoid generating V2X messages too frequently, such that such frequent messages may congest the communication channel or overload the receiving V2X processor. In contrast, generating V2X messages too slowly may not provide accurate and consistent status data of the V2X system participants generating such V2X messages. For example, in some V2X systems, the maximum frequency may be one V2X message every 100 milliseconds and the minimum frequency may be one V2X message per second, although smaller or larger maximum and minimum frequency thresholds may be set.

[0111]

[0119] In decision block 531, the V2X processor may determine whether the elapsed time between the instantaneous V2X message and the previously generated V2X message exceeds either a maximum frequency threshold or a minimum frequency threshold.

[0112]

[0120] In response to determining that the elapsed time between the instantaneous V2X message and the previously generated V2X message exceeds either a maximum frequency threshold or a minimum frequency threshold (i.e., decision block 531=yes), the V2X processor may generate a fraud report at block 525 of method 500a and send the MBR at block 529 to the fraud management authority 74 directly or indirectly through the OEM server 70, 72, as described.

[0113]

[0121] In response to determining that the elapsed time between the instantaneous V2X message and the previously generated V2X message does not exceed either the maximum frequency threshold or the minimum frequency threshold (i.e., decision block 531=no), the V2X processor may determine in decision block 533 whether a calculated deviation in the V2X system participant's heading exceeds a heading deviation threshold. In navigation, the heading of a V2X system participant may refer to a compass direction in which the major axis of the V2X system participant may be pointed. Heading may be measured in radians or degrees, and true north may be designated as zero (0) or 360 degrees. The calculated deviation may indicate how many degrees the heading has changed. Over a short duration, such as a 1 millisecond duration between V2X messages, the heading deviation may be only a few degrees. Dramatic heading deviations over such a short duration may indicate that a V2X system participant (e.g., a vehicle) is out of control (i.e., a misbehavior condition).

[0114]

[0122] In response to determining that the heading deviation between the instantaneous V2X message and the previously generated V2X message exceeds the heading deviation threshold (i.e., decision block 533=yes), the V2X processor may generate a fraud report at block 525 of method 500a and send the MBR at block 529 to the fraud management authority 74 directly or indirectly through the OEM server 70, 72, as described.

[0115]

[0123] In response to determining that the heading deviation between the instantaneous V2X message and the previously generated V2X message does not exceed the heading deviation threshold (i.e., decision block 533=no), the V2X processor may determine in decision block 535 whether the calculated deviation value in the position of the V2X system participant exceeds the position deviation threshold. The position of the V2X system participant (i.e., vehicle) may be determined through a GPS sensor or perhaps a visual location sensor (i.e., camera). The calculated deviation may indicate how far the vehicle has moved. Over a short duration, such as a 1 millisecond duration between V2X messages, the position deviation may be as little as a foot or yard. A dramatic position deviation over such a short duration may indicate that the V2X system participant (e.g., vehicle) is moving at a high speed, such as in an accident (i.e., a misconduct condition).

[0116]

[0124] In response to determining that the position deviation between the instantaneous V2X message and the previously generated V2X message exceeds the position deviation threshold (i.e., decision block 535=yes), the V2X processor may generate a fraud report at block 525 of method 500a and send the MBR at block 529 to the fraud management authority 74 directly or indirectly through the OEM servers 70, 72, as described.

[0117]

[0125] In response to determining that the position deviation between the instantaneous V2X message and the previously generated V2X message does not exceed the position deviation threshold (i.e., decision block 535=no), the V2X processor may determine in decision block 537 whether a calculated deviation in the speed of the V2X system participant exceeds a speed deviation threshold. The speed of the V2X system participant (i.e., the vehicle) may be determined through an accelerometer or speedometer or derived from the vehicle's tachometer or other sensor. The calculated deviation may indicate how fast the vehicle is traveling. In some locations, posted speed limits may mandate how fast or at what speed a vehicle may travel. Exceeding such posted speed limits may indicate a misbehavior condition. Additionally, a sudden change in speed (e.g., acceleration) may indicate that the vehicle is in an accident (i.e., a misbehavior condition).

[0118]

[0126] In response to determining that the speed deviation between the instantaneous V2X message and the previously generated V2X message exceeds the speed deviation threshold (i.e., decision block 537=yes), the V2X processor may generate a fraud report at block 525 of method 500a and send the MBR at block 529 to the fraud management authority 74 directly or indirectly through the OEM servers 70, 72, as described.

[0119]

[0127] In response to determining that the speed deviation between the instantaneous V2X message and the previously generated V2X message does not exceed the speed deviation threshold (i.e., decision block 537=no), indicating that the generation of the V2X message does not exceed any deviation threshold, the V2X processor may generate a V2X message at block 517 of method 500a and transmit the V2X message to other V2X system participants at block 523 as described.

[0120]

[0128] 5C illustrates another embodiment method 500b of detecting a misconduct condition including security proof detection related to generation of a V2X message, consistent with various embodiments. With reference to FIGS. 1-5C, the operations of method 500a may be performed by a V2X processing device in a V2X node (e.g., 200). Method 500b includes the operations of similarly numbered blocks of method 500a described with reference to FIG. 5A as well as additional analysis of security proof that may be applied to the V2X message at block 519 and decision block 521.

[0121]

[0129] At blocks 501, 503, and 505, the V2X processor may perform the operations of the similarly numbered blocks of method 500a as described.

[0122]

[0130] In block 507, the V2X processor may optionally determine the type of V2X message requested from the ITS application. Different V2X messages may follow different protocols. For example, BSM / CAM may have specific maximum and minimum frequency thresholds, while SPAT, CPM, DENM, or MAP messages may have completely different deviation thresholds. Thus, by determining which type of V2X message is requested for generation, an appropriate threshold may be used in decision block 515.

[0123]

[0131] At block 509, the V2X system processor may determine a current geographic area in which the V2X system participants are located. The current geographic area may be determined, for example, via a GPS sensor. Different geographic areas may mandate different protocols and thresholds. For example, BSM is a message generated in ITS systems deployed in North America, and CAM is a message used in ITS systems deployed in Europe. The various thresholds associated with each V2X message may be influenced by the current geographic area in which the V2X system participants are located. For example, in some countries, areas, regions, the communication systems may not be as robust as other countries, areas, regions. In addition, traffic in urban areas may be denser than rural areas. Each of these factors may affect communication channel congestion. Thus, in areas where communication channel congestion may be more prevalent (due to either V2X system participant density or communication infrastructure), the maximum and minimum frequency thresholds may be changed to mitigate communication channel congestion. Thus, the current geographic area location may affect the misconduct detection decisions of the V2X system.

[0124]

[0132] In block 511, the V2X system processor may also optionally determine the type of communication technology that the V2X system participants may be employing to transmit and receive V2X messages. For reasons similar to those described above, the type of communication technology being used may affect communication channel bandwidth and congestion.

[0125]

[0133] At block 513, the V2X system processor may retrieve a V2X message profile. As described above, several factors may affect the sensor deviation thresholds. These factors may include the V2X message type, the current geographic area, and the communication technology being used. Based on these determined values, the V2X system processor may retrieve an appropriate V2X message profile. The V2X message profile may include appropriate sensor deviation thresholds that may determine whether the generation of a V2X message represents a misbehavior condition. For example, when a vehicle (i.e., a V2X system participant) moves from one geographic area to another (e.g., from country to country, from city to rural area, etc.), the vehicle may retrieve a new V2X message profile so that appropriate thresholds are used to determine whether a misbehavior condition has occurred.

[0126]

[0134] As described, the retrieved V2X message profile may further include characteristics and parameters mandated for the application of security credentials to the V2X message. Such security credentials mandates may be affected by variations in geographic location, among other things. These security credentials parameters may include a signature algorithm, signature algorithm parameters, an encryption algorithm, an encryption algorithm parameters, a security credentials certificate type, a full security credentials attachment rate, security credentials header fields, security credentials header checks, and an anonymous modification strategy.

[0127]

[0135] In decision block 515, the V2X processor may use the correct V2X message profile retrieved in block 513 to determine whether the deviation value exceeds any threshold deviation value.

[0128]

[0136] As described, in response to the V2X processor determining that any of the calculated deviation values ​​exceed the respective threshold deviation values ​​(i.e., decision block 515=yes), the V2X processor may generate a misconduct report at block 525 of method 500a.

[0129]

[0137] The V2X processor may optionally identify the detected misbehavior condition as a violation of a production rule. To support the determination of the misbehavior condition as a violation of a production rule, the V2X system processor may append the V2X message profile or append an index of a pre-agreed V2X message profile to the MBR in optional block 527. As described, in some embodiments, a list or database of pre-agreed V2X message profiles may be stored in a memory within or accessible by the V2X processor, which may enable the V2X system processor to communicate the appropriate V2X message profile to be used by including only the index value corresponding to the appropriate profile in the list or database of pre-agreed V2X message profiles. Such an embodiment may reduce the amount of information included in the MBR.

[0130]

[0138] The V2X processor may also transmit the MBR to the fraud management authority 74, either directly or indirectly through the OEM servers 70, 72, in block 529 of method 500a, as described.

[0131]

[0139] In response to the V2X processor determining that none of the calculated deviation values ​​exceed the respective threshold deviation value (i.e., decision block 515=no), the V2X processor may generate a V2X message at block 517 as described.

[0132]

[0140] In block 519, a security services module in the V2X system processor may apply security attestation to the generated V2X message response to the V2X system processor that generated the V2X message in block 517.

[0133]

[0141] In decision block 521, the V2X system processor may determine whether the parameters of the applied security credentials match the security credentials parameters included in the V2X message profile.

[0134]

[0142] In response to the V2X system processor determining that the security credential parameters applied to the V2X message match the security credential parameters included in the V2X message profile (i.e., decision block 521=Yes), the V2X processor may transmit the V2X message at block 523 of method 500a as described or perform an optional decision regarding the spatial / event data at decision block 522.

[0135]

[0143] In response to the V2X system processor determining that the parameters of the applied security credentials do not match the security credentials parameters included in the V2X message profile (i.e., decision block 521=no), the V2X processor may generate a misconduct report (MBR) at block 525, optionally append the V2X message profile or an index of a pre-agreed V2X message profile in a list or database of pre-agreed V2X message profiles to the MBR at block 527, and transmit the MBR to the misconduct authority 74, either directly or indirectly through the OEM servers 70, 72, at block 529 of method 500a as described.

[0136]

[0144] In some embodiments, at decision block 522, the V2X processor may determine whether the spatial and / or event data surrounding the generation of the V2X message meets required conditions for valid V2X message generation. As described, the V2X message profile may include threshold spatial data values. Some V2X systems may require that a V2X system participant (e.g., a vehicle) be in a particular location when the V2X message is generated. For example, a V2X system may require that a vehicle be located at (or passing through) an intersection when the V2X message is generated. Other V2X systems may require that a vehicle be within a threshold distance from a stationary V2X system participant (e.g., a traffic light, road sign, etc.) when the V2X message is generated. Thus, at decision block 522, the V2X processor may compare the spatial location data associated with the generation of the V2X message to the threshold spatial data values ​​included in the V2X message profile.

[0137]

[0145] In response to determining that the spatial location data associated with the generation of the V2X message matches the threshold spatial data value included in the V2X message profile (i.e., decision 522=yes), the V2X processor may transmit the V2X message at block 523.

[0138]

[0146] In response to determining that the spatial location data associated with the generation of the V2X message does not match the threshold spatial data value included in the V2X message profile (i.e., decision 522=no), the V2X processor may generate an MBR at block 525.

[0139]

[0147] In some embodiments, the V2X processor may compare event data associated with the generation of the V2X message to a threshold event data value included in the V2X message profile at decision block 522. As described, a V2X system may include vehicle use, such as windshield wipers, headlights, or fog lights, as events associated with the generation of a V2X message.

[0140]

[0148] In response to determining that the event data associated with the generation of the V2X message matches a threshold event data value included in the V2X message profile (i.e., decision 522=yes), the V2X processor may transmit the V2X message at block 523.

[0141]

[0149] In response to determining that the event data associated with the generation of the V2X message does not match a threshold event data value included in the V2X message profile (i.e., decision 522=no), the V2X processor may generate an MBR at block 525.

[0142]

[0150] To prevent malicious actors from flooding a V2X system with false and misleading V2X messages, each V2X message may include a security certificate that is applied to the message to authenticate the message to other V2X system participants. Typically, such security certificates follow a known protocol with required parameters.

[0143]

[0151] For example, in Europe, the generation of CAMs involves a specific set of standardized rules regarding the inclusion of security data. These standardized rules may mandate that, as a default, a selection digest is included with the V2X message, where the selection digest may be a shortened version of the security certification certificate with a smaller data size (i.e., 10-32 bytes). Thus, the V2X message profile may mandate that a specific security certification certificate type is applied to the V2X message. In addition, the standardized rules may mandate that a selection certificate is included once one second after the last inclusion of the selection certificate, where the selection certificate may be a full version of the security certification certificate with an intermediate data size. Thus, the V2X message profile may mandate a full security certification add rate.

[0144]

[0152] Standardized rules may mandate that when an ITS-S receives a CAM signed by a previously unknown AT, it immediately includes the selection certificate in its next CAM instead of including the selection digest. In such a case, the timer for the next inclusion of the selection certificate is restarted.

[0145]

[0153] Standardized rules may also mandate that when an ITS-S receives a CAM containing a tbsdata.headerInfo component of type inlineP2pcdRequest, the ITS-S evaluates the list of certificate digests contained in that component. If the ITS-S finds the certificate digest of the currently used authorization ticket in that list, the system may immediately include the selected certificate in the next CAM instead of including the selected digest. Thus, the V2X message profile may mandate certain security credentials header fields and security credentials header checks.

[0146]

[0154] In some standardized regulations, there may be an obligation to include a certificate chain, which may include a certificate of large data size that includes a set of certificates. In some standardized regulations, the inclusion of security attestations or the type of security attestation included may depend on the size of the V2X message. Larger V2X messages may not include security attestations as frequently as smaller sized V2X messages. Alternatively, in cases where the V2X messages are larger, smaller sized security attestations, such as selected digests, may be used.

[0147]

[0155] In many areas, standardized regulations mandate such security certificate rules not only to provide a secure V2X system, but also to limit the amount of data that can be included in a V2X message. For example, if all V2X messages included a certificate chain as a way to authorize the message, problems resulting from communication channel congestion and receiving system processor overload could occur when too much data is transmitted and received. Thus, in some embodiments, the detection system may verify that full certificates are not included too frequently, as this may increase channel congestion and computational overhead on the receiver.

[0148]

[0156] As described above, the V2X message generation profile may be regional or tailored according to the sender's context. Such regional tailoring may be particularly appropriate for the security attestation profile. The inclusion of security attestation may depend on regional policies. For example, each country may not have the same communication infrastructure that can continuously support the transmission and reception of robust security attestation. In addition, not all connected V2X stations (e.g., roadside units and other fixed V2X system participants) are equipped with C-V2X capabilities. Thus, the geographic context may vary from country to country, state to state, or road to road. For example, from a regional policy perspective, the V2X generation profile may state that applications should not insert full attestation into each CAM because available bandwidth is limited. From a V2X message type perspective, the V2X generation profile may state that applications should not insert attestation for some specific types of V2X messages due to their larger data size. For example, a collective cognitive message (CPM) is only appended with its full attestation every 450 ms. Various embodiments ensure that each V2X message is generated according to standardized specifications and security policies. As previously mentioned, various embodiments may be implemented in V2X transmitter and receiver tamper detection systems. By retrieving the appropriate V2X message profile in block 513 of the described method 500b, security policies and regional mandates for communication channel control may be complied with.

[0149]

[0157] 5D illustrates operations that may be performed as part of decision block 521 of method 500b. With reference to FIGS. 1A-5D, the operations of decision block 521 may be performed by a V2X processing device in a V2X node (e.g., 200). Decision block 521 may include any and / or all of optional decision blocks 541-549. Depending on which security credential parameters may be included in the V2X message profile, various decisions may be made to determine whether the security credential parameters of the applied security credential match the security credential parameters included in the V2X message profile.

[0150]

[0158] At decision block 541, the V2X system processor may determine whether the security credential applied to the V2X message at block 519 uses a signature algorithm and / or signature algorithm parameters included in the retrieved V2X message profile. In response to determining that the signature algorithm and / or signature algorithm parameters of the applied security credential do not match the signature algorithm and / or signature algorithm parameters identified in the retrieved V2X message profile (i.e., decision block 541=no), the V2X system processor may generate a misconduct report (MBR) at block 525 of method 500a and transmit the MBR at block 529 to the misconduct management authority 74 directly or indirectly through the OEM server 70, 72, as described.

[0151]

[0159] In response to determining that the signature algorithm and / or signature algorithm parameters of the applied security certificate match the signature algorithm and / or signature algorithm parameters identified in the retrieved V2X message profile (i.e., decision block 541=yes), the V2X system processor may utilize any of the other optional decision blocks before the V2X processor transmits the V2X message at block 523 of method 500a or 500b, as described.

[0152]

[0160] In decision block 543, the V2X system processor may determine whether the security credentials applied to the V2X message in block 519 use an encryption algorithm and / or encryption algorithm parameters included in the retrieved V2X message profile.

[0153]

[0161] In response to determining that the encryption algorithm and / or encryption algorithm parameters of the applied security credential do not match the encryption algorithm and / or encryption algorithm parameters identified in the retrieved V2X message profile (i.e., decision block 543=no), the V2X system processor may generate a misconduct report (MBR) at block 525 of method 500a as described and transmit the MBR at block 529 to the misconduct management authority 74 directly or indirectly through the OEM server 70, 72.

[0154]

[0162] In response to determining that the encryption algorithm and / or encryption algorithm parameters of the applied security credential match the encryption algorithm and / or encryption algorithm parameters identified in the retrieved V2X message profile (i.e., decision block 543=yes), the V2X system processor may utilize any of the other optional decision blocks before the V2X processor transmits the V2X message at block 523 of method 500a or 500c, as described.

[0155]

[0163] In decision block 545, the V2X system processor may determine whether the security credentials applied to the V2X message in block 519 use the security credentials header fields and checks included in the retrieved V2X message profile.

[0156]

[0164] In response to determining that the security credential header fields and checks of the applied security credential do not match the security credential header fields and checks included in the retrieved V2X message profile (i.e., decision block 545=no), the V2X system processor may generate a misconduct report (MBR) at block 525 of method 500a as described and transmit the MBR to the misconduct authority 74 at block 529, either directly or indirectly through the OEM servers 70, 72.

[0157]

[0165] In response to determining that the security credential header fields and checks of the applied security credential match the security credential header fields and checks identified in the retrieved V2X message profile (i.e., decision block 545=yes), the V2X system processor may utilize any of the other optional decision blocks before the V2X processor may transmit the V2X message at block 523 of method 500a or 500c, as described.

[0158]

[0166] In decision block 547, the V2X system processor may determine whether the security credential type applied to the V2X message in block 519 is a security credential type identified in the retrieved V2X message profile.

[0159]

[0167] In response to determining that the security credential type of the applied security credential does not match the security credential type identified in the retrieved V2X message profile (i.e., decision block 547=no), the V2X system processor may generate a misconduct report (MBR) at block 525 of method 500a as described and transmit the MBR to the misconduct management authority 74 at block 529, either directly or indirectly through the OEM servers 70, 72.

[0160]

[0168] In response to determining that the security credential type of the applied security credential matches the security credential type identified in the retrieved V2X message profile (i.e., decision block 547=yes), the V2X system processor may utilize any of the other optional decision blocks before the V2X processor may transmit the V2X message at block 523 of method 500a or 500c as described.

[0161]

[0169] In decision block 549, the V2X system processor may determine whether the frequency at which the full security credentials are applied to V2X messages in block 519 exceeds (either higher or lower than) a threshold identified in the retrieved V2X message profile.

[0162]

[0170] In response to determining that the frequency with which the full security attestation certificate is applied to V2X messages exceeds a threshold (i.e., decision block 549 = yes), the V2X system processor may generate a misconduct report (MBR) at block 525 of method 500a as described and transmit the MBR to the misconduct management authority 74 at block 529, either directly or indirectly through the OEM servers 70, 72.

[0163]

[0171] In response to determining that the frequency with which the full security attestation certificate is applied to the V2X message does not exceed the threshold (i.e., decision block 547=no), the V2X system processor may utilize any of the other optional decision blocks before the V2X processor may transmit the V2X message at block 523 of method 500a or 500c, as described.

[0164]

[0172] 5E illustrates in more detail example operations related to applying security credentials to V2X messages in block 519 of method 500b. With reference to FIGS. 1A-5E, the operations of block 519 may be performed by a V2X processing device in a V2X node (e.g., 200).

[0165]

[0173] As part of the V2X message generation, the V2X system processor may make a request to the security module 415 from the access layer to request security data in block 551. The requested security data may include security credential type and specific credential information. The security module 415 may apply the requested security credential to the V2X message.

[0166]

[0174] In block 553, the V2X system processor's V2X protocol 409 module may execute a misconduct detection system to continuously monitor generated and received V2X messages to determine if a misconduct condition has occurred. As part of the monitoring process, the misconduct detection system may execute decision block 515 in methods 500a and 500c as described.

[0167]

[0175] At block 555, the fraud detection system may perform security algorithms for secure V2X message generation, such as by performing the operations at decision block 521 of method 500b, as described, to ensure that the type and frequency of security attestations are appropriate for the particular V2X system.

[0168]

[0176] In some embodiments, the tamper condition may be detected by the V2X message receiver. From the perspective of the V2X message receiver, the security module 415 and the tamper detection system may ensure that there are no anomalies related to the V2X message content. Thus, the tamper detection system and the cryptographic security system (e.g., HSM) may ensure the correctness of the V2X data before evaluating the requirements for generating a secure V2X message.

[0169]

[0177] 6A illustrates a simplified embodiment method 600a of monitoring received V2X messages to determine whether the received V2X messages may indicate that a misconduct condition may occur based on a frequency of V2X message reception. With reference to FIGS. 1A-6A, the operations of method 600a may be performed by a V2X processing device in a V2X node (e.g., 200).

[0170]

[0178] At block 601, a receiving second V2X system participant may receive a first V2X message from a first V2X system participant.

[0171]

[0179] At block 603, the V2X system processor of the receiving V2X system participant may store in memory the time of receipt of the first V2X message from the first V2X system participant.

[0172]

[0180] At block 605, a second V2X message may be received from the first V2X system participant.

[0173]

[0181] In block 613, the V2X system processor may retrieve the V2X message profile.

[0174]

[0182] At decision block 631, the V2X system processor of the receiving second V2X system participant may determine whether the elapsed time between received V2X messages from the first V2X system participant exceeds a maximum or minimum time-frequency threshold. The time-frequency threshold may be hard-coded in the V2X system processor memory or may be included in a geographic area search V2X message profile.

[0175]

[0183] In response to determining that the elapsed time between received V2X messages from the first V2X system participant exceeds a maximum or minimum time frequency threshold (i.e., decision block 631=yes), the V2X system processor of the receiving second V2X system participant determines that a misconduct condition has occurred and generates an MBR (block 625), similar to blocks 525 and 529 of Figures 5A and 5C.

[0176]

[0184] In some embodiments, the V2X processor may identify the detected misbehavior condition as a violation of a reception rule. To support the determination of the misbehavior condition as a violation of a production rule, the V2X system processor may append a V2X message profile to the MBR at optional block 627.

[0177]

[0185] In block 629, the V2X processor may send the MBR directly to the fraud control authority 74 or indirectly through the OEM server 70, 72. In response to determining that the elapsed time between received V2X messages from the first V2X system participant does not exceed a maximum or minimum time frequency threshold (i.e., decision block 631=no), the V2X system processor of the receiving second V2X system participant may read the V2X messages (block 623) and update the status of the first V2X participant.

[0178]

[0186] Figure 6B illustrates another embodiment method 600b of monitoring received V2X messages to determine whether the received V2X messages may indicate that a misconduct condition may occur based on various deviation thresholds and appropriate security certification decisions similar to the monitoring and analysis that may be performed on the generating / transmitting V2X system processor described in Figure 5C. With reference to Figures 1A-6B, the operations of method 600b may be performed by a V2X processing device in a V2X node (e.g., 200).

[0179]

[0187] In method 600b, a V2X system processor of a receiving second V2X system participant may perform the operations of blocks 601, 603, and 605 of method 600a as described.

[0180]

[0188] At block 606, the V2X system processor of the receiving second V2X system participant may decode the first and second received V2X messages to obtain sensor data included in each respective V2X message. Based on the obtained sensor data, the V2X system processor of the receiving second V2X system participant may calculate a deviation value for each of the obtained sensor data.

[0181]

[0189] At blocks 507, 509, 511, and 513, the V2X system processor of the receiving second V2X system participant may retrieve a V2X message profile appropriate for the geographic area, communication message type, and / or communication technology in blocks 507-513 of the described method 500a.

[0182]

[0190] At decision block 515, the V2X system processor of the receiving second V2X system participant may determine whether any calculated deviation values ​​from the received first and second V2X messages exceed any threshold deviation values ​​included in the retrieved V2X message profile, as described.

[0183]

[0191] In response to the V2X processor of the receiving second V2X system participant determining that any of the calculated deviation values ​​exceed the respective threshold deviation values ​​(i.e., decision block 515=yes), the V2X processor of the receiving second V2X system participant may generate a misbehavior report (MBR) in block 625.

[0184]

[0192] In some embodiments, the V2X processor of the receiving second V2X system participant may identify the detected misbehavior condition as a violation of the reception rules. To support the determination of the misbehavior condition as a violation of the reception rules, the V2X system processor may append a V2X message profile to the MBR at optional block 627.

[0185]

[0193] At block 629, the V2X processor of the receiving second V2X system participant may transmit the MBR to the fraud management authority 74 directly or indirectly through the OEM servers 70, 72 at block 629 of method 600a, as described.

[0186]

[0194] In response to the V2X processor of the receiving second V2X system participant determining that none of the calculated deviation values ​​exceed the respective threshold deviation value (i.e., decision block 515=no), the V2X processor of the receiving second V2X system participant may determine, in decision block 621, whether the security attestation parameters of the security attestation applied to the received V2X message match the security attestation parameters included in the V2X message profile, similar to the operation in decision block 521 of the described method 500b.

[0187]

[0195] In response to the V2X system processor of the receiving second V2X system participant determining that the security attestations applied to the V2X message are appropriate (i.e., decision block 621=yes), the V2X processor of the receiving second V2X system participant may determine, in decision block 622, whether the spatial / event data associated with the generation of the V2X message matches the spatial / event threshold data values ​​included in the V2X message profile, similar to the operation at decision block 522 of the described method 500b.

[0188]

[0196] In response to the V2X system processor of the receiving second V2X system participant determining that the security credentials applied to the V2X message are not appropriate (i.e., decision block 621=no), the V2X processor of the receiving second V2X system participant may generate a misconduct report (MBR) in block 625 and transmit the MBR directly to the misconduct management authority 74 or indirectly through the OEM server 70, 72 in block 629.

[0189]

[0197] In response to the V2X processor of the receiving second V2X system participant determining that the spatial / event data associated with the generation of the V2X message does not match the spatial / event threshold data values ​​included in the V2X message profile (i.e., decision block 622=no), in block 625, the V2X processor of the receiving second V2X system participant may generate a misbehavior report (MBR).

[0190]

[0198] In response to the V2X processor of the receiving second V2X system participant determining that the spatial / event data associated with the generation of the V2X message matches the spatial / event threshold data values ​​included in the V2X message profile (i.e., decision block 622=yes), the V2X processor of the receiving second V2X system participant may read the V2X message in block 623 and update the status of the first V2X system participant.

[0191]

[0199] Various embodiments (including but not limited to those described above with reference to FIGS. 1A-6B) may be implemented in a wide variety of computing systems, including on-board equipment as well as mobile computing devices, one example of which suitable for use with various embodiments is shown in FIG. 7. With reference to FIGS. 1A-7, a mobile computing device 700 may include a processor 702 coupled to a touch screen controller 704 and an 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 or non-volatile memory, and may be secure and / or encrypted memory, or non-secure 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 a touchscreen panel 712, such as a resistive-sensing touchscreen, a capacitive-sensing touchscreen, an infrared-sensing touchscreen, etc. Additionally, the display of the mobile computing device 700 need not have touchscreen capabilities.

[0192]

[0200] The mobile computing device 700 may have one or more wireless signal transceivers 708 (e.g., Peanut, Bluetooth, Zigbee, Wi-Fi, RF radio) and antennas 710 coupled to each other and / or to the processor 702 for transmitting and receiving communications. The transceivers 708 and antennas 710 may be used with the circuits 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 coupled to the processor to enable communication over a cellular network.

[0193]

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

[0194]

[0202] 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 constructed of plastic, metal, or a combination of materials to contain all or a portion of the components described herein. Those skilled in the art may recognize that the housing 720 may be a dashboard console of a vehicle in an on-board embodiment. The mobile computing device 700 may include a power source 722, such as a disposable or rechargeable battery, coupled to the processor 702. The rechargeable battery may also be coupled to a peripheral device connection port to receive charging current from a power source external 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.

[0195]

[0203] Various embodiments (including but not limited to those described above with reference to FIGS. 1A-6B) may be implemented in a wide variety of computing systems, including a laptop computer 800, an example of which is shown in FIG. 8. Many laptop computers include a touchpad touch surface 817 that serves as the computer's pointing device and may therefore receive drag, scroll, and flick gestures similar to those implemented on the computing devices described above equipped with touchscreen displays. The laptop computer 800 typically includes a processor 802 coupled to volatile memory 812 and a 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 a 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 computing devices may include a computer mouse or trackball coupled to the processor (e.g., via a USB input), as is well known, which may also be used with the various embodiments.

[0196]

[0204] Various embodiments (including but not limited to those described above with reference to FIGS. 1A-6B) may be in accordance with various vehicle computing systems, an example of which is shown in FIG. 9. The vehicle computing system 900 typically includes one or more multi-core processor assemblies 901 coupled to a volatile memory 902 and a large capacity non-volatile memory such as a disk drive 904. As shown in FIG. 9, the multi-core processor assembly 901 may be added to the vehicle computing system 900 by inserting it into a rack of assemblies. The vehicle computing system 900 may also include a communication port 907 coupled to the multi-core processor assembly 901 for exchanging data and commands with a wireless module (not shown), such as a local area network, the Internet, a public switched telephone network, and / or a cellular data network (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.

[0197]

[0205] A number of different cellular and mobile communication services and standards may become available or are contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, for example, 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, third generation wireless mobile communication technologies (3G), fourth generation wireless mobile communication technologies (4G), fifth generation wireless mobile communication technologies (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), and Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020®), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Networks (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. Any reference to terminology and / or technical details relating to a particular telecommunications standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless expressly stated in the claim language.

[0198]

[0206] Example implementations are described in the following paragraphs. Although some of the following implementations are described with respect to example methods, further example implementations may include the example methods described in the following paragraphs implemented by a V2X system processor, which may be an on-board unit, a mobile device unit, a mobile computing unit, or a fixed roadside unit including a processor configured with processor-executable instructions for performing operations of the methods of the following implementations, and the example methods described in the following paragraphs implemented by a V2X system including means for performing the functions of the methods of the following implementations, which may be implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a V2X system processor to perform operations of the methods of the following implementations.

[0199]

[0207] Example 1. A method of detecting a misbehavior condition in a Vehicle-to-Everything (V2X) system, comprising: retrieving a V2X message profile including a threshold deviation value for sensor data; comparing current sensor data to sensor data included in a previous Vehicle-to-Everything (V2X) message to calculate a deviation value for each of the sensor data; determining whether the deviation value for each of the sensor data from the sensor data included in the previous V2X message exceeds the threshold deviation value included in the V2X message profile; and in response to determining that the deviation value for each of the sensor data from the sensor data included in the previous V2X message does not exceed the threshold deviation value for each of the sensor data, generating and transmitting a V2X message including the current sensor data.

[0200]

[0208] Example 2. The method of example 1, further comprising generating and transmitting a misconduct report to a misconduct management authority in response to determining that a deviation value in the sensor data from the sensor data included in a previous V2X message exceeds a threshold deviation value.

[0201]

[0209] Example 3. The method of example 2, further comprising identifying the misconduct condition in the misconduct report as a generation violation and appending an index of the V2X message profile or a pre-agreed V2X message profile to the misconduct report.

[0202]

[0210] Example 4. The method of any of Examples 1 to 3, further comprising: applying security attestation to the generated V2X message; determining whether the applied security attestation is appropriate for the V2X message; and in response to determining that the applied security attestation is appropriate, transmitting the V2X message to another V2X system participant; and in response to determining that the parameters of the applied security attestation do not match the security attestation parameters included in the V2X message profile, generating and transmitting an abuse report.

[0203]

[0211] Example 5. The method of any of Examples 1 to 4, further comprising determining a type of V2X message to be generated, and retrieving a V2X message profile comprises retrieving a V2X message profile based on the determined V2X message type.

[0204]

[0212] Example 6. The method of any of Examples 1 to 5, further comprising: determining the current geographical area such that retrieving a V2X message profile may include operations of retrieving a V2X message profile based on the determined current geographical area, and security attestation parameters included in the V2X message profile may include a signature algorithm, a signature algorithm parameter, an encryption algorithm, an encryption algorithm parameter, a security attestation credential type, a full security attestation credential append rate, a security attestation header field, a security attestation header check, and an anonymous modification strategy; and determining that parameters of the applied security attestation match the security attestation parameters included in the V2X message profile in response to determining that at least one of the security attestation parameters of the applied security attestation type matches the security attestation parameters included in the V2X message profile.

[0205]

[0213] Example 7. The method of any of Examples 1 to 6, further comprising determining a communication technology being used by the V2X system participants to transmit and receive V2X messages, wherein the threshold deviation value included in the V2X message profile is based on the determined communication technology.

[0206]

[0214] Example 8. The method of any of Examples 1-7, wherein the V2X message may be a cooperative awareness message (CAM), and the V2X message profile may include a threshold for a maximum frequency of CAM messages, a threshold for a minimum frequency of CAM messages, a heading deviation threshold, a position deviation threshold, and a velocity deviation threshold.

[0207]

[0215] Example 9. The method of any of Examples 1 to 8, wherein the security authentication certificate type can be one of an authentication certificate digest, an authentication full certificate, or an authentication chain.

[0208]

[0216] Example 10. The method of any of Examples 1 to 9, further including determining whether the current sensor spatial data values ​​match a threshold spatial data value included in a V2X message profile, such that in response to determining that a deviation value for each of the sensor data from the sensor data included in the previous V2X message does not exceed the threshold deviation value for each of the sensor data, generating and transmitting a V2X message including the current sensor data, further including in response to determining that the current sensor spatial data values ​​match a threshold spatial data value included in the V2X message profile.

[0209]

[0217] Example 11. The method of any of Examples 1-9, further comprising: determining whether the current sensor event data value matches a threshold event data value included in the V2X message profile, such that in response to determining that a deviation value for each of the sensor data from the sensor data included in the previous V2X message does not exceed the threshold deviation value for each of the sensor data, generating and transmitting a V2X message including the current sensor data, further comprising: in response to determining that the current sensor event data value matches a threshold event data value included in the V2X message profile, generating and transmitting a V2X message.

[0210]

[0218] Example 12. A method of detecting a misconduct condition in a Vehicle-to-Everything (V2X) system, comprising retrieving a V2X message profile including a threshold deviation value for sensor data; receiving a first V2X message from another V2X system participant; storing a time of receipt of the first V2X message; receiving a second V2X message from the other V2X system participant; determining whether an elapsed time between a time of receipt of the second V2X message and a time of receipt of the first V2X message exceeds a threshold time value included in the V2X message profile; and in response to determining that the elapsed time between a time of receipt of the second V2X message and a time of receipt of the first V2X message exceeds the threshold time value, sending a misconduct report to a misconduct management authority.

[0211]

[0219] Example 13. The method of Example 12, further comprising: comparing the sensor data included in each of the first V2X message and the second V2X message to determine whether there was a deviation in the sensor data that exceeded a threshold deviation value included in the V2X message profile; and in response to determining that the deviation in the sensor data exceeded the threshold deviation value, sending a misconduct report to a misconduct management authority.

[0212]

[0220] Example 14. The method of example 12 or 13, further comprising identifying the misconduct condition in the misconduct report as a reception violation and attaching the V2X message profile to the misconduct report.

[0213]

[0221] Example 15. The method of any of Examples 12-14, further comprising: retrieving applied security attestation included in the first V2X message, if present; retrieving applied security attestation included in the second V2X message, if present; determining whether parameters of the applied security attestation match security attestation parameters included in the V2X message profile; and generating and transmitting a misconduct report in response to determining that parameters of the applied security attestation do not match security attestation parameters included in the V2X message profile.

[0214]

[0222] Example 16. The method of any of Examples 12-15, further comprising: determining a V2X message type of the first and second V2X messages; and retrieving a V2X message profile including a threshold time value based on the determined message type.

[0215]

[0223] Example 17. The method of any of Examples 12-16, further comprising: determining a current geographic area; and, in response to determining that at least one of the security attestation parameters of the applied security attestation type matches the security attestation parameters included in the V2X message profile, wherein a V2X message profile is retrieved based on the determined geographic area, and the security attestation parameters included in the V2X message profile may include a signature algorithm, a signature algorithm parameter, an encryption algorithm parameter, a security attestation credential type, a full security attestation credential append rate, a security attestation header field, a security attestation header check, and an anonymous modification strategy, determining that the parameters of the applied security attestation match the security attestation parameters included in the V2X message profile.

[0216]

[0224] The various embodiments shown 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 associated embodiment, and may be used with or combined with other embodiments shown and described. Moreover, the claims are not limited by any one exemplary embodiment.

[0217]

[0225] The above method descriptions and process flow diagrams are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the above embodiments may be performed in any order. Words such as "then," "then," and "next" do not limit the order of operations, but rather these words are used to guide the reader through the method descriptions. Additionally, references to claim elements in the singular using, for example, the articles "a," "an," or "the" should not be construed as limiting the element to the singular.

[0218]

[0226] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described with respect to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various exemplary components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0219]

[0227] The hardware used to implement the various example logic, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed 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. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors associated with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

[0220]

[0228] 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-transitory computer-readable or processor-readable storage medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module or processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such a non-transitory computer-readable or processor-readable storage medium may include 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 can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically and discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable media and non-transitory processor-readable media. Furthermore, operations of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable storage medium and / or a non-transitory computer-readable storage medium, which may be incorporated into a computer program product.

[0221]

[0229] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. 1. A method for detecting a misbehavior condition in a Vehicle-to-Everything (V2X) system, comprising: Retrieving a Vehicle-to-Everything (V2X) message profile including a threshold deviation value for the sensor data; comparing the current sensor data with sensor data included in a previous V2X message to calculate a deviation value for each of the sensor data; determining whether the deviation value for each of the sensor data from the sensor data included in a previous V2X message exceeds the threshold deviation value included in the V2X message profile; generating and transmitting a V2X message including the current sensor data in response to determining that the deviation value for each of the sensor data from the sensor data included in a previous V2X message does not exceed a threshold deviation value for each of the sensor data; A method comprising:

2. 10. The method of claim 1, further comprising generating and transmitting a fraud report to a fraud management authority in response to determining that the deviation value in the sensor data from the sensor data included in a previous V2X message exceeds a threshold deviation value.

3. identifying the misconduct condition in the misconduct report as a production violation; appending an index of the V2X message profile or a pre-agreed V2X message profile to the misconduct report; The method of claim 2 , further comprising:

4. applying security attestations to the generated V2X messages; and determining whether security credential parameters of the applied security credential match security credential parameters included in the V2X message profile; in response to determining that the security credential parameters of the applied security credential match security credential parameters included in the V2X message profile, transmitting the V2X message to another V2X system participant; generating and transmitting an abuse report in response to determining that the security credential parameters of the applied security credential do not match security credential parameters included in the V2X message profile; Further equipped with Optionally, the method further comprises: Determining a current geographic area; wherein retrieving the V2X message profile comprises retrieving the V2X message profile based on the determined current geographic area, and the security credential parameters included in the V2X message profile include: A signature algorithm; signature algorithm parameters; An encryption algorithm; encryption algorithm parameters; A security certification certificate type; Full security certification certificate addition rate, A security credentials header field; A security certificate header check; Anonymous modification strategy and Equipped with determining that security credential parameters of the applied security credential type match security credential parameters included in the V2X message profile in response to determining that at least one of the security credential parameters of the applied security credential type matches security credential parameters included in the V2X message profile; Further equipped with Optionally, the method further comprises determining a communication technology being used by V2X system participants to send and receive V2X messages, and the threshold deviation value included in the V2X message profile is based on the determined communication technology, wherein: The V2X message is a Cooperative Awareness Message (CAM), The V2X message profile includes: a threshold for the maximum frequency of CAM messages; a threshold for a minimum frequency of CAM messages; a threshold value of heading deviation; a position deviation threshold; Speed ​​deviation threshold and The method of claim 2 , comprising:

5. The method further comprises determining whether a current sensor spatial or event data value matches a threshold spatial data value included in the V2X message profile; 2. The method of claim 1, wherein generating and transmitting the V2X message including the current sensor data in response to determining that the deviation value for each of the sensor data from the sensor data included in a previous V2X message does not exceed a threshold deviation value for each of the sensor data, further comprises generating and transmitting the V2X message in response to determining that the current sensor spatial or event data value matches a threshold spatial data value included in the V2X message profile.

6. 1. A method for detecting a fraud condition, comprising: Retrieving a Vehicle-to-Everything (V2X) message profile including a threshold deviation value for the sensor data; receiving a first V2X message from another V2X system participant; storing a time of receipt of the first V2X message; and receiving a second V2X message from the other V2X system participant; and determining whether an elapsed time between a time of receipt of the second V2X message and the time of receipt of the first V2X message exceeds a threshold time value included in the V2X message profile; in response to determining that the elapsed time between the time of receipt of the second V2X message and the time of receipt of the first V2X message exceeds the threshold time value, sending a fraud report to a fraud management authority. A method comprising:

7. comparing sensor data included in each of the first V2X message and the second V2X message to determine if there was a deviation in the sensor data that exceeded a threshold deviation value included in the V2X message profile; in response to determining that the deviation in the sensor data exceeds a threshold deviation value included in the V2X message profile, sending a fraud report to the fraud management authority; The method of claim 6 further comprising:

8. identifying a misconduct condition in the misconduct report as a receiving violation; adding a V2X message profile or a pre-agreed V2X message profile index to the misconduct report; The method of claim 7 further comprising:

9. If present, obtaining the applied security credentials included in the first V2X message; and If present, obtaining the applied security credentials included in the second V2X message; and determining whether security credential parameters of the applied security credential match security credential parameters included in the V2X message profile; generating and transmitting the misconduct report in response to determining that the security credential parameters of the applied security credential do not match security credential parameters included in the V2X message profile; The method of claim 7 further comprising:

10. determining one or both of a current geographic area or a V2X message type of the first V2X message and the second V2X message; wherein retrieving the V2X message profile comprises retrieving the V2X message profile based on one or both of the determined current geographic area or the determined message type; Wherein, the security credentials parameters included in the V2X message profile include: A signature algorithm; signature algorithm parameters; An encryption algorithm; encryption algorithm parameters; A security certification certificate type; Full security certification certificate addition rate, A security credentials header field; A security certificate header check; Anonymous modification strategy and Equipped with determining that security credential parameters of the applied security credential type match security credential parameters included in the V2X message profile in response to determining that at least one of the security credential parameters of the applied security credential type matches security credential parameters included in the V2X message profile; Further equipped with 10. The method of claim 9, optionally wherein the V2X message profile includes a maximum message frequency threshold, a minimum message frequency threshold, a heading deviation threshold, a position deviation threshold, and a velocity deviation threshold.

11. determining whether a current sensor spatial data value or a threshold event data value included in either the received first V2X message or the received second V2X message matches a threshold spatial data value or a threshold event data value included in the V2X message profile; in response to determining that the current sensor spatial data value or threshold event data value included in either the received first V2X message or the received second V2X message does not match a threshold spatial data value or threshold event data value included in the V2X message profile, sending the misconduct report to the misconduct management authority; The method of claim 7 further comprising:

12. a transmitter configured to wirelessly transmit and receive a V2X message including a misconduct report; a processor coupled to the transmitter; A vehicle-to-everything (V2X) device comprising: Retrieving a V2X message profile including a threshold deviation value for the sensor data; comparing current sensor data with sensor data included in a previous Vehicle-to-Everything (V2X) message to calculate a deviation value for each of the sensor data; determining whether the deviation value for each of the sensor data from the sensor data included in a previous V2X message exceeds the threshold deviation value included in the V2X message profile; generating and transmitting a V2X message including the current sensor data in response to determining that the deviation value for each of the sensor data from the sensor data included in a previous V2X message does not exceed a threshold deviation value for each of the sensor data; A V2X device configured with processor-executable instructions to perform the steps of:

13. a transmitter configured to wirelessly transmit and receive V2X messages and misconduct reports; a processor coupled to the transmitter; A vehicle-to-everything (V2X) device comprising: Retrieving a V2X message profile including a threshold deviation value for the sensor data; receiving a first V2X message from another V2X system participant; storing a time of receipt of the first V2X message; and receiving a second V2X message from the other V2X system participant; and determining whether an elapsed time between a time of receipt of the second V2X message and the time of receipt of the first V2X message exceeds a threshold time value included in the V2X message profile; in response to determining that the elapsed time between the time of receipt of the second V2X message and the time of receipt of the first V2X message exceeds the threshold time value included in the V2X message profile, sending a fraud report to a fraud management authority; A V2X device configured with processor-executable instructions to perform the steps of:

14. 13. The V2X device of claim 12, wherein the processor is further configured with processor-executable instructions for performing a method according to any one of claims 2 to 5.

14. The V2X device of claim 13, wherein the processor is further configured with processor-executable instructions for performing a method according to any one of claims 6 to 11.

15. A non-transitory processor-readable storage medium having processor-executable instructions configured to cause a V2X system processor to perform any of the operations of the methods described in claims 1 to 5 or any of the operations of the methods described in claims 6 to 11.

Images