METHOD AND SYSTEM FOR MALFUNCTION DETECTION REPORT MANAGEMENT ROUTING - Patent application

Abstract

The method, malfunction management system, and non-transitory processor-readable medium of various embodiments provide for generation, storage, and transmission of malfunction reports from a vehicle-to-everything (V2X) onboard equipment to an associated entity, such as a malfunction management authority. Various embodiments can include detecting that a malfunction condition has occurred and determining whether to generate a malfunction report based on the aggregate value. The malfunction management system can then determine whether to store the malfunction report being generated. The malfunction management system can also determine whether to transmit the generated malfunction report to the malfunction management authority. In some embodiments, the malfunction management system can determine which stored malfunction reports can be erased from storage.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 137,324, filed January 14, 2021, entitled "Method and System for Misbehavior Detection Report Management Routing," the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] The Cellular Vehicle-to-Everything (C-V2X) protocol serves as the foundation for vehicle-based wireless communications, supporting intelligent highways, autonomous and semi-autonomous vehicles, and can be used to improve the overall efficiency and safety of highway transportation systems. C-V2X specifies 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 direct C-V2X, which includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P) communications and provides extended communication range and reliability within a dedicated Intelligent Transport Systems (ITS) 5.9 gigahertz (GHz) spectrum that is independent of cellular networks. The second transmission mode includes vehicle-to-network (V2N) communications in mobile broadband systems and technologies, such as third-generation wireless mobile communication technologies (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) systems, Code Division Multiple Access (CDMA) 2000 systems, etc.), fourth-generation wireless mobile communication technologies (4G) (e.g., Long Term Evolution (LTE) systems, LTE-Advanced systems, Mobile Worldwide Interoperability for Microwave Access (Mobile WiMAX) systems, etc.), and fifth-generation wireless mobile communication technologies (e.g., 5G NR systems).

[0003] IEEE 1609 is a standard being developed for vehicle-based communication systems and functions. Part of that system is the ability for vehicles to broadcast Basic Safety Messages ("BSM" in the drawings) or Cooperative Awareness Messages (CAMs) that other vehicles can receive and process to improve road safety. The processing of such messages in the sending and receiving vehicles occurs in onboard equipment that provides the V2X functionality (referred to herein as "V2X onboard equipment").

[0004] In V2X communications, it is important to detect inaccurate, corrupted, or hacked (i.e., bad) data and prevent such inaccurate data from spreading further. However, with the growing number of vehicles being prepared to join such networks, the amount of potential malfunction condition data is large and growing exponentially. Therefore, to efficiently utilize V2X messaging, the management of such detected malfunction conditions can be controlled. A malfunction detection system is important to perform the functions of detecting bad data and generating a malfunction report (MBR). The MBR needs to be generated, stored locally, and transmitted to a trusted third party (e.g., a malfunction management authority) for investigation. Therefore, the integrity and functionality of V2X onboard equipment become important design considerations when V2X systems are deployed. Summary of the Invention [Means for solving the problem]

[0005] Various aspects include a method for managing generation, storage, and transmission of a malfunction detection report (MBR in the figures) from a V2X or V2V onboard equipment to a malfunction management authority (MA) after a malfunction condition is detected by the V2X or V2V onboard equipment. Various aspects can include determining whether to generate a malfunction report identifying the malfunction condition based on an aggregate severity value in response to detecting the malfunction condition, generating a malfunction report identifying the malfunction condition in response to determining to generate a malfunction report identifying the malfunction condition, determining whether to store the generated malfunction report, and transmitting the generated malfunction report to the malfunction management authority.

[0006] Some aspects may further include determining whether the generated malfunction report should be transmitted to a malfunction management authority, wherein the step of transmitting the generated malfunction report to the malfunction management authority is performed in response to a determination that the generated malfunction report should be transmitted.

[0007] Some aspects may further include analyzing the sensor data using the machine learning model to determine whether a malfunction condition is detected, and generating a malfunction report identifying the malfunction condition may include generating a malfunction report including one or more of the machine learning model, an output of the machine learning model, a principal component analysis of the machine learning model, an intermediate representation of the machine learning model, or an identifier of the machine learning model.

[0008] Some embodiments may further include one or more of the steps of classifying the detected malfunction condition based on the level of the malfunction condition's potential safety impact or potential traffic disruption, determining the observed length of the malfunction condition, determining the number of recurrences of the malfunction condition, or determining the number of adjacent vehicles experiencing the malfunction condition, and may further include generating an aggregate severity value based on one or more of the malfunction condition classification, the observed length of the malfunction condition, the number of recurrences of the malfunction condition, and the number of adjacent vehicles experiencing the malfunction condition.

[0009] Some embodiments may further include one or more of the steps of determining a certainty level of detection of the malfunction condition that is the subject of the malfunction report, or determining whether additional messages from nearby vehicles should be attached to the malfunction report, and determining whether a network communication link to the malfunction management authority is available for transmitting the malfunction condition, and the step of determining whether to store the generated malfunction report to identify the malfunction condition may be based on one or more of the certainty level of detection of the malfunction condition, the number of nearby vehicles to attach additional messages to the malfunction report, and whether a network communication link to the malfunction management authority is available for transmitting the malfunction condition.

[0010] Some aspects may further include the steps of classifying a detected malfunction condition that is the subject of a malfunction report being generated based on the potential safety impact of the malfunction condition, assigning an initial weight to the malfunction report based on the classification of the malfunction condition, assigning a decay factor to the malfunction report, and multiplying the assigned initial weight by the decay factor at periodic intervals to determine a determined weight of the malfunction report, wherein the step of determining whether to store the malfunction report is further based on the determined weight of the malfunction report.

[0011] Some aspects may further include the steps of classifying the detected malfunction condition that is the subject of the malfunction report being generated based on the level of potential traffic disruption; assigning an initial weight to the malfunction report based on the classification of the malfunction condition; assigning a decay factor to the malfunction report; and multiplying the assigned initial weight by the decay factor at periodic intervals to determine a determined weight of the malfunction report, wherein the step of determining whether to store the malfunction report is further based on the determined weight of the malfunction report.

[0012] Some embodiments may further include determining whether the available storage space is below a storage space threshold level, and performing a flush operation in response to determining that the available storage space is below the storage space threshold level, the flush operation erasing stored malfunction reports based on one of the order in which the malfunction reports are stored, the classification of the malfunction condition, the number of duplicate contents stored, and the determined weight of the malfunction reports.

[0013] In some aspects, determining whether to transmit the malfunction report may be based on at least one of a classification of the malfunction condition, an order in which the malfunction report is stored, or a fairness rule. Some aspects may further include transmitting the malfunction report to a malfunction pre-processing entity for pre-processing before being sent to the malfunction management authority.

[0014] Some aspects may further include receiving feedback from a malfunction management authority and performing one or more of the following steps: adjusting, in response to the feedback, generation parameters that influence a decision to generate a malfunction report to identify the malfunction condition; adjusting, in response to the feedback, one or more thresholds for a certainty level of detection of the malfunction condition used to determine whether the malfunction report being generated should be stored, the number of additional message neighboring vehicles to accompany the malfunction report, and whether a communication link to the malfunction management authority is available to transmit the malfunction report; or adjusting, in response to the feedback, transmission parameters that influence a decision to transmit the malfunction report to the malfunction management authority.

[0015] A further aspect includes a malfunction management system including a memory and a processor configured to perform the operations of any of the methods summarized above. A further aspect may include a malfunction management system having various means for performing functions corresponding to any of the methods summarized above. A further aspect may include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of the malfunction management system to perform various operations corresponding to any of the methods summarized above.

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the provided general description and detailed description, serve to explain features herein. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic block diagram illustrating a subset of a V2X system suitable for implementing various embodiments. [Figure 2] FIG. 1 is a component diagram of a malfunction management network for implementing malfunction reporting. [Figure 3]FIG. 1 is a process flow diagram of an exemplary method for managing the generation, storage, and transmission of malfunction reports by a malfunction management system. [Figure 4A] FIG. 1 is a process flow diagram of an exemplary method for determining whether to generate a malfunction report by a malfunction management system. [Figure 4B] FIG. 1 is a process flow diagram of an exemplary method for determining whether to generate a malfunction report by a malfunction management system. [Figure 5A] FIG. 1 is a process flow diagram of an exemplary method for determining whether to store a malfunction report by a malfunction management system. [Figure 5B] FIG. 1 is a process flow diagram of an exemplary method for determining whether to store a malfunction report by a malfunction management system. [Figure 6] FIG. 1 is a process flow diagram of an exemplary method for calculating weights of malfunction reports being generated by a malfunction management system. [Figure 7] FIG. 10 is a process flow diagram of an exemplary method for determining which stored malfunction reports can be cleared by a malfunction management system. [Figure 8] FIG. 1 is a process flow diagram of an exemplary method for adjusting a threshold in a feedback signal by a malfunction management system. [Figure 9] FIG. 1 is a component block diagram illustrating an exemplary mobile computing device suitable for use with various embodiments. [Figure 10] FIG. 1 is a component block diagram illustrating an exemplary mobile computing device suitable for use with various embodiments. [Figure 11] FIG. 1 is a component block diagram illustrating an exemplary server suitable for use with the various embodiments. DETAILED DESCRIPTION OF THE INVENTION

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

[0019] Generally, various embodiments include methods and mechanisms for generating, storing, transmitting, and pre-processing a malfunction report (MBR in the drawings) from a V2X or V2V onboard device to a management authority, such as a malfunction management authority and / or a security certificate management system (SCMS), following the detection of a malfunction condition.

[0020] V2X systems and technology hold considerable promise for improving traffic flow and vehicle safety by enabling vehicles to share information about their location, speed, heading, braking, and other factors that may be useful to other vehicles for collision prevention and other safety functions. Vehicles equipped with V2X / V2V onboard equipment will transmit their vehicle information frequently (e.g., up to 20 times per second) in packets referred to as Basic Safety Messages (BSMs) or Cooperative Awareness Messages (CAMs). With all V2X-equipped vehicles transmitting such BSM / CAM messages, all receiving vehicles have the information necessary to control their own speed and direction to avoid collisions and efficiently and safely position vehicles relative to one another. It is envisioned that V2X-equipped vehicles may be able to improve traffic flow by safely reducing separation distances and alternating positions with some vehicles, avoiding vehicles experiencing obstacles.

[0021] For ease of reference, some of the embodiments are described in this application using a malfunction management system operating within the terminology of vehicle-to-everything (V2X). However, it should be understood that various embodiments encompass any or all of V2X or vehicle-based communication standards, messages, or technologies. Therefore, nothing in this application should be construed as limiting the claims to V2X and basic safety messages (BSMs) unless expressly recited as such in the claims. Additionally, the embodiments described herein discuss on-board equipment for implementing V2X communications. Other embodiments are contemplated in which V2X communications may also include mobile devices, mobile computers, and roadside units (RSUs) that monitor road and vehicle conditions and are prepared to participate in V2X communications.

[0022] To help illustrate the problem addressed by various embodiments, FIG. 1 illustrates a portion of a V2X system 100 including three vehicles 12, 14, and 16. Each vehicle 12, 14, and 16 includes V2X onboard equipment 102, 104, and 106 configured to periodically broadcast basic safety messages 112, 114, and 116, respectively, for reception and processing by other onboard equipment (e.g., 102, 104, and 106). By sharing vehicle location, speed, direction, braking, and other information, the vehicles can maintain safe separation and identify and avoid potential collisions. For example, a trailing vehicle 12 receiving a basic safety message 114 from a leading vehicle 16 can determine the speed and location of the vehicle 16, enabling the vehicle 12 to match speeds and maintain a safe separation distance 20. By being notified via the primary safety message 114 when the leading vehicle 16 applies its brakes, the V2X equipment 102 in the following vehicle 12 can simultaneously apply its brakes to maintain the safety separation distance 20, even if the leading vehicle 16 suddenly stops. As another example, the V2X equipment 104 in the truck vehicle 14 can receive the primary safety messages 112, 116 from the two vehicles 12, 16 and thus be notified that the truck vehicle 14 should stop at an intersection to avoid a collision. Each of the V2X on-board equipment 102, 104, 106 can communicate with each other using any of a variety of proximity communication protocols. Additionally, the vehicles may be able to transmit data and information regarding detected primary safety messages and detected malfunction reports via communication links 122, 124 and over a communication network 18 (e.g., cellular, WiFi, etc.) to an original equipment manufacturer (OEM) (132, 134) and / or a remote malfunction management authority 136. The malfunction report may be transmitted directly to the malfunction management authority 136 (e.g., via communication link 146). In other embodiments, the malfunction report may first be transmitted via communication links 122, 124 to a malfunction report pre-processing unit, such as an OEM server 132, 134, for pre-processing.The preprocessed malfunction report may then be transmitted from the malfunction report preprocessors 132, 134 to the malfunction management authority 136 over communication links 142, 144.

[0023] 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 approach used to ensure authenticity involves issuing each V2X onboard device a certificate that can be used to sign basic safety messages. Certificates issued to V2X onboard devices do not contain the persistent identity of the V2X onboard device and, for this reason, are typically referred to as anonymous certificates. Malfunction management systems operating within the V2X onboard devices in nearby vehicles and the basic safety podcast highway monitoring system can verify the authenticity of the V2X onboard device issuing the basic safety message by verifying the signature in the broadcast message. V2X onboard devices receiving the basic safety message can verify the signature using the public key. To defend against hacking or interference with V2X system operation, V2X onboard devices can be configured to ignore any received basic safety messages signed using an expired or invalid certificate.

[0024] Although signing basic safety messages with a certificate issued to the V2X onboard equipment protects against attempts to inject false basic safety messages, the signature verification process cannot detect cases in which malfunctioning V2X onboard equipment generates incorrect basic safety messages using a legitimate certificate. Various equipment malfunctions can cause the V2X onboard equipment to generate incorrect basic safety messages. For example, faults in the navigation sensors, speed sensors, and / or the wiring from such sensors to the V2X onboard equipment can result in inaccurate reporting of vehicle location (e.g., incorrect lane or larger error) or speed. It is also possible that the V2X onboard equipment could be maliciously modified to generate incorrect basic safety messages signed with a legitimate certificate. Both cases are referred to as malfunctions.

[0025] In many cases, a receiving malfunction management system can detect a malfunction through malfunction detection in onboard processing. Incorrect basic safety messages can be recognized by a malfunction management system operating in another vehicle when information contained in such messages contradicts reliable information available to the V2X onboard equipment. For example, the malfunction management system can recognize location information in a received basic safety message as incorrect when the reported location of the reporting vehicle overlaps with the location of the vehicle receiving the basic safety message. As another example, the malfunction management system can recognize speed information in a received basic safety message as 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 also be used.

[0026] To ensure the integrity and reliability of the V2X system, the malfunction management system can be configured to notify other vehicles and highway systems or authorities of detected incorrect basic safety messages by transmitting messages informing other systems of the detected problem. In conventional systems, the receiving V2X onboard equipment may automatically generate a malfunction report (MBR in the drawings) or a malfunction detection report. Each malfunction report may include the anonymous certificate of the malfunctioning V2X onboard equipment that signed the incorrect basic safety message. Upon detecting a malfunction, the malfunction management system can be configured to send the malfunction detection report to a specific network back-end entity, referred to herein as the SCMS Malfunction Authority (MA), for processing. The reporting V2X onboard equipment is typically configured by the OEM, and therefore the receiver of the malfunction report is typically operated by or on behalf of the reporting V2X onboard equipment's OEM.

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

[0028] The term malfunctioning V2X vehicle equipment is used herein to refer to the V2X vehicle equipment that is alleged to be the cause of the malfunction in the malfunction detection report. However, in some cases, another component or entity other than the allegedly causing V2X vehicle equipment may be malfunctioning using messages or credentials obtained from the V2X vehicle equipment. For example, a faulty sensor or equipment in the same vehicle as the allegedly causing V2X vehicle equipment may be the cause of the erroneous information in the basic safety message that results in the malfunction detection, but there are other scenarios in which an entity outside the vehicle may be the cause of the incorrect basic safety message being transmitted.

[0029] An entity such as an OEM may use malfunction reports for a variety of reasons. For example, an OEM of a V2X vehicle equipment may be interested in seeing information about malfunction reports for malfunctions caused by its V2X vehicle equipment. In some cases, the OEM may desire the information purely for statistical purposes. In other cases, the OEM may take appropriate steps, including, but not limited to, attempting to correct errors in the V2X vehicle equipment implementation, replacing the V2X vehicle equipment, disabling the V2X vehicle equipment, notifying the owner that the vehicle should be brought in for maintenance, erasing certificates from the OEM vehicle equipment, placing some of the OEM vehicle equipment certificates on a revocation list, or issuing new certificates to the V2X vehicle equipment. The OEM may perform such actions over the air in some cases, while in other cases, physical access to the V2X vehicle equipment is required.

[0030] 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 with the large number of malfunction reports. Therefore, it may be necessary to manage whether or not a malfunction report should be generated each time a malfunction condition is detected based on the assigned severity of the detected malfunction. Furthermore, if a malfunction management system operating within the V2X equipment decides to generate a malfunction report, it may be necessary to manage whether or not to store the malfunction report and / or whether or not to send the malfunction report to a management authority within the SCMS. Again, the decision regarding whether or not to store the malfunction report may be based on the severity assigned to the malfunction condition being detected. As malfunction management systems become more sophisticated, the malfunction management system may receive feedback from the malfunction management authority, which provides the malfunction management system with feedback that may enable the malfunction management system to refine and improve its management of malfunction events. In particular, the feedback may enable the malfunction management system to refine when to generate a malfunction report in response to detecting a malfunction, storing the generated malfunction report, and / or transmitting the malfunction report to a malfunction management authority. In some embodiments, the feedback may enable the malfunction management system to refine the level of severity that can be assigned to a detected malfunction condition.

[0031] In V2X communications, it is beneficial to detect bad data to prevent the spread of useless data between vehicles. A malfunction detection system can fulfill this role and generate a malfunction report as a post-detection reaction. The malfunction report may need to be generated, stored locally, and transmitted to a trusted third party (e.g., a malfunction authority within the SCMS) for investigation. The rules for generation, storage, and transmission are non-trivial and can be defined to maximize usefulness and minimize overhead. For example, a malfunction detection system should not generate a malfunction report for each single malfunction of the same type coming from the same remote vehicle, but rather create one report and append an “occurrence” value. This saves generation time (and I / O operations), local storage space, and reduces the number of malfunction reports that need to be transmitted and checked by the MA. The ITS community lacks such a set of rules / algorithms for malfunction report management.

[0032] Various embodiments disclosed herein provide methods and mechanisms for managing malfunction reports after a malfunction condition is detected. Various embodiments may determine when it is appropriate to generate a malfunction report based on a severity assigned in response to the detection of a malfunction condition. Various embodiments may also determine when it is appropriate to store a generated malfunction report when the malfunction report is generated. The decision to store a malfunction report may also be based on the severity level assigned to the detected underlying malfunction condition that is the subject of the malfunction report. Various embodiments may also determine when it is appropriate to delete a previously stored malfunction report. Various embodiments may also determine when it is appropriate to send a malfunction report to a management authority. In some embodiments, to more efficiently utilize the information in the malfunction report, the malfunction management system may preprocess the data included in the malfunction report.

[0033] Various embodiments may include operations of receiving feedback from a management authority to modify or optimize the management of malfunction reports, which may include refining the severity levels assigned.

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

[0035] To provide context and background for various embodiments, the following background regarding the IEEE 1609 malfunction report processing system is provided. The following description is high-level and is provided primarily to explain the roles of various authorities and functions envisioned for interactions between various entities with V2X vehicle equipment. Various implementations are not limited to the following malfunction report management process.

[0036] A transmitting V2X device (e.g., an On-Board Unit (OBU), an RSU, an ASD) may detect a malfunction condition and decide whether to generate, store, and / or transmit a malfunction report to a Malfunction Management Authority (MA), which may also provide such a report to the SCMS. To authenticate the malfunction condition, malfunction report, and basic safety message, each transmitting V2X device may attach a public key signature to each malfunction condition, malfunction report, and basic safety message, which may be verified by the public signing key in a pseudonym certificate issued to the transmitting V2X on-board device.

[0037] Figure 2 shows the various entities and relationships between them involved in the communication of malfunction reports between the malfunction management authority and individual V2X on-board devices.

[0038] 3 illustrates a method 300 of basic operations involved in generating, storing, and managing transmission of malfunction reports from a malfunction management system and malfunction management authority for V2X equipment, according to various embodiments. With reference to FIGS. 1-3, the operations of method 300 may be performed by a malfunction management system (e.g., 102, 104, 106), such as a processor configured with processor-executable instructions to perform the operations of method 300.

[0039] In block 302, malfunction management systems included in the onboard V2X equipment 102, 104, 106 may monitor various sensor data or their respective vehicles 12, 14, 16 to determine whether a malfunction condition is detected. In some embodiments, the V2X equipment may also include roadside devices and / or other mobile units that may be capable of monitoring and observing the behavior of each other vehicle to determine whether a malfunction condition exists. For example, the V2X equipment may receive a basic safety message from another vehicle that is inconsistent with observations that the V2X equipment of the other vehicle may make. As an example, the V2X equipment 102 onboard the vehicle 12 may receive a basic safety message (BSM) from the V2X equipment 106 onboard the vehicle 16 that the vehicle 16 is initiating an emergency braking maneuver. 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 the emergency brakes. In such a situation, the V2X equipment 106 onboard the vehicle 16 can detect the malfunction condition because the BSM that an emergency braking action is being taken is inconsistent with other sensor data monitored by the malfunction management system of the V2X equipment 106 onboard the vehicle 16. Additionally, the malfunction management system of the V2X equipment 102 onboard the vehicle 12, which receives the BSM from the malfunction management V2X equipment 106 onboard the vehicle 16, can also detect the malfunction condition because the BSM received from the V2X equipment 106 onboard the vehicle 16 is inconsistent with observations made by the V2X equipment 102 onboard the vehicle 12.

[0040] While both the V2X equipment 106 onboard the vehicle 16 and the V2X equipment 102 onboard the vehicle 12 can detect a malfunction condition, each V2X equipment 102, 106 can make the decision as to whether a malfunction report should be generated in decision block 304, and if so, what evidence to collect and add to the generated malfunction report. The decision to generate a malfunction report after detecting a malfunction condition can be based on several factors. As discussed in more detail below with reference to Figures 4A and 4B, the decision to generate a malfunction report may be based on (i) the severity of the detected malfunction (level of potential safety impact or potential road traffic disruption), (ii) the length of the observed malfunction (which helps to distinguish temporary failures from persistent malfunctions), (iii) the number of times a remote vehicle is detected as malfunctioning (i.e., which helps to cover sporadic malfunctions), (iv) the number of nearby vehicles (with different certificates) detected as performing a similar malfunction (which helps to aggregate and report larger issues), or (v) simply after at least one detector is triggered.

[0041] In response to a determination that a malfunction report should be generated (i.e., decision block 304="Yes"), the malfunction report may be generated in block 306. Once the malfunction report is generated, the V2X device may determine whether the generated malfunction report should be stored and / or transmitted to a malfunction management authority. In response to a determination that a malfunction report should not be generated (i.e., decision block 304="No"), the V2X device processor may return to monitoring various sensor data to determine whether a malfunction condition is detected in block 302.

[0042] In decision block 308, the malfunction management system can determine whether the malfunction report should be stored in memory. The decision to store the malfunction report after the report is generated can be based on an assigned severity level, which is based on multiple criteria. As discussed in more detail below with reference to Figures 5A and 5B, the decision to store the generated malfunction report can also depend on the assigned severity level, which is based on multiple criteria, which can include: (i) a certainty level of detection of the malfunction condition; (ii) a determined message set size (e.g., a detected malfunction requires only a certain number of messages from nearby devices); (iii) determined storage required for the blacklisting approach (note that storing a hash of a remote vehicle certificate in a counting Bloom filter (or Cuckoo filter) works); and (iv) whether a network connection to the SCMS / PKI is available.

[0043] In response to a determination that the malfunction report should be stored (i.e., decision block 308="Yes"), the malfunction report may be stored in memory storage of the malfunction management system in block 310. Once the malfunction report is stored, the malfunction management system may determine in block 312 whether the generated malfunction report should be transmitted to a malfunction management authority.

[0044] In response to a determination that the malfunction report should not be stored (i.e., decision block 312="No"), the malfunction management system may return to monitoring various sensor data to determine whether a malfunction condition is detected in block 302.

[0045] In some embodiments, even if the malfunction management system determines that the malfunction report should not be stored (i.e., decision block 308="No"), the malfunction management system may optionally determine whether or not to transmit the malfunction report to a malfunction management authority in decision block 312 before again monitoring the various sensor data to determine whether or not a malfunction condition is detected in block 302. As shown in the optional dashed line in FIG. 3, if the malfunction management system determines that the malfunction report should not be stored (i.e., decision block 308="No"), the malfunction management system may optionally determine whether or not to transmit the generated malfunction report to a malfunction management authority in optional decision block 312. The malfunction management system can determine whether or not to transmit the malfunction report to the malfunction management authority.

[0046] In response to a determination that a malfunction report should be transmitted (i.e., decision block 312="Yes"), the malfunction report may be transmitted to the malfunction management authority in block 314. After the malfunction report is transmitted, the malfunction management system may return to monitoring the various sensor data to determine whether a malfunction condition is detected in block 302.

[0047] In some embodiments, the malfunction management system may use artificial intelligence, neural networks, and / or machine learning techniques (generally referred to herein as a "machine learning model") to detect the occurrence of a malfunction condition. The machine learning model may be used by the malfunction management system 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 in which the malfunction management system uses a machine learning model to detect a malfunction condition, the malfunction management system may generate a malfunction report that includes information related to and / or generated by the machine learning model. This may reduce the amount of data included in, stored with, and / or transmitted with the malfunction report compared to including all data associated with or characterizing the detected malfunction condition. Thus, in embodiments in which the malfunction management system uses a machine learning model to detect a malfunction condition, the malfunction management system may be configured to generate a malfunction report that includes one or more of the following: the machine learning model, an output of the machine learning model, a principal component analysis of the machine learning model, an intermediate representation of the machine learning model, or an identifier of the machine learning model. In embodiments where the malfunction report includes an identifier of the machine learning model, the malfunction management system running on the V2X device and the malfunction management authority may have previously shared the machine learning model and may have agreed on an index value.

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

[0049] Another transmission priority rule may be a "fairness" rule, whereby the ego vehicle may transmit malfunction reports that it reports regarding its neighboring vehicles (i.e., vehicles with different IDs). This transmission priority rule may ensure that the ego vehicle does not always report only one particular neighboring vehicle. Fairness may be implemented using a round-robin scheduling technique. For example, the ego vehicle may detect a malfunction condition occurring within itself and a malfunction condition occurring within a neighboring vehicle. Referring to FIG. 1 , vehicle 12 (ego vehicle) may detect a malfunction condition occurring within vehicle 12 as well as a malfunction condition occurring within vehicles 14 and 16. A malfunction management system operating within V2X equipment 102 may generate a series of malfunction reports related to malfunction conditions occurring within each of vehicle 12, vehicle 14, and vehicle 16. In one example, the malfunction management system operating within V2X equipment 102 may generate three separate malfunction reports related to malfunction conditions occurring within each of vehicle 12, vehicle 14, and vehicle 16. These malfunction reports may be organized into MBRs. 12-1 , MBR 12-2 , MBR 12-3 , MBR 14-1 , MBR 14-2 , MBR 14-3 , MBR16-1 , MBR 16-2 , and MBR 16-3 Embodiments that implement a "fairness" rule can ensure that malfunction reports associated with each different vehicle are reported equally within a given uplink budget. Thus, reports are reported based on the MBR 12-1 , MBR 14-1 , MBR 16-1 , MBR 12-2 , MBR 14-2 , MBR 16-2 , MBR 12-3 , MBR 14-3 , and MBR 16-3 etc., may be transmitted in the order

[0050] The generated malfunction reports can be transmitted to a central "malfunction management authority" (MA) that processes the malfunction reports. The malfunction management authority can perform further analysis on the malfunction reports and determine what enforcement actions to take based on the analysis. In conventional malfunction management systems, the malfunction management authority may not maintain a good knowledge of the authenticity or functionality of the received malfunction reports because the reporting malfunction management systems may not want to reveal proprietary information about their functionality or what they have observed, and because encryption overhead and processing redundant data can be a burden to the malfunction management authority.

[0051] In some embodiments, the malfunction report may be transmitted to a malfunction pre-processing entity (also referred to as a malfunction processor, or MBRPre for short) in block 316 for pre-processing before being sent to a malfunction management authority (MA). For example, the MBRPre (e.g., 132, 134) may be the OEM (in the case of reports received from vehicles) or the mobile network operator (in the case of reports received from smartphones). An important characteristic of the MBRPre may be that it may have an individual relationship with the V2X devices 102, 104, 106 and be trusted by the central malfunction management authority 136. This relationship allows the malfunction report processor (e.g., 132, 134) to update the malfunction management systems running on the V2X devices so that they can send malfunction reports in their proprietary format to their MBPres (e.g., 132, 134). This relationship also allows the MBPres to update the malfunction report format or create aggregate or statistical reports, potentially forwarding the original report material. Thus, in some embodiments, the malfunction report initially transmitted from the V2X equipment 102, 104, 106 to the MBPre (e.g., 132, 134) may include more information than if the V2X equipment 102, 104, 106 were to transmit the malfunction report directly to the MA 136. For example, the malfunction report initially transmitted from the V2X equipment 102, 104, 106 to the MBPre (e.g., 132, 134) may include specific or unique information that enables the MBPre (e.g., 132, 134) to monitor and / or calibrate sensors and record unique information related to the operation of the vehicle. It may be unnecessary for the MA 136 to receive such information. Thus, in some embodiments, such additional information may be stripped or removed from the malfunction report before the malfunction report is relayed to the MA 136.

[0052] For example, on-board equipment (e.g., 102, 104, 106) in vehicles 12, 14, 16 can detect an overlapping malfunction when two nearby V2X-equipped vehicles are observed at an overlapping location. The vehicle OEM can recognize the faulty GNSS receiver and can therefore disregard or dismiss the malfunction report resulting from this detected condition to avoid sending the faulty malfunction report to a specific malfunction management authority. As another example, if the OEM knows that the GNSS is not faulty, the OEM can augment the malfunction report with telematics data to provide richer evidence to the malfunction management authority (e.g., 136).

[0053] FIG. 4A illustrates an exemplary method for determining whether a malfunction report should be generated based on an assigned severity level of the underlying malfunction condition at decision block 304. The assigned severity level may be based on multiple criteria. For example, the assigned severity level may be based on the classification of the underlying malfunction condition that is the subject of the presented malfunction report, the observed length of the underlying malfunction condition, the number of occurrences of the underlying malfunction condition, and the number of nearby vehicles that may experience the underlying malfunction condition. To conserve network resources, the generation of malfunction reports may be limited to underlying malfunction conditions with higher aggregate severity values. Limiting the generation of malfunction reports to more significant (i.e., more severe) underlying malfunction conditions may improve the overall system by prioritizing malfunction conditions that may affect user safety or are sufficiently pervasive to affect a larger number of V2X system participants.

[0054] Referring to FIG. 4A , after the malfunction management system detects that a malfunction condition has occurred in block 302, the malfunction management system can determine whether to generate a malfunction report based on whether an aggregate severity value exceeds a threshold. The aggregate severity value may be based on one or more of the malfunction condition classification, the observed length of the malfunction condition, the number of times the malfunction condition recurs, and the number of nearby vehicles experiencing the malfunction condition. Accordingly, FIG. 4A illustrates several optional classification and decision blocks that may be aggregated to generate the aggregate severity value. Various embodiments may use any, some, or all of the optional classification and decision operations. For example, the malfunction management system may classify the malfunction condition detected in block 321. For example, the 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 can be assigned to the malfunction condition 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.

[0055] In the example described above, the malfunction management system of the V2X equipment 102 onboard the vehicle 12 may receive a Basic Safety Message (BSM) from the V2X equipment 106 onboard the vehicle 16 that the vehicle 16 is initiating an emergency braking maneuver. However, other sensor data and observations made by other external V2X equipment, such as those in other vehicles or roadside units, may contradict the emergency braking maneuver. Such a malfunction condition may cause other vehicles to unnecessarily perform sudden braking maneuvers that lead to accidents. Therefore, the malfunction condition may be classified as being associated with a potential safety issue.

[0056] In another example, a vehicle's global positioning system (GPS) may incorrectly determine the vehicle's location. An incorrectly calculated vehicle location may cause a particular road / street to erroneously report that more vehicles are traveling on the road / street than are actually traveling on the road / street. Such an incorrect report may be associated with potential road traffic disruptions. Furthermore, an incorrectly determined vehicle location may be associated with a potential safety hazard. For example, if a vehicle GPS determines 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 be induced to perform evasive maneuvers to avoid the "phantom" vehicle that is incorrectly reporting its location. This may lead to a potential safety hazard.

[0057] In some embodiments, a 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 may be assigned a value on a single sliding scale. For example, a malfunction condition associated with a safety hazard that may result in serious harm may be assigned a high value. A malfunction condition associated only with road traffic disruption may be assigned a low value. Other malfunction conditions that may be associated with both a potential safety hazard and a potential road traffic disruption may be assigned an intermediate value based on the relative potential harm of the malfunction condition compared to the inconvenience.

[0058] In block 323, the malfunction management system can 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 detection of a malfunction. However, in other cases, the malfunction condition may be persistent. For example, if the malfunction condition occurs only for a short period of time in a particular location, this may be evidence of malicious hacking in a particular area affecting vehicles traveling in that area. In contrast, a persistent malfunction may be the result of a sensor failure that continuously reports erroneous data. Whether the malfunction condition is short or long in duration may be important to the malfunction management system. How the malfunction management system determines to respond to the observed length of the malfunction condition (i.e., long vs. short) may be subjective. In any case, the observed length of the detected malfunction may be assigned a value to take into account in whether a malfunction report should be generated.

[0059] In block 325, the malfunction management system 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 the malfunction management system consistently and repeatedly detects the same malfunction, this may indicate that the sensor needs repair or replacement. Thus, multiple occurrences of the detected malfunction may be assigned a value (higher or lower) that may result in a determination that a malfunction report should be generated.

[0060] In block 327, the malfunction management system 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 may receive a Basic Safety Message (BSM) from the V2X equipment 106 onboard the vehicle 16 that the vehicle 16 is initiating an emergency braking action. However, other sensor data and observations made by other external V2X equipment, such as those in other vehicles or roadside units, may contradict the emergency braking action. The malfunction management system of the vehicle 12 may receive V2X communications from the malfunction management system of the V2X equipment 106 onboard the vehicle 16 informing the V2X equipment 102 onboard the vehicle 12 of the observations made by the V2X equipment 106 onboard the vehicle 16. Such indications of nearby vehicles regarding the same detected malfunction condition can further support the level of confidence of the malfunction management system of the vehicle 12 that the malfunction condition was accurately detected. Such indications from nearby vehicles can be recorded and added as evidence of the detection of a malfunction condition. The malfunction management system can assign a value to the malfunction condition based on the number of nearby vehicles experiencing the same malfunction. For example, if there are a large number of other nearby vehicles experiencing the same malfunction, this can increase the likelihood that the malfunction condition has been accurately detected.

[0061] In block 329, to calculate an aggregate value for the detected malfunction condition, values ​​assigned by the malfunction management system may be aggregated based on the classification of the detected malfunction condition in operation block 321, the observed length of the detected malfunction in block 323, the number of occurrences of the detected malfunction in block 325, and the number of adjacent vehicles experiencing the malfunction in block 327. As mentioned above, the aggregate severity value may include any, some, or all of the malfunction condition classification, the observed length of the malfunction condition, the number of recurrences of the malfunction condition, and the number of adjacent vehicles experiencing the malfunction condition.

[0062] At decision block 330, the malfunction management system may determine whether the aggregate severity value exceeds a threshold. In some embodiments, the value assigned to each of the criteria used to determine whether to generate a malfunction report may be lower for more severe conditions that warrant generating a malfunction report. In such embodiments, an aggregate value lower than the threshold will exceed the threshold. In other embodiments, the value assigned to each of the criteria used to determine whether to generate a malfunction report may be higher for more severe conditions that warrant generating a malfunction report. In such embodiments, an aggregate value higher than the threshold will exceed the threshold.

[0063] In response to a determination that the aggregate severity value exceeds the threshold (ie, decision block 330 = “Yes”), the malfunction management system may generate a malfunction report at block 306 .

[0064] In response to a determination that the aggregate severity value does not exceed the threshold (ie, decision block 330="No"), the malfunction management system may again monitor for other malfunction conditions at block 302.

[0065] 4B, an alternative embodiment is shown for determining whether to generate a malfunction report at decision block 304 in response to detecting a malfunction condition. Referring to FIGS. 1-4B, the alternative embodiment may also perform the operations of classifying the detected malfunction condition at block 321, determining the observed length of the detected malfunction at block 323, determining the number of occurrences of the detected malfunction at block 325, and determining the number of nearby vehicles experiencing the malfunction at block 327. However, in contrast to the embodiment shown in FIG. 4A, after each classification or decision operation, a separate determination may be made as to whether the assigned value for each criterion exceeds a threshold value such that a malfunction report may be generated.

[0066] For example, after isolating the detected malfunction condition in block 321 and assigning a value based on the classification of the detected malfunction condition, the malfunction management system can determine whether the assigned value exceeds a threshold in decision block 322.

[0067] If the assigned value based on the classification exceeds the threshold (i.e., decision block 322="Yes"), the malfunction management system may generate a malfunction report in block 306. If the assigned value based on the classification of the detected malfunction does not exceed the threshold (i.e., decision block 322="No"), the malfunction management system may perform the actions of block 323 as described.

[0068] After determining the observed length of the detected malfunction condition in block 323 and assigning a value based on the observed length of the detected malfunction condition, the malfunction management system may determine in decision block 324 whether the assigned value based on the observed length exceeds a threshold.

[0069] In response to a determination that the assigned value exceeds the threshold (i.e., decision block 324="Yes"), the malfunction management system may generate a malfunction report in block 306. In response to a determination that the assigned value does not exceed the threshold based on the observed length of the detected malfunction condition (i.e., decision block 324="No"), the malfunction management system may perform the actions of block 325 as described.

[0070] After determining the number of occurrences of the detected malfunction condition in block 325 and assigning a value based on the number of occurrences of the detected malfunction condition, the malfunction management system may determine in decision block 326 whether the assigned value based on the number of occurrences exceeds a threshold value.

[0071] In response to a determination that the assigned value exceeds the threshold (i.e., decision block 326="Yes"), the malfunction management system may generate a malfunction report in block 306. In response to a determination that the assigned value does not exceed the threshold based on the number of occurrences of the detected malfunction condition (i.e., decision block 326="No"), the malfunction management system may determine the number of nearby vehicles experiencing the malfunction condition in block 327.

[0072] After determining the number of nearby vehicles experiencing the same detected malfunction condition in block 327 and assigning a value based on the number of nearby vehicles experiencing the same detected malfunction condition, the malfunction management system may determine in decision block 328 whether the assigned value based on the number of nearby vehicles experiencing the same detected malfunction condition exceeds a threshold value.

[0073] In response to a determination that the assigned value exceeds the threshold (i.e., decision block 328="Yes"), the malfunction management system may generate a malfunction report in block 306. In response to a determination that the assigned value does not exceed the threshold based on the n number of nearby vehicles experiencing the same detected malfunction condition (i.e., decision block 326="No"), the malfunction management system may again monitor for other malfunction conditions in block 302 as described.

[0074] After generating the malfunction report in block 306, the malfunction management system can decide whether to store the malfunction report in local memory in decision block 308, or whether to transmit the malfunction report in decision block 312, or most likely both. If the vehicle does not have a network connection to transmit its malfunction report, the malfunction management system can decide to store the malfunction report. The decision to store the malfunction report may depend on several factors, such as: (i) a malfunction is detected but with low certainty (thus allowing for the collection of more evidence and increasing certainty); (ii) the detector requires a larger message set (e.g., a malfunction is detected but requires a certain number of messages from nearby devices); (iii) storage is required for blacklisting techniques (a hash of a remote vehicle certificate may be stored in a counting Bloom filter or Cuckoo filter); and / or (iv) there is no network connection to the SCMS / PKI.

[0075] FIG. 5A illustrates an embodiment method 308a for determining whether a malfunction report should be stored in decision block 308. Referring to FIGS. 1-5A, after a malfunction report is generated, it is determined whether the malfunction report should be stored in memory. In light of limited memory capacity and the amount of potential malfunction conditions that may be detected, the malfunction management system may determine which of the generated malfunction reports should be stored in memory. Similar to the determination of whether to generate a malfunction report for a detected malfunction condition shown in FIG. 4A, the malfunction management system may consider and determine several criteria associated with storing the generated malfunction report and assign a value to the generated malfunction report for the particular criteria. The malfunction management system may aggregate the assigned values ​​and determine whether the aggregate value exceeds a threshold. In response to a determination that the threshold is exceeded, the malfunction management system may store the generated malfunction report in block 310.

[0076] For example, after a malfunction report is generated in block 306, the malfunction management system may determine a certainty level of the detected malfunction condition that is the subject of the generated malfunction report in block 331. As described above, several data points may support a higher certainty level of the detected malfunction condition. As one example, the number of nearby vehicles may provide an indication of their observation that a Basic Safety Message (BSM) received from another vehicle is inaccurate. If a large number of nearby vehicles provide corroborating evidence that the BSM is inaccurate, the certainty level that the malfunction condition is detected may be high. In another example, as a result of conflicting sensor data between multiple sensors on the vehicle, the malfunction management system may conclude that a malfunction condition has occurred. If an overwhelming number of other sensor data contradicts the data from a particular sensor, the malfunction management system may conclude with a relatively high certainty that a malfunction condition has occurred. In any of these examples, a certainty value may be assigned to the detected malfunction condition.

[0077] Additionally, the malfunction management system may determine, in block 333, whether additional messages from neighboring vehicles are needed to support the malfunction report. For example, as described above, the malfunction management system may receive indications from neighboring vehicles that their respective observations contradict the BSM received from the initial vehicle. Each of these indications may support and increase the level of confidence that the malfunction condition is accurately detected. However, each of these additional messages added to the data supporting the malfunction report increases the size of the malfunction report to be stored. Thus, valuable storage space may be utilized. In some embodiments, it may be determined that such a large malfunction report with additional messages from neighboring vehicles is too large to store. In some embodiments, such a malfunction report may be assigned a value that is too large to support a decision that the malfunction report should be stored. However, in other embodiments, such a malfunction report with supporting evidence may be assigned a value that supports a greater likelihood that the malfunction report will be stored.

[0078] Additionally, the malfunction management system may determine whether a communication link to a malfunction management authority is available in block 335. If a communication link to the malfunction management authority is available, the malfunction management system may transmit the malfunction report to a remote malfunction management authority for analysis and storage. Thus, the need to store the malfunction report locally on the V2X equipment may be eliminated. Thus, the malfunction management system may assign a value to the malfunction report that supports not storing the malfunction report locally when a communication link to the malfunction management authority is available.

[0079] In decision block 339, the malfunction management system may tally a value assigned by the malfunction management system based on the level of certainty of the detected malfunction condition determined in block 331, the number of nearby vehicles experiencing the malfunction condition determined in block 333, and whether a communication link to the malfunction management authority is available, determined in block 337.

[0080] In response to a determination that the aggregate value exceeds the threshold (ie, decision block 339 = “Yes”), the malfunction management system may store a malfunction report at block 310 .

[0081] In response to a determination that the aggregate value does not exceed the threshold value (i.e., decision block 339="No"), the malfunction management system may continue to monitor for other malfunction conditions at block 302. In some embodiments, the value assigned to each of the criteria used to determine whether to store a malfunction report may be lower for more severe conditions that warrant storing a malfunction report. In such embodiments, an aggregate value lower than the threshold value will exceed the threshold value. In other embodiments, the value assigned to each of the criteria used to determine whether to store a malfunction report may be higher for more severe conditions that warrant storing a malfunction report. In such embodiments, an aggregate value higher than the threshold value will exceed the threshold value.

[0082] 5B illustrates an alternative embodiment method 308b for determining whether to store a malfunction report in decision block 308. Referring to FIGS. 1-5B, method 308b may include, as described, operations for determining a certainty level of a detected malfunction condition in block 331, determining a number of nearby vehicles experiencing the malfunction condition in block 333, and determining whether a communication link to a malfunction management authority is available in block 337 of method 308a. However, in contrast to method 308a, after each determination operation, a separate determination may be made as to whether an assigned value for each criterion exceeds a threshold value, resulting in a malfunction report being stored.

[0083] For example, after determining the certainty level of the detected malfunction condition in block 331 and assigning a value based on the certainty level of the detected malfunction condition, the malfunction management system may determine whether the assigned value exceeds a threshold in decision block 332. In response to a determination that the assigned value based on the certainty level exceeds the threshold (i.e., decision block 332="Yes"), the malfunction management system may store a malfunction report in local memory in block 310. In response to a determination that the assigned value based on the classification of the detected malfunction condition does not exceed the threshold (i.e., decision block 332="No"), the malfunction management system may determine the number of nearby vehicles experiencing the malfunction condition in block 333.

[0084] After assigning a value based on the number of adjacent vehicles experiencing a malfunction condition and the number of adjacent vehicles experiencing a detected malfunction condition in block 333, the malfunction management system may determine whether the assigned value based on the number of adjacent vehicles exceeds a threshold in decision block 334. In response to a determination that the assigned value exceeds the threshold (i.e., decision block 334="Yes"), the malfunction management system may store a malfunction report in local memory in block 310 of method 300 as described.

[0085] In response to a determination that the assigned value based on the number of nearby vehicles does not exceed the threshold value (i.e., decision block 334="No"), the malfunction management system may determine whether a communication link to the malfunction management authority is available in block 335. In response to a determination that a communication link to the malfunction management authority is available (i.e., decision block 335="Yes"), the malfunction management system may decide to transmit the report to the malfunction management authority in block 314 of method 300 as described. In response to a determination that a communication link to the malfunction management authority is not available (i.e., decision block 335="No"), the malfunction management system may store the malfunction report in local memory in block 310 of method 300 as described.

[0086] In addition to determining whether to store a malfunction report, the malfunction management system may determine when to erase or flush a stored malfunction report from local storage to make room for a more recently generated malfunction report. To facilitate this determination, a weight may be assigned to each stored malfunction report. The weight assigned to each stored malfunction report may also be used by the malfunction management system to determine the priority of transmission of a particular malfunction report. For example, in decision block 312 (FIG. 3) of method 300, the malfunction management system may prioritize one stored malfunction report over another based on the respective weights of the stored malfunction reports.

[0087] 6 illustrates a method 600 for calculating a weight for a generated malfunction report. Referring to FIGS. 1-6, method 600 may be performed by a malfunction management system after a malfunction report is generated or after a generated malfunction report is stored. As discussed above, in block 321, the detected malfunction condition that is the subject of the malfunction report being generated may be classified by the malfunction management system. For example, the 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.

[0088] In block 343, the malfunction management system can assign initial weight values ​​to malfunction conditions to identify them as either malfunctions associated with a potential safety hazard or malfunctions associated with potential road traffic disruptions. In some embodiments, malfunction conditions can be classified as either malfunctions associated with potential road traffic disruptions or malfunctions associated with potential road traffic disruptions, while in other embodiments, malfunction conditions can be assigned initial weight values ​​on a single sliding scale. For example, malfunction conditions associated with safety hazards that may result in serious harm can be assigned a high initial weight value. Malfunction conditions associated only with road traffic disruptions can be assigned a low initial weight value. Other malfunction conditions that may be associated with both potential safety hazards and potential road traffic disruptions can be assigned an intermediate initial weight value based on the relative potential harm of the malfunction condition compared to the inconvenience. Other factors can affect the assigned initial weight or trigger adjustments or corrections to the assigned initial weight. 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, if multiple instances of the same malfunction are observed from the same source, this may prompt or trigger the malfunction management system to aggregate each instance of the malfunction and weight each instance with a higher weight. In some embodiments, if the malfunction management system receives a command from the malfunction management authority 136 (or the malfunction authority pre-processing entity unit 132, 134) to update the assigned initial weights, such a command may prompt or trigger the malfunction management system to adjust the weights accordingly. Such an update by the malfunction management system may increase or decrease the assigned initial weights. In some embodiments, a device or vehicle may experience an event that results in an increase in the initial weight assigned to a malfunction condition.

[0089] As mentioned above, the initial weighting depends not only on the malfunction reporting classification, but may also depend on how severe the underlying malfunction is and / or be based on how much it exceeds a reporting threshold. For example, if yaw rate should be consistent with speed and lateral acceleration, a 25% inconsistency will get a higher initial weighting than a 5% inconsistency.

[0090] In some embodiments, the aggregated value that may be calculated in block 329 may be used as the initial weight assigned to the malfunction condition in block 343. For example, the value assigned to the malfunction condition detected by the malfunction management system in block 329 shown in FIG. 4A may include a value based on one or more of the classification of the detected malfunction condition made in block 321, the observed length of the detected malfunction determined in block 323, the number of occurrences of the detected malfunction determined in block 325, and / or the number of nearby vehicles experiencing the malfunction determined in block 327.

[0091] In addition to the initial weight value, the malfunction management system may assign a damping factor to the malfunction report in block 345. The damping factor may be a value greater than 0 and less than 1. The damping factor may be associated with a predetermined time interval. For example, the predetermined time interval may be several hours, several days, several weeks, or one month. In some embodiments, if the volume of malfunction reports to be generated is large, the malfunction management system may assign damping factors with shorter predetermined time intervals. In some embodiments, a smaller damping factor may be used to reduce the number of malfunction reports available for storage and / or transmission. In some embodiments, the combination of a shorter predetermined time interval and a smaller damping factor may facilitate a reduction in the overall number of malfunction reports determined by the malfunction management system for storage and / or transmission.

[0092] In block 347, the malfunction management system may determine an initial weight for the malfunction report, such as by multiplying the malfunction report's assigned initial weight value and a damping factor.

[0093] The malfunction management system may store this determined weight with the associated malfunction report in block 349. The malfunction management system may retrieve this stored determined weight and use it as a factor to determine whether to store the associated malfunction report in decision block 308 of method 300 (FIG. 3), decision block 330 of operation 304 (FIG. 4A), and / or decision block 339 of operation 308a (FIG. 5A).

[0094] The malfunction management system may use a counter, timer, and / or clock to maintain the predetermined time interval. The malfunction management system may determine whether the predetermined time interval has elapsed in decision block 351. In response to a determination that the predetermined time interval has not elapsed (i.e., decision block 351="No"), the malfunction management system may return to determining whether the predetermined time interval has elapsed at a later point in time.

[0095] In response to determining that the predetermined time interval has elapsed (i.e., decision block 351="Yes"), the malfunction management system may determine a new weight for the malfunction report in block 353. To recalculate the weight for the malfunction report, the malfunction management system may retrieve the previously determined weight from storage and multiply that value by a damping factor.

[0096] The malfunction management system may store the redetermined weight value of the malfunction report in block 349. Once the determined weight or redetermined weight value is stored, this value may be used by the malfunction management system to determine whether to store, clear, and / or transmit the malfunction report based on the stored determined weight value.

[0097] 7 includes a method 700 of a flush / erase process that may utilize the determined weight of a malfunction report. Referring to FIGS. 1-7, after a malfunction report is stored in block 310 of method 300, the malfunction management system may audit the remaining available storage space in local memory and determine whether the remaining storage space is below a threshold amount in decision block 361. When the malfunction management system detects low storage space, the malfunction management system may flush the malfunction reports in any of several manners, such as: (i) first-in-first-out (FIFO); (ii) least severe / hazardous / disruptive first; (iii) duplicates first (assuming malfunction reports are generated to report the same source ID and the same malfunction, the system may aggregate the malfunction reports before purging older duplicates); and / or (iv) based on individual current malfunction report weights.

[0098] In response to determining that the remaining storage space is below the threshold amount (i.e., decision block 361="Yes"), the malfunction management system may erase stored malfunction reports in block 363. The selection of malfunction reports to erase may be based on one of the order in which they were stored (e.g., FIFO or last-in-first-out (LIFO)), the classification type of the malfunction report, the number of malfunction reports reporting the same duplicate malfunction condition, or the determined weight of the malfunction report as determined in method 600 (FIG. 6). The malfunction management system of some embodiments may select to erase stored malfunction reports in a FIFO or LIFO manner. The malfunction management system of some embodiments may select to erase stored malfunction reports such that only malfunction reports reporting potential road traffic disruption inconveniences are erased. In this manner, any malfunction reports associated with a safety issue may be retained. In some malfunction management systems, reports containing duplicate malfunctions may be selected for erasure. In some embodiments, values ​​representing any and all of these factors may be provided and tallied. The decision as to which malfunction reports to clear may be based on the aggregate value of these factors.

[0099] In response to a determination that the remaining storage space exceeds the threshold amount (i.e., decision block 361 = "No"), the malfunction management system may continue to monitor for malfunction conditions at block 302 of method 300 as described.

[0100] An alternative to erasing malfunction reports is to offload the storage of the malfunction reports to another module (e.g., a smartphone, an edge device, another vehicle) as long as the malfunction reports are encrypted and signed. The decision of which malfunction reports to offload may follow the erasure or transmission rules described herein.

[0101] When the MBR is transmitted to a central malfunction management authority, such as an SCMS, the manner in which the malfunction management system generates malfunctions, stores malfunction reports, and determines whether to transmit malfunction reports may be modified. Figure 8 shows a method 800 for modifying the manner in which the malfunction management system may be modified.

[0102] 1-8 , following the operation at block 314 of method 300, the malfunction management system may receive feedback from a central malfunction management authority, such as an SCMS, at block 371. This feedback may be a message sent from the central malfunction management authority to the vehicle malfunction management system, confirming or denying the existence of a malfunction condition event. For example, the feedback message may include a Boolean / binary value indicating whether the malfunction report transmitted by the malfunction management system is correct (response value equal to true) or incorrect (response value equal to false). In some embodiments, a local malfunction detection system (belonging to an end entity) may update its initial weighting factor. For example, the end entity may lower the confidence level of its local detection system if the malfunction management system disagrees with the local detection system.

[0103] As described above, different weights and values ​​can be assigned to the various coefficients in each of the various decisions based on how the malfunction management system chooses to emphasize certain coefficients over other coefficients. For example, in some embodiments, the malfunction management system can attribute repeated occurrences of the same malfunction condition to a sensor failure and ignore it as a minor inconvenience. In such embodiments, the malfunction management system can assign a lower priority to the repeated occurrence. However, feedback received from a central malfunction management authority can modify the coefficients the malfunction management system uses to make its various decisions. Additionally, thresholds that can result in decisions to generate, store, and / or transmit can be modified based on feedback from the central malfunction management authority. In method 800, each of the generation thresholds, storage thresholds, and transmission thresholds that govern each of these decisions can be adjusted at blocks 373, 375, and 377. Once adjustments to the various values ​​have been made, the malfunction management system can again monitor the sensor data for additional malfunction conditions at block 302 of method 300.

[0104] 4A, 4B, and 8, the malfunction management authority may provide feedback that changes the value assigned to a particular detected malfunction condition or the threshold used to evaluate a particular detected malfunction condition by the malfunction management system, so that only malfunction conditions associated with the most severe safety conditions and / or that persist for an extended period of time result in the generation of a malfunction report. In some embodiments, feedback from the malfunction management authority may inform the malfunction management system operating on a particular vehicle's V2X equipment (i.e., 102, 104, 106) that a particular type of malfunction is to be downgraded, thereby downgrading the aggregate severity value, and therefore, a report identifying that particular malfunction condition should not be generated.

[0105] An example of a method of one embodiment is now described. A vehicle 12 equipped with a V2X device 102 may receive a basic safety message with erroneous data. A local malfunction detection system analyzes the BSM and may conclude that remote source A (e.g., vehicle 14) is malfunctioning and indicates that the source is transmitting a false location, which may trigger a false electronic emergency brake light warning. A malfunction management system decides to generate a malfunction report (MBR-A). The malfunction management system may collect evidence (e.g., the vehicle 12's own BSM, the remote source BSM, a list of triggered detectors, etc.) and may classify the malfunction condition as a "false motion state" and assign a severity value of "high." The malfunction management system may then decide to store the MBR-A with an initial weight value of 1 and a decay coefficient of 0.1. In this example, the vehicle 12 equipped with the V2X device 102 does not have a connection to the SCMS (to upload the malfunction report), and therefore the vehicle 12 equipped with the V2X device 102 must wait to transmit it. The next day (i.e., the predetermined time interval = day), the malfunction management system applies a decay factor to MBR-A, reducing its priority to 0.9. The vehicle 12 equipped with V2X equipment 102 detects another malfunction condition caused by a different remote source B (e.g., vehicle 16). The malfunction condition of source B is a location jump within communication range, but is not safety-critical. Therefore, MBR-B can be stored with a priority value of 0.5 and a decay factor of 0.2. The vehicle 12 equipped with V2X equipment 102 establishes a connection with the SCMS and begins uploading its stored malfunction report according to the priority value MBR-A → MBR-B. The malfunction management system keeps a record of identifiers A and B for blacklisting purposes and erases MBR-A and MBR-B after acknowledgment of successful upload. (Optional) After two days, the malfunction management authority can complete its malfunction investigation and prefers to provide feedback to the malfunction management system. The vehicle 12 equipped with the V2X device 102 receives notification that MBR-A was accurate but MBR-B was not.The malfunction management system can then adjust its generation / storage / transmission parameters accordingly and notify the local malfunction detection system to adjust its internal parameters.

[0106] Various embodiments (including, but not limited to, those described above with reference to FIGS. 1-8 ) may be implemented within a wide variety of computing systems, including in-vehicle equipment and mobile computing devices, examples of which are suitable for use with various embodiments are shown in FIG. 9 . The mobile computing device 400 may include a processor 402 coupled to a touchscreen controller 404 and internal memory 406. The processor 402 may be one or more multi-core integrated circuits, general-purpose or designated for specific processing tasks. The internal memory 406 may be volatile or non-volatile memory, and may be secure and / or encrypted, or non-secure and / or non-encrypted, or any combination thereof. Examples of memory types that may be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 404 and processor 402 may be coupled to a touchscreen panel 412, such as a resistive-sensing touchscreen, a capacitive-sensing touchscreen, or an infrared-sensing touchscreen. Additionally, the display of the mobile computing device 400 need not have touchscreen capabilities.

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

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

[0109] The mobile computing device 400 may also include a speaker 414 for providing audio output. The mobile computing device 400 may also include a housing 420 constructed from plastic, metal, or a combination of materials for enclosing all or a portion of the components described herein. Those skilled in the art will recognize that the housing 420 may be a vehicle dashboard counsel within an in-vehicle device. The mobile computing device 400 may also include a power source 422, such as a disposable or rechargeable battery, coupled to the processor 402. The rechargeable battery may be coupled to a peripheral device connection port to receive charging current from a power source external to the mobile computing device 400. The mobile computing device 400 may also include a physical button 424 for receiving user input. The mobile computing device 400 may include a power button 426 for turning the mobile computing device 400 on and off.

[0110] Various embodiments (including, but not limited to, those described above with reference to FIGS. 1-8 ) may be implemented in a wide variety of computing systems, including a laptop computer 500, an example of which is shown in FIG. 10 . Many laptop computers include a touchpad touch surface 517 that acts as the computer's pointing device and, therefore, can receive drag, scroll, and flick gestures similar to those implemented on the above-described computing devices equipped with touchscreen displays. The laptop computer 500 typically includes a processor 502 coupled to volatile memory 512 and large-capacity non-volatile memory, such as a flash memory disk drive 513. Additionally, the computer 500 may have one or more antennas 508 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or a cellular telephone transceiver 516 coupled to the processor 502. The computer 500 may also include a floppy disk drive 514 and a compact disk (CD) drive 515 coupled to the processor 502. In a notebook configuration, the computer housing includes a touchpad 517, a keyboard 518, and a display 519, all coupled to the processor 502. Other configurations of computing devices may include a computer mouse or trackball coupled to the processor (e.g., via a USB input), as is well known, and may also be used with various embodiments.

[0111] Various embodiments (including, but not limited to, those described above with reference to FIGS. 1-8 ) may also include a malfunction management authority that utilizes a fixed computing system, such as any of a variety of commercially available servers. An exemplary server 600 is shown in FIG. 11 . Such a server 600 typically includes one or more multi-core processor assemblies 601 coupled to large-capacity non-volatile memory, such as volatile memory 602 and disk drive 604. As shown in FIG. 6 , multi-core processor assemblies 601 may be added to server 600 by inserting them into a rack of assemblies. Server 600 may also include a floppy disk drive, compact disk (CD), or digital versatile disk (DVD) disk drive 606 coupled to processor 601. The server 600 may also include a network access port 603 coupled to the 3G, multi-core processor assembly 601 for establishing a network interface connection with a network 607, such as a local area network, the Internet, a public switched telephone network, and / or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular data network) coupled to other broadcast system computers and servers.

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

[0113] Example 1. A method for managing malfunction reports, comprising the steps of: determining whether to generate a malfunction report identifying the malfunction condition based on an aggregate severity value in response to detecting a malfunction condition; generating a malfunction report identifying the malfunction condition in response to a determination that a malfunction report identifying the malfunction condition should be generated; determining whether to store the generated malfunction report; and transmitting the generated malfunction report to a malfunction management authority.

[0114] Example 2. The method of Example 1, wherein the method further includes a step of determining whether the generated malfunction report should be transmitted to a malfunction management authority, and the step of transmitting the generated malfunction report to the malfunction management authority is performed in response to a determination that the generated malfunction report should be transmitted.

[0115] Example 3. The method of example 1 or 2, wherein the method further includes analyzing the sensor data using a machine learning model to determine whether a malfunction condition is detected, and wherein generating a malfunction report identifying the malfunction condition includes generating a malfunction report including one or more of the machine learning model, an output of the machine learning model, a principal component analysis of the machine learning model, an intermediate representation of the machine learning model, or an identifier of the machine learning model.

[0116] Example 4. The method of any of Examples 1 to 3, wherein the method includes one or more of the steps of classifying the detected malfunction condition based on the level of the malfunction condition's potential safety impact or potential traffic disruption, determining an observed length of the malfunction condition, determining a number of recurrences of the malfunction condition, or determining a number of adjacent vehicles experiencing the malfunction condition, and the method further includes generating an aggregate severity value based on one or more of the malfunction condition classification, the observed length of the malfunction condition, the number of recurrences of the malfunction condition, and the number of adjacent vehicles experiencing the malfunction condition.

[0117] Example 5. The method of any of Examples 1 to 4, wherein the method further includes one or more of the steps of determining a certainty level of detection of the malfunction condition that is the subject of the malfunction report, determining whether additional messages from nearby vehicles should be attached to the malfunction report, or determining whether a network communication link to a malfunction management authority is available to transmit the malfunction condition, and the method includes determining whether to store the malfunction report based on one or more of the certainty level of detection of the malfunction condition, the number of nearby vehicles to attach additional messages to the malfunction report, and whether a network communication link to a malfunction management authority is available to transmit the malfunction condition.

[0118] Example 6. The method of example 5, wherein the method further includes the steps of classifying a detected malfunction condition that is the subject of a malfunction report being generated based on the potential safety impact of the malfunction condition, assigning an initial weight to the malfunction report based on the classification of the malfunction condition, assigning a decay factor to the malfunction report, and multiplying the assigned initial weight by the decay factor at periodic intervals to determine a determined weight of the malfunction report, wherein the step of determining whether to store the malfunction report is further based on the determined weight of the malfunction report.

[0119] Example 7. The method of example 5, wherein the method further includes the steps of classifying a detected malfunction condition that is the subject of a malfunction report being generated based on a level of potential traffic disruption, assigning an initial weight to the malfunction report based on the classification of the malfunction condition, assigning a decay factor to the malfunction report, and multiplying the assigned initial weight by the decay factor at periodic intervals to determine a determined weight of the malfunction report, wherein the step of determining whether to store the malfunction report is further based on the determined weight of the malfunction report.

[0120] Example 8. The method of Example 6 or 7, wherein the method further includes determining whether the available storage space is below a storage space threshold level, and performing a flush operation in response to determining that the available storage space is below the storage space threshold level, the flush operation erasing the stored malfunction reports based on one of the order in which the malfunction reports are stored, the classification of the malfunction condition, the number of duplicate contents stored, and the determined weight of the malfunction reports.

[0121] Example 9. The method of example 8, wherein determining whether to transmit the malfunction report is based on at least one of a classification of the malfunction condition, an order in which the malfunction report is stored, or a fairness rule.

[0122] Example 10. The method of example 9, further comprising receiving feedback from a malfunction management authority and performing one or more of the steps of: adjusting a generation parameter in response to the feedback that influences a decision to generate a malfunction report to identify the malfunction condition; adjusting one or more thresholds for a level of certainty of detection of the malfunction condition used to determine whether or not to store the malfunction report being generated in response to the feedback, a number of additional message neighboring vehicles to accompany the malfunction report, and whether a communication link to the malfunction management authority is available for transmitting the malfunction report; or adjusting a transmission parameter in response to the feedback that influences a decision to transmit the malfunction report to the malfunction management authority.

[0123] Example 11. The method of any of Examples 1 to 10, further comprising transmitting the malfunction report to a malfunction pre-processing entity for pre-processing before being sent to the malfunction management authority.

[0124] The above method descriptions and process flow diagrams are provided merely as illustrative examples and do not require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the above-described embodiments may be performed in any order. Terms such as "then," "then," and "next" do not limit the order of operations; these terms are merely used to guide the reader through the method descriptions. Furthermore, any reference to claim elements in the singular, for example, using the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

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

[0126] The hardware used to implement the various exemplary logic, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed using general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., 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. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

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

[0128] 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. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. [Explanation of symbols]

[0129] 12 vehicles 14 vehicles 16 vehicles 18. Communication Networks 20 Safety separation distance 100 V2X systems 102 V2X automotive equipment 104 V2X vehicle equipment 106 V2X automotive equipment 112 Basic Safety Message 114 Basic Safety Message 116 Basic Safety Message 122 communication links 124 communication links 132 Original Equipment Manufacturer (OEM) Servers 134 Original Equipment Manufacturer (OEM) Servers 136 Remote Malfunction Management Authority 146 Communication Links 200 systems 300 ways 400 Mobile Computing Devices 402 processor 404 Touchscreen Controller 406 internal memory 408 Transceiver 410 Antenna 412 Touch Screen Panel 416 Cellular Network Wireless Modem Chip 418 Peripheral Device Connection Interface 420 Housing 422 Power supply 424 Physical Buttons 426 Power Button 500 laptop computers 502 processor 508 Antenna 512 Volatile Memory 513 disk drive 514 Floppy Disk Drive 515 Compact Disc (CD) Drive 516 Transceiver 517 Touchpad 518 keyboard 519 Display 600 Method, Server 601 Multi-core Processor Assembly 602 Volatile Memory 603 Network Access Port 604 disk drive 606 Digital Versatile Disc (DVD) Disc Drive 607 Network 700 methods 800 ways

Claims

1. 1. A method for managing malfunction reports implemented by a processor of a vehicle-to-everything (V2X) device, comprising: determining whether to generate a malfunction report identifying the malfunction condition based on the aggregate severity value in response to detecting the malfunction condition; generating a malfunction report identifying the malfunction condition in response to a determination to generate a malfunction report identifying the malfunction condition, wherein the determination to generate a malfunction report identifying the malfunction condition is in response to the aggregate severity value exceeding a threshold; determining whether the malfunction report being generated should be stored; transmitting the generated malfunction report to a malfunction management authority; Steps below: classifying the detected malfunction conditions based on the level of potential safety impact or potential traffic disruption of the malfunction conditions; determining the observed length of said malfunction condition; or determining a number of adjacent vehicles experiencing said malfunction condition; and one or more of generating the aggregate severity value as an aggregate of one or more values ​​assigned to the malfunction condition, the one or more values ​​being based on a corresponding one or more of a classification of the malfunction condition, the observed length of the malfunction condition, and a number of the nearby vehicles experiencing the malfunction condition; A method comprising:

2. 2. The method of claim 1, further comprising the step of determining whether the generated malfunction report should be transmitted to the malfunction management authority, wherein the step of transmitting the generated malfunction report to the malfunction management authority is performed in response to a determination that the generated malfunction report should be transmitted.

3. 3. The method of claim 2, further comprising analyzing sensor data using a machine learning model to determine whether a malfunction condition is detected, and wherein generating a malfunction report identifying the malfunction condition comprises generating a malfunction report including one or more of the machine learning model, an output of the machine learning model, a principal component analysis of the machine learning model, an intermediate representation of the machine learning model, or an identifier of the machine learning model.

4. determining a level of certainty of detection of said malfunction condition that is the subject of said malfunction report; determining whether there are additional messages from a plurality of nearby vehicles to accompany the malfunction report; or determining whether a network communication link to the malfunction management authority is available for transmitting the malfunction condition; and further comprising one or more of:

2. The method of claim 1, further comprising determining whether to store the malfunction report based on one or more of the level of certainty of the detection of the malfunction condition, the number of additional message nearby vehicles to accompany the malfunction report, or whether a network communication link to the malfunction management authority is available to transmit the malfunction condition.

5. classifying the detected malfunction condition that is the subject of the generated malfunction report based on the potential safety impact of the malfunction condition; assigning an initial weight to the malfunction report based on the classification of the malfunction condition; assigning a damping factor to the malfunction report; The method of claim 4, further comprising: determining a weight for the malfunction report at regular intervals based on the assigned initial weight and the decay coefficient; and determining whether or not to store the malfunction report is further based on the determined weight for the malfunction report.

6. classifying the detected malfunction condition that is the subject of the generated malfunction report based on the potential safety impact of a level of potential traffic disruption; assigning an initial weight to the malfunction report based on the classification of the malfunction condition; assigning a damping factor to the malfunction report; determining a weight for the malfunction report at periodic intervals based on the assigned initial weight and the decay factor, wherein determining whether to store the malfunction report includes determining a weight for the malfunction report further based on the determined weight for the malfunction report.

5. The method of claim 4, further comprising:

7. The method comprises: determining whether the available storage space is below a storage space threshold level; performing a flush operation in response to determining that the available storage space is below a storage space threshold level, the flush operation erasing stored malfunction reports based on one of an order in which the malfunction reports are stored, a classification of the malfunction condition, a number of duplicates of stored duplicate content, or a determined weight of the malfunction reports; 7. The method of claim 6, further comprising:

8. The method of claim 7 , wherein determining whether to transmit the malfunction report is based on at least one of the classification of the malfunction condition, the order in which the malfunction report is stored, or a fairness rule.

9. receiving feedback from the malfunction management authority; adjusting a generation parameter influencing the decision to generate the malfunction report to identify the malfunction condition in response to the feedback; adjusting, in response to the feedback, one or more thresholds for the certainty level of detection of the malfunction condition, the number of additional message neighboring vehicles to accompany the malfunction report, and whether a communication link to the malfunction management authority is available for transmitting the malfunction report, used to determine whether the malfunction report being generated should be stored; or adjusting transmission parameters in response to the feedback that influence the decision to transmit the malfunction report to the malfunction management authority; performing one or more of:

9. The method of claim 8, further comprising:

10. The method of claim 1 , further comprising the step of transmitting the malfunction report to a malfunction pre-processing entity for pre-processing before being sent to the malfunction management authority.

11. 1. A malfunction management system for use in a vehicle-to-everything (V2X) device, comprising: a transmitter configured to wirelessly transmit and receive data associated with the malfunction report to and from the malfunction management authority; a memory storage coupled to the transmitter and configured to store a malfunction report; a processor coupled to the transmitter and the memory storage; wherein the processor: determining whether to generate a malfunction report identifying the malfunction condition based on the aggregate severity value in response to detecting the malfunction condition; generating a malfunction report identifying the malfunction condition in response to a determination to generate a malfunction report identifying the malfunction condition, wherein the determination to generate a malfunction report identifying the malfunction condition is in response to the aggregate severity value exceeding a threshold; determining whether the malfunction report being generated should be stored; transmitting the generated malfunction report to a malfunction management authority; below: classifying the detected malfunction conditions based on the level of potential safety impact or potential traffic disruption of the malfunction conditions; determining the observed length of said malfunction condition; or determining a number of adjacent vehicles experiencing said malfunction condition; and one or more of generating the aggregate severity value as an aggregate of one or more values ​​assigned to the malfunction condition, the one or more values ​​being based on a corresponding one or more of a classification of the malfunction condition, the observed length of the malfunction condition, and a number of the nearby vehicles experiencing the malfunction condition; a malfunction management system comprising processor-executable instructions for:

12. The processor is configured to: The malfunction management system of claim 11 further comprising processor-executable instructions for:

13. 11. A non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause a processor of a malfunction management system to perform the method of any one of claims 1 to 10.

Images