JP2024505423A - Local malfunction prevention system for cooperative intelligent transportation systems - Google Patents

Abstract

In various embodiments, a vehicle-to-everything (V2X) processing device receives V2X messages from an intelligent transportation system (ITS) station, analyzes information in the received V2X messages to detect malfunction conditions, and analyzes information in the received V2X messages to detect malfunction conditions. A station identifier associated with a V2X message received from an ITS station may be added to a local block list in response to detection of a malfunction condition in a V2X message received from the ITS station. In some embodiments, a V2X processing device may transmit a malfunction report to a management entity in response to detecting a malfunction condition in a V2X message.

Description

RELATED APPLICATIONS This application is filed on January 19, 2021, the entire contents of which are incorporated herein by reference for all purposes, United States Provisional Pat. Claims priority benefit of application no. 63/138,916.

Various standards are being 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 Communications (DSRC) and ITS-G5 communications standards. IEEE1609 is a higher standard based on IEEE802.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 to support intelligent highways, autonomous and semi-autonomous vehicles, and to improve the overall efficiency and safety of highway transportation systems. can be used. Other V2X wireless technologies are also being considered in several different regions of the world. The techniques described herein are applicable to any V2X wireless technology.

C-V2X defines two transmission modes that together provide 360° non-line-of-sight awareness and higher levels of predictability for enhanced road safety and autonomous driving. The first transmission mode includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P), and is a dedicated ITS 5.9 gigahertz (GHz) ) within the spectrum, including direct C-V2X, which provides extended communication range and reliability. The second transmission mode is a third generation wireless mobile communication technology (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) system, code division multiple access (CDMA) 2000 system, etc.), a fourth generation wireless Mobile communication technology (4G) (e.g. Long Term Evolution (LTE) system, LTE Advanced system, Mobile Worldwide Interoperability for Microwave Access (Mobile WiMAX) system, etc.), 5th generation new radio wireless mobile communication technology (5G) including vehicle-to-network (V2N) communications in mobile broadband systems and technologies, such as NR systems).

Multiple regions of the world are developing systems for vehicle-based communication systems and functions, such as those being developed in IEEE1609 and SAE for use in North America, or ETSI and CEN for use in Europe. Developing a plan. Part of that system is the Basic Safety Message (BSM) used in North America, which a vehicle can receive and process by other vehicles to improve traffic safety and efficiency. ) or the ability to broadcast Cooperative Awareness Messages (CAM, used in Europe). Processing of such messages in the sending and receiving vehicles takes place in onboard equipment that provides V2X functionality (referred to herein as "V2X onboard equipment").

In V2X communications, it is important that inaccurate, corrupted, or hacked (i.e., bad) data is detected to prevent further dissemination of such inaccurate data. However, as the number of vehicles being prepared to participate in such networks is increasing, the amount of potential malfunctioning condition data is large and growing exponentially. Accordingly, management of such detected malfunction conditions may be controlled in order to efficiently utilize V2X messaging. Malfunction detection systems are important to perform the functions of detecting bad data and generating malfunction reports (MBRs). The MBR needs to be generated, stored locally, and transmitted to a trusted third party (eg, malfunction authority) for investigation. Therefore, the integrity and functionality of V2X onboard equipment becomes an important design consideration when V2X systems are deployed.

Various aspects include a method of local malfunction message filtering implemented by a vehicle-to-everything (V2X) processing device. Various aspects include receiving a V2X message from an Intelligent Transportation System (ITS) station, analyzing information in the received V2X message to detect malfunction conditions in the V2X message, and detecting a V2X message received from the ITS station. adding a station identifier associated with a V2X message received from an ITS station to a local block list in response to detecting a malfunction condition in the message. Some aspects can include transmitting a malfunction report to a management entity in response to detecting a malfunction condition in a V2X message. In such aspects, transmitting a malfunction report to a management entity in response to detecting a malfunction condition in a V2X message is performed when adding a station identifier associated with a V2X message received from an ITS station to a local block list. may be done.

Some aspects include determining whether a station identifier associated with another received V2X message is present in a local block list; and determining whether a station identifier associated with another received V2X message is present in a local block list. blocking the V2X message from further processing in response to the determination to do so. Such aspects may include determining a type of malfunction associated with a station identifier present in the local block list and determining a block time period based on the type of malfunction. In such aspects, blocking the V2X message from further processing in response to determining that a station identifier associated with the V2X message is present in a local block list includes blocking the V2X message from further processing for a blocking time period. May include steps.

In some aspects, adding a station identifier associated with a V2X message received from an Intelligent Transportation System (ITS) station to a local block list in response to detecting a malfunction condition in a V2X message received from the ITS station includes: determining whether a station identifier associated with a V2X message received from an ITS station should be added to a local block list in response to detection of a malfunction condition in a V2X message received from an ITS station; adding the station identifier associated with the V2X message to the local block list in response to the determination that the station identifier should be added to the local block list.

Some aspects include receiving a certificate revocation list (CRL) that includes one or more station identifiers and updating a local block list based on the one or more station identifiers in the CRL. can be included. In some aspects, updating the local block list based on one or more station identifiers of the CRL may include removing the station identifier associated with the V2X message from the local block list. In some aspects, updating the local block list based on one or more station identifiers of the CRL may include increasing a block time period for the station identifier associated with the V2X message.

A further aspect includes a V2X processing device that includes a processor configured to perform the operations of any of the methods summarized above. A further aspect includes a malfunction management system that includes a memory and a processor configured to perform the operations of any of the methods summarized above. Further embodiments may include a V2X processing device having various means for performing functions corresponding to any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium storing processor-executable instructions configured to cause a processor of a V2X processing device to perform various operations corresponding to any of the methods summarized above. obtain.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims, and together with the general description and detailed description given, , to help explain the features herein.

1 is a system block diagram illustrating an example V2X system suitable for implementing various embodiments. FIG. 1 is a conceptual diagram illustrating an example V2X communication protocol stack suitable for implementing various embodiments. FIG. 1 is a component diagram illustrating an example vehicle system suitable for implementing various embodiments. FIG. FIG. 1 is a component diagram illustrating a malfunction management network suitable for implementing various embodiments. FIG. 2 is a process flow diagram illustrating an example method for managing MBR generation, storage, and transmission by a malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for determining whether a malfunction report should be generated by a malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for determining whether a malfunction report should be generated by a malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for determining whether a malfunction report should be stored by a malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for determining whether a malfunction report should be stored by a malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for calculating the weight of a malfunction report being generated by a malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for determining which stored malfunction reports may be cleared by the malfunction management system. FIG. 2 is a process flow diagram illustrating example operations for adjusting a threshold in a feedback signal by a malfunction management system. 1 is a block component diagram illustrating an example system for local malfunction message filtering in accordance with various embodiments. FIG. FIG. 2 is a process flow diagram illustrating an example method of local malfunction message filtering in accordance with various embodiments. FIG. 2 is a process flow diagram illustrating an example method of local malfunction message filtering in accordance with various embodiments. FIG. 3 is a process flow diagram illustrating an example method of local malfunction message filtering in accordance with various embodiments. 1 is a component block diagram illustrating an example mobile computing device suitable for use with various embodiments. FIG. FIG. 2 is a component block diagram illustrating an example server suitable for use with various aspects.

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

In general, various embodiments include methods and mechanisms for local management of Intelligent Transportation System (ITS) station malfunctions detected by V2X vehicle equipment. The V2X vehicle equipment may also report such malfunctions to a management authority such as a malfunction management authority and/or a security certificate management system (SCMS), provided that the management authority does not provide any concessions such as a certificate revocation list (CRL). It may take several hours or days for a response to occur. Various embodiments enable a V2X processing device (eg, of a V2X vehicle equipment) to respond quickly to a detected malfunction compared to a management authority's response time.

V2X systems and technologies allow vehicles to share information about their location, speed, heading, braking, and other factors that may be useful to other vehicles for collision prevention and other safety features. This holds considerable promise for improving traffic flow and vehicle safety. Vehicles equipped with V2X/V2V onboard equipment frequently (e.g. up to 20 times per second) transmit their vehicle information in packets referred to as Basic Safety Messages (BSM) or Cooperative Awareness Messages (CAM). Become. All vehicles equipped with V2X transmit such BSM/CAM messages so that all receiving vehicles can track their own speed and Contains the information necessary to control direction. It may be possible for vehicles equipped with V2X to improve traffic flow by safely reducing separation distances, swapping positions with several vehicles, and avoiding vehicles experiencing obstructions. It is assumed that

In V2X communications, it is important that inaccurate, corrupted, or hacked (i.e., bad) data is detected to prevent further dissemination of such inaccurate data. However, as the number of vehicles being prepared to participate in such networks is increasing, the amount of potential malfunctioning condition data is large and growing exponentially. Management of such detected malfunction conditions may be controlled to efficiently utilize V2X messaging. Malfunction detection systems are important to perform the functions of detecting bad data and generating malfunction reports (MBRs). However, currently malfunction detection systems process all incoming messages even from reported malfunctioning transmitting devices (herein generally referred to as "ITS stations"). . This behavior consumes finite computing resources. For example, a malfunctioning station may send up to 10-20 messages per second, and a malfunction detection system may detect this amount of such messages in addition to other messages received by the V2X system. need to be processed.

A local malfunction detection system may send the MBR to a network security function such as a malfunction authority, but the process of revoking a malfunctioning ITS station's certificate may take hours or days. For example, for each confirmed malfunctioning ITS station (which may require receipt of several MBRs), the malfunctioning authority may revoke the malfunctioning ITS station's certificate. The malfunctioning authority sends 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. can do. However, as mentioned above, this revocation process may take hours or days. Before certificate revocation is complete, a malfunctioning ITS station may send a large number of incorrect or malicious V2X messages (e.g., up to one message every 100 milliseconds). The latency of communication by a malfunctioning authority is due to the absence of connectivity with the malfunctioning authority, the lack of connected infrastructure (associated with DSRC), the lack of cellular connectivity (associated with C-V2X), and the lack of connectivity with the malfunctioning authority. It can be caused or exacerbated by a lack of evidence that the station is malfunctioning.

Various embodiments include a method and a V2X processing device configured to implement the method of local malfunction management. In some embodiments, a V2X processing device (e.g., of a V2X vehicle equipment), in response to detecting a malfunctioning condition in a V2X message, adds station identifiers associated with V2X messages having the detected malfunctioning condition to a local block list. can be added to. 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., delivered by a V2X public key infrastructure (PKI), a media access control (MAC) address, or other suitable information). .

In various embodiments, the local block list may be updated using locally detected information, such as an ITS station malfunction, and a station identifier associated with the malfunctioning ITS station. In some embodiments, the local block list may also include information provided by the malfunction authority, such as a station identifier provided in the CRL. In various embodiments, a CRL is a global block list established by a malfunction authority based on processing malfunction reports sent by a number of ITS stations. A CRL therefore represents a more global block list. In some embodiments, the V2X processing device uses local information (i.e., based on ITS station malfunctions detected locally by the V2X processing device) and "global" information received in the CRL. or other suitable information from the malfunctioning authority or entity may be used to update the local block list.

In some embodiments, the V2X processing device is 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." May include. A local malfunction detection system can detect V2X messages containing incorrect or false information. Local malfunction detection systems detect whether incorrect information is unintentional (e.g., incorrect information reported by a malfunctioning sensor) or intentional (e.g., malicious information, or provided by a hacked V2X device). information) can be determined. The local malfunction reporting system may generate and send, for example, a malfunction management entity, a malfunction report (MBR) indicating the detected malfunction. The local malfunction reporting system may also send the MBR to the local malfunction prevention system.

In some embodiments, the local malfunction detection system may implement filtering or firewall functionality to prevent V2X messages having detected malfunction conditions from being further processed by the local malfunction detection system. In some embodiments, a local anti-malfunction system may be configured with a local block list. The local block list may include station identifiers of ITS stations that sent incorrect or bogus V2X messages. In this way, the V2X processing device determines whether a station identifier associated with a received V2X message is present in the local block list and whether a station identifier associated with another received V2X message is present in the local block list. The V2X message may be configured to determine whether to block the V2X message from further processing in response to the determination. In some embodiments, the V2X processing device may add the station identifier associated with the V2X message with the detected malfunction condition to the local block list once the malfunction report is transmitted to the management entity. In some embodiments, the V2X processing device may determine whether to add a station identifier associated with a V2X message having a detected malfunctioning condition to a local block list.

In some embodiments, the V2X processing device may determine the type of malfunction associated with the station identifier present in the local block list. For example, a V2X processing device may have malfunctions that are either unintentional (e.g., caused by a malfunctioning device or sensor) or intentional (e.g., as a result of an attack or the deliberate injection of incorrect or false information). can be determined. In some embodiments, the V2X processing device may determine a blocking time period based on the type of malfunction and may block the V2X message from further processing for the blocking time period. For example, the V2X processing device may determine a relatively short period of time or may impose a temporary block on V2X messages from the ITS source for unintentional malfunctions. In some embodiments, the V2X processing device may determine a relatively long period of time or may impose a permanent block on V2X messages from the ITS source for intentional malfunctions. .

In some embodiments, the V2X processing device may update the local block list 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 malfunctioning management entity may provide a CRL hours or days after a malfunctioning ITS station is reported. To address this, various embodiments allow V2X processing devices to act quickly to locally block V2X messages from malfunctioning ITS stations by updating a local block list, and then Finally, it is possible to update the local block list based on the information provided in the CRL (or other information or messages) by the malfunction management entity. In some embodiments, the V2X processing device may remove from the local block list one or more station identifiers 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, a V2X processing device may maintain or add one or more station identifiers present in a CRL on a local block list. In some embodiments, the V2X processing device may increase the blocking time period for station identifiers present in the CRL (eg, to impose a permanent block on such station identifiers).

Various embodiments reduce demands on V2X processing system resources by reducing the number or amount of invalid or inaccurate messages processed by the V2X processing system received from malfunctioning ITS stations. can improve the operation of V2X processing systems. Various embodiments provide that the V2X processing system responds quickly and dynamically to such malfunctions well before the malfunction management entity is able to respond to reports of detected malfunctions from ITS stations. improve the operation of V2X processing systems by enabling Various embodiments improve the operation of a V2X processing system by imposing blocking times that can vary in duration based on different types of malfunction conditions and correct within a relatively short period of time (e.g., several hours). For possible unintentional malfunctions, blocking the ITS station for a long period of time (eg, days or weeks) can be avoided.

For ease of reference, some of the embodiments are described in this application using a malfunction management system that operates within the vehicle-to-everything (V2X) terminology. However, it is to be understood that the various embodiments encompass any or all V2X or vehicle-based communication standards, messages or techniques. Accordingly, nothing in this application should be construed to limit the scope of the claims to V2X and Basic Safety Messages (BSM) unless explicitly stated to do so in the claims. do not have. Additionally, embodiments described herein discuss onboard equipment for implementing V2X communications. Other embodiments are contemplated in which V2X communications may also include mobile devices, mobile computers, and roadside units (RSUs) configured to monitor road and vehicle conditions and participate in V2X communications.

To help explain the problems addressed by the various embodiments, FIG. 1A depicts a portion of a V2X system 100 that includes three vehicles 12, 14, 16. FIG. 1B shows an example V2X communication protocol stack 150 suitable for implementing various embodiments. 1A and 1B, each vehicle 12, 14, 16 periodically sends basic safety messages 112, 114, 116, respectively, for reception and processing by other onboard equipment (e.g., 102, 104, 106). a vehicle processing system (e.g., V2X vehicle equipment) 102, 104, 106 configured to broadcast information. By sharing vehicle location, speed, direction, braking, and other information, vehicles can maintain safe separation and identify and avoid potential collisions. For example, a trailing vehicle 12 that receives a basic safety message 114 from a leading vehicle 16 can determine the speed and location of the vehicle 16 so that the vehicle 12 can match its speed and maintain a safe separation distance 20. It is possible. By being notified via basic safety message 114 when the leading vehicle 16 applies the brakes, the V2X equipment 102 in the trailing vehicle 12 can apply the brakes at the same time even if the leading vehicle 16 suddenly stops. safety separation distance of 20 can be maintained. As another example, the V2X equipment 104 within the truck vehicle 14 may receive basic safety messages 112, 116 from the two vehicles 12, 16 so that the truck vehicle 14 is at an intersection to avoid a collision. You can be notified that it should be stopped. Each of the V2X vehicle devices 102, 104, 106 may communicate with each other using any of a variety of proximity communication protocols. In addition, the vehicle transmits data and information regarding detected basic safety messages and detected malfunction reports to the original equipment manufacturer via the communication links 122, 124 through the communication network 18 (e.g. cellular, WiFi, etc.). (OEM) (132, 134) and/or remote malfunction management authority 136. The MBR may be transmitted directly to malfunction management authority 136 (eg, over communication link 146). In other embodiments, the MBR may first be transmitted over 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 preprocessor 132, 134 to the malfunction management authority 136 via the communication link 142, 144.

Given the importance of basic safety messages to the safe operation 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 authenticity involves issuing each V2X vehicle device with a certificate that can be used to sign basic safety messages. Certificates issued to V2X in-vehicle devices do not contain the persistent identity of the V2X in-vehicle device, and for this reason are typically referred to as anonymous certificates. A malfunction management system operating within V2X in-vehicle devices in nearby vehicles and the Basic Safety Podcast's highway monitoring system establishes the authenticity of the V2X in-vehicle device issuing the basic safety message by verifying the signature in the broadcast message. You can confirm the gender. V2X in-vehicle devices that receive the basic safety message can verify the signature using the public key. To protect against hacking or interference with V2X system operation, V2X in-vehicle equipment may be configured to ignore any incoming basic safety messages signed using a revoked or invalid certificate.

Although signing basic safety messages using certificates issued to V2X in-vehicle devices protects against attempts to inject false basic safety messages, the signature verification process Unable to detect when in-vehicle equipment generates inaccurate basic safety messages using legitimate certificates. Various equipment malfunctions can cause V2X vehicle equipment to generate incorrect basic safety messages. For example, reporting of vehicle location (e.g. incorrect lane or larger error) or speed may become inaccurate as a result of failures in navigation sensors, speed sensors and/or wiring from such sensors to V2X on-board equipment. There is sex. It is also possible that V2X in-vehicle devices could be maliciously modified to generate incorrect basic safety messages that are signed using legitimate certificates. Both cases are referred to as malfunctions.

In many instances, the receiver malfunction management system can detect the malfunction via malfunction detection in on-board processing. Incorrect basic safety messages can be recognized by malfunction management systems operating within other vehicles when the information contained in such messages is inconsistent with reliable information available to the V2X vehicle equipment. For example, a malfunction management system may recognize that 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. Can be done. As another example, a malfunction management system may recognize that speed information in a received basic safety message is incorrect when the speed is inconsistent with the speed of the equipment's own vehicle and surrounding vehicles. Other methods of recognizing incorrect basic safety messages may be used.

To ensure the integrity and reliability of the V2X system, the malfunction management system transmits detected incorrect basic safety messages to other vehicles and Can be configured to notify a highway system or authority. In conventional systems, the receiving V2X vehicle equipment may automatically generate a malfunction report or malfunction detection report (MBR in the drawing). Each MBR may contain an anonymous certificate of a malfunctioning V2X vehicle device that signed an incorrect basic safety message. A malfunction management system that detects a malfunction may be configured to send a malfunction detection report to a particular network backend entity, referred to herein as a malfunction authority (MA) of the SCMS, for processing. The reporting V2X vehicle equipment is typically configured by the OEM, and therefore the device receiving the malfunction report is typically operated by or in the name of the reporting V2X vehicle equipment OEM.

Malfunction detection reports may be collected by a malfunction authority operated by any of a variety of parties, such as a government agency, an independent third party or service provider, and/or an OEM. May be an entity. The malfunction authority may be configured to take actions to protect the reliability and integrity of V2X systems and equipment. For example, a malfunctioning authority can blacklist the certificate of a malfunctioning V2X vehicle device, resulting in other V2X vehicle devices ignoring basic safety messages containing the blacklisted certificate. You can know. The distributed malfunction authority may also notify the certificate registration authority of the certificate so that appropriate action can be taken by the corresponding registration authority.

The term malfunctioning V2X vehicle-mounted device is used herein for a V2X vehicle-mounted device that is identified as the cause of the malfunction in the malfunction detection report. However, in some cases, another component or entity other than the responsible V2X vehicle equipment may be malfunctioning using messages or credentials obtained from the V2X vehicle equipment. For example, a faulty sensor or equipment within the same vehicle as the V2X onboard equipment that is the cause may be the source of the incorrect information in the basic safety message resulting in the malfunction detection, but an entity outside the vehicle There are other scenarios that could cause an incorrect basic safety message to be transmitted.

Entities such as OEMs may utilize MBR for a variety of reasons. For example, a V2X vehicle equipment OEM may be interested in seeing information about malfunctioning MBRs caused by its V2X vehicle equipment. In some cases, the OEM may desire that information purely for recording statistics. In other instances, the OEM should, without limitation, attempt to correct errors in the V2X vehicle equipment implementation, replace the V2X vehicle equipment, cause the V2X vehicle equipment to malfunction, or bring the vehicle in for maintenance. remove certificates from the OEM vehicle equipment, place some of the OEM vehicle equipment certificates on a revocation list, and issue new certificates to the V2X vehicle equipment. , appropriate steps can be taken. OEMs can perform such operations wirelessly in some cases, while in other cases they need physical access to the V2X vehicle equipment.

As more and more vehicles are equipped with V2X equipment, the amount of potential detected malfunctions is increasing exponentially. If a malfunction report were to be generated in response to every detected malfunction, the OEM and/or any malfunction authority would be overwhelmed by the large number of MBRs. Therefore, it may be necessary to manage whether an MBR should be generated each time a malfunction condition is detected. Moreover, if the malfunction management system operating within the V2X equipment decides to generate an MBR, the malfunction management system will determine whether the MBR should be stored or not and/or send the MBR to the management authority within the SCMS. It may be necessary to manage whether or not to do so. As malfunction management systems are becoming more sophisticated, malfunction management systems are becoming more sophisticated, and so malfunction management systems are becoming more sophisticated. , and be able to receive feedback. In particular, the feedback allows the malfunction management system to refine when to generate an MBR in response to detecting a malfunction, storing the generated MBR, and/or sending the MBR to the malfunction management authority. can be made possible.

In V2X communication, it is beneficial to detect bad data to prevent the spread of unnecessary data between vehicles. A malfunction detection system fulfills this role and, as a reaction after detection, can generate a malfunction report (MBR). The MBR may need to be generated, stored locally, and transmitted to a trusted third party (eg, a malfunction authority within the SCMS) for investigation. The rules for generation, storage and transmission are not trivial and can be defined such that utility is maximized and overhead is minimized. For example, a malfunction detection system should not generate an MBR for every single malfunction of the same type coming from the same remote vehicle, but may generate one report and append an "occurrence" value. This saves generation time (and I/O operations), local storage space, and reduces the number of MBRs that must be transmitted and checked by the MA. The ITS community lacks a set of such rules/algorithms for MBR management.

Various embodiments disclosed herein provide methods and mechanisms for managing MBR. Various embodiments may determine when it is appropriate to generate a malfunction report when a malfunction condition is detected. Various embodiments may also determine when it is appropriate to store a generated malfunction report when the malfunction report is generated. Various embodiments may also determine when it is appropriate to erase previously stored malfunction report deletions. Various embodiments may also determine when it is appropriate to send a malfunction report to a management authority. To more efficiently utilize the information within the malfunction report, some embodiments may pre-process the data included in the malfunction report.

Various embodiments may include an act of receiving feedback from a management authority to modify or optimize management of malfunction reports.

The malfunction management system of various embodiments can be deployed on any device capable of directly or indirectly receiving V2X messages. Accordingly, various embodiments disclosed herein can operate within a self-contained unit mounted on a vehicle, a smartphone, a roadside device, or even in the cloud, to name a few. .

To provide context and background for the various embodiments, the following background regarding the IEEE 1609 Malfunction Report Processing System is provided. 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 with V2X vehicle equipment. The various implementation fluids are not limited to the malfunction reporting management process below.

Should the sending V2X equipment (e.g., onboard unit (OBU), RSU, ASD) detect a malfunction condition and generate, store, and/or transmit a malfunction report to a malfunction management authority (MA)? The MA may also provide such reports to the SCMS. To authenticate malfunction conditions, malfunction reports, and basic safety messages, each sending V2X device can attach a public key signature to each malfunction condition, malfunction report, and basic safety message, which the sending It can be verified using the public signature key in the anonymous certificate issued to the V2X in-vehicle device.

FIG. 2A is a component diagram of an exemplary vehicle system 200 suitable for implementing various embodiments. FIG. 2B is a component diagram illustrating a malfunction management network 250 suitable for implementing various embodiments. Referring to FIGS. 1A-2B, a system 200 can include a vehicle 202 that includes a vehicle processing system 204 (eg, a telematics control unit or on-board unit (TCU/OBU)). In some embodiments, the system 200 operates within, as part of, and/or in the context of a malfunction management network 250 that includes a malfunction authority 252 and elements or functionality that provide malfunction pre-processing 254. Can be done. V2X processing device 202 can communicate with various systems and devices, such as an in-vehicle network 210, an infotainment system 212, various sensors 214, various actuators 216, and a wireless module 218. V2X processing device 202 may also communicate with various other vehicles 220, roadside units 222, base stations 224, and other external devices. Vehicle processing system 204 may be configured to perform operations to authenticate plaintext and ciphertext, as described further below.

Vehicle processing device 204 may include a processor 205, memory 206, input module 207, output module 208, and wireless module 218. Processor 205 can be coupled to memory 206 (i.e., a non-transitory storage medium) and includes information stored in memory 206 for performing operations of methods according to various embodiments described herein. can be constructed by processor-executable instructions. Processor 205 may also be coupled to an output module 208 that can control in-vehicle displays and an input module 207 for receiving information from vehicle sensors and driver input.

Vehicle processing system 204 is coupled to a wireless module 218 configured to communicate with another vehicle 220, a roadside unit 222, and one or more ITS stations, such as a base station 224 or another suitable network access point. can include a V2X antenna 219. In various embodiments, V2X processing device 202 can receive information from multiple sources, such as in-vehicle network 210, infotainment system 212, various sensors 214, various actuators 216, and wireless module 218. . The V2X processing device 202 detects a malfunctioning condition within a system of the vehicle, such as one of a plurality of information sources 210-218, an application or service running on the V2X processing device 202, or another system of the vehicle. can be detected.

Examples of in-vehicle networks include controller area networks (CAN), local interconnect networks (LIN), networks using the FlexRay protocol, media oriented system 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, radars, lidar, ultrasonic sensors, infrared sensors, and other suitable sensor devices and systems. Examples of vehicle actuators include various physical control systems such as steering, brakes, engine operation, lighting, turn signals, etc.

FIG. 3 is a process flow diagram illustrating an example method 300 for managing MBR generation, storage, and transmission by a malfunction management system. Referring to FIGS. 1A-3, operations of method 300 may be performed by a processor of a vehicle processing system (eg, 102, 104, 106, 204).

In various embodiments, method 300 includes acts that are involved in managing the generation, storage, and transmission of malfunction reports that may be performed by a V2X device and/or a malfunction management authority.

At block 302, a malfunction management system included in the onboard V2X equipment (e.g., 102, 104, 106) in their respective vehicles (e.g., 12, 14, 106) to determine whether a malfunction condition is detected. 16) various sensor data can be analyzed (e.g., monitored and analyzed). In some embodiments, the V2X equipment may also be capable of monitoring and observing the behavior of each other vehicle to determine whether a malfunction condition exists. Mobile units may also be included. For example, V2X equipment may receive basic safety messages from another vehicle that are inconsistent with observations that the other vehicle's V2X equipment may make. As an example, V2X equipment 102 onboard vehicle 12 may receive a basic safety message (BSM) from V2X equipment 106 onboard vehicle 16 that vehicle 16 is initiating an emergency braking operation. However, the malfunction management system of the V2X equipment 102 onboard the vehicle 12 may observe that the vehicle 16 is not slowing down or applying emergency braking. In such a situation, the BSM that an emergency braking action is occurring is inconsistent with other sensor data monitored by the malfunction management system of the V2X equipment 106 on board the vehicle 16, The V2X equipment 106 installed in the is capable of detecting malfunction conditions. In addition, the BSM received from V2X equipment 106 onboard vehicle 16 is inconsistent with the observations made by V2X equipment 102 onboard vehicle 12, resulting in malfunction management on board vehicle 16. A malfunction management system for V2X equipment 102 installed in vehicle 12 that receives the BSM from V2X equipment 106 may also detect malfunction conditions. Means for performing the operations of block 302 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , wireless module 218 , and sensors 214 .

At decision block 304, the processor may determine whether a malfunction report should be generated. In various embodiments, both the V2X equipment 106 onboard the vehicle 16 and the V2X equipment 102 onboard the vehicle 12 are capable of detecting malfunction conditions, but each V2X equipment 102, 106 is capable of reporting malfunctions. A determination may be made as to whether or not a malfunction report should be generated, and if so, a determination may be made as to what evidence should be collected and appended to the generated malfunction report. The decision to generate a malfunction report after detecting a malfunction condition may be based on several factors. For example, as discussed in more detail below with reference to Figures 4A and 4B, the decision to generate a malfunction report depends on (i) the severity of the detected malfunction (potential safety impact, or (ii) the length of the observed malfunction (which helps distinguish temporary faults from permanent malfunctions); (iii) the extent to which remote vehicles are malfunctioning. (i.e., this helps to cover sporadic malfunctions); (iv) of nearby vehicles (with different certificates) detected as performing similar malfunctions; (which helps aggregate and report larger issues), or (v) simply after at least one detector has been triggered. Means for implementing the operations of decision block 304 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that a malfunction report should be generated (ie, decision block 304=“Yes”), the processor may generate a malfunction report at block 306. Means for performing the operations of block 306 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At decision block 308, the processor may determine whether the malfunction report should be stored in memory. The decision to store a malfunction report after detecting a malfunction condition may be based on several criteria. As discussed in more detail below with reference to FIGS. 5A and 5B, the decision to store a generated malfunction report may be based on multiple criteria, which may include the following: (i) the level of confidence in the detection of the malfunction condition; (ii) the determined message set size (e.g., a detected malfunction only requires a certain number of messages from neighboring devices); (iii) the blacklist. (Note that the storage of the hash of the remote vehicle certificate in a counting Bloom filter (or cuckoo filter) works), (iv) the network connection to the SCMS/PKI is Is it available or not? The means for implementing the operations of decision block 308 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that a malfunction report should not be generated (i.e., decision block 308 = "No"), the processor again determines whether a malfunction condition is detected at block 302 as described. Sensor data can be analyzed (i.e., monitored and analyzed) in order to

In response to determining that the malfunction report is to be stored (i.e., decision block 308="Yes"), the processor may store the malfunction report in memory storage of the malfunction management system at block 310. . Means for implementing the operations of decision block 308 may include vehicle processing system 102 , 104 , 106 , 204 , processor 205 , and memory 206 .

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

In response to determining that the malfunction report should not be stored (i.e., decision block 312 = "No"), the processor determines whether a malfunction condition is detected at block 302 as described. Sensor data can be analyzed (i.e., monitored and analyzed) for purposes.

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 whether to transmit the malfunction report to a malfunction management authority at decision block 312.

In response to determining that the malfunction report should be transmitted (ie, decision block 312=“Yes”), the processor may transmit the malfunction report to a malfunction management authority at block 314. Means for implementing the operations of block 314 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 . The processor may then analyze (ie, monitor and analyze) the sensor data to determine whether a malfunction condition is detected at block 302 as described.

In various embodiments, after generating the MBR at block 306, the processor may determine whether to store the MBR in local memory at decision block 308 or transmit the MBR at decision block 312. Alternatively, it may be determined whether to both store the MBR in local memory and transmit the MBR. In some situations, a vehicle may not have a network connection to transmit its MBR and therefore may store the generated MBR locally. The decision to store the MBR may depend on multiple factors, including: (i) the malfunction is detected but with low certainty (which could allow more evidence to be collected and increased certainty); (ii) the detector requires a larger message set (e.g., a fixed number of (iii) storage is required for blacklisting techniques (counting hashes of remote vehicle certificates in Bloom or Cuckoo filters); and/or (iv) there is no network connection to SCMS/PKI available to transport the MBR.

In some embodiments, the malfunction management system employs artificial intelligence, neural networks, and/or machine learning techniques (referred to herein generally as "machine learning models") to detect the occurrence of malfunction conditions. May be used. Machine learning models may be used by malfunction management systems to analyze large amounts of data from multiple sensors and data sources to obtain an indication or probability of whether a malfunction condition exists. In embodiments where the malfunction management system uses a machine learning model to detect malfunction conditions, the malfunction management system generates an MBR that includes information about and/or generated by the machine learning model. Can be done. This reduces the amount of data contained in, stored with, and/or transmitted in the MBR compared to including all data related to or characterizing the detected malfunction condition. be able to. Accordingly, in embodiments where the malfunction management system uses machine learning models to detect malfunction conditions, the malfunction management system may be configured to generate malfunction reports that include one or more of the following: A machine learning model, the output of a machine learning model, a principal component analysis of a machine learning model, an intermediate representation of a machine learning model, or an identifier of a machine learning model. In embodiments where the malfunction report includes a machine learning model identifier, the malfunction management system operating on the V2X device and the malfunction management authority may have previously shared machine learning models and have agreed on index values. Can be done.

Additionally, in embodiments where there may be multiple stored malfunction reports, the malfunction management system can set the priority in which the MBR is transmitted. For example, the priority may be based on the calculated weight of each MBR (ie, highest priority first). As discussed in more detail below with reference to FIG. 6, an MBR can be assigned a weight that can vary depending on the relative age of the MBR. If competing MBRs have the same calculated weight value, the stored order of MBRs may be used to determine transmission priority. For example, a first-in-first-out (FIFO) or last-in-first-out (LIFO) method may be used, or if the calculated weights are decoupled from the classification or severity of the underlying malfunction condition, the assigned classification. Alternatively, a severity value may be used as a priority parameter.

Another transmission priority rule may be a "fairness" rule in which the own vehicle may transmit the MBR it reports regarding its neighboring vehicles (ie, vehicles with different IDs). This transmission priority rule can ensure that the own vehicle does not always report only one particular nearby vehicle. Fairness can be implemented using round robin scheduling techniques. For example, the own vehicle can detect malfunction conditions occurring within the own vehicle and malfunction conditions occurring within nearby vehicles. Referring to FIG. 1, vehicle 12 (own vehicle) can detect malfunction conditions occurring within vehicle 12 and malfunction conditions occurring within vehicles 14 and 16. A malfunction management system operating within V2X equipment 102 may generate a series of MBRs related to malfunction conditions occurring within each of vehicle 12, vehicle 14, and vehicle 16. In one example, a malfunction management system operating within V2X equipment 102 may generate three separate MBRs associated with malfunction conditions occurring within each of vehicle 12, vehicle 14, and vehicle 16. These MBRs are MBR _12-1 , MBR _12-2 , MBR _12-3 , MBR _14-1 , MBR _14-2 , MBR _14-3 , MBR _16-1 , MBR _16-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. Therefore, the reports are: 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 The data may be transmitted in the following order.

The generated MBR can be transmitted to a central "malfunction management authority" (MA) that processes the MBR. The Malfunction Management Authority may perform further analysis on the MBR and determine what enforcement actions to take based on the analysis. In traditional MBR management systems, malfunction management authorities may not want reporting MBR management systems to reveal proprietary information about their capabilities or the things they have observed, and also because of the cryptographic overhead. and processing redundant data can be a burden to the malfunction management authority, which may not maintain good knowledge of the reliability of the receiving MBRs or their functionality. In some embodiments, the MBR includes a malfunction preprocessing entity (e.g., 254) in optional block 316 for preprocessing before being sent to a management authority (e.g., a malfunction management authority (MA)). The malfunctioning processor (also referred to as MBRPre for short) may be transmitted to the malfunctioning processor. For example, MBRPre (e.g. 132, 134) may be the OEM (for reports received from a vehicle) or the mobile network operator (for reports received from a smartphone). . In some embodiments, the MBRPre may have a separate relationship with (eg, be associated with) the V2X equipment 102 , 104 , 106 and may be trusted by the central malfunction management authority 136 . This relationship allows MBR processors (e.g., 132, 134) to send proprietary format MBRs to their MBPre (e.g., 132, 134) so that malfunction management systems running on V2X equipment can , it may be possible to update malfunction management systems operating within V2X equipment. This relationship may also allow MBPres to update malfunction reporting formats or create aggregate or statistical reports and possibly forward original reporting materials.

For example, onboard equipment in vehicles 12, 14, 16 (e.g., 102, 104, 106) may detect an overlap malfunction when two adjacent vehicles with V2X are observed at overlapping locations. can. The vehicle OEM can be aware of the faulty GNSS receiver and therefore override the MBR resulting from this detected condition to avoid the fault MBR being sent to a specific malfunction management authority. or can be withdrawn. As another example, if the OEM knows that the GNSS is not faulty, the OEM may augment the MBR with telematics data to provide richer evidence to the malfunction management authority (e.g., 136). can.

4A and 4B are process flow diagrams illustrating example operations for determining whether a malfunction report should be generated that may be performed as part of method 300. Referring to FIGS. 1A-4B, operations may be performed by a processor of a vehicle processing system (eg, 102, 104, 106, 204).

Referring to FIG. 4A, after the malfunction management system detects that a malfunction condition has occurred at block 302, the malfunction management system may classify the detected malfunction condition at block 321. For example, a malfunction condition may be classified into one of two categories, such as a malfunction associated with a potential safety hazard, or a malfunction associated with a potential road traffic disruption. . An appropriate value may be assigned to a malfunction condition in order to identify the malfunction condition as either a malfunction associated with a potential safety hazard or a malfunction associated with a potential road traffic disruption. can. Means for performing the operations of block 321 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

For example, a malfunction management system for V2X equipment 102 onboard vehicle 12 receives a basic safety message (BSM) from V2X equipment 106 onboard vehicle 16 that vehicle 16 is initiating an emergency braking action. It is possible. However, other sensor data and observations made by other external V2X equipment, such as those in other vehicles or roadside aircraft, may conflict with the emergency braking action. Such malfunction conditions can cause other vehicles to unnecessarily perform sudden braking actions that can lead to an accident. Accordingly, a malfunction condition may be classified as being associated with a potential safety hazard.

In another example, a vehicle's global positioning system (GPS) may incorrectly calculate the vehicle's location. When vehicle positions are incorrectly calculated, causing a particular road/street to falsely report that more vehicles are traveling on it than there are actually traveling on it. There is. Such false reports may be associated with potential road traffic disruptions. Still further, an incorrectly calculated vehicle location may be associated with a potential safety hazard. For example, if a vehicle's GPS calculates and reports the vehicle's location as being in the wrong driving lane (i.e., on the wrong side of the road/street), other vehicles may misreport its location and They may be induced to perform evasive maneuvers to avoid a "phantom" vehicle. This could lead to potential safety issues.

In some embodiments, the malfunction condition may be classified as either a malfunction associated with a potential road traffic disruption or a malfunction associated with a potential road traffic disruption, while in other embodiments A malfunction condition can be assigned a value on a single sliding scale. For example, malfunction conditions associated with safety hazards that can result in serious harm may be assigned a high value. Malfunction conditions that are associated only with road traffic disruption may be assigned a low value. Other malfunctioning conditions that may be associated with both potential safety hazards and potential road traffic disruptions may be assigned intermediate values based on the relative potential harm of the malfunctioning condition compared to the inconvenience. .

At block 323, the processor may determine the observed length of the malfunction condition and assign a value based on the observed length. As an example, in some cases the malfunction condition may be a temporary anomaly that causes the malfunction to be detected. However, in other cases the malfunctioning condition may be permanent. For example, if a malfunction condition only occurs for a short period of time at a specific location, this may be evidence of malicious hacking within a specific area that affects vehicles traveling within the specific area. . In contrast, a persistent malfunction may be the result of a sensor failure that continually reports incorrect data. Whether the duration of the malfunction condition is short or long can be important to the MBR management system. How a malfunction management system determines to respond to the observed length of a malfunction condition (ie, long vs. short) can be subjective. In any case, the observed length of the detected malfunction can be assigned a value to be taken into account in whether an MBR should be generated or not. Means for implementing the operations of block 323 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 325, the processor may determine the number of occurrences of the detected malfunction and may assign a value based on the number of occurrences of the detected malfunction. For example, if a malfunction management system consistently and repeatedly detects the same malfunction, this may indicate that the sensor requires repair or replacement. Accordingly, multiple occurrences of detected malfunctions may be assigned a value (higher or lower) that may result in a determination that an MBR is generated. Means for performing the operations of block 325 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 327, the processor may determine the number of nearby vehicles experiencing a malfunction. As discussed in the example above, the malfunction management system of the V2X equipment 102 onboard the vehicle 12 sends a basic safety message (BSM) to the vehicle 16 that the vehicle 16 is initiating an emergency braking action. may be received from the V2X device 106 that is However, other sensor data and observations made by other external V2X equipment, such as those in other vehicles or roadside aircraft, may conflict with the emergency braking action. The malfunction management system of the vehicle 12 transmits V2X communication that notifies the V2X device 102 installed in the vehicle 12 of the observation performed by the V2X device 106 installed in the vehicle 16. may be received from the malfunction management system. Such an indication of a nearby vehicle regarding the same detected malfunction condition may further support the level of confidence of the vehicle 12 malfunction management system that the malfunction condition was accurately detected. Such indications from nearby vehicles may be recorded and added as evidence of detection of a malfunctioning condition. The malfunction management system can assign a value to a malfunction condition based on the number of nearby vehicles experiencing the same malfunction. For example, if there are a large number of other nearby vehicles experiencing the same malfunction, this can increase the likelihood that the malfunction condition is accurately detected. Means for implementing the operations of block 327 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 329, the processor includes a classification of the detected malfunction conditions (e.g., in the act of block 321), a classification of the detected malfunction conditions (e.g., in the act of block 323), to calculate an aggregate value of the detected malfunction conditions. Based on the observed length of the malfunction, the number of detected occurrences of the malfunction (e.g., in the act of block 325), and the number of nearby vehicles experiencing the malfunction (e.g., in the act of block 327); Values assigned by processors can be aggregated. Means for implementing the operations of block 329 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At decision block 330, the processor may determine whether the aggregate value exceeds a threshold. Means for implementing the operations of decision block 330 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the aggregate value exceeds the threshold (ie, decision block 330=“Yes”), the processor may generate an MBR, which may be generated at block 306 as described.

Responsive to determining that the aggregate value does not exceed the threshold (i.e., decision block 330 = "No"), the processor operates to determine whether a malfunction condition is detected at block 302 as described. Sensor data can be analyzed (ie, monitored and analyzed).

In some embodiments, the values assigned to each of the criteria used to determine whether to generate an MBR may be lower for more severe conditions that warrant generation of an MBR. You can. In such embodiments, aggregate values that are lower than the threshold will exceed the threshold. In other embodiments, the values assigned to each of the criteria used to determine whether to generate an MBR are higher values for more severe conditions that warrant generation of an MBR. Good too. In such embodiments, an aggregate value that is higher than the threshold value will exceed the threshold value.

FIG. 4B illustrates a process performed by a processor of a vehicle processing system (e.g., 102, 104, 106, 204) to determine whether to generate an MBR at decision block 304 (FIG. 3) in response to detection of a malfunction condition. indicates an alternative behavior that may be performed. The processor performs acts of classifying the detected malfunction condition at block 321, determining the observed length of the detected malfunction at block 323, and determining the number of occurrences of the detected malfunction at block 325, as described. An act of determining and determining the number of nearby vehicles experiencing a malfunction in block 327) may be performed. Additionally, after performing the operations of each of blocks 321, 323, 325, and 327, the processor determines whether the assigned value of each criterion exceeds a threshold such that an MBR may be generated. Can be done.

For example, after classifying the detected malfunction condition at block 321 as described (which may include assigning a value based on the classification of the detected malfunction condition), the processor determines at decision block 322 that the assigned value is It can be determined whether the threshold value is exceeded. The means for implementing the operations of decision block 322 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the assigned value based on the classification exceeds the threshold (ie, decision block 322="Yes"), the malfunction management system may generate an MBR at block 306 as described. In response to determining that the assigned value based on the classification does not exceed the threshold (ie, decision block 322="No"), the processor may perform the operations of block 323 as described.

After determining the observed length of the detected malfunction condition at block 323 (which may include assigning a value based on the observed length of the detected malfunction condition), the processor determines the observed length of the detected malfunction condition at decision block 324. It can be determined whether the assigned value based on the assigned length exceeds a threshold. The means for implementing the operations of decision block 324 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the assigned value exceeds the threshold (ie, decision block 324="Yes"), the processor may generate an MBR at block 306 as described.

In response to determining that the assigned value based on the observed length does not exceed the threshold (i.e., decision block 324 = "No"), the processor performs the operations of block 325 as described. be able to.

After determining the number of occurrences of the detected malfunction condition at block 325 (which may include assigning a value based on the number of occurrences of the detected malfunction condition), the processor determines the number of occurrences of the detected malfunction condition at decision block 326. It can be determined whether the value exceeds a threshold. The means for implementing the operations of decision block 326 may include vehicle processing system 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the assigned value exceeds the threshold (ie, decision block 326="Yes"), the processor may generate an MBR at block 306 as described.

In response to determining that the value assigned based on the number of occurrences of the detected malfunction condition does not exceed the threshold (i.e., decision block 326 = "No"), the processor performs the operations of block 327 as described. can be carried out.

After determining the number of nearby vehicles experiencing the same detected malfunction condition at block 327 (which may include assigning a value based on the number of nearby vehicles experiencing the same detected malfunction condition); The processor may determine whether the assigned value based on the number of nearby vehicles experiencing the same malfunction condition detected at decision block 328 exceeds a threshold. The means for implementing the operations of decision block 328 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to the determination that the assigned value exceeds the threshold (ie, decision block 328="Yes"), the processor may generate an MBR at block 306 as described.

In response to a determination that the assigned value based on the number of nearby vehicles experiencing the same detected malfunction condition does not exceed the threshold (i.e., decision block 326="No"), the malfunction management system , the various sensor data of their respective vehicles may be analyzed (eg, monitored and analyzed) at block 302 as described.

5A and 5B are process flow diagrams illustrating example 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 FIGS. 1A-5B, operations may be performed by a processor of a vehicle processing system (eg, 102, 104, 106, 204).

Referring to FIG. 5A, after the MBR is generated at block 306 as described, the processor may determine whether the MBR is to be stored in memory. In light of the limited memory capacity and the amount of potential malfunction conditions that can be detected, the processor of the malfunction management system determines which of the generated MBRs should be stored in memory. can do. For example, similar to the determination of whether to generate an MBR for a detected malfunction condition as shown in FIG. 4A, the processor considers and determines several criteria associated with storage of the generated MBR. , a value can be assigned to the generated MBR for certain criteria. In some embodiments, the processor may aggregate the assigned values and determine whether the aggregate value exceeds a threshold. In response to determining that the aggregate value exceeds the threshold, the processor may store the MBR generated at block 310 as described.

For example, after the MBR is generated at block 306 as described, the processor may determine, at block 331, the confidence level of the detected malfunction condition that is the subject of the generated MBR. In various embodiments, the more data points used by the processor, the higher the level of certainty of a detected malfunction condition that the processor can determine. As an example, the number of nearby vehicles can provide an indication of those observations that a Basic Safety Message (BSM) received from another vehicle is inaccurate. If a large number of nearby vehicles provide observations (which may include supporting evidence, for example) that the BSM is inaccurate, the level of certainty with which a malfunction condition is detected may be relatively high. As another example, receiving conflicting sensor data from multiple sensors on a vehicle may cause the processor to conclude that a malfunction condition has occurred. As another example, if the data from a particular sensor is a clear outlier (e.g., if an overwhelming number of other sensor data contradict the data from that particular sensor), the processor may It can be concluded with a relatively high degree of certainty that this has occurred. In various embodiments, such as any of these examples, a detected malfunction condition may be assigned a certainty value. Means for implementing the operations of block 331 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 333, the processor may determine whether additional messages from nearby vehicles are needed to support MBR. In some embodiments, the processor may determine whether the processor has sufficient information available to evaluate the malfunction report or whether more information is needed. In some embodiments, the processor may determine the number of additional messages that may be required to support MBR (eg, to provide evidence or examples of MBR). For example, the processor may receive an indication from a nearby vehicle that their respective observations are inconsistent with the BSM received from the initial vehicle. Each of these instructions can support and enhance the level of certainty that malfunction conditions are 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 may balance the storage that may be consumed by the additional data and the usefulness of information in the additional data. In some embodiments, the processor determines that such a large MBR with additional messages from nearby vehicles is too large to be stored (e.g., the size of the MBR is greater than or equal to a threshold). can do. In some embodiments, such an MBR may be assigned a value that is too large to support a determination that the MBR should be stored. However, in other embodiments, such MBRs with supporting evidence may be assigned a value that supports a greater likelihood that the MBR will be remembered. Means for performing the operations of block 333 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 335, the processor may 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 may 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 may determine that it is not necessary to store the MBR locally on the V2X device. Accordingly, the processor may assign a value to the MBR report that supports not storing the MBR locally when a communication link to the malfunction management authority is available. Means for performing the operations of block 335 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 337, the processor determines the confidence level of the detected malfunction condition (block 331), whether additional messages from nearby vehicles are required at block 333, and/or the accuracy level of the detected malfunction condition to calculate the aggregate value of the MBR. Alternatively, a value may be aggregated based on the number of messages required from nearby vehicles and whether a communication link to the malfunction management authority at block 335 is available. Means for performing the operations of block 337 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At decision block 339, the processor may determine whether the aggregate value exceeds a threshold (eg, whether the aggregate value warrants storing the MBR).

In response to determining that the aggregate value warrants storage of the MBR (e.g., in response to determining that the aggregate value exceeds a threshold) (i.e., decision block 339="Yes"), the processor performs the operations as described. The MBR may be stored at block 310.

In response to determining that the aggregate value warrants storage of the MBR (e.g., in response to determining that the aggregate value does not exceed a threshold (i.e., decision block 339="No")), the processor At block 302, sensor data is analyzed (ie, monitored and analyzed) to determine whether a malfunction condition is detected.

In some embodiments, the values assigned to each of the criteria used to determine whether to store the MBR may be lower for more severe conditions that warrant storage of the MBR. You can. In such embodiments, aggregate values that are lower than the threshold will exceed the threshold. In some embodiments, the values assigned to each of the criteria used to determine whether to store the MBR may be higher for more severe conditions warranting storage of the MBR. You can. In such embodiments, an aggregate value that is higher than the threshold value will exceed the threshold value.

FIG. 5B illustrates alternative operations that may be performed by a processor of a vehicle processing system (e.g., 102, 104, 106, 204) to determine whether to store the MBR at decision block 308 (FIG. 3). shows. The processor performs an act of determining the level of certainty of the detected malfunction condition at block 331, an operation of determining the number of nearby vehicles experiencing the malfunction condition at block 333, and a malfunction management authority at block 335), as described. An operation may be performed to determine whether a communication link to is available. Additionally, after performing the operations of each of blocks 331, 333, 335, and 337, the processor determines whether the assigned value of each criterion exceeds a threshold such that the MBR may be stored. Can be done.

For example, after determining the confidence level of the detected malfunction condition at block 331 as described (which may include assigning a value based on the confidence level of the detected malfunction condition), the processor determines the confidence level of the detected malfunction condition at decision block 332. It is possible to determine whether the calculated value exceeds a threshold value. Means for performing the operations of block 332 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the assigned value based on the certainty level exceeds the threshold (i.e., decision block 332="Yes"), the processor may store the MBR in local memory at block 310 as described. can.

In response to a determination that the assigned value based on the classification does not exceed the threshold (ie, decision block 332="No"), the processor may perform the operations of block 333 as described.

After determining whether additional messages from nearby vehicles are needed to support MBR at block 333 (assigning a value based on the number of nearby vehicles experiencing the detected malfunction condition) ), the processor may determine whether the assigned value based on the number of nearby vehicles exceeds a threshold at decision block 334. The means for implementing the operations of decision block 334 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the assigned value exceeds the threshold (ie, decision block 334="Yes"), the processor may store the MBR in local memory at block 310 as described.

In response to determining that the value assigned based on the number of nearby vehicles does not exceed the threshold (i.e., decision block 334 = "No"), the processor determines in block 335 that the communication link to the malfunction management authority is available. It can be determined whether or not it is possible. Means for performing the operations of block 335 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that a communication link to the malfunction management authority is available (i.e., decision block 335=“Yes”), the processor transmits the MBR to the malfunction management authority at block 314 as described. Can be done.

In response to determining that the communication link to the malfunction management authority is not available (i.e., decision block block 335="No"), the processor may store the MBR in local memory at block 310 as described. can.

In some embodiments, in addition to determining whether to store an MBR, the processor also determines whether to erase or flush the stored MBR to make room for a more recently generated MBR. It can be determined whether or not. To facilitate this determination, 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, at decision block 312, the processor may prioritize one stored MBR over another based on the respective calculated weights assigned to the stored MBRs.

FIG. 6 is a process flow diagram illustrating example operations 600 for calculating the weight of a malfunction report being generated that may be performed as part of method 300. Referring to FIGS. 1A-6, operations 600 may be performed by a processor of a vehicle processing system (eg, 102, 104, 106, 204).

In some embodiments, the processor may calculate the weight of the MBR after the MBR is generated or after the generated MBR is stored.

After the malfunction report is generated at block 306 as described or after the MBR is stored in memory at block 310 as described, the processor stores the MBR subject matter generated at block 321 as described. Certain detected malfunction conditions can be classified.

At block 343, the processor determines the initial weight value to identify the malfunction condition as either a malfunction associated with a potential safety hazard or a malfunction associated with a potential road traffic disruption. can be assigned to malfunction conditions. In some embodiments, the malfunction condition may be classified as either a malfunction associated with a potential road traffic disruption or a malfunction associated with a potential road traffic disruption, while in other embodiments The processor may assign initial weight values on a sliding scale. For example, a malfunction condition associated with a safety hazard that can result in serious harm may be assigned a relatively high initial weight value, while a malfunction condition associated only with road traffic disruption may be assigned a relatively high initial weight value. can be assigned a low initial weight value. Other malfunctioning conditions that may be associated with both potential safety hazards and potential road traffic disruptions are assigned intermediate initial weight values based on the relative potential harm of the malfunctioning condition compared to the inconvenience. It can be done. Other factors may affect the initial weights assigned. 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 weight may depend not only on the MBR classification, but also on how severe the underlying malfunction is and/or how much it exceeds the reporting threshold. It can also be based on For example, if yaw rate should be consistent with velocity and lateral acceleration, then in response to a determination that the inconsistency is 25%, the processor Initial weights can be assigned. In some embodiments, an aggregate value that may be calculated (eg, in the act of block 329 (FIG. 4A)) may be used as the initial weight assigned to the malfunction condition. For example, the values assigned to a detected malfunction condition by the processor may include the classification of the detected malfunction condition at block 321, the observed length of the detected malfunction at block 323, and the number of occurrences of the detected malfunction at block 325. , and/or the number of nearby vehicles experiencing the malfunction at block 327.

At block 345, the processor may assign an attenuation factor to the MBR. In some embodiments, the damping coefficient may be greater than 0 twist and less than 1. In some embodiments, the attenuation coefficient can be associated with a predetermined time interval. For example, the predetermined time interval may be several hours, days, one week, or one month. In some embodiments, a shorter predetermined time interval may be required to generate a larger amount of MBR. In other embodiments, smaller attenuation factors may be used to reduce the number of viable MBRs for storage and/or transmission. In some embodiments, the combination of a shorter predetermined time interval and a smaller attenuation factor reduces the overall number of MBRs determined (identified, selected) by the processor for storage and/or transmission. It can be easily done. Means for performing the operations of block 345 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 347, the processor may calculate an initial weight for the MBR, which may be calculated by multiplying the MBR's assigned initial weight value and the damping factor. Means for implementing the operations of block 347 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 349, the processor may store the calculated weights along with the associated MBR. In some embodiments, a processor may use counters, timers, and/or clocks to measure predetermined time intervals. Means for performing the operations of block 349 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At decision block 351, the processor may determine whether a predetermined time interval has elapsed. Means for implementing the operations of block 351 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to the determination that the predetermined time interval has not elapsed (i.e., decision block 351=“No”), the processor again determines at decision block 351 whether the predetermined time interval has elapsed. Can be done.

In response to determining that the predetermined time interval has elapsed (ie, decision block 351=“Yes”), the processor may recalculate the MBR weights at block 353. In some embodiments, to recalculate the malfunction report weight, a previously calculated weight value may be retrieved from storage and multiplied by an attenuation factor. Means for performing the operations of block 353 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

The malfunction management system may again store the calculated weights along with the associated MBRs at block 349 as described. In some embodiments, when a calculated weight or recalculated weight value is stored, this value is used by other processes/decisions to store the MBR based on the stored calculated weight value. , erasure, and/or transmission.

FIG. 7 is a process flow diagram illustrating example operations 700 for determining which stored malfunction reports may be cleared, which may be performed as part of method 300. Referring to FIGS. 1A-7, operations 700 may be performed by a processor of a vehicle processing system (eg, 102, 104, 106, 204). In some embodiments, operation 700 includes a flush/erase process that may utilize the calculated weights of the MBR.

After the MBR is stored at block 310 as described, the processor may determine at decision block 361 whether the remaining storage space is below a threshold amount. For example, the processor may audit available remaining storage space in local memory.

In response to determining that the remaining storage space is below a threshold amount (ie, decision block 361=“Yes”), the processor may clear the stored MBR report at block 363. In some embodiments, a processor may erase one or more MBRs in multiple ways, such as, for example: (i) first in, first out (FIFO), (ii) least severe/hazardous/destructive first, (iii) duplicates first (MBR to report same source ID and same malfunction) generated), the system may aggregate the MBR before erasing old duplicates), and/or (iv) based on the individual current weights. In some embodiments, the processor determines the stored order (i.e., FIFO or LIFO), the classification type of the MBRs, the number of MBRs reporting the same overlapping malfunction condition, or (e.g., one of the operations 600 of FIG. 6). The MBR to be erased may be selected based on one or more of the calculated weights of the malfunction as calculated (partially). In some embodiments, the processor may select an MBR to erase in a FIFO or LIFO manner. In some embodiments, the processor may clear the stored MBRs such that only MBRs reporting potential road traffic disruption inconveniences are cleared. In this way, any MBR associated with security issues is preserved. 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 mentioned above. In some embodiments, the processor may select (determine, identify) which MBR to erase based on aggregate values of such factors. Means for performing the operations of block 363 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the remaining storage space is above the threshold amount (i.e., decision block 361 = "No"), the processor determines whether a malfunction condition is detected at block 302 as described. Various sensor data of their respective vehicles (e.g., 12, 14, 16) may be analyzed (i.e., monitored and analyzed) for the purpose.

In some embodiments, as an alternative to erasing the MBR, the processor offloads the MBR to another storage or module (e.g., smartphone, edge device, other vehicle) (i.e., the stored MBR can be moved). In some embodiments, the processor may encrypt and/or electronically sign each MBR (ie, 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 MBRs to offload.

FIG. 8 is a process flow diagram illustrating example operations 800 for thresholding in a feedback signal that may be implemented as part of method 300. Referring to FIGS. 1A-8, operations 800 may be performed by a processor of a vehicle processing system (eg, 102, 104, 106, 204). In some embodiments, once 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 to transmit the MBR is modified. You can.

After transmitting the malfunction report to the malfunction management authority at block 314 as described, the processor may receive feedback from a central malfunction management authority, such as an SCMS, at 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 to confirm or deny 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 (eg, a response value equal to true) or incorrect (eg, a response value equal to false). Means for implementing the operations of block 371 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 .

In some embodiments, the processor may update its initial weighting factors based on feedback from the management authority. For example, the processor may reduce the accuracy level of the local detection system if the malfunction management system disagrees with the local detection system.

In some embodiments, in response to feedback received from the 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 may 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 based on how the processor decides to emphasize certain factors over other factors. can be assigned to various factors. For example, in some embodiments, repeated occurrences of the same malfunction condition may be due to sensor failure and may be dismissed as a minor inconvenience. In such embodiments, recurring occurrences may be given a lower priority value.

At optional block 373, the processor may adjust one or more generation thresholds governing generation of malfunction reports based on feedback received from the management authority. Means for implementing the operations of block 373 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At optional block 375, the processor may adjust one or more storage thresholds governing storage of generated malfunction reports based on feedback received from the management authority. Means for performing the operations of block 375 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At optional block 377, the processor may adjust a transmission threshold governing the transmission of generated or stored malfunction reports. Means for performing the operations of block 377 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

The processor then analyzes (e.g., monitoring and analysis).

For example, with reference to Figures 4A, 4B, and 8, the Malfunction Management Authority may ensure that only malfunction conditions associated with the most severe safety conditions and/or malfunction conditions that persist over an extended period of time result in the generation of an MBR. , the processor may change the value assigned to any particular detected malfunction condition or provide feedback based on the threshold used to evaluate the malfunction condition. In some embodiments, the feedback from the malfunction management authority may inform the processor that the particular type of malfunction is minor and therefore a report identifying that particular malfunction condition should not be generated. Can be done.

An example of a method of one embodiment is disclosed as follows. A vehicle 12 equipped with V2X equipment 102 may receive a basic safety message with incorrect data. A local malfunction detection system can analyze the BSM and conclude that remote source A (e.g., vehicle 14) is malfunctioning, potentially triggering a false electronic emergency brake light warning. Notify that the sender is transmitting the location of. The malfunction management system determines (determines) to generate a malfunction report (MBR-A). The malfunction management system (i.e., the vehicle processor) can collect evidence (the vehicle 12's own BSM, BSM from remote sources, list of triggered detectors, etc.) and classify the malfunction condition as a "false motion condition." ” and a severity value of “high.” The malfunction management system (ie, vehicle processor) may then decide to store MBR-A with an initial weight value of 1 and a damping coefficient of 0.1. Vehicle 12 equipped with V2X equipment 102 does not have a connection to the SCMS (to upload the MBR) and therefore vehicle 12 equipped with V2X equipment 102 has to wait until it transmits it. Must be. The next day (eg, after a predetermined time interval of a day), the malfunction management system may apply a damping factor to the MBRA that reduces its priority to 0.9. Vehicle 12 equipped with V2X equipment 102 may detect another malfunction condition due to a different remote source B (eg, vehicle 16). Although source B's malfunction condition is a position jump within communication range, the processor may determine that this malfunction condition is not safety critical. Therefore, the processor can store MBR-B with a priority value of 0.5 and an attenuation factor of 0.2. A vehicle 12 equipped with V2X equipment 102 can establish a connection with the SCMS and upload its stored MBR according to the MBR-A->MBR-B priority value. The malfunction management system (ie, vehicle processor) may store a record of identifiers A and B for blacklisting purposes. The processor may erase MBR-A and MBR-B after receiving a successful upload acknowledgment. Optionally, after two days, the malfunction management authority may complete its malfunction investigation and provide feedback to the MBR management system. Vehicle 12 equipped with V2X device 102 can receive a notification that MBR-A was accurate but MBR-B was not. The vehicle malfunction management system may adjust its generation/storage/transmission parameters accordingly, and the local malfunction detection system may be configured with the adjusted internal parameters accordingly.

FIG. 9 is a block component diagram of an example system 900 for local malfunction message filtering. 1A-9, a 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 may be instantiated or implemented in hardware, software, or a combination of hardware and software (eg, by the components shown in FIGS. 11 and 12).

V2X communication module 902 can include a V2X antenna and can be configured to communicate with one or more ITS stations 920 and malfunction management entity 930 via wireless signals, for example. V2X communication module 902 can receive V2X messages from one (or more) ITS stations 920. V2X communication module 902 can also send V2X messages to ITS station 920. V2X communication module 902 may receive a CRL from malfunction management entity 930.

Local malfunction detection system 906 can detect V2X messages containing incorrect or false information. The local malfunction detection system 906 detects whether the incorrect information is unintentional (e.g., incorrect information reported by a malfunctioning sensor) or intentional (e.g., malicious information, or by a hacked V2X device). information provided).

Local malfunction reporting system 908 may generate and send a malfunction report (MBR) indicating the detected malfunction to V2X communication module 902 for transmission to malfunction management entity 930. Local malfunction reporting system 908 may also send the MBR to local malfunction prevention system 904.

Local malfunction prevention system 904 may implement filtering or firewall functionality to prevent V2X messages having detected malfunction conditions from further processing by local malfunction detection system 906. In some embodiments, local anti-malfunction system 904 can be configured with a local block list. The local block list may include station identifiers of ITS stations (eg, 920) that sent incorrect or bogus V2X messages. The V2X processing device is responsive to determining whether a station identifier associated with a received V2X message is present in the local block list and whether a station identifier associated with another received V2X message is present in the local block list. may be configured to determine whether the V2X message should be blocked from further processing (eg, by local malfunction detection system 906).

In some embodiments, local malfunction reporting system 908 may include an interface that allows control of various functions by system administrator 940. For example, the system administrator 940 can selectively enable or disable the provision of the MBR to the local anti-malfunction system 904. In some embodiments, the system administrator 940 can enable or disable the addition of station identifiers to the local block list. In some embodiments, if reporting functionality is disabled and, as a result, local malfunction reporting system 908 does not send reports to local malfunction prevention system 904, local malfunction prevention system 904 is provided by malfunction management entity 930. The information provided can be used to populate the local block list.

FIG. 10A is a process flow diagram of an example method 1000A of local malfunction message filtering in accordance with various embodiments. Referring to FIGS. 1A-10A, operations of method 1000A may be performed on a vehicle including hardware, software, or a combination of hardware and software, such as those shown in FIGS. 9, 11, 12, and 13. It may be implemented by a Everything (V2X) processing device (“processor”).

At block 1002, a V2X processing device may receive a V2X message from an Intelligent Transportation System (ITS) station. Means for performing the operations of block 1002 may include a vehicle processing system (eg, V2X vehicle equipment) 102 , 104 , 106 , 204 , a processor 205 , and a wireless module 218 .

At block 1004, the V2X processing device may analyze information within the received V2X message to detect malfunction conditions as described herein. Means for performing the operations of block 1004 may include vehicle processing systems 102, 104, 106, 204, processor 205.

At block 1010, the V2X processing device may add a station identifier associated with the V2X message having the detected malfunction condition to a local block list in response to the detection of the malfunction condition in the V2X message at block 1010. Means for implementing the operations of block 1010 may include vehicle processing systems 102, 104, 106, 204, processor 205.

At block 1012, the V2X processing device may transmit a malfunction report to a management entity (eg, malfunction management entity 930). In some embodiments, adding a station identifier associated with a V2X message having a detected malfunction condition to a local block list (e.g., block 1012) is performed when the malfunction report is transmitted to a management entity. You can. Means for performing the operations of block 1012 may include vehicle processing systems (eg, V2X onboard equipment) 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 .

The V2X processing device may again receive V2X messages from the ITS station at block 1002 as described.

FIG. 10B is a process flow diagram of an example method 1000B of local malfunction message filtering in accordance with various embodiments. Referring to FIGS. 1A-10B, operations of method 1000B may be performed on a vehicle including hardware, software, or a combination of hardware and software, such as those shown in FIGS. 9, 11, 12, and 13. It may also be implemented by a Everything (V2X) processing device.

At block 1002, a V2X processing device may receive a V2X message from an Intelligent Transportation System (ITS) station as described.

At block 1004, the V2X processing device may analyze information within the received V2X message to detect malfunction conditions as described herein.

At optional decision block 1006, the V2X processing device may determine whether the station identifier should be added to the local block list in some embodiments. For example, a system administrator (eg, system administrator 940) may enable or disable the ability to add station identifiers of detected malfunctioning conditions to a local block list. In such embodiments, the V2X processing device (e.g., local malfunction detection system 906) may analyze information within the received V2X message to detect malfunction conditions. Means for implementing the operations of optional decision block 1006 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

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

In response to a determination that the station identifier should not be added to the local block list (i.e., decision block 1006="No") or subsequent performance of the act of block 1010, the V2X processing device, as described, In response to detecting a malfunction condition in the V2X message at block 1012, a malfunction report may be transmitted to a management entity (eg, malfunction management entity 930). In some embodiments, adding a station identifier associated with a V2X message having a detected malfunction condition to a local block list (e.g., block 1012) is performed when the malfunction report is transmitted to a management entity. You can.

At decision block 1014, the V2X processing device may determine whether a station identifier associated with another received V2X message is present in the local block list. For example, when a V2X processor receives another (second) V2X message, the V2X processor determines whether the station identifier (e.g., message certificate) associated with the second V2X message is on the local block list. It can be determined whether or not. Means for implementing the operations of decision block 1014 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the station identifier associated with another received V2X message is not present in the local block list (i.e., decision block 1014="No"), the V2X processing device begins processing the V2X message at block 1016. may be allowed. For example, the V2X processing device may allow further processing of the V2X message by the local malfunction detection system 906. Means for performing the operations of block 1016 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that a station identifier associated with another received V2X message is present in the local block list (i.e., decision block 1014="Yes"), in some embodiments, the V2X processing device optionally The type of malfunction associated with the station identifier present in the local block list may be determined at block 1018 of . For example, the V2X processing device may determine whether a malfunction associated with a station identifier is an intentional malfunction or an unintentional malfunction. Means for implementing the operations of optional block 1018 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At optional block 1020, the V2X processing device may determine a block time period based on the type of malfunction. For example, the V2X processing device may determine a relatively short time period for unintentional malfunctions. As another example, the V2X processing device may determine a relatively long time period for intentional malfunctions. Means for implementing the operations of optional block 1020 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In various embodiments, after performing the operations of optional block 1020 or determining that a station identifier associated with another received V2X message is present in the local block list (i.e., decision block 1014="Yes") ), the V2X processing device may block the V2X message from further processing (eg, by local malfunction detection system 906) at block 1022. Means for performing the operations of block 1022 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

After performing the operations of block 1016 or block 1022, the V2X processing device may receive a CRL including one or more station identifiers at block 1024. Means for implementing the operations of block 1024 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 .

At block 1026, the V2X processing device may update the local block list based on the one or more station identifiers in the CRL. In some embodiments, the V2X processing device may remove from the local block list one or more station identifiers that are not present in the CRL. As another example, a V2X processing device may maintain or add one or more station identifiers present in a CRL on a local block list. Means for implementing the operations of block 1026 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

The V2X processing device may perform the operations of method 1000B continuously or periodically by again performing the act of receiving a V2X message at block 1002. In various embodiments, a V2X processing device may repeatedly perform the operations of blocks 1002-1026 from time to time.

FIG. 10C is a process flow diagram of an example method 1000C of local malfunction message filtering in accordance with various embodiments. Referring to FIGS. 1A-10C, operations of method 1000C may be performed on a vehicle including hardware, software, or a combination of hardware and software, such as those shown in FIGS. 9, 11, 12, and 13. It may also be implemented by a Everything (V2X) processing device.

At block 1052, the V2X processing device may receive V2X data. The V2X data may include a V2X message from an ITS station (eg, 920) or a CRL from a malfunction management entity (eg, 930). Means for implementing the operations of block 1052 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 .

At decision block 1054, the V2X processing device may determine whether the V2X data is a V2X message. Means for implementing the operations of decision block 1054 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the V2X data is not a V2X message (i.e., decision block 1054 = "No") (e.g., the V2X data is a CRL), the V2X processing device at block 1056 determines that the V2X data is not a V2X message. The local block list can be updated based on the station identifier of the station. Means for performing the operations of block 1056 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 . The V2X processing device may again perform the operations of block 1052 as described.

In response to determining that the V2X data is a V2X message (i.e., decision block 1054 = "Yes"), the V2X processing device determines in decision block 1058 that the station identifier associated with the received V2X message is present in the local block list. It is possible to determine whether or not to do so. Means for implementing the operations of decision block 1058 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the station identifier associated with the received V2X message is present in the block list (i.e., decision block 1058=“Yes”), the V2X processing device, in some embodiments, The type of malfunction associated with the station identifier present in the local block list can be determined at. For example, the V2X processing device may determine whether a malfunction associated with a station identifier is an intentional malfunction or an unintentional malfunction. Means for implementing the operations of optional block 1060 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At optional block 1062, the V2X processing device may determine a block time period based on the type of malfunction. For example, the V2X processing device may determine a relatively short time period for unintentional malfunctions. As another example, the V2X processing device may determine a relatively long time period for intentional malfunctions. Means for implementing the operations of optional block 1062 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At block 1064, the V2X processing device may receive a CRL that includes one or more station identifiers at block 1024. Means for implementing the operations of block 1060 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 . The V2X processing device can then repeat method 1000A by again performing the operations of block 1052 as described.

In response to determining that the station identifier associated with the received V2X message is not present in the local block list (i.e., decision block 1058="No"), the V2X processing device at block 1068 determines that the station identifier associated with the received V2X message is not present in the local block list. Information within incoming V2X messages can be analyzed. Means for performing the operations of block 1068 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

At optional decision block 1070, the V2X processing device may determine whether the station identifier should be added to the local block list in some embodiments. For example, a system administrator (eg, system administrator 940) may enable or disable the ability to add station identifiers of detected malfunctioning conditions to a local block list. In such embodiments, the V2X processing device (e.g., local malfunction detection system 906) may analyze information within the received V2X message to detect malfunction conditions. Means for implementing the operations of optional decision block 1070 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to determining that the station identifier should be added to the local block list (i.e., decision block 1070="Yes"), the V2X processing system responds to detecting a malfunction condition in the V2X message at block 1072. The station identifier associated with the V2X message having the detected malfunctioning condition may be added to the local block list. Means for implementing the operations of optional block 1072 may include vehicle processing systems 102 , 104 , 106 , 204 and processor 205 .

In response to a determination that the station identifier should not be added to the local block list (i.e., decision block 1070="No") or subsequent performance of the operation of optional block 1072, the V2X processing device determines that the station identifier should not be added to the local block list at block 1074. In response to detecting a malfunction condition in a V2X message, a malfunction report can be transmitted to a management entity (eg, malfunction management entity 930). Means for performing the operations of block 1074 may include vehicle processing systems 102 , 104 , 106 , 204 , processor 205 , and wireless module 218 . The V2X processing device can then repeat method 1000A by again performing the operations of block 1052 as described.

FIG. 11 is a component block diagram illustrating an example mobile computing device 400 suitable for use with various embodiments. 1A-11, various embodiments (including, but not limited to, the embodiments described above with reference to FIGS. 1A-10C) may be used for mobile computing devices such as in-vehicle equipment and mobile computing devices 400. It may be implemented in a wide variety of computing systems, including devices. Mobile computing device 400 may include a processor 402 coupled to a touch screen controller 404 and internal memory 406. Processor 402 may be one or more multi-core integrated circuits designated for general purpose or specific processing tasks. Internal memory 406 may be volatile or non-volatile memory, and may be secure and/or encrypted or non-secure and/or non-encrypted 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. is included. Touch screen controller 404 and processor 402 may be coupled to touch screen panel 412, such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen, etc. Additionally, the display of mobile computing device 400 need not have touch screen capabilities.

Mobile computing device 400 includes one or more wireless signal transceivers 408 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF) coupled to each other and/or to processor 402 for transmitting and receiving communications. wireless) and an antenna 410. Transceiver 408 and antenna 410 may be used with the circuits described above to implement various wireless transmission protocol stacks and interfaces. Mobile computing device 400 may include a cellular network wireless modem chip 416 coupled to the processor to enable communication via a cellular network.

Mobile computing device 400 may include a peripheral device connection interface 418 coupled to processor 402. Peripheral device connection interface 418 may be configured solely to accept one type of connection, or may be configured to accept a variety of physical types, common or proprietary, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. It may be configured to accept connections and communication connections. Peripheral device connection interface 418 may also be coupled to a similarly configured peripheral device connection port (not shown).

Mobile computing device 400 may also include speakers 414 for providing audio output. Mobile computing device 400 may also include a housing 420 constructed from plastic, metal, or a combination of materials for housing all or some of the components described herein. One skilled in the art may recognize that the housing 420 may be a vehicle's dashboard counselor within an onboard device. Mobile computing device 400 may also include a power source 422 coupled to processor 402, such as a disposable or rechargeable battery. A rechargeable battery may also be coupled to a peripheral device connection port to receive charging current from a power source external to mobile computing device 400. Mobile computing device 400 may also include physical buttons 424 for receiving user input. Mobile computing device 400 may include a power button 426 for turning mobile computing device 400 on and off.

FIG. 12 is a component block diagram illustrating an example server 500 suitable for use with various aspects. 1A-12, various embodiments (including, but not limited to, the embodiments described above with reference to FIGS. 1A-10C) may also include any of a variety of commercially available servers, such as server 500. It may include a malfunction management authority that utilizes fixed computing systems, such as. Such a server 500 typically includes one or more multi-core processor assemblies 501 coupled to volatile memory 502 and bulk non-volatile memory, such as disk drives 504. As shown in FIG. 12, multi-core processor assemblies 501 may be added to server 500 by inserting them into a rack of assemblies. Server 500 may also include a floppy disk drive, compact disc (CD), or digital versatile disc (DVD) disk drive 506 coupled to processor 501. Server 500 may also be connected to a local area network, the Internet, the public switched telephone network, and/or cellular data networks (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, A network access port 503 coupled to a 3G, multi-core processor assembly 501 may be included for establishing a network interface connection with a network 507, such as LTE, or any other type of cellular data network.

An example implementation is described in the following paragraphs. Although some of the implementations below are described in terms of example methods, additional example implementations include the example methods described in the following paragraphs, wherein operations of the example methods are performed by a processor. An example method, described in the following paragraphs, implemented by a computing device comprising a processor configured to execute enabled instructions, the example method described in the following paragraphs performing the operations of the example implementation method. In the following paragraphs, an exemplary method implemented by a V2X processing device, which may be a vehicle-mounted device, a mobile device unit, a mobile computing unit, or a stationary roadside machine, includes a processor configured by processor-executable instructions for Example methods described in the following paragraphs, including means for performing the functions of the example methods implemented by a V2X processing device: An example method that may be implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a V2X processing device to perform the operations of the example implementation method below. May include.

Example 1. A method for local malfunction management implemented by a vehicle-to-everything (V2X) processing device, comprising receiving a V2X message from an intelligent transportation system (ITS) station and detecting 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 detecting a malfunction condition in the V2X message received from the ITS station. and the method.

Example 2. The method of Example 1, further comprising transmitting a malfunction report to a management entity in response to detecting a malfunction condition in the V2X message.

Example 3. 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 a station identifier associated with a V2X message received from an ITS station to a local block list. , the method described in Example 2.

Example 4. Determining whether a station identifier associated with another received V2X message is present in a local block list; and determining whether a station identifier associated with another received V2X message is present in a local block list. and blocking the V2X message from further processing in response to the determination.

Example 5. The method further comprises: determining a type of malfunction associated with a station identifier present in a local block list; and determining a blocking time period based on the type of malfunction, the station identifier associated with a V2X message. 5. The method of example 4, wherein blocking the V2X message from further processing in response to determining that the V2X message is present in the local block list comprises blocking the V2X message from further processing for a blocking time period.

Example 6. Adding a station identifier associated with a V2X message received from an ITS station to a local block list in response to detecting a malfunction condition in a V2X message received from an ITS station comprises: determining whether a station identifier associated with a V2X message received from an ITS station in response to detection of a malfunctioning condition should be added to a local block list; and determining whether the station identifier should be added to a local block list. and adding a station identifier associated with the V2X message to a local block list in response to the determination of the V2X message.

Example 7. The method further comprises receiving a certificate revocation list (CRL) including one or more station identifiers, and updating a local block list based on the one or more station identifiers in the CRL. , the method described in any of Examples 1 to 6.

Example 8. The method of Example 7, wherein updating the local block list based on the one or more station identifiers of the CRL comprises removing the station identifier associated with the V2X message from the local block list. .

Example 9. The method of Example 7, wherein updating the local block list based on one or more station identifiers of the CRL comprises increasing a block time period for the station identifier associated with the V2X message. .

The method descriptions and process flow diagrams above are provided as illustrative examples only and do not require or imply that the operations of the various embodiments must be performed in the order presented. . As will be appreciated by those skilled in the art, the order of operations in the embodiments described above may be performed in any order. The words "thereafter," "then," "next," and the like do not limit the order of operations; they are merely used to guide the reader through the description of the method. Furthermore, any reference to a claim element in the singular, eg, using the articles "a," "an," or "the," shall not be construed as limiting the element to the singular.

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

The hardware used to implement the various example logic, logic blocks, modules, and circuits described with respect to the embodiments disclosed herein may include 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 other devices designed to perform the functions described herein. Any combination may be used or implemented. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. obtain. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

In one or more embodiments, the described functionality 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 code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. A non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable medium or non-transitory processor-readable medium may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage. The computer may include a device or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. As used herein, "disk" and "disc" refer to compact disc (disc) (CD), laser disc (disc), optical disc (disc), digital versatile disc (disc) (DVD), and floppy disc. (disk), and Blu-ray (registered trademark) disc (disc), where the disc (disk) usually reproduces data magnetically, and the disc (disc) optically reproduces data using a laser. Reproduce. Combinations of the above are also included within the scope of non-transitory computer-readable media and non-transitory processor-readable media. Additionally, the operations of the method or algorithm may be performed on one or more of the codes and/or instructions on a non-transitory processor-readable medium and/or a non-transitory computer-readable medium that may be embodied in a computer program product. May exist in any combination or set.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Accordingly, this disclosure is not intended to be limited to the embodiments set forth herein, but rather to the broadest scope consistent with the following claims and the principles and features of novelty disclosed herein. A range should be given.

12 vehicles
14 Vehicle
16 vehicles
18 Communication Network
20 Safety separation distance
100 V2X system
102 V2X vehicle equipment
104 V2X vehicle equipment
106 V2X automotive equipment
112 Basic safety messages
114 Basic safety messages
116 Basic safety messages
122 Communication Link
124 Communication Link
132 Original Equipment Manufacturer (OEM) Server
134 Original Equipment Manufacturer (OEM) Server
136 Remote Malfunction Management Authority
142 Communication Link
144 Communication Link
150 V2X communication protocol stack
200 systems
202 V2X processing device
204 Vehicle processing system
205 processor
206 Memory
207 Input module
208 Output module
210 In-vehicle network
212 Infotainment system
214 sensor
216 Actuator
218 Wireless module
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 processor
404 touch screen controller
406 Internal memory
408 transceiver
410 antenna
412 Touch Screener Panel
414 Speaker
416 Cellular Network Wireless Modem Chip
418 Peripheral device connection interface
420 housing
422 Power supply
424 Physical Button
426 Power button
500 servers
501 multi-core processor assembly
502 volatile memory
503 network access port
504 disk drive
506 Digital Versatile 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 (28)

A method of local malfunction message filtering implemented by a vehicle-to-everything (V2X) processing device, the method comprising:
receiving a V2X message from an intelligent transportation system (ITS) station;
analyzing information in the received V2X message to detect malfunction conditions in the V2X message;
adding a station identifier associated with the V2X message received from the ITS station to a local block list in response to detecting a malfunction condition in the V2X message received from the ITS station. 2. The method of claim 1, further comprising transmitting a malfunction report to a management entity in response to detection of the malfunction condition in the V2X message. transmitting the malfunction report to the management entity in response to the detection of the malfunction condition in the V2X message, when adding the station identifier associated with the V2X message received from an ITS station to the local block list; 3. The method of claim 2, wherein the method is carried out. determining whether a station identifier associated with another received V2X message is present in the local block list;
2. The method of claim 1, further comprising blocking the V2X message from further processing in response to determining that the station identifier associated with another received V2X message is present in the local block list. determining a type of malfunction associated with the station identifier present in the local block list;
determining a block time period based on the type of malfunction;
blocking the V2X message from further processing in response to determining that the station identifier associated with the V2X message is present in the local block list, blocking the V2X message from further processing for the blocking time period; 5. The method of claim 4, comprising the steps. adding the station identifier associated with the V2X message received from the ITS station to the local block list in response to detecting a malfunction condition in the V2X message received from the ITS station;
determining whether the station identifier associated with the V2X message received from the ITS station should be added to the local block list in response to detection of a malfunction condition in the V2X message received from the ITS station;
adding the station identifier associated with the V2X message to the local block list in response to determining that the station identifier should be added to the local block list. Method. receiving a certificate revocation list (CRL) including one or more station identifiers;
and updating the local block list based on the one or more station identifiers in the CRL. 8. Updating the local block list based on the one or more station identifiers of the CRL comprises removing station identifiers associated with the V2X message from the local block list. Method. 8. The method of claim 7, wherein updating the local block list based on the one or more station identifiers of the CRL includes increasing a block time period for station identifiers associated with the V2X message. . A vehicle-to-everything (V2X) processing device comprising a processor, the processor comprising:
receiving a V2X message from an intelligent transportation system (ITS) station;
analyzing information in the received V2X message to detect malfunction conditions 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 detecting a malfunction condition in the V2X message received from the ITS station. A vehicle-to-everything (V2X) processing device configured. 11. The V2X processing device of claim 10, wherein the processor is further configured with processor-executable instructions for transmitting a malfunction report to a management entity in response to detection of the malfunction condition in the V2X message. The processor transmits the malfunction report to the management entity in response to the detection of the malfunction condition in the V2X message when adding the station identifier associated with the V2X message received from an ITS station to the local block list. 12. The V2X processing device of claim 11, further configured with processor-executable instructions for transmitting to. The processor includes:
determining whether a station identifier associated with another received V2X message is present in the local block list;
and blocking the V2X message from further processing in response to determining that the station identifier associated with the another received V2X message is present in the local block list. 11. The V2X processing device of claim 10. The processor includes:
determining a type of malfunction associated with the station identifier present in the local block list;
determining a blocking time period based on the type of malfunction;
14. The V2X processing device of claim 13, further configured with processor-executable instructions for: blocking the V2X message from further processing for the blocking time period. The processor includes:
determining whether to add the station identifier associated with the V2X message received from the ITS station to the local block list in response to detection of a malfunction condition in the V2X message received from the ITS station;
and adding the station identifier associated with the V2X message to the local block list in response to determining that the station identifier should be added to the local block list. 11. The V2X processing device of claim 10, further configured. The processor includes:
receiving a certificate revocation list (CRL) including one or more station identifiers;
11. The V2X processing device of claim 10, further configured by processor-executable instructions for: updating the local block list based on the one or more station identifiers in the CRL. 17. The V2X processing device of claim 16, wherein the processor is further configured with processor-executable instructions to remove a station identifier associated with the V2X message from the local block list. 17. The V2X processing device of claim 16, wherein the processor is further configured with processor-executable instructions to increase a block time period for a station identifier associated with the V2X message. A vehicle-to-everything (V2X) processing device,
means for receiving a V2X message from an intelligent transportation system (ITS) station;
means for analyzing information in the received V2X message to detect malfunction conditions in the V2X message;
and means for adding a station identifier associated with a V2X message received from the ITS station to a local block list in response to detection of a malfunction condition in the V2X message received from the ITS station. processing device. 20. The V2X processing device of claim 19, further comprising means for transmitting a malfunction report to a management entity in response to detection of the malfunction condition in the V2X message. Means for transmitting the malfunction report to the management entity in response to detection of the malfunction condition in the V2X message adds the station identifier associated with the V2X message received from an ITS station to the local block list. 21. The V2X processing device of claim 20, comprising means for. means for determining whether a station identifier associated with another received V2X message is present in the local block list;
20. Means for blocking the V2X message from further processing in response to determining that the station identifier associated with the another received V2X message is present in the local block list. V2X processing device. means for determining the type of malfunction associated with the station identifier present in the local block list;
and means for determining a blocking time period based on the type of malfunction;
Means for blocking the V2X message from further processing in response to determining that the station identifier associated with the V2X message is present in the local block list includes blocking the V2X message from further processing for the blocking time period. 23. The V2X processing device of claim 22, comprising means for blocking. Means for adding to the local block list the station identifier associated with the V2X message received from the ITS station in response to detection of a malfunction condition in the V2X message received from the ITS station;
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 in response to detection of a malfunction condition in the V2X message received from the ITS station; and,
and means for adding the station identifier associated with the V2X message to the local block list in response to determining that the station identifier should be added to the local block list. V2X processing device listed. means for receiving a certificate revocation list (CRL) including one or more station identifiers;
20. The V2X processing device of claim 19, further comprising means for updating the local block list based on the one or more station identifiers in the CRL. 5. The means for updating the local block list based on the one or more station identifiers of the CRL includes means for removing station identifiers associated with the V2X message from the local block list. V2X processing devices described in 25. 25. The means for updating the local block list based on the one or more station identifiers of the CRL includes means for increasing a block time period for station identifiers associated with the V2X message. V2X processing device described in. a non-transitory processor-readable medium to a processor of a V2X processing device;
an operation of receiving a V2X message from an intelligent transportation system (ITS) station;
an act of analyzing information in the received V2X message to detect malfunction conditions 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 detection of a malfunction condition in the V2X message received from the ITS station. a non-transitory processor-readable medium having processor-executable instructions stored thereon;

Images