A method for filtering local malfunction messages performed by a vehicle-to-everything (V2X) processing device, a V2X processing device, and a non-transient processor-readable medium.

Abstract

In various embodiments, a vehicle-to-everything (V2X) processing device can receive a V2X message from an intelligent transportation system (ITS) station, analyze information in the received V2X message to detect a malfunction condition, and add a station identifier associated with the V2X message received from the ITS station to a local block list in response to detecting the malfunction condition in the V2X message received from the ITS station. In some embodiments, the V2X processing device can transmit a malfunction report to a management entity in response to detecting the malfunction condition in the V2X message.

Description

[Technical Field]

[0001] Related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 138,916, filed on 19 January 2021, entitled “Local Misbehavior Prevention System for Cooperative Intelligent Transportation,” the entirety of which is incorporated herein by reference for all purposes. [Background technology]

[0002] Various standards have been developed for vehicle-to-everything (V2X) communication systems and functions. The 802.11p standard, developed by the Institute of Electrical and Electronics Engineers (IEEE), is the basis for the Short-Range Communication (DSRC) and ITS-G5 communication standards. IEEE 1609 is a higher-level standard based on IEEE 802.11p. The Cellular Vehicle-to-Everything (C-V2X) standard is a competing standard developed under the auspices of the Third Generation Partnership Project. These standards serve as the foundation for vehicle-based wireless communications and can be used to support intelligent highways, autonomous and semi-autonomous vehicles, and improve the overall efficiency and safety of trunk road transport systems. Other V2X wireless technologies are also being considered in multiple different regions of the world. The techniques described herein are applicable to any V2X wireless technology.

[0003] C-V2X defines two transmission modes that provide enhanced road safety and 360° beyond-line-of-sight perception and a higher level of predictability for autonomous driving. The first transmission mode includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P), and includes Direct C-V2X, which brings extended communication range and reliability within a dedicated ITS 5.9 gigahertz (GHz) spectrum that is independent of cellular networks. The second transmission mode includes vehicle-to-network (V2N) communications in mobile broadband systems and technologies such as third-generation wireless mobile communication technologies (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) system, Code Division Multiple Access (CDMA) 2000 system, etc.), fourth-generation wireless mobile communication technologies (4G) (e.g., Long-Term Evolution (LTE) system, LTE Advanced system, Mobile Worldwide Interoperability for Microwave Access (Mobile WiMAX) system, etc.), and fifth-generation new radio wireless mobile communication technologies (e.g., 5G NR system).

[0004] Several regions of the world are developing standards for vehicle-based communication systems and functions, such as IEEE 1609 and SAE for use in North America, or ETSI and CEN for use in Europe. Part of these systems is the ability of a vehicle to broadcast basic safety messages ("BSM" in the diagram, used in North America) or cooperative recognition messages (CAM, used in Europe) that other vehicles can receive and process to improve traffic safety and efficiency. Processing of such messages in the transmitting and receiving vehicles is carried out in on-board equipment that provides V2X functionality (referred to herein as "V2X on-board equipment").

[0005] In V2X communication, it is crucial to detect inaccurate, corrupted, or hacked (i.e., faulty) data and prevent its further spread. However, as the number of vehicles preparing to participate in such networks increases, the amount of potential malfunction condition data is large and growing exponentially. Therefore, to efficiently utilize V2X messaging, the management of such detected malfunction conditions may be controlled. Malfunction detection systems are essential for performing the function of detecting faulty data and generating malfunction reports (MBRs). MBRs need to be generated, stored locally, and transmitted to a trusted third party (e.g., a malfunction authority) for investigation. Therefore, the integrity and functionality of V2X in-vehicle equipment are important design considerations when V2X systems are deployed. [Overview of the Initiative] [Means for solving the problem]

[0006] Various embodiments include methods for local malfunction message filtering performed by a vehicle-to-everything (V2X) processing device. Various embodiments may include the steps of receiving a V2X message from an Intelligent Transportation System (ITS) station, analyzing information within the received V2X message to detect a malfunction condition in the V2X message, and adding a station identifier associated with the V2X message received from the ITS station to a local block list in response to the detection of a malfunction condition in the V2X message received from the ITS station. Some embodiments may include the step of transmitting a malfunction report to a management entity in response to the detection of a malfunction condition in the V2X message. In such embodiments, the step of transmitting a malfunction report to a management entity in response to the detection of a malfunction condition in the V2X message may be performed when adding a station identifier associated with the V2X message received from the ITS station to a local block list.

[0007] Some embodiments include the step of determining whether a station identifier associated with another received V2X message exists in a local blocklist, and the step of blocking the V2X message from further processing in response to the determination that a station identifier associated with another received V2X message exists in the local blocklist. Such embodiments include the step of determining the type of malfunction associated with a station identifier that exists in the local blocklist, and the step of determining the block duration based on the type of malfunction. In such embodiments, the step of blocking the V2X message from further processing in response to the determination that a station identifier associated with a V2X message exists in a local blocklist may include the step of blocking the V2X message from further processing for the block duration.

[0008] In some embodiments, the step of adding a station identifier associated with a V2X message received from an ITS station to a local block list in response to the detection of a malfunction condition in a V2X message received from an ITS station may include the steps of determining whether or not the station identifier associated with a V2X message received from an ITS station should be added to a local block list in response to the detection of a malfunction condition in a V2X message received from an ITS station, and adding the station identifier associated with the V2X message to the local block list in response to the decision that the station identifier should be added to the local block list.

[0009] Some embodiments may include the steps of receiving a Certificate Revocation List (CRL) containing one or more station identifiers, and updating a local blocklist based on one or more station identifiers in the CRL. In some embodiments, the step of updating the local blocklist based on one or more station identifiers in the CRL may include the step of removing station identifiers associated with V2X messages from the local blocklist. In some embodiments, the step of updating the local blocklist based on one or more station identifiers in the CRL may include the step of increasing the block time period for station identifiers associated with V2X messages.

[0010] Further embodiments include a V2X processing device including a processor configured to perform any of the operations summarized above. Further embodiments include a malfunction control system including memory and a processor configured to perform any of the operations summarized above. Further embodiments may include a V2X processing device having various means for performing functions corresponding to any of the operations summarized above. Further embodiments may include a non-temporary processor-readable storage medium storing processor-executable instructions configured to cause the processor of the V2X processing device to perform various operations corresponding to any of the operations summarized above.

[0011] The accompanying drawings, incorporated herein and constituting part thereof, illustrate exemplary embodiments of the claims and, together with the given schematic description and “Modes for Carrying Out the Invention,” are useful in illustrating the features herein. [Brief explanation of the drawing]

[0012] [Figure 1A] This is a system block diagram showing an exemplary V2X system suitable for implementing various embodiments. [Figure 1B]A conceptual diagram showing an exemplary V2X communication protocol stack suitable for implementing various embodiments. [Figure 2A] A component diagram showing an exemplary vehicle system suitable for implementing various embodiments. [Figure 2B] A component diagram showing a malfunction management network suitable for implementing various embodiments. [Figure 3] A process flow diagram showing an exemplary method for managing the generation, storage, and transmission of MBR by a malfunction management system. [Figure 4A] A process flow diagram showing an exemplary operation for determining whether a malfunction report should be generated by a malfunction management system. [Figure 4B] A process flow diagram showing an exemplary operation for determining whether a malfunction report should be generated by a malfunction management system. [Figure 5A] A process flow diagram showing an exemplary operation for determining whether a malfunction report should be stored by a malfunction management system. [Figure 5B] A process flow diagram showing an exemplary operation for determining whether a malfunction report should be stored by a malfunction management system. [Figure 6] A process flow diagram showing an exemplary operation for calculating the weight of a generated malfunction report by a malfunction management system. [Figure 7] A process flow diagram showing an exemplary operation for determining which of the stored malfunction reports can be deleted by a malfunction management system. [Figure 8] A process flow diagram showing an exemplary operation for adjusting the threshold in a feedback signal by a malfunction management system. [Figure 9] A block component diagram showing an exemplary system for local malfunction message filtering according to various embodiments. [Figure 10A] A process flow diagram showing an exemplary method for local malfunction message filtering according to various embodiments. [Figure 10B] A process flow diagram illustrating an exemplary method of local malfunction message filtering according to various embodiments. [Figure 10C] A process flow diagram illustrating an exemplary method of local malfunction message filtering according to various embodiments. [Figure 11] A component block diagram showing an exemplary mobile computing device suitable for use with various embodiments. [Figure 12] A component block diagram showing an exemplary server suitable for use with various aspects. **DETAILED DESCRIPTION OF THE INVENTION**

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

[0014] Generally, various embodiments include methods and mechanisms for local management of malfunctions of an advanced road traffic system (ITS) station detected by a V2X in-vehicle device. The V2X in-vehicle device can also report such malfunctions to a management authority such as a malfunction management authority and / or a security certificate management system (SCMS), but it may take hours or days for the management authority to respond by means of a concession such as a certificate revocation list (CRL). Various embodiments enable a V2X processing device (e.g., of a V2X in-vehicle device) to respond quickly compared to the response time of the management authority to a detected malfunction.

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

[0016] In V2X communication, it is crucial to detect inaccurate, corrupted, or hacked (i.e., malfunctioning) data and prevent its further spread. However, as the number of vehicles preparing to participate in such networks increases, the amount of potential malfunction condition data is large and growing exponentially. To efficiently utilize V2X messaging, the management of such detected malfunction conditions can be controlled. Malfunction detection systems are essential for performing the function of detecting malfunctioning data and generating malfunction reports (MBRs). However, currently, malfunction detection systems process all incoming messages, even those from reported malfunctioning transmitting devices (generally referred to herein as "ITS stations"). This behavior consumes finite computing resources. For example, a malfunctioning station may send up to 10-20 messages per second, requiring the malfunction detection system to process this quantity of such messages in addition to other messages received by the V2X system.

[0017] While a local malfunction detection system can send the MBR to network security functions such as a malfunction authority, the process of revoking the certificates of malfunctioning ITS stations can take hours or even days. For example, for each confirmed malfunctioning ITS station (which may require the receipt of several MBRs), the malfunction authority can revoke the certificates of the malfunctioning ITS stations. The malfunction authority can send a list of ITS stations to be revoked, such as a Certificate Revocation List (CRL) containing one or more identifiers of the ITS stations to be revoked, to other devices participating in the communication network. However, as mentioned above, this revocation process can take hours or even days. Before the certificate revocation is complete, the malfunctioning ITS station may send a large number of incorrect or malicious V2X messages (e.g., one message every 100 milliseconds). Communication latency due to a malfunctioning authority may be caused by or exacerbated by the absence of a connection to the malfunctioning authority, the lack of connected infrastructure (associated with DSRC), the lack of cellular connectivity (associated with C-V2X), and the lack of evidence that the ITS station is malfunctioning.

[0018] Various embodiments include a V2X processing device configured to implement a method and a method for local malfunction management. In some embodiments, a V2X processing device (e.g., in a V2X in-vehicle device) can, in response to the detection of a malfunction condition in a V2X message, add a station identifier associated with the V2X message having the detected malfunction condition to a local blocklist. In some embodiments, the station identifier may include any unique identifier of an ITS station. In some embodiments, the station identifier may include a certificate or certificate number. In some embodiments, the station identifier may include an anonymous certificate, an authentication ticket (e.g., a media access control (MAC) address delivered by a V2X public key infrastructure (PKI)), or other appropriate information.

[0019] In various embodiments, the local blocklist can be updated using locally detected information, such as ITS station malfunctions, and station identifiers associated with the malfunctioning ITS stations. In some embodiments, the local blocklist may also include information provided by the malfunction authority, such as station identifiers provided in the CRL. In various embodiments, the CRL is a global blocklist set by the malfunction authority based on the processing of malfunction reports sent by a number of ITS stations. Thus, the CRL represents a more global blocklist. In some embodiments, the V2X processing device can update the local blocklist using local information (i.e., based on ITS station malfunctions detected locally by the V2X processing device) and using "global" information received in the CRL or other appropriate information from the malfunction authority or entity.

[0020] In some embodiments, the V2X processing device may include hardware, software, or a combination of hardware and software that instantiates the functionality of the system for local malfunction detection, local malfunction reporting, and local malfunction filtering or "prevention." The local malfunction detection system can detect V2X messages containing incorrect or false information. The local malfunction detection system can determine whether the incorrect information is unintentional (e.g., incorrect information reported by a malfunctioning sensor) or intentional (e.g., malicious information or information provided by a hacked V2X device). The local malfunction reporting system can generate a malfunction report (MBR) indicating the detected malfunction and send it, for example, to a malfunction management entity. The local malfunction reporting system can also send the MBR to a local malfunction prevention system.

[0021] In some embodiments, the local malfunction prevention system can implement filtering or firewall functions to prevent V2X messages having detected malfunction conditions from being further processed by the local malfunction detection system. In some embodiments, the local malfunction prevention system can be configured to have a local blocklist. The local blocklist may include station identifiers of ITS stations that have sent incorrect or false V2X messages. Thus, the V2X processing device can be configured to determine whether the station identifier associated with an incoming V2X message is present in the local blocklist, and whether the V2X message should be blocked from further processing in response to the determination that the station identifier associated with another incoming V2X message is present in the local blocklist. In some embodiments, when a malfunction report is transmitted to the management entity, the V2X processing device can add the station identifier associated with the V2X message having detected malfunction conditions to the local blocklist. In some embodiments, the V2X processing device can determine whether the station identifier associated with the V2X message having detected malfunction conditions should be added to the local blocklist.

[0022] In some embodiments, the V2X processing device can determine the type of malfunction associated with a station identifier present in a local blocklist. For example, the V2X processing device can determine whether the malfunction is unintentional (e.g., caused by a malfunctioning device or sensor) or intentional (e.g., as a result of an attack or the intentional injection of incorrect or false information). In some embodiments, the V2X processing device can determine a block duration based on the type of malfunction, and block further processing of the V2X message over the block duration. For example, the V2X processing device may determine a relatively short time duration, or impose a temporary block on V2X messages from an ITS source for unintentional malfunctions. In some embodiments, the V2X processing device may determine a relatively long time duration, or impose a permanent block on V2X messages from an ITS source for intentional malfunctions.

[0023] In some embodiments, a V2X processing device can update its local blocklist based on subsequent information, such as a Certificate Revocation List (CRL) received from a malfunction management entity. In some embodiments, the CRL may include one or more station identifiers of ITS stations whose certificates have been revoked. As mentioned above, the malfunction management entity may provide the CRL hours or days after a malfunctioning ITS station is reported. To address this, various embodiments allow the V2X processing device to act quickly to locally block V2X messages from malfunctioning ITS stations by updating the local blocklist, and later update the local blocklist based on information eventually provided by the malfunction management entity in the CRL (or other information or messages). In some embodiments, the V2X processing device can remove one or more station identifiers from the local blocklist that are not present in the CRL. For example, an ITS station with a malfunctioning sensor that is quickly repaired may not appear in the CRL because the certificate for this ITS station has not been revoked. As another example, the V2X processing device can retain or add one or more station identifiers present in the CRL to the local blocklist. In some embodiments, the V2X processing device can increase the block time duration for station identifiers present in the CRL (for example, to impose a persistent block on such station identifiers).

[0024] Various embodiments can improve the operation of the V2X processing system by reducing the number or volume of invalid or inaccurate messages processed by the V2X processing system received from a malfunctioning ITS station, thereby reducing the demand on V2X processing system resources. Various embodiments can improve the operation of the V2X processing system by enabling the V2X processing system to respond quickly and dynamically to such malfunctions long before the malfunction management entity can respond to the detected malfunction report from the ITS station. Various embodiments can improve the operation of the V2X processing system by imposing block times whose duration can vary based on different types of malfunction conditions, thereby avoiding blocking the ITS station for extended periods (e.g., days or weeks) for unintentional malfunctions that can be corrected within a relatively short period (e.g., a few hours).

[0025] For ease of reference, some embodiments are described in this application using malfunction management systems operating within the scope of the Vehicle-to-Everything (V2X) terminology. However, it should be understood that various embodiments encompass either or all of V2X or vehicle-based communication standards, messages, or technologies. Therefore, nothing in this application should be construed as limiting the claims to V2X and Basic Safety Messages (BSM) unless expressly stated so in the claims. In addition, the embodiments described herein discuss in-vehicle equipment for carrying out V2X communication. Other embodiments are conceivable that V2X communication may also include mobile devices, mobile computers, and roadside units (RSUs) prepared to monitor road and vehicle conditions and participate in V2X communication.

[0026] To aid in illustrating the problems addressed by various embodiments, Figure 1A shows a portion of a V2X system 100 including three vehicles 12, 14, and 16. Figure 1B shows an exemplary V2X communication protocol stack 150 suitable for implementing various embodiments. Referring to Figures 1A and 1B, each vehicle 12, 14, and 16 includes a vehicle processing system (e.g., V2X on-board equipment) 102, 104, and 106, respectively, configured to periodically broadcast basic safety messages 112, 114, and 116 for reception and processing by other on-board equipment (e.g., 102, 104, and 106). By sharing vehicle location, speed, direction, braking, and other information, vehicles can maintain safe separation and identify and avoid potential collisions. For example, a following vehicle 12 receiving a basic safety message 114 from a preceding vehicle 16 can determine the speed and location of vehicle 16, and vehicle 12 can match its speed to maintain a safe separation distance 20. When the preceding vehicle 16 applies its brakes, it is notified via a basic safety message 114, allowing the V2X device 102 in the following vehicle 12 to simultaneously apply its brakes and maintain a safe separation distance 20, even if the preceding vehicle 16 suddenly stops. As another example, the V2X device 104 in the truck vehicle 14 can receive basic safety messages 112 and 116 from the two vehicles 12 and 16, and thus be notified that the truck vehicle 14 should stop at an intersection to avoid a collision. Each of the V2X in-vehicle devices 102, 104, and 106 can communicate with each other using any of various proximity communication protocols. In addition, the vehicles may transmit data and information regarding detected basic safety messages and reports of detected malfunctions to the original equipment manufacturers (OEMs) (132, 134) and / or the remote malfunction management authority 136 via communication links 122 and 124 and a communication network 18 (e.g., cellular, WiFi, etc.). The MBR may be transmitted directly to the malfunction management authority 136 (for example, via communication link 146).In other embodiments, the MBR may first be transmitted via communication links 122, 124 to an MBR preprocessing unit such as an OEM server 132, 134 for preprocessing. The preprocessed MBR may then be transmitted from the MBR preprocessing units 132, 134 to a malfunction management authority 136 via communication links 142, 144.

[0027] Given the importance of basic safety messages to the safe driving of surrounding vehicles, care must be taken to ensure that basic safety messages are accurate and can be relied upon by other vehicles. One measure used to ensure reliability includes issuing a certificate to each V2X vehicle-mounted device that can be used to sign basic safety messages. The certificate issued to the V2X vehicle-mounted device does not contain the persistent identity of the V2X vehicle-mounted device and for this reason is typically referred to as an anonymous certificate. A malfunction management system operating within the highway monitoring system for V2X vehicle-mounted devices in nearby vehicles and basic safety podcasts can verify the authenticity of the V2X vehicle-mounted device issuing the basic safety message by verifying the signature in the broadcast message. A V2X vehicle-mounted device receiving a basic safety message can verify the signature using a public key. To defend against hacking or interference with V2X system operation, V2X vehicle-mounted devices can be configured to ignore any incoming basic safety messages signed with an expired or invalid certificate.

[0028] Signing basic safety messages using certificates issued to V2X in-vehicle devices protects against attempts to inject false basic safety messages; however, the signature verification process cannot detect cases where a malfunctioning V2X in-vehicle device generates an inaccurate basic safety message using a legitimate certificate. Various device malfunctions can cause V2X in-vehicle devices to generate incorrect basic safety messages. For example, faults in navigation sensors, speed sensors, and / or wiring from such sensors to the V2X in-vehicle device may result in inaccurate reporting of vehicle location (e.g., incorrect lane or greater error) or speed. It is also possible that a V2X in-vehicle device could be maliciously modified to generate an incorrect basic safety message signed using a legitimate certificate. Both scenarios are referred to as malfunctions.

[0029] In many cases, the receiving malfunction management system can detect malfunctions through malfunction detection during onboard processing. An incorrect basic safety message can be recognized by a malfunction management system operating in another vehicle when the information contained in such a message contradicts reliable information available to the V2X vehicle device. For example, a malfunction management system can recognize that the location information in a received basic safety message is incorrect when the reported location of the reporting vehicle overlaps with the location of the vehicle receiving the basic safety message. As another example, a malfunction management system can recognize that the speed information in a received basic safety message is incorrect when the speed is inconsistent with the speed of the device's own vehicle and surrounding vehicles. Other methods may be used to recognize incorrect basic safety messages.

[0030] To ensure the integrity and reliability of the V2X system, the malfunction management system can be configured to notify other vehicles and highway systems or authorities of detected incorrect basic safety messages by transmitting messages that inform other systems of the detected problem. In conventional systems, the receiving V2X vehicle equipment may automatically generate a malfunction report or malfunction detection report (MBR in the diagram). Each MBR may include an anonymous certificate of the malfunctioning V2X vehicle equipment that signed the incorrect basic safety message. The malfunction management system that has detected a malfunction may be configured to send the malfunction detection report for processing to a specific network backend entity, referred herein as the malfunction authority (MA) of the SCMS. The reporting V2X vehicle equipment is typically configured by the OEM, and therefore the receiving device of the malfunction report is typically operated by or in the name of the OEM of the reporting V2X vehicle equipment.

[0031] Malfunction detection reports can be collected by a malfunction authority, which may be an entity operated by any of various parties, such as a government agency, an independent third-party organization or service provider, and / or an OEM. The malfunction authority may be configured to take measures to protect the reliability and integrity of V2X systems and equipment. For example, the malfunction authority may blacklist the certificates of malfunctioning V2X in-vehicle equipment, so that other V2X in-vehicle equipment can know to ignore basic safety messages containing blacklisted certificates. A distributed malfunction authority may also notify a certificate registration authority of a certificate, so that the corresponding registration authority can take appropriate action.

[0032] The term "malfunctioning V2X vehicle device" is used herein to refer to a V2X vehicle device that is identified as the cause of a malfunction in a malfunction detection report. However, in some cases, another component or entity other than the identified V2X vehicle device may be causing the malfunction by using messages or credentialing from the V2X vehicle device. For example, a faulty sensor or device within the same vehicle as the identified V2X vehicle device may be the cause of the incorrect information in the basic safety message resulting from the malfunction detection, but there are other scenarios in which an entity outside the vehicle may be the cause of the incorrect basic safety message being transmitted.

[0033] Entities such as OEMs may utilize the Master Record Broker (MBR) for various reasons. For example, an OEM of a V2X vehicle device may be interested in viewing MBR information regarding malfunctions caused by that V2X vehicle device. In some cases, the OEM may desire this information purely for statistical purposes. In other cases, the OEM may take appropriate steps, including, but are not limited to, attempting to correct errors in the V2X vehicle device implementation, replacing the V2X vehicle device, deactivating the V2X vehicle device, informing the owner that the vehicle should be brought in for maintenance, erasing certificates from the OEM vehicle device, adding some of the OEM vehicle device certificates to the revocation list, and issuing new certificates to the V2X vehicle device. In some cases, the OEM may be able to perform such actions wirelessly, while in other cases, physical access to the V2X vehicle device is required.

[0034] As more and more vehicles are equipped with V2X devices, the amount of potential malfunctions to be detected is increasing exponentially. If a malfunction report were to be generated in response to every malfunction detected, OEMs and / or any malfunction authority would be overwhelmed by the sheer volume of MBRs. Therefore, it may be necessary to manage whether or not an MBR should be generated each time a malfunction condition is detected. Furthermore, if a malfunction management system operating within a V2X device decides to generate an MBR, the malfunction management system may need to manage whether or not to store the MBR and / or send it to a management authority within the SCMS. As malfunction management systems are becoming more sophisticated, they can receive feedback from malfunction management authorities that provide feedback to the malfunction management system, enabling the malfunction management system to improve and enhance its management of malfunction events. In particular, feedback can enable the malfunction management system to refine when an MBR should be generated in response to the detection of a malfunction, the storage of the generated MBR, and / or the transmission of the MBR to the malfunction management authority.

[0035] In V2X communication, detecting faulty data is beneficial to prevent the spread of unnecessary data between vehicles. A malfunction detection system can fulfill this role and, as a response to detection, generate a Malfunction Report (MBR). The MBR may need to be generated, stored locally, and transmitted to a trusted third party for investigation (e.g., a malfunction authority within the SCMS). The rules for generation, storage, and transmission are not trivial but can be defined to maximize usefulness and minimize overhead. For example, a malfunction detection system should not generate an MBR for each single malfunction of the same type coming from the same remote vehicle, but rather create one report and add an "occurrence" value. This saves generation time (and I / O operation), local storage space, and reduces the number of MBRs that need to be transmitted and checked by the MA. The ITS community lacks such a set of rules / algorithms for MBR management.

[0036] Various embodiments disclosed herein provide methods and mechanisms for managing the Master Builder Record (MBR). Various embodiments can determine when it is appropriate to generate a malfunction report when malfunction conditions are detected. Various embodiments can also determine when it is appropriate to store a generated malfunction report when it is generated. Various embodiments can also determine when it is appropriate to erase a previously stored malfunction report. Various embodiments can also determine when it is appropriate to send a malfunction report to a management authority. To make more efficient use of the information within the malfunction report, some embodiments can preprocess the data contained in the malfunction report.

[0037] Various embodiments may include operations that receive feedback from a management authority to correct or optimize the management of malfunction reports.

[0038] Various embodiments of the malfunction management systems can be deployed on any device capable of receiving V2X messages directly or indirectly. Therefore, the various embodiments disclosed herein can operate, to name a few, in vehicles, smartphones, roadside units, or even in built-in units located in the cloud.

[0039] To provide context and background for various embodiments, the following background information regarding the IEEE 1609 malfunction reporting processing system is given. The following description is at a high level and is given primarily to explain the roles of various authorities and functions envisioned for interactions between various entities having V2X in-vehicle equipment. Various implementations are not limited to the malfunction reporting management process described below.

[0040] The transmitting V2X device (e.g., Onboard Unit (OBU), RSU, ASD) can detect malfunction conditions and determine whether to generate, store, and / or transmit a malfunction report to the Malfunction Management Authority (MA), which can also provide such reports to the SCMS. To authenticate malfunction conditions, malfunction reports, and basic safety messages, each transmitting V2X device can attach a public key signature to each malfunction condition, malfunction report, and basic safety message, which can be verified by the public signing key in an anonymous certificate issued to the transmitting V2X onboard device.

[0041] Figure 2A is a component diagram of an exemplary vehicle system 200 suitable for implementing various embodiments. Figure 2B is a component diagram showing a malfunction management network 250 suitable for implementing various embodiments. Referring to Figures 1A to 2B, the system 200 may include a vehicle 202 including a vehicle processing system 204 (e.g., a telematics control unit or on-board unit (TCU / OBU)). In some embodiments, the system 200 may operate as part of and / or in the context of a malfunction management network 250 which includes a malfunction authority 252 and elements or functions that provide malfunction pre-processing 254. The V2X processing device 202 may communicate with various systems and devices such as an in-vehicle network 210, an infotainment system 212, various sensors 214, various actuators 216, and a wireless module 218. The V2X processing device 202 may also communicate with various other vehicles 220, roadside units 222, base stations 224, and other external devices. The vehicle processing system 204 can be configured to perform operations for authenticating plaintext and ciphertext, as further described below.

[0042] The vehicle processing device 204 may include a processor 205, a memory 206, an input module 207, an output module 208, and a wireless module 218. The processor 205 may be coupled to the memory 206 (i.e., a non-temporary storage medium) and may consist of processor-executable instructions stored in the memory 206 for performing the operations of the methods according to the various embodiments described herein. The processor 205 may also be coupled to an output module 208 that can control an in-vehicle display, and an input module 207 for receiving information from vehicle sensors and driver input.

[0043] The vehicle processing system 204 may include a V2X antenna 219 coupled to a radio module 218 configured to communicate with one or more ITS stations, such as another vehicle 220, a roadside unit 222, and a base station 224 or another suitable network access point. In various embodiments, the V2X processing device 202 may receive information from multiple sources, such as an in-vehicle network 210, an infotainment system 212, various sensors 214, various actuators 216, and the radio module 218. The V2X processing device 202 may detect malfunction conditions within the vehicle's systems, such as one of the multiple sources 210-218, an application or service running on the V2X processing device 202, or another system in the vehicle.

[0044] Examples of in-vehicle networks include Controller Area Networks (CAN), Local Interconnection Networks (LIN), networks using the FlexRay protocol, Media-Oriented Systems Transport (MOST) networks, and in-vehicle Ethernet networks. Examples of vehicle sensors include location detection systems (such as Global Navigation Satellite System (GNSS) systems), cameras, radar, lidar, ultrasonic sensors, infrared sensors, and other appropriate sensor devices and systems. Examples of vehicle actuators include various physical control systems such as steering, brakes, engine operation, lighting, and turn signals.

[0045] Figure 3 is a process flow diagram illustrating an exemplary method 300 in which the generation, storage, and transmission of the MBR are managed by a malfunction management system. Referring to Figures 1A to 3, the operation of method 300 can be carried out by the processors of the vehicle processing system (e.g., 102, 104, 106, 204).

[0046] In various embodiments, Method 300 includes operations that involve managing the generation, storage, and transmission of malfunction reports, which can be performed by a V2X device and / or a malfunction management authority.

[0047] In block 302, a malfunction management system included in the on-board V2X equipment (e.g., 102, 104, 106) can analyze (e.g., monitor and analyze) various sensor data from each of those vehicles (e.g., 12, 14, 16) to determine whether a malfunction condition has been detected. In some embodiments, the V2X equipment may also include roadside units and / or other mobile units that may be capable of monitoring and observing the behavior of each of the other vehicles to determine whether a malfunction condition exists. For example, a V2X device may receive a basic safety message from another vehicle that is inconsistent with observations that the V2X equipment in the other vehicle may be able to make. As an example, a V2X device 102 mounted on vehicle 12 may receive a basic safety message (BSM) from a V2X device 106 mounted on vehicle 16 indicating that vehicle 16 has initiated emergency braking. However, the malfunction management system of the V2X device 102 mounted on vehicle 12 may observe that vehicle 16 is not decelerating or has not applied emergency brakes. In such a situation, the BSM indicating that emergency braking is being performed is inconsistent with other sensor data monitored by the malfunction management system of the V2X device 106 mounted on vehicle 16, so the V2X device 106 mounted on vehicle 16 can detect the malfunction condition. In addition, the BSM received from the V2X device 106 mounted on vehicle 16 is inconsistent with observations made by the V2X device 102 mounted on vehicle 12, so the malfunction management system of the V2X device 102 mounted on vehicle 12, which receives the BSM from the malfunction management V2X device 106 mounted on vehicle 16, can also detect the malfunction condition. Means for performing the operation of block 302 may include vehicle processing systems 102, 104, 106, 204, processor 205, wireless module 218, and sensor 214.

[0048] In decision block 304, the processor can determine whether or not a malfunction report should be generated. In various embodiments, both the V2X device 106 installed in vehicle 16 and the V2X device 102 installed in vehicle 12 can detect malfunction conditions, but each V2X device 102, 106 can determine whether or not a malfunction report should be generated, and if so, which evidence to collect and add to the generated malfunction report. The decision to generate a malfunction report after detecting malfunction conditions may be based on several factors. For example, as will be discussed in more detail below with reference to Figures 4A and 4B, the decision to generate a malfunction report may be based on (i) the severity of the malfunction detected (the level of potential safety impact or potential disruption to road traffic), (ii) the length of the malfunction observed (this helps distinguish transient malfunctions from permanent malfunctions), (iii) the number of times a remote vehicle has been detected as malfunctioning (i.e., this helps cover sporadic malfunctions), (iv) the number of nearby vehicles (with different certificates) detected as performing similar malfunctions (this helps aggregate and report larger problems), or (v) simply since at least one detector has been triggered. Means for carrying out the operation of decision block 304 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0049] In response to a decision that a malfunction report should be generated (i.e., decision block 304 = "Yes"), the processor may generate a malfunction report in block 306. Means for performing the operation in block 306 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0050] In decision block 308, the processor can determine whether the malfunction report should be stored in memory. The decision to store the malfunction report after detecting a malfunction condition may be based on several criteria. As will be discussed in more detail below with reference to Figures 5A and 5B, the decision to store the generated malfunction report may be based on several criteria, including: (i) the accuracy level of detecting the malfunction condition; (ii) the determined message set size (for example, the malfunction to be detected requires only a certain number of messages from nearby devices); (iii) the determined storage required for the blacklisting method (note that this involves storing hashes of remote vehicle certificates in a counting Bloom filter (or Cuckoo filter)); and (iv) whether a network connection to the SCMS / PKI is available. Means for performing the operation of decision block 308 may include vehicle processing systems 102, 104, 106, 204, and processor 205.

[0051] In response to the decision that a malfunction report should not be generated (i.e., decision block 308 = "No"), the processor can again analyze (i.e., monitor and analyze) the sensor data to determine whether or not a malfunction condition is detected in block 302 as described.

[0052] In response to the decision that the malfunction report should be stored (i.e., decision block 308 = "Yes"), the processor may, in block 310, store the malfunction report in the memory storage of the malfunction management system. Means for performing the operation of decision block 308 may include vehicle processing systems 102, 104, 106, 204, processor 205, and memory 206.

[0053] When a malfunction report (MBR) is stored in block 310, and / or, optionally, in response to a decision that a malfunction report should not be generated (i.e., decision block 308 = "No"), the processor may determine in decision block 312 whether the generated malfunction report should be transmitted to a malfunction management authority (e.g., 252). Means for performing the operation of decision block 312 may include vehicle processing systems 102, 104, 106, 204, and processor 205.

[0054] In response to the decision that a malfunction report should not be stored (i.e., decision block 312 = "No"), the processor may analyze (i.e., monitor and analyze) the sensor data to determine whether a malfunction condition is detected in block 302 as described.

[0055] In some embodiments, as mentioned above, even if the malfunction management system determines that the malfunction direction should not be stored (i.e., decision block 308 = "No"), the processor may optionally determine in decision block 312 whether or not to transmit the malfunction report to the malfunction management authority.

[0056] In response to a decision that a malfunction report should be transmitted (i.e., decision block 312 = "Yes"), the processor may, in block 314, transmit the malfunction report to the malfunction management authority. Means for performing the operation of block 314 may include vehicle processing systems 102, 104, 106, 204, processor 205, and wireless module 218. The processor may then analyze (i.e., monitor and analyze) sensor data to determine whether a malfunction condition is detected in block 302 as described above.

[0057] In various embodiments, after MBR generation in block 306, the processor may determine in decision block 308 whether the MBR should be stored in local memory, or in decision block 312 whether the MBR should be transmitted, or whether both storage of the MBR in local memory and transmission of the MBR should be performed. In some situations, a vehicle may not have a network connection to transmit its MBR, and therefore the generated MBR may be stored locally. The decision to store the MBR may depend on several factors, including: (i) a malfunction is detected but with low certainty (which may allow for the collection of more evidence and increased certainty); (ii) the detector requires a larger message set (for example, a malfunction may be detected when a certain number of messages are received from nearby devices); (iii) storage is required for a blacklisting technique (the hash of the remote vehicle certificate may be stored in a counting Bloom filter or Cuckoo filter); and / or (iv) there is no network connection to an SCMS / PKI available to transmit the MBR.

[0058] In some embodiments, the malfunction management system may use artificial intelligence, neural networks, and / or machine learning techniques (collectively referred to herein as “machine learning models”) to detect the occurrence of malfunction conditions. Machine learning models may be used by the malfunction management system to analyze large amounts of data from numerous sensors and data sources to obtain an indicator or probability of whether or not a malfunction condition exists. In embodiments where the malfunction management system uses machine learning models to detect malfunction conditions, the malfunction management system can generate an MBR containing information about and / or generated by the machine learning model. This reduces the amount of data included in, stored with, and / or transmitted in the MBR compared to including all data related to or characterizing the detected malfunction condition. Therefore, in embodiments where the malfunction management system uses machine learning models to detect malfunction conditions, the malfunction management system may be configured to generate a malfunction report including one or more of the following: the machine learning model, the output of the machine learning model, the principal component analysis of the machine learning model, the intermediate representation of the machine learning model, or an identifier for the machine learning model. In embodiments where the malfunction report includes an identifier for a machine learning model, the malfunction management system operating on the V2X device and the malfunction management authority may have previously shared machine learning models and may have agreed on index values.

[0059] In addition, in embodiments where multiple stored malfunction reports may exist, the malfunction management system can set a priority order for the transmission of MBRs. For example, the priority may be based on the calculated weight of each MBR (i.e., the highest priority goes first). As will be discussed in more detail below with reference to Figure 6, MBRs can be assigned weights that may vary depending on the relative age of the MBRs. If competing MBRs have the same calculated weight values, the stored order of the MBRs can be used to determine the transmission priority. For example, a first-in, first-out (FIFO) or last-in, first-out (LIFO) scheme may be used, or, if the calculated weights are decoupled from the classification or severity of the underlying malfunction condition, the assigned classification or severity value may be used as the priority parameter.

[0060] Another transmission priority rule could be a “fairness” rule that allows a vehicle to transmit MBRs reporting about its neighboring vehicles (i.e., vehicles with different IDs). This transmission priority rule can ensure that a vehicle does not always report only one specific neighboring vehicle. Fairness can be implemented using a round-robin scheduling technique. For example, a vehicle can detect malfunction conditions occurring within its own vehicle and malfunction conditions occurring in neighboring vehicles. Referring to Figure 1, vehicle 12 (the vehicle) can detect malfunction conditions occurring within vehicle 12 as well as malfunction conditions occurring in vehicles 14 and 16. A malfunction management system operating within the V2X device 102 can generate a set of MBRs relating to the malfunction conditions occurring in each of vehicles 12, 14, and 16. In one example, a malfunction management system operating within the V2X device 102 can generate three separate MBRs relating to the malfunction conditions occurring in each of vehicles 12, 14, and 16. These MBRs are MBRs 12-1 MBR 12-2 MBR 12-3 MBR 14-1 MBR 14-2 MBR 14-3 MBR 16-1 MBR16-2 and MBR 16-3 can be identified as. Embodiments implementing "fairness" rules can ensure that the MBRs associated with each different vehicle are reported equally within a given uplink budget. Thus, the reports can be transmitted in the order of MBR 12-1 MBR 14-1 MBR 16-1 MBR 12-2 MBR 14-2 MBR 16-2 MBR 12-3 MBR 14-3 and MBR 16-3 etc.

[0061] The generated MBR can be transmitted to a central "Malfunction Management Authority" (MA) that processes the MBR. The Malfunction Management Authority can perform further analysis on the MBR and determine what enforcement activities should be taken based on the analysis. In conventional MBR management systems, the Malfunction Management Authority may not have good knowledge of the reliability or functionality of the received MBR because the reporting MBR management system may not want to reveal its own information about their functions or what they have observed, and because encryption overhead and processing redundant data can be a burden on the Malfunction Management Authority. In some embodiments, the MBR may be transmitted in an optional block 316 to a malfunction preprocessing entity (e.g., 254) (also called a malfunction processor, abbreviated as MBRPre) for preprocessing before being sent to the management authority (e.g., the Malfunction Management Authority (MA)). For example, the MBRPre (e.g., 132, 134) may be an OEM (in the case of reports received from a vehicle) or a mobile network operator (in the case of reports received from a smartphone). In some embodiments, MBRPre may have individual relationships with (e.g., be associated with) V2X devices 102, 104, and 106, which can be trusted by a central malfunction management authority 136. This relationship may enable MBR processors (e.g., 132, 134) to update the malfunction management systems operating within the V2X devices so that the malfunction management systems running on the V2X devices can send MBRs in their own format to those MBPres (e.g., 132, 134). This relationship may also enable MBPres to update the malfunction reporting format, or to create aggregate or statistical reports, and possibly transfer the original reporting materials.

[0062] For example, on-board equipment (e.g., 102, 104, 106) within vehicles 12, 14, and 16 can detect a single-overlap malfunction when observed in a location where two nearby vehicles equipped with V2X overlap. The vehicle's OEM can recognize the faulty GNSS receiver and therefore disregard or withdraw the MBR resulting from this detected condition to avoid sending a fault MBR to a specific malfunction management authority. As another example, if the OEM knows that the GNSS is not faulty, the OEM can supplement the MBR with telematics data to provide richer evidence to the malfunction management authority (e.g., 136).

[0063] Figures 4A and 4B are process flow diagrams illustrating exemplary actions for determining whether a malfunction report should be generated, which may be performed as part of Method 300. Referring to Figures 1A to 4B, the actions can be performed by the processors of the vehicle processing system (e.g., 102, 104, 106, 204).

[0064] Referring to Figure 4A, after the malfunction management system detects that a malfunction condition has occurred in block 302, in block 321 the malfunction management system can classify the detected malfunction condition. For example, a malfunction condition can be classified into one of two categories, such as a malfunction related to a potential safety problem or a malfunction related to a potential road traffic disruption. An appropriate value can be assigned to the malfunction condition to identify it as either a malfunction related to a potential safety problem or a malfunction related to a potential road traffic disruption. Means for carrying out the operation of block 321 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0065] For example, the malfunction management system of the V2X device 102 installed in vehicle 12 may receive a basic safety message (BSM) from the V2X device 106 installed in vehicle 16 indicating that vehicle 16 has initiated emergency braking. However, other sensor data and observations made by other external V2X devices, such as those in other vehicles or roadside units, may contradict the emergency braking action. Such malfunction conditions could cause other vehicles to unnecessarily perform sudden braking actions that could lead to accidents. Therefore, malfunction conditions may be classified as relating to potential safety issues.

[0066] In another example, a vehicle's Global Positioning System (GPS) may miscalculate its location. This miscalculation could cause a particular road / street to incorrectly report more vehicles on it than are actually present. Such misreports could be linked to potential road traffic disruption. Furthermore, miscalculated vehicle locations could be linked to potential safety issues. For example, if a vehicle's GPS calculates and reports a vehicle's location as being in the wrong lane (i.e., on the wrong side of the road / street), other vehicles might be misled into taking evasive maneuvers to avoid the "phantom" vehicle whose location is being misreported. This could lead to potential safety issues.

[0067] In some embodiments, malfunction conditions may be classified as either malfunctions related to potential road traffic disruption or malfunctions related to potential road traffic disruption, while in other embodiments, malfunction conditions may be assigned a value on a single sliding scale. For example, malfunction conditions related to safety issues that could result in serious harm may be assigned a high value. Malfunction conditions related only to road traffic disruption may be assigned a low value. Other malfunction conditions that may be related to both potential safety issues and potential road traffic disruption may be assigned an intermediate value based on the relative potential harm of the malfunction condition compared to the inconvenience.

[0068] In block 323, the processor can determine the observed duration of a malfunction condition and assign a value based on the observed duration. For example, in some cases, a malfunction condition may be a transient anomaly that triggers the detection of a malfunction. However, in other cases, a malfunction condition may be persistent. For instance, if a malfunction condition occurs only for a short period of time at a particular location, this may be evidence of malicious hacking within a particular area affecting vehicles traveling within that area. In contrast, a persistent malfunction may be the result of a sensor failure that continuously reports incorrect data. Whether the duration of the malfunction condition is short or long may be important to the MBR management system. How the malfunction management system decides to respond to the observed duration (i.e., long vs. short) of the malfunction condition may be subjective. In any case, the observed duration of the detected malfunction may be assigned a value to be taken into consideration in determining whether or not an MBR should be generated. Means for carrying out the operation of block 323 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0069] In block 325, the processor can determine the number of times a detected malfunction has occurred and can assign a value based on the number of detected malfunctions. For example, if the malfunction management system consistently and repeatedly detects the same malfunction, this may indicate that the sensor needs repair or replacement. Thus, multiple occurrences of a detected malfunction can be assigned a value (higher or lower) that may lead to a decision that an MBR will be generated. Means for carrying out the operation of block 325 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0070] In block 327, the processor can determine the number of nearby vehicles experiencing a malfunction. As discussed in the example above, the malfunction management system of the V2X device 102 installed in vehicle 12 may receive a Basic Safety Message (BSM) from the V2X device 106 installed in vehicle 16 indicating that vehicle 16 has initiated emergency braking. However, other sensor data and observations made by other external V2X devices, such as those in other vehicles or roadside units, may contradict the emergency braking. The malfunction management system of vehicle 12 may receive a V2X communication from the malfunction management system of the V2X device 106 installed in vehicle 16, notifying the V2X device 102 of observations made by the V2X device 106 installed in vehicle 16. Such indications from nearby vehicles regarding the same detected malfunction condition can further support the level of confidence of the malfunction management system of vehicle 12 that the malfunction condition was accurately detected. Such instructions from nearby vehicles can be recorded and added as evidence of the detection of the malfunction condition. The malfunction management system can assign a value to the malfunction condition based on the number of nearby vehicles experiencing the same malfunction. For example, if there are many other nearby vehicles experiencing the same malfunction, this can increase the likelihood that the malfunction condition will be accurately detected. Means for carrying out the operation of block 327 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0071] In block 329, the processor may aggregate values ​​assigned by the processor based on the classification of the detected malfunction conditions (for example, in the operation of block 321), the observed length of the detected malfunction (for example, in the operation of block 323), the number of times the detected malfunction occurred (for example, in the operation of block 325), and the number of nearby vehicles experiencing the malfunction (for example, in the operation of block 327), in order to calculate an aggregate value of the detected malfunction conditions. Means for performing the operation of block 329 may include vehicle processing systems 102, 104, 106, 204, and processor 205.

[0072] In the decision block 330, the processor can determine whether the aggregated value exceeds a threshold. The means for performing the operation of the decision block 330 may include the vehicle processing systems 102, 104, 106, 204 and the processor 205.

[0073] In response to the determination that the aggregate value exceeds the threshold (i.e., determination block 330 = "Yes"), the processor can generate the MBR that may be generated in block 306 as described.

[0074] In response to the determination that the aggregated value does not exceed the threshold (i.e., decision block 330 = "No"), the processor can analyze (i.e., monitor and analyze) the sensor data to determine whether a malfunction condition is detected in block 302 as described.

[0075] In some embodiments, the values ​​assigned to each criterion used to determine whether or not an MBR should be generated may be lower for more serious conditions that guarantee the generation of an MBR. In such embodiments, an aggregate value lower than the threshold will exceed the threshold. In other embodiments, the values ​​assigned to each criterion used to determine whether or not an MBR should be generated may be higher for more serious conditions that guarantee the generation of an MBR. In such embodiments, an aggregate value higher than the threshold will exceed the threshold.

[0076] Figure 4B shows alternative operations that may be performed by the processors of the vehicle processing system (e.g., 102, 104, 106, 204) to determine whether an MBR should be generated in decision block 304 (Figure 3) in response to the detection of a malfunction condition. The processors may perform operations as described above, such as classifying the detected malfunction condition in block 321, determining the observed duration of the detected malfunction in block 323, determining the number of occurrences of the detected malfunction in block 325, and determining the number of nearby vehicles experiencing the malfunction in block 327). In addition, after performing the operations in blocks 321, 323, 325, and 327, the processors may determine whether the assigned values ​​for each criterion exceed a threshold that may generate an MBR.

[0077] For example, after classifying the malfunction conditions detected in block 321 as described (which may include assigning values ​​based on the classification of the detected malfunction conditions), the processor can determine whether the value assigned in decision block 322 exceeds a threshold. Means for performing the operation of decision block 322 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0078] In response to a determination that the assigned value based on classification exceeds the threshold (i.e., determination block 322 = "Yes"), the malfunction management system may generate the MBR in block 306 as described. In response to a determination that the assigned value based on classification does not exceed the threshold (i.e., determination block 322 = "No"), the processor may perform the operation in block 323 as described.

[0079] After determining the observed length of the malfunction condition detected in block 323 (which may include assigning a value based on the observed length of the detected malfunction condition), the processor can determine in determination block 324 whether the assigned value based on the observed length exceeds a threshold. Means for performing the operation of determination block 324 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0080] In response to the determination that the assigned value exceeds the threshold (i.e., determination block 324 = "Yes"), the processor can generate the MBR in block 306 as described.

[0081] In response to the determination that the value assigned based on the observed length does not exceed the threshold (i.e., decision block 324 = "No"), the processor may perform the operation of block 325 as described.

[0082] After determining the number of occurrences of the malfunction condition detected in block 325 (which may include assigning a value based on the number of occurrences of the detected malfunction condition), the processor can determine in determination block 326 whether the assigned value based on the number of occurrences exceeds a threshold. Means for performing the operation of determination block 326 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0083] In response to the determination that the assigned value exceeds the threshold (i.e., determination block 326 = "Yes"), the processor may generate the MBR in block 306 as described.

[0084] In response to the determination that the value assigned based on the number of occurrences of the detected malfunction condition does not exceed the threshold (i.e., determination block 326 = "No"), the processor may perform the operation of block 327 as described.

[0085] After determining the number of nearby vehicles experiencing the same malfunction condition detected in block 327 (which may include assigning a value based on the number of nearby vehicles experiencing the same malfunction condition), the processor can determine in determination block 328 whether the assigned value based on the number of nearby vehicles experiencing the same malfunction condition exceeds a threshold. Means for performing the operation of determination block 328 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0086] In response to the decision that the assigned value exceeds the threshold (i.e., decision block 328 = "Yes"), the processor can generate the MBR in block 306 as described.

[0087] In response to the determination that the value assigned based on the number of nearby vehicles experiencing the same detected malfunction conditions does not exceed the threshold (i.e., determination block 326 = "No"), the malfunction management system can analyze (e.g., monitor and analyze) various sensor data for each of those vehicles in block 302 as described.

[0088] Figures 5A and 5B are process flow diagrams illustrating exemplary operations for determining whether a malfunction report should be stored by a malfunction management system, which may be performed as part of Method 300. Referring to Figures 1A to 5B, the operations can be performed by a processor in the vehicle processing system (e.g., 102, 104, 106, 204).

[0089] Referring to Figure 5A, after the MBR is generated in block 306 as described, the processor can determine whether the MBR should be stored in memory. Given the limited memory capacity and the amount of potential malfunction conditions that may be detected, the processor of the malfunction management system can determine which of the generated MBRs should be stored in memory. For example, similar to the determination of whether or not to generate an MBR for a detected malfunction condition shown in Figure 4A, the processor can consider and determine several criteria related to the storage of the generated MBRs and assign values ​​to the generated MBRs for specific criteria. In some embodiments, the processor can aggregate the assigned values ​​and determine whether the aggregated values ​​exceed a threshold. In response to the determination that the aggregated values ​​exceed a threshold, the processor can store the MBR generated in block 310 as described.

[0090] For example, after the MBR is generated in block 306 as described, the processor can determine in block 331 the confidence level of the detected malfunction condition, which is the subject of the generated MBR. In various embodiments, the more data points used by the processor, the higher the confidence level of the detected malfunction condition that the processor can determine. As an example, the number of nearby vehicles can provide an indicator of their observations that a Basic Safety Message (BSM) received from another vehicle is inaccurate. If a large number of nearby vehicles provide observations that the BSM is inaccurate (which may include, for example, supporting evidence), the confidence level of detecting the malfunction condition may be relatively high. As another example, if conflicting sensor data is received from multiple sensors on a vehicle, the processor may conclude that a malfunction condition has occurred. As yet another example, if the data from a particular sensor is a clear outlier (for example, if an overwhelming number of other sensor data contradicts the data from that particular sensor), the processor may conclude with relatively high confidence that a malfunction condition has occurred. In various embodiments, such as any of these examples, a confidence value can be assigned to the detected malfunction condition. Means for performing the operation of block 331 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0091] In block 333, the processor can determine whether additional messages from nearby vehicles are needed to support the MBR. In some embodiments, the processor can determine whether it has enough information available to evaluate the malfunction report, or whether further information is needed. In some embodiments, the processor can determine the number of additional messages that may be needed to support the MBR (e.g., to provide evidence or examples of the MBR). For example, the processor may receive instructions from nearby vehicles that each of their observations contradicts the BSM received from the initial vehicle. Each of these instructions can support and enhance the level of confidence at which the malfunction condition is accurately detected. However, each of these additional messages appended to the data supporting the MBR increases the size of the MBR to be stored and consumes valuable storage space. In some embodiments, the processor can balance the storage that may be consumed by the additional data with the usefulness of the information in the additional data. In some embodiments, the processor can determine that such a large MBR with additional messages from nearby vehicles is too large to store (e.g., the size of the MBR is above a threshold). In some embodiments, such an MBR may be assigned a value that is too large to support the decision that the MBR should be stored. However, in other embodiments, such an MBR with supporting evidence may be assigned a value that supports a greater likelihood that the MBR will be stored. Means for carrying out the operation of block 333 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0092] In block 335, the processor can determine whether a communication link to the malfunction management authority is available. For example, if a communication link to the malfunction management authority is available, the processor can transmit the MBR to the remote malfunction management authority for analysis and storage in response to the MBR being transmitted to the remote malfunction management authority, and the processor can determine that it is unnecessary to store the MBR locally in the V2X device. Thus, when a communication link to the malfunction management authority is available, the processor can assign a value to the MBR report that supports not storing the MBR locally. Means for carrying out the operation of block 335 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0093] In block 337, the processor can aggregate values ​​to calculate the MBR aggregate value based on the accuracy level of the detected malfunction condition (block 331), whether additional messages from nearby vehicles are required in block 333 and / or the number of messages required from nearby vehicles, and whether a communication link to the malfunction management authority in block 335 is available. Means for performing the operation of block 337 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0094] In decision block 339, the processor can determine whether the aggregated value exceeds a threshold (for example, whether to guarantee that the aggregated value will be stored in the MBR).

[0095] In response to a decision that the aggregate value guarantees the storage of the MBR (for example, in response to a decision that the aggregate value exceeds a threshold) (i.e., decision block 339 = "Yes"), the processor may store the MBR in block 310 as described.

[0096] In response to the decision that the aggregated value guarantees storage in the MBR (for example, in response to the decision that the aggregated value does not exceed a threshold (i.e., decision block 339 = "No")), the processor analyzes (i.e., monitors and analyzes) the sensor data to determine whether a malfunction condition is detected in block 302 as described.

[0097] In some embodiments, the values ​​assigned to each criterion used to determine whether or not the MBR should be stored may be lower for more stringent conditions that guarantee the storage of the MBR. In such embodiments, an aggregate value lower than the threshold will exceed the threshold. In some embodiments, the values ​​assigned to each criterion used to determine whether or not the MBR should be stored may be higher for more stringent conditions that guarantee the storage of the MBR. In such embodiments, an aggregate value higher than the threshold will exceed the threshold.

[0098] Figure 5B shows alternative operations that may be performed by the processors of the vehicle processing system (e.g., 102, 104, 106, 204) to determine whether or not the MBR should be stored in decision block 308 (Figure 3). The processors may perform operations as described above, such as determining the probability level of the detected malfunction condition in block 331, determining the number of nearby vehicles experiencing the malfunction condition in block 333, and determining whether or not a communication link to the malfunction management authority is available in block 335). In addition, after performing the operations in blocks 331, 333, 335, and 337, the processors may determine whether the assigned values ​​for each criterion exceed a threshold that would allow the MBR to be stored.

[0099] For example, after determining the accuracy level of the malfunction condition detected in block 331 as described (which may include assigning a value based on the accuracy level of the detected malfunction condition), the processor can determine whether the value assigned in determination block 332 exceeds a threshold. Means for performing the operation of block 332 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0100] In response to a determination that the assigned value based on the accuracy level exceeds the threshold (i.e., determination block 332 = "Yes"), the processor may store the MBR in local memory in block 310 as described.

[0101] In response to the determination that the assigned value based on the classification does not exceed the threshold (i.e., decision block 332 = "No"), the processor can perform the operation of block 333 as described.

[0102] After determining in block 333 whether additional messages from nearby vehicles are required to support the MBR (which may include assigning a value based on the number of nearby vehicles experiencing the detected malfunction condition), the processor can determine in determination block 334 whether the assigned value based on the number of nearby vehicles exceeds a threshold. Means for performing the operation of determination block 334 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0103] In response to the determination that the assigned value exceeds the threshold (i.e., determination block 334 = "Yes"), the processor may store the MBR in local memory in block 310 as described.

[0104] In response to a determination that the value assigned based on the number of nearby vehicles does not exceed a threshold (i.e., determination block 334 = "No"), the processor may determine in block 335 whether a communication link to the malfunction management authority is available. Means for performing the operation of block 335 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0105] In response to the decision that a communication link to the malfunction management authority is available (i.e., decision block 335 = "Yes"), the processor may transmit the MBR to the malfunction management authority in block 314 as described.

[0106] In response to a decision that a communication link to the malfunction management authority is unavailable (i.e., decision block 335 = "No"), the processor may store the MBR in local memory in block 310 as described.

[0107] In some embodiments, in addition to deciding whether or not to store an MBR, the processor may determine whether or not to erase or flush a stored MBR to make room for a more recently generated MBR. To facilitate this decision, the processor may assign a calculated weight to each stored MBR. Additionally or alternatively, the processor may use the calculated weights to determine the transmission priority of a particular MBR. For example, in decision block 312, the processor may prioritize one stored MBR over another based on the calculated weight assigned to each stored MBR.

[0108] Figure 6 is a process flow diagram showing an exemplary operation 600 for calculating the weights of generated malfunction reports, which may be performed as part of method 300. Referring to Figures 1A to 6, operation 600 can be performed by a processor in the vehicle processing system (e.g., 102, 104, 106, 204).

[0109] In some embodiments, the processor may calculate the weights of the MBR after it has been generated or after the generated MBR has been stored.

[0110] After a malfunction report is generated in block 306 as described, or after the MBR is stored in memory in block 310 as described, the processor can classify the detected malfunction conditions, which are the subject of the MBR generated in block 321 as described.

[0111] In block 343, the processor may assign initial weight values ​​to malfunction conditions to identify them as either malfunctions related to a potential safety issue or malfunctions related to a potential road traffic disruption. In some embodiments, malfunction conditions may be classified as either malfunctions related to a potential road traffic disruption or malfunctions related to a potential road traffic disruption, while in other embodiments, the processor may assign initial weight values ​​on a sliding scale. For example, malfunction conditions related to a safety issue that could cause serious harm may be assigned relatively high initial weight values, and malfunction conditions related only to road traffic disruption may be assigned relatively low initial weight values. Other malfunction conditions that may be related to both a potential safety issue and a potential road traffic disruption may be assigned intermediate initial weight values ​​based on the relative potential harm of the malfunction condition compared to the inconvenience. Other factors may influence the assigned initial weights. For example, if multiple instances of the same malfunction are observed from the same source, each instance of the malfunction may be weighted differently. In some embodiments, the initial weights may depend not only on the MBR classification but also on how severe the underlying malfunction is, and / or on how much it exceeds the reporting threshold. For example, if the yaw rate should be consistent with velocity and lateral acceleration, in response to a determination that the inconsistency is 25%, the processor may assign a higher initial weight than the inconsistency determined to be 5%. In some embodiments, aggregate values ​​that can be calculated (e.g., in the operation of block 329 (Figure 4A)) may be used as the initial weights assigned to the malfunction conditions. For example, the values ​​assigned to the malfunction conditions detected by the processor may include values ​​based on one or more of the following: the classification of the detected malfunction condition in block 321, the observed length of the detected malfunction in block 323, the number of occurrences of the detected malfunction in block 325, and / or the number of nearby vehicles experiencing the malfunction in block 327.

[0112] In block 345, the processor can assign a damping coefficient to the MBR. In some embodiments, the damping coefficient may be a value greater than 0 and less than 1. In some embodiments, the damping coefficient can be associated with a predetermined time interval. For example, the predetermined time interval may be several hours, several days, a week, or a month. In some embodiments, a shorter predetermined time interval may be required to generate a larger number of MBRs. In other embodiments, a smaller damping coefficient may be used to reduce the number of MBRs that can be used for storage and / or transmission. In some embodiments, a combination of a shorter predetermined time interval and a smaller damping coefficient can facilitate a reduction in the overall number of MBRs that are determined (identified, selected) by the processor for storage and / or transmission. Means for carrying out the operation of block 345 may include vehicle processing systems 102, 104, 106, 204, and the processor 205.

[0113] In block 347, the processor can calculate the initial weights of the MBR, which can be calculated by multiplying the assigned initial weight values ​​of the MBR by the damping coefficient. Means for carrying out the operation of block 347 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0114] In block 349, the processor can store the calculated weights together with the associated MBR. In some embodiments, the processor can use counters, timers, and / or clocks to measure predetermined time intervals. Means for carrying out the operation of block 349 may include vehicle processing systems 102, 104, 106, 204, and processor 205.

[0115] In the decision block 351, the processor can determine whether a predetermined time interval has elapsed. The means for performing the operation of block 351 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0116] In response to a determination that a predetermined time interval has not elapsed (i.e., determination block 351 = "No"), the processor can again determine in determination block 351 whether or not a predetermined time interval has elapsed.

[0117] In response to a determination that a predetermined time interval has elapsed (i.e., determination block 351 = "Yes"), the processor may recalculate the MBR weights in block 353. In some embodiments, to recalculate the malfunction report weights, previously calculated weight values ​​may be retrieved from storage and multiplied by a damping coefficient. Means for performing the operation of block 353 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0118] The malfunction management system can again store the calculated weights along with the associated MBR in block 349, as described. In some embodiments, once the calculated or recalculated weight values ​​are stored, these values ​​can be evaluated by other processes / decisions regarding whether the MBR should be stored, erased, and / or transmitted based on the stored calculated weight values.

[0119] Figure 7 is a process flow diagram showing an exemplary operation 700 for determining which stored malfunction reports can be erased, which may be performed as part of method 300. Referring to Figures 1A to 7, operation 700 can be performed by a processor in the vehicle processing system (e.g., 102, 104, 106, 204). In some embodiments, operation 700 includes a flash / erase process that may utilize the calculated weights of the MBR.

[0120] As explained, after the MBR is stored in block 310, the processor can determine in decision block 361 whether the remaining storage space falls below a threshold. For example, the processor can audit the remaining available storage space in local memory.

[0121] In response to a determination that the remaining storage space falls below a threshold amount (i.e., determination block 361 = "Yes"), the processor may, in block 363, erase the stored MBR reports. In some embodiments, the processor may erase one or more MBRs in several ways, for example, such as: (i) first-in, first-out (FIFO), (ii) least severe / hazardous / destructive first, (iii) duplicates first (assuming MBRs were generated to report the same source ID and the same malfunction, the system can aggregate MBRs before erasing older duplicates), and / or (iv) based on their individual current weights. In some embodiments, the processor may select the MBRs to erase based on one or more of the stored order (i.e., FIFO or LIFO), the classification type of the MBRs, the number of MBRs reporting the same duplicate malfunction condition, or the calculated weight of the malfunction as calculated (for example, as part of operation 600 in Figure 6). In some embodiments, the processor may select the MBRs to erase in a FIFO or LIFO manner. In some embodiments, the processor may clear stored MBRs such that only MBRs reporting inconveniences of potential road traffic disruption are cleared. In this way, any MBRs related to safety issues are retained. In some embodiments, the processor may clear reports containing duplicate malfunctions. In some embodiments, the processor may aggregate values ​​representing any and / or all of the factors described above. In some embodiments, the processor may select (determine, identify) which MBRs to clear based on such aggregate values ​​of factors. Means for carrying out the operation of block 363 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0122] In response to the determination that the remaining storage space exceeds the threshold amount (i.e., determination block 361 = "No"), the processor can analyze (i.e., monitor and analyze) various sensor data from each of those vehicles (e.g., 12, 14, 16) to determine whether a malfunction condition is detected in block 302 as described.

[0123] In some embodiments, as an alternative to erasing the MBR, the processor may offload the MBR to another storage or module (e.g., a smartphone, edge device, or other vehicle) (i.e., move the stored MBR). In some embodiments, the processor may encrypt and / or electronically sign each MBR (i.e., generate an electronic signature on or based on the MBR). In some embodiments, the processor may use rules, such as erasure or transmission rules, to determine or select which MBRs to offload.

[0124] Figure 8 is a process flow diagram showing an exemplary operation 800 for setting a threshold in a feedback signal, which may be performed as part of method 300. Referring to Figures 1A to 8, operation 800 can be performed by a processor of the vehicle processing system (e.g., 102, 104, 106, 204). In some embodiments, when the MBR is transmitted to a central malfunction management authority such as an SCMS, the manner in which the MBR management system generates the MBR, stores the MBR, and determines whether or not to transmit the MBR may be modified.

[0125] As described, after transmitting a malfunction report to the malfunction management authority in block 314, the processor may receive feedback from the central malfunction management authority, such as an SCMS, in block 371. In some embodiments, this feedback may be included in a message sent from the central malfunction management authority to the vehicle malfunction management system, confirming or denying the existence of a malfunction condition event. For example, the feedback message may include a Boolean / binary value indicating whether the MBR content transmitted by the processor is correct (e.g., a response value equal to true) or incorrect (e.g., a response value equal to false). Means for performing the operation of block 371 may include vehicle processing systems 102, 104, 106, 204, processor 205, and wireless module 218.

[0126] In some embodiments, the processor can update its initial weight coefficients based on feedback from the administrative authority. For example, if the malfunction management system does not agree with the local detection system, the processor can lower the confidence level of that local detection system.

[0127] In some embodiments, in response to feedback received from a central malfunction management authority, the processor may modify one or more coefficients that the processor uses to make its various decisions. For example, thresholds that can result in decisions to generate, store, and / or transmit may be modified based on feedback from the central malfunction management authority. For example, as mentioned above, in various decisions, the processor may assign different weights and values ​​to different factors based on how the processor decides to emphasize certain factors over others. For example, in some embodiments, the repeated occurrence of the same malfunction condition may be caused by a sensor failure and can be ignored as a minor inconvenience. In such embodiments, recurring occurrences may be given a low priority value.

[0128] In an optional block 373, the processor may adjust one or more generation thresholds that control the generation of malfunction reports based on feedback received from the administrative authority. Means for performing the operation of block 373 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0129] In an optional block 375, the processor may adjust one or more memory thresholds that control the storage of generated malfunction reports based on feedback received from the administrative authority. Means for performing the operation of block 375 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0130] In an optional block 377, the processor may adjust a transmission threshold that controls the transmission of generated or stored malfunction reports. Means for performing the operation of block 377 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0131] The processor can then analyze (e.g., monitor and analyze) various sensor data from each of those vehicles (e.g., 12, 14, 16) to determine whether or not a malfunction condition is detected in block 302 as described.

[0132] For example, referring to Figures 4A, 4B, and 8, the malfunction management authority may provide feedback to the processor, based on the thresholds used to evaluate the malfunction conditions, so that only the malfunction conditions associated with the most serious safety conditions and / or malfunction conditions that persist over a long period of time result in the generation of an MBR. In some embodiments, feedback from the malfunction management authority may inform the processor that a particular type of malfunction is minor and therefore a report identifying that particular malfunction condition should not be generated.

[0133] An example of a method according to one embodiment is disclosed as follows: A vehicle 12 equipped with a V2X device 102 may receive a basic safety message with erroneous data. A local malfunction detection system may analyze the BSM and conclude that a remote source A (e.g., vehicle 14) is malfunctioning and notify that the source is transmitting a false location which may trigger a false electronic emergency brake light warning. A malfunction management system decides to generate a malfunction report (MBR-A). The malfunction management system (i.e., vehicle processor) may collect evidence (such as the BSM of vehicle 12 itself, the BSM from the remote source, and a list of triggered detectors) and classify the malfunction condition as a “false motion state” and a severity value of “high”. The malfunction management system (i.e., vehicle processor) may then decide to store the MBR-A with an initial weight value of 1 and a damping coefficient of 0.1. Vehicle 12, equipped with V2X device 102, does not have a connection to the SCMS (for uploading the MBR), and therefore, vehicle 12 equipped with V2X device 102 must wait until it can transmit it. The next day (for example, after a predetermined time interval of one day), the malfunction management system may apply a damping factor to the MBR, reducing its priority to 0.9. Vehicle 12 equipped with V2X device 102 may detect another malfunction condition from a different remote source B (for example, vehicle 16). The malfunction condition from source B is a position jump within the communication range, but the processor may determine that this malfunction condition is not safety critical. Therefore, the processor may store MBR-B with a priority value of 0.5 and a damping factor of 0.2. Vehicle 12 equipped with V2X device 102 can establish a connection to the SCMS and upload its stored MBR according to the priority values ​​of MBR-A->MBR-B. The malfunction management system (i.e., the vehicle processor) can store records of identifiers A and B for the purpose of blacklisting them. The processor can erase MBR-A and MBR-B after receiving an acknowledgment of successful upload.Optionally, after two days, the malfunction management authority can complete its malfunction investigation and provide feedback to the MBR management system. Vehicle 12 equipped with V2X device 102 can receive notification that MBR-A was accurate but MBR-B was not. The vehicle's malfunction management system can adjust its generation / storage / transmission parameters accordingly, and the local malfunction detection system can be configured with the adjusted internal parameters.

[0134] Figure 9 is a block diagram of an exemplary system 900 for local malfunction message filtering. Referring to Figures 1A to 9, system 900 may include a V2X communication module 902, a local malfunction prevention system 904, a local malfunction detection system 906, and a local malfunction reporting system 908, and / or all of them may be instantiated or implemented by hardware, software, or a combination of hardware and software (for example, by the components shown in Figures 11 and 12).

[0135] The V2X communication module 902 may include a V2X antenna and may be configured to communicate, for example, with one or more ITS stations 920 and malfunction management entities 930 via wireless signals. The V2X communication module 902 may receive V2X messages from one (or more) ITS stations 920. The V2X communication module 902 may also send V2X messages to ITS stations 920. The V2X communication module 902 may receive CRLs from malfunction management entities 930.

[0136] The local malfunction detection system 906 can detect V2X messages that contain incorrect or false information. The local malfunction detection system 906 can determine whether the incorrect information is unintentional (e.g., incorrect information reported by a malfunctioning sensor) or intentional (e.g., malicious information or information provided by a hacked V2X device).

[0137] The local malfunction reporting system 908 can generate a malfunction report (MBR) indicating the detected malfunction and transmit it to the V2X communication module 902 for transmission to the malfunction management entity 930. The local malfunction reporting system 908 can also transmit the MBR to the local malfunction prevention system 904.

[0138] The local malfunction prevention system 904 can implement filtering or firewall functions to prevent V2X messages having detected malfunction conditions from being further processed by the local malfunction detection system 906. In some embodiments, the local malfunction prevention system 904 may be configured to have a local blocklist. The local blocklist may include station identifiers of ITS stations (e.g., 920) that have sent incorrect or false V2X messages. The V2X processing device may be configured to determine whether a station identifier associated with an incoming V2X message exists in the local blocklist, and whether, in response to the determination that a station identifier associated with another incoming V2X message exists in the local blocklist, the V2X message should be blocked from further processing (e.g., by the local malfunction detection system 906).

[0139] In some embodiments, the local malfunction reporting system 908 may include an interface that allows the system administrator 940 to control various functions. For example, the system administrator 940 may selectively enable or disable the provision of the MBR to the local malfunction prevention system 904. In some embodiments, the system administrator 940 may enable or disable the addition of station identifiers to the local block list. In some embodiments, if the reporting function is disabled and as a result the local malfunction reporting system 908 does not send a report to the local malfunction prevention system 904, the local malfunction prevention system 904 may populate the local block list with data using the information provided by the malfunction management entity 930.

[0140] Figure 10A is a process flow diagram of an exemplary method 1000A for local malfunction message filtering in various embodiments. Referring to Figures 1A to 10A, the operation of method 1000A may be carried out by a vehicle-to-everything (V2X) processing device ("processor") including hardware, software, or a combination of hardware and software, such as those shown in Figures 9, 11, 12, and 13.

[0141] In block 1002, the V2X processing device can receive V2X messages from an Intelligent Transportation System (ITS) station. Means for performing the operation of block 1002 may include vehicle processing systems (e.g., V2X on-board equipment) 102, 104, 106, 204, a processor 205, and a wireless module 218.

[0142] In block 1004, the V2X processing device can analyze information in the received V2X message to detect malfunction conditions as described herein. Means for performing the operation of block 1004 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0143] In block 1010, the V2X processing device can, in response to the detection of a malfunction condition in a V2X message in block 1010, add the station identifier associated with the V2X message having the detected malfunction condition to the local block list. Means for performing the operation of block 1010 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0144] In block 1012, the V2X processing device can transmit a malfunction report to a management entity (e.g., a malfunction management entity 930). In some embodiments, adding a station identifier associated with a V2X message having detected malfunction conditions to a local block list (e.g., block 1012) may be performed when the malfunction report is transmitted to the management entity. Means for performing the operation of block 1012 may include vehicle processing systems (e.g., V2X on-board equipment) 102, 104, 106, 204, a processor 205, and a wireless module 218.

[0145] The V2X processing device can then receive V2X messages from the ITS station again in block 1002, as described.

[0146] Figure 10B is a process flow diagram of an exemplary method 1000B for local malfunction message filtering in various embodiments. Referring to Figures 1A to 10B, the operation of method 1000B may be carried out by a vehicle-to-everything (V2X) processing device including hardware, software, or a combination of hardware and software, such as those shown in Figures 9, 11, 12, and 13.

[0147] In block 1002, the V2X processing device can receive V2X messages from an Intelligent Transportation System (ITS) station as described.

[0148] In block 1004, the V2X processing device can analyze information in the received V2X message to detect malfunction conditions as described herein.

[0149] In the optional decision block 1006, the V2X processing device can, in some embodiments, determine whether a station identifier should be added to the local block list. For example, a system administrator (e.g., system administrator 940) can enable or disable the function to add the station identifier of a detected malfunction condition to the local block list. In such embodiments, based on whether the function to automatically add the station identifier of a detected malfunction condition to the local block list is enabled or disabled, the V2X processing device (e.g., local malfunction detection system 906) can analyze the information in the received V2X message to detect the malfunction condition. Means for performing the operation of the optional decision block 1006 may include vehicle processing systems 102, 104, 106, 204, and processor 205.

[0150] In response to the decision that the station identifier should be added to the local block list (i.e., decision block 1006 = "Yes"), the V2X processing device may, as described, in response to the detection of a malfunction condition in the V2X message in block 1010, add the station identifier associated with the V2X message having the detected malfunction condition to the local block list.

[0151] In response to a decision that the station identifier should not be added to the local block list (i.e., decision block 1006 = "No") or a subsequent execution of the action in block 1010, the V2X processing device may transmit a malfunction report to a management entity (e.g., malfunction management entity 930) in response to the detection of a malfunction condition in the V2X message in block 1012, as described. In some embodiments, adding the station identifier associated with the V2X message having the detected malfunction condition to the local block list (e.g., block 1012) may be performed when the malfunction report is transmitted to the management entity.

[0152] In decision block 1014, the V2X processing device can determine whether a station identifier associated with another received V2X message exists in the local block list. For example, when a V2X processor receives another (second) V2X message, the V2X processor can determine whether a station identifier (e.g., a message certificate) associated with the second V2X message exists on the local block list. Means for performing the operation of decision block 1014 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0153] In response to a determination that no station identifier associated with another received V2X message exists in the local block list (i.e., determination block 1014 = "No"), the V2X processing device may permit processing of the V2X message in block 1016. For example, the V2X processing device may permit further processing of the V2X message by the local malfunction detection system 906. Means for performing the operation in block 1016 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0154] In response to a determination that a station identifier associated with another received V2X message exists in the local block list (i.e., determination block 1014 = "Yes"), in some embodiments, the V2X processing device can determine in an optional block 1018 the type of malfunction associated with the station identifier present in the local block list. For example, the V2X processing device can determine whether the malfunction associated with the station identifier is intentional or unintentional. Means for performing the operation of optional block 1018 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0155] In an optional block 1020, the V2X processing device can determine the block duration based on the type of malfunction. For example, the V2X processing device may determine a relatively short duration for unintentional malfunctions. Alternatively, the V2X processing device may determine a relatively long duration for intentional malfunctions. Means for performing the operation of the optional block 1020 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0156] In various embodiments, after performing an operation of an optional block 1020, or in response to a determination that a station identifier associated with another received V2X message exists in the local block list (i.e., determination block 1014 = "Yes"), the V2X processing device may block the V2X message in block 1022 from further processing (e.g., by the local malfunction detection system 906). Means for performing the operation of block 1022 may include vehicle processing systems 102, 104, 106, 204, and processor 205.

[0157] After performing the operation of block 1016 or block 1022, the V2X processing device can receive a CRL containing one or more station identifiers in block 1024. Means for performing the operation of block 1024 may include vehicle processing systems 102, 104, 106, 204, processor 205, and radio module 218.

[0158] In block 1026, the V2X processing device can update the local block list based on one or more station identifiers in the CRL. In some embodiments, the V2X processing device can remove one or more station identifiers that do not exist in the CRL from the local block list. As another example, the V2X processing device can retain or add one or more station identifiers that exist in the CRL to the local block list. Means for performing the operation of block 1026 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0159] The V2X processing device can perform the operation of method 1000B continuously or periodically by repeating the operation of receiving V2X messages in block 1002. In various embodiments, the V2X processing device may occasionally repeat the operations of blocks 1002 to 1026.

[0160] Figure 10C is a process flow diagram of an exemplary method 1000C for local malfunction message filtering in various embodiments. Referring to Figures 1A to 10C, the operation of method 1000C may be carried out by a vehicle-to-everything (V2X) processing device including hardware, software, or a combination of hardware and software, such as those shown in Figures 9, 11, 12, and 13.

[0161] In block 1052, the V2X processing device can receive V2X data. The V2X data may include V2X messages from an ITS station (e.g., 920) or CRLs from a malfunction management entity (e.g., 930). Means for performing the operation of block 1052 may include vehicle processing systems 102, 104, 106, 204, processor 205, and wireless module 218.

[0162] In the decision block 1054, the V2X processing device can determine whether the V2X data is a V2X message. Means for performing the operation of the decision block 1054 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0163] In response to a determination that the V2X data is not a V2X message (i.e., determination block 1054 = "No") (for example, the V2X data is a CRL), the V2X processing device may update the local block list in block 1056 based on one or more station identifiers in the CRL. Means for performing the operation of block 1056 may include vehicle processing systems 102, 104, 106, 204 and processor 205. The V2X processing device may again perform the operation of block 1052 as described.

[0164] In response to the determination that the V2X data is a V2X message (i.e., determination block 1054 = "Yes"), the V2X processing device may determine in determination block 1058 whether the station identifier associated with the received V2X message exists in the local block list. Means for performing the operation of determination block 1058 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0165] In response to a determination that a station identifier associated with an received V2X message exists in the block list (i.e., determination block 1058 = "Yes"), the V2X processing device may, in some embodiments, determine in an optional block 1060 the type of malfunction associated with the station identifier that exists in the local block list. For example, the V2X processing device may determine whether the malfunction associated with the station identifier is intentional or unintentional. Means for performing the operation of optional block 1060 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0166] In an optional block 1062, the V2X processing device can determine the block duration based on the type of malfunction. For example, the V2X processing device may determine a relatively short duration for unintentional malfunctions. Alternatively, the V2X processing device may determine a relatively long duration for intentional malfunctions. Means for performing the operation of the optional block 1062 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0167] In block 1064, the V2X processing device can receive a CRL containing one or more station identifiers in block 1024. Means for performing the operation in block 1060 may include vehicle processing systems 102, 104, 106, 204, processor 205, and radio module 218. The V2X processing device can then repeat method 1000A by performing the operation in block 1052 again as described.

[0168] In response to a determination that the station identifier associated with the received V2X message does not exist in the local block list (i.e., determination block 1058 = "No"), the V2X processing device may analyze the information in the received V2X message to detect a malfunction condition in block 1068. Means for performing the operation of block 1068 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0169] In the optional decision block 1070, the V2X processing device can, in some embodiments, determine whether a station identifier should be added to the local block list. For example, a system administrator (e.g., system administrator 940) can enable or disable the function to add the station identifier of a detected malfunction condition to the local block list. In such embodiments, based on whether the function to automatically add the station identifier of a detected malfunction condition to the local block list is enabled or disabled, the V2X processing device (e.g., local malfunction detection system 906) can analyze the information in the received V2X message to detect the malfunction condition. Means for performing the operation of the optional decision block 1070 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0170] In response to a decision that a station identifier should be added to the local block list (i.e., decision block 1070 = "Yes"), the V2X processing system may, in response to the detection of a malfunction condition in a V2X message in block 1072, add the station identifier associated with the V2X message having the detected malfunction condition to the local block list. Means for performing the optional operation of block 1072 may include vehicle processing systems 102, 104, 106, 204 and processor 205.

[0171] In response to a decision that the station identifier should not be added to the local block list (i.e., decision block 1070 = "No") or a subsequent execution of the optional block 1072, the V2X processing device may, in response to the detection of a malfunction condition in the V2X message in block 1074, transmit a malfunction report to a management entity (e.g., malfunction management entity 930). Means for performing the operation of block 1074 may include vehicle processing systems 102, 104, 106, 204, processor 205, and radio module 218. The V2X processing device may then repeat method 1000A by again performing the operation of block 1052 as described.

[0172] Figure 11 is a component block diagram showing an exemplary mobile computing device 400 suitable for use with various embodiments. Referring to Figures 1A to 11, various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1A to 10C) may be implemented in a wide variety of computing systems, including automotive equipment and mobile computing devices such as the mobile computing device 400. The mobile computing device 400 may include a processor 402 coupled to a touchscreen controller 404 and internal memory 406. The processor 402 may be one or more multi-core integrated circuits designated for general-purpose or specific processing tasks. The internal memory 406 may be volatile memory or non-volatile memory, and may also be secure memory and / or encrypted memory or non-secure memory and / or unencrypted memory, or any combination thereof. Examples of memory types that may be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 404 and processor 402 may be coupled to a touchscreen panel 412 such as a resistive touchscreen, capacitive touchscreen, or infrared touchscreen. In addition, the display of the mobile computing device 400 does not need to have touchscreen functionality.

[0173] The mobile computing device 400 may have one or more radio signal transceivers 408 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) for transmitting and receiving communications, coupled to each other and / or to the processor 402, and an antenna 410. The transceivers 408 and antenna 410 may be used together with the aforementioned circuitry to implement various wireless transmission protocol stacks and interfaces. The mobile computing device 400 may include a cellular network wireless modem chip 416 that enables communication over a cellular network and is coupled to the processor.

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

[0175] The mobile computing device 400 may also include a speaker 414 for providing audio output. The mobile computing device 400 may also include a housing 420 made of plastic, metal, or a combination of materials for housing all or some of the components described herein. It will be recognized by those skilled in the art that the housing 420 may be in the vehicle's dashboard counsel, within the in-vehicle equipment. The mobile computing device 400 may also include a power supply 422 coupled to the processor 402, such as a disposable or rechargeable battery. The rechargeable battery may be coupled to a peripheral device connection port to receive charging current from a power supply outside the mobile computing device 400. The mobile computing device 400 may also include a physical button 424 for receiving user input. The mobile computing device 400 may also include a power button 426 for turning the mobile computing device 400 on and off.

[0176] Figure 12 is a component block diagram showing an exemplary server 500 suitable for use with various embodiments. Referring to Figures 1A to 12, various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1A to 10C) may also include a malfunction management authority that utilizes a fixed computing system, such as any of various commercially available servers, including server 500. Such server 500 typically includes one or more multicore processor assemblies 501 coupled to large-capacity non-volatile memory, such as volatile memory 502 and disk drives 504. As shown in Figure 12, the multicore processor assemblies 501 can be added to server 500 by inserting them into a rack of assemblies. Server 500 may also include a floppy disk drive, compact disk (CD), or digital versatile disk (DVD) disk drive 506 coupled to the processor 501. Server 500 may also include a 3G network access port 503 coupled to a multicore processor assembly 501 to establish network interface connections with networks 507, such as local area networks, the Internet, public switched telephone networks, and / or cellular data networks (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular data network), coupled to other broadcast system computers and servers.

[0177] Implementation examples are described in the following paragraphs. While some of the following implementation examples are described in terms of exemplary methods, further exemplary implementations may include exemplary methods described in the following paragraphs, which are implemented by a computing device having a processor configured to execute processor-executable instructions for performing the operation of the exemplary method; exemplary methods described in the following paragraphs, which are implemented by a V2X processing device, which may be an in-vehicle device, mobile device unit, mobile computing unit, or stationary roadside machine, including a processor configured with processor-executable instructions for performing the operation of the implementation example method; exemplary methods described in the following paragraphs, which are implemented by a V2X processing device including means for performing the function of the implementation example method; and exemplary methods described in the following paragraphs, which may be implemented as a non-temporary processor-readable storage medium storing processor-executable instructions configured to cause the processor of the V2X processing device to perform the operation of the implementation example method.

[0178] Example 1. A method for local malfunction management performed by a vehicle-to-everything (V2X) processing device, comprising the steps of: receiving a V2X message from an Intelligent Transportation System (ITS) station; analyzing information in the received V2X message to detect a malfunction condition in the V2X message; and adding a station identifier associated with the V2X message received from the ITS station to a local block list in response to the detection of a malfunction condition in the V2X message received from the ITS station.

[0179] Example 2. The method according to Example 1, further comprising the step of transmitting a malfunction report to a management entity in response to the detection of a malfunction condition in a V2X message.

[0180] Example 3. The method according to Example 2, wherein the step of transmitting a malfunction report to a management entity in response to the detection of a malfunction condition in a V2X message is performed when adding the station identifier associated with the V2X message received from the ITS station to a local block list.

[0181] Example 4. The method according to any one of Examples 1 to 3, further comprising the steps of determining whether a station identifier associated with another received V2X message exists in a local blocklist, and blocking the V2X message from further processing in response to the determination that a station identifier associated with another received V2X message exists in a local blocklist.

[0182] Example 5. The method according to Example 4, further comprising the steps of determining the type of malfunction associated with a station identifier present in a local blocklist, and determining a block time period based on the type of malfunction, wherein the step of blocking a V2X message from further processing in response to the determination that a station identifier associated with a V2X message is present in a local blocklist includes the step of blocking the V2X message from further processing for a block time period.

[0183] Example 6. The method according to any one of Examples 1 to 5, wherein the step of adding a station identifier associated with a V2X message received from an ITS station to a local block list in response to the detection of a malfunction condition in a V2X message received from an ITS station includes the steps of determining whether or not a station identifier associated with a V2X message received from an ITS station to a local block list in response to the detection of a malfunction condition in a V2X message received from an ITS station should be added to a local block list, and adding the station identifier associated with the V2X message to a local block list in response to the determination that the station identifier should be added to a local block list.

[0184] Example 7. The method according to any one of Examples 1 to 6, further comprising the steps of receiving a Certificate Revocation List (CRL) containing one or more station identifiers, and updating a local blocklist based on one or more station identifiers in the CRL.

[0185] Example 8. The method according to Example 7, wherein the step of updating the local blocklist based on one or more station identifiers of the CRL includes the step of removing the station identifier associated with the V2X message from the local blocklist.

[0186] Example 9. The method according to Example 7, wherein the step of updating the local block list based on one or more station identifiers of the CRL includes the step of increasing the block time period for station identifiers associated with a V2X message.

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

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

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

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

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

[0192] 12 vehicles 14 vehicles 16 vehicles 18. Communication Networks 20 Safety separation distance 100 V2X System 102 V2X vehicle equipment 104 V2X vehicle equipment 106 V2X automotive equipment 112 Basic Safety Message 114 Basic Safety Message 116 Basic Safety Message 122 Communication Links 124 Communication Links 132 Original Equipment Manufacturer (OEM) Servers 134 Original Equipment Manufacturer (OEM) Servers 136 Remote Malfunction Management Authority 142 Communication Links 144 Communication Links 150 V2X communication protocol stacks 200 Systems 202 V2X Processing Devices 204 Vehicle Processing System 205 Processor 206 memory 207 Input Module 208 Output Modules 210 In-vehicle network 212 Infotainment System 214 sensors 216 Actuator 218 Wireless Modules 219 V2X Antenna 220 vehicles 222 Roadside machine 224 base station 250 Malfunction Management Network 252 Malfunction Authority 254 Malfunction Pre-processing 300 ways 400 mobile computing devices 402 Processors 404 Touchscreen Controller 406 internal memory 408 Transceiver 410 Antenna 412 Touchscreen Panel 414 Speakers 416 Cellular Network Wireless Modem Chip 418 Peripheral device connection interface 420 Housing 422 Power supply 424 physical buttons 426 Power button 500 servers 501 Multicore Processor Assembly 502 Volatile memory 503 Network Access Port 504 Disk Drive 506 Digital Multipurpose Disc (DVD) Disc Drive 507 Network 600 operations 700 operations 800 operations 900 System 902 V2X communication module 904 Local Malfunction Prevention System 906 Local Malfunction Detection System 908 Local Malfunction Reporting System 920 ITS Station 930 Malfunction Management Entity 940 System Administrator 100A Method 100B method 100C method

Claims

1. A method for filtering local malfunction messages performed by a vehicle-to-everything (V2X) processing device, Steps include receiving a V2X message from an Intelligent Transportation System (ITS) station, A step of analyzing information within a received V2X message in order to detect a malfunction condition in the V2X message, the step of analyzing information within a received V2X message includes detecting the malfunction condition based on the fact that the information within the received V2X message is inconsistent with observations made by a V2X device installed in the vehicle, and The steps include adding a station identifier associated with the V2X message received from the ITS station to a local block list in response to the detection of malfunction conditions in the V2X message received from the ITS station, A step of determining a block time period during which the V2X message associated with the station identifier is blocked from further processing, based on the type of malfunction associated with the station identifier present in the local block list, wherein the type of malfunction indicates whether the malfunction is unintentional or intentional, and the further processing includes processing for detecting the malfunction condition in the V2X message. The steps include blocking the V2X message associated with the station identifier from further processing during the aforementioned block time period, and Methods that include...

2. The method according to claim 1, further comprising the step of transmitting a malfunction report to a management device in response to the detection of the malfunction condition in the V2X message.

3. The method according to claim 2, wherein the step of transmitting the malfunction report to the management device in response to the detection of the malfunction condition in the V2X message is performed when adding the station identifier associated with the V2X message received from the ITS station to the local block list.

4. The step further includes determining whether a station identifier associated with another received V2X message exists in the local blocklist, The method according to claim 1, wherein the step of blocking the V2X message associated with the station identifier from further processing during the block time period includes the step of blocking the V2X message from further processing in response to a determination that the station identifier associated with another received V2X message is present in the local block list.

5. The step of adding the station identifier associated with the V2X message received from the ITS station to the local block list in response to the detection of malfunction conditions in the V2X message received from the ITS station is: The steps include determining whether the station identifier associated with the V2X message received from the ITS station should be added to the local block list based on whether the function to add the station identifier to the local block list is enabled or disabled in response to the detection of malfunction conditions in the V2X message received from the ITS station, The steps of adding the station identifier associated with the V2X message to the local block list in response to a decision that the station identifier should be added to the local block list, The method according to claim 1, including the method described in claim 1.

6. The steps include receiving a Certificate Revocation List (CRL) containing one or more station identifiers, The steps of updating the local block list based on one or more station identifiers in the CRL: The method according to claim 1, further comprising:

7. The method according to claim 6, wherein the step of updating the local block list based on the one or more station identifiers of the CRL includes the step of removing the station identifier associated with the V2X message from the local block list if the station identifier associated with the V2X message does not exist in the CRL.

8. The method according to claim 6, wherein the step of updating the local block list based on the one or more station identifiers of the CRL includes the step of increasing the block time period for the station identifier associated with the V2X message.

9. A vehicle-to-everything (V2X) processing device, A means for receiving V2X messages from an Intelligent Transportation System (ITS) station, Means for analyzing information within a received V2X message in order to detect malfunction conditions in the V2X message, wherein the means for analyzing information within the received V2X message includes means for detecting the malfunction conditions based on the fact that the information within the received V2X message is inconsistent with observations made by a V2X device installed in the vehicle, Means for adding a station identifier associated with a V2X message received from an ITS station to a local block list in response to the detection of malfunction conditions in the V2X message received from the ITS station, A means for determining a block time period during which the V2X message associated with the station identifier is blocked from further processing, based on the type of malfunction associated with the station identifier present in the local block list, wherein the type of malfunction indicates whether the malfunction is unintentional or intentional, and the further processing includes processing for detecting the malfunction condition in the V2X message. During the aforementioned block time period, means for blocking the V2X message associated with the station identifier from further processing, A vehicle-to-everything (V2X) processing device equipped with [the following features].

10. The system further comprises means for transmitting a malfunction report to a management device in response to the detection of the malfunction condition in the V2X message, The V2X processing device according to claim 9, wherein the means for transmitting the malfunction report to the management device in response to the detection of the malfunction condition in the V2X message includes means for adding the station identifier associated with the V2X message received from the ITS station to the local block list.

11. The system further includes means for determining whether a station identifier associated with another received V2X message exists in the local blocklist, The V2X processing device according to claim 9, wherein means for blocking the V2X message associated with the station identifier from further processing during the block time period include means for blocking the V2X message from further processing in response to a determination that the station identifier associated with another received V2X message is present in the local block list.

12. Means for adding the station identifier associated with the V2X message received from the ITS station to the local block list in response to the detection of malfunction conditions in the V2X message received from the ITS station are: A means for determining whether the station identifier associated with the V2X message received from the ITS station should be added to the local block list based on whether the function for adding the station identifier to the local block list is enabled or disabled in response to the detection of malfunction conditions in the V2X message received from the ITS station, Means for adding the station identifier associated with the V2X message to the local block list in response to a decision that the station identifier should be added to the local block list; A V2X processing device according to claim 9, including the V2X processing device according to claim 9.

13. Means for receiving a Certificate Revocation List (CRL) containing one or more station identifiers, means for updating the local block list based on one or more station identifiers in the CRL, Furthermore, The V2X processing device according to claim 9, wherein means for updating the local block list based on the one or more station identifiers of the CRL include means for removing a station identifier associated with a V2X message from the local block list if the station identifier associated with the V2X message does not exist in the CRL.

14. Means for receiving a Certificate Revocation List (CRL) containing one or more station identifiers, means for updating the local block list based on one or more station identifiers in the CRL, Furthermore, The V2X processing device according to claim 9, wherein means for updating the local block list based on the one or more station identifiers of the CRL include means for increasing the block time period for station identifiers associated with the V2X message.

15. A non-temporary processor-readable medium storing processor-executable instructions configured to cause a processor of a V2X processing device to perform the method described in any one of claims 1 to 8.

Images