FMEA-msr monitoring and system response method and electronic device

Abstract

The embodiment of the application discloses a kind of FMEA-MSR monitoring and system response method and electronic equipment.The method obtains the risk data of the key safety system of vehicle, and according to the risk level in risk data, the key safety system is monitored differently with risk, to obtain the first risk monitoring parameter;If the first risk monitoring parameter shows abnormal, according to the first abnormal event report of failure chain information generation, and according to the first abnormal event report, the first response strategy of FMEA analysis is obtained, to trigger the vehicle execution end to control and manage the vehicle in driving state, realizes the real-time linkage of FMEA failure risk and MSR monitoring response, improves the risk prediction accuracy and safety control ability of vehicle in dynamic running scene.

Description

Technical Field

[0001] This application relates to the field of FMEA technology, and in particular to an FMEA-MSR monitoring and system response method and electronic device. Background Technology

[0002] Intelligent connected vehicles integrate advanced technologies such as autonomous driving, vehicle networking, and artificial intelligence. The operational status of their core systems, such as perception modules, communication units, and power control systems, is directly related to driving safety.

[0003] FMEA (Failure Mode and Effects Analysis), as a reliability analysis method, only identifies potential failure modes, analyzes failure causes, and assesses risk levels during the vehicle research and development design stage, and forms corresponding risk management requirements. It is not linked with the vehicle's MSR (Monitoring and System Response), resulting in poor ability to predict and handle safety risks in complex operating scenarios. Summary of the Invention

[0004] Based on this, this application provides an FMEA-MSR monitoring and system response method and electronic device, which can avoid the disconnect between FMEA analysis and MSR, and improve the functional safety, response accuracy and system operation reliability of intelligent connected vehicles in dynamic operating scenarios.

[0005] Firstly, this application provides an FMEA-MSR monitoring and system response method, including: Obtain risk data for the vehicle's critical safety systems; the risk data includes the risk level and failure chain information of the critical safety systems. Based on the risk level, risk monitoring is performed on critical security systems to obtain the first risk monitoring parameter; If the first risk monitoring parameter shows an anomaly in a critical safety system, generate a first anomaly event report based on the failure chain information. Based on the first abnormal event report, obtain the first response strategy from the critical safety system FMEA analysis to trigger the vehicle's execution end to control the vehicle in motion.

[0006] Secondly, this application also provides an FMEA-MSR monitoring and system response device, comprising: The first acquisition unit is used to acquire risk data of the vehicle's key safety systems; the risk data includes the risk level and failure chain information of the key safety systems. The risk monitoring unit is used to monitor the critical security system according to the risk level and obtain the first risk monitoring parameter. The generation unit is used to generate a first abnormal event report based on the failure chain information if the first risk monitoring parameter shows an abnormality in the critical safety system. The second acquisition unit is used to acquire the first response strategy of the critical safety system FMEA analysis based on the first abnormal event report, so as to trigger the vehicle's execution end to control the vehicle in the driving state.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the FMEA-MSR monitoring and system response method as described in the first aspect above.

[0008] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the FMEA-MSR monitoring and system response method provided in the first aspect.

[0009] Fifthly, embodiments of this application also provide a computer program product, including a computer program or instructions, wherein the computer program or instructions are executed by a processor using the FMEA-MSR monitoring and system response method provided in the first aspect.

[0010] The FMEA-MSR monitoring and system response method provided in this application acquires risk data containing risk level and failure chain information, and implements differentiated risk monitoring strategies based on risk level. This ensures that the monitoring intensity matches the severity of potential risks, thereby obtaining the first risk monitoring parameter reflecting the system status. When an abnormal parameter is detected, the failure chain information can be used for precise source tracing and generate a first abnormal event report, avoiding blind alarms. Based on the first abnormal event report, a predefined FMEA response strategy is invoked, triggering the execution end to actively control the vehicle's driving status. This achieves a closed-loop process from risk perception, hierarchical monitoring, anomaly identification to guided response, effectively solving the problem of the disconnect between FMEA analysis and MSR monitoring and response. It ensures that high-risk failure modes can be prioritized for identification and rapid handling, while making the response measures closely aligned with the failure mechanism. This significantly improves the functional safety, response accuracy, and system reliability of intelligent connected vehicles in dynamic operating scenarios. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating the FMEA-MSR monitoring and system response method provided in this application embodiment; Figure 2 An architecture diagram of the FMEA-MSR monitoring and system response method provided in the embodiments of this application; Figure 3 A schematic block diagram of the FMEA-MSR monitoring and system response device provided in the embodiments of this application; Figure 4 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0015] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0016] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0017] Furthermore, in this application, unless otherwise explicitly specified or limited in the embodiments, the terms "installation," "connection," "joining," and "fixing" appearing in the embodiments should be interpreted broadly. For example, a connection can be a fixed connection, a detachable connection, or an integral part; it can also be a mechanical connection, an electrical connection, etc. Of course, it can also be a direct connection, or an indirect connection through an intermediate medium, or it can be the internal communication between two components, or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific implementation.

[0018] For ease of understanding, some key terms in this embodiment are explained below.

[0019] Failure Cause (FC) is the fundamental or direct factor that leads to the occurrence of a failure mode.

[0020] A failure mode (FM) is a specific way in which a product or its components may fail, resulting in loss of function or degradation of performance. For example, excessive power supply output voltage can be considered a failure mode.

[0021] Failure Effect (FE) is the consequence of a failure mode on a product, system, user, or environment.

[0022] A failure chain (FC-FM-FE) is a logical sequence or a data structure that includes the cause of failure, the failure mode, and the impact of failure, to ensure a comprehensive description of a single failure event.

[0023] An undesired event (UE) is an event caused by one or more failure modes and their potential causes that negatively impacts product functionality or system performance.

[0024] A System Undesired Event (SUE) is a serious event that occurs at the system level and is caused by the failure modes and causes of one or more components / subsystems, resulting in a deviation of the overall system functionality, performance, or safety objectives from the expected state.

[0025] Functional networks are a graphical or structured representation used to show the relationships, dependencies, or execution order among the various functions (FUNCs) in a product.

[0026] End-of-Line Defect (EOL-DEF) refers to non-conformities found during final inspection at the end of the production line. Its core objective is to identify defects and ensure that products meet quality standards.

[0027] In related technologies, Failure Mode and Effects Analysis (FMEA) is mainly applied in the vehicle research and development design phase to identify potential failure modes, analyze failure causes, assess risk levels, and formulate corresponding risk management requirements. Meanwhile, Monitoring and System Response (MSR) modules (such as sensor monitoring, data anomaly detection, and status warning units) are responsible for collecting sensor data in real time during vehicle operation, detecting signal anomalies, and executing preset fault handling procedures.

[0028] Because FMEA analysis results are stored as static documents, while the MSR module passively monitors based on fixed thresholds and logic, the two remain relatively independent in terms of data interaction and logical linkage. This results in a disconnect between FMEA analysis and real-time MSR monitoring, making it impossible to implement differentiated monitoring strategies based on dynamically changing risk levels. Furthermore, when anomalies are detected, it is impossible to generate targeted response plans based on specific failure mechanisms, thereby affecting the vehicle's ability to predict and effectively handle safety risks in complex operating scenarios.

[0029] In addition, the updated FMEA risk parameters cannot be automatically synchronized to the monitoring module, and the real-time monitoring data cannot be fed back to the FMEA system, resulting in a break in the data loop of the dynamic operation process, making it difficult to cope with the complex and ever-changing driving scenarios of intelligent connected vehicles.

[0030] To address this, this application provides an FMEA-MSR monitoring and system response method. By acquiring risk data containing risk level and failure chain information, and employing differentiated risk monitoring strategies based on risk level, the monitoring intensity is matched to the severity of potential risks. This yields a first risk monitoring parameter reflecting the system status. When an abnormal parameter is detected, the failure chain information can be used for precise source tracing and a first abnormal event report can be generated, avoiding blind alarms. Based on the first abnormal event report, a predefined FMEA response strategy is invoked, triggering the execution end to proactively control the vehicle's driving status. This achieves a closed-loop process from risk perception, hierarchical monitoring, anomaly identification to guided response, effectively solving the problem of disconnect between FMEA analysis and MSR monitoring and response. It ensures that high-risk failure modes can be prioritized for identification and rapid handling, while ensuring that response measures closely align with the failure mechanism. This significantly improves the functional safety, response accuracy, and system reliability of intelligent connected vehicles in dynamic operating scenarios.

[0031] The FMEA-MSR monitoring and system response method provided in this application embodiment can be applied to the MSR (Monitoring and System Response) module (such as sensor monitoring, data anomaly detection, and status warning unit) in the vehicle. The method is executed by the application software installed in the MSR module.

[0032] like Figure 2 As shown, the MSR module can be equipped with a data acquisition and reporting unit, a monitoring unit, an anomaly preprocessing unit, and a response execution unit. The MSR module can transmit data with the FMEA located in the cloud through a standardized linkage interface on the vehicle. The standardized linkage interface has a data upload interface and a command issuance interface. The data acquisition and reporting unit can transmit monitoring data / anomaly reports / response results to the FMEA in the cloud through the data upload interface to update the failure network, design / production linkage system, and FMEA requirement library in the cloud FMEA. The FMEA requirement library can transmit the updated risk parameters / optimized failure chains to the lightweight FMEA data unit set on the vehicle terminal for storage through the command issuance interface. The monitoring unit and the corresponding execution unit can obtain the corresponding data from the lightweight FMEA data unit to send response commands to the vehicle execution layer to execute safety protection mechanisms (degradation / braking / alarm) and function adjustments (parameter adjustment / mode switching).

[0033] It should be noted that the application scenarios described in the following embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0034] The FMEA-MSR monitoring and system response method provided in this application will be described in detail below.

[0035] like Figure 1 As shown, the method includes the following steps S110 to S140.

[0036] S110. Obtain risk data for the vehicle's critical safety systems; the risk data includes the risk level and failure chain information of the critical safety systems. S120. Based on the risk level, conduct risk monitoring on critical safety systems to obtain the first risk monitoring parameter; S130. If the first risk monitoring parameter shows an anomaly in the critical safety system, generate a first anomaly event report based on the failure chain information. S140. Based on the first abnormal event report, obtain the first response strategy from the critical safety system FMEA analysis to trigger the vehicle's execution end to control the vehicle in motion.

[0037] In this embodiment, the critical safety system can be understood as the core subsystems in the vehicle that involve functional safety (FuSa), such as the autonomous driving perception system, the vehicle communication module, the power control system, or the braking system.

[0038] Risk data serves as the baseline input for subsequent monitoring and response by the MSR module on the vehicle side. It can be obtained from pre-stored data in the vehicle's lightweight FMEA data unit, or directly from the latest data disseminated via OTA technology from the cloud-based FMEA system. Preferably, this application obtains the data directly from the pre-stored data in the vehicle's lightweight FMEA data unit.

[0039] Risk level can be understood as a classification based on the Risk Priority Number (RPN) calculated according to the severity (S), occurrence frequency (O), and detectability (D) of a failure mode, used to characterize the potential danger of the system in its current state. For example, risk levels can be divided into high risk (RPN≥80), medium risk (40≤RPN<80), and low risk (RPN<40).

[0040] Failure chain information can be understood as structured data describing the causal relationship of failure, specifically including triple information of failure cause (FC), failure mode (FM), and failure effect (FE), and the triple information is processed by ID (such as FC-ID, FM-ID, FE-ID).

[0041] Specifically, the combined use of risk level and failure chain information enables the monitoring system to identify anomalies, pinpoint their causes and consequences, and thus provide a data foundation for subsequent differentiated monitoring and precise response. This application, by acquiring risk data based on risk level and failure chain information, dynamically embeds static FMEA analysis results into the vehicle's real-time operating environment, solving the problem of traditional monitoring lacking risk orientation.

[0042] The primary risk monitoring parameter can be understood as a quantitative indicator reflecting the current operating status of a critical safety system. Examples include the amplitude of sensor signals, data transmission delay, voltage fluctuation range, or error count in logic checks.

[0043] In the process of risk monitoring of critical safety systems according to risk level, this application can determine differentiated monitoring strategies based on risk level to achieve risk monitoring of critical safety systems. This enables early detection of potential failure trends, avoids missed or delayed detections that may be caused by fixed-frequency monitoring, and significantly improves the system's sensitivity to critical safety status in dynamic driving scenarios.

[0044] For high-risk systems, multi-dimensional redundant monitoring and predictive detection can be used, with stricter threshold deviations and higher sampling frequencies (e.g., increasing from the usual 50ms / time to 30ms / time). For medium- and low-risk systems, regular monitoring or periodic summary reporting can be used to balance system resource usage.

[0045] Meanwhile, in the process of monitoring the risks of critical safety systems according to risk levels to generate the first risk monitoring parameters, the raw sensor data or status signals can be collected and preliminarily processed in real time, such as obtaining stable values ​​after removing transient interference through filtering algorithms.

[0046] The indication of an anomaly in the critical safety system as a first risk monitoring parameter can be understood as the first risk monitoring parameter exceeding a preset threshold deviation or triggering a specific logical error flag. After determining that an anomaly has been indicated in the critical safety system, this application can call upon the acquired failure chain information to correlate and map the current anomaly with the specific failure cause, failure mode, and failure impact, thereby generating a first anomaly event report.

[0047] The first anomaly report can be understood as a standardized data structure that includes the type of anomaly, the corresponding FM-ID (Failure Mode Label), the associated risk level, the timestamp of the occurrence, and the current vehicle driving scenario. The first anomaly report not only records fault codes but also uses failure chain information to trace and characterize the anomaly; for example, it can directly link camera image interruption to camera power supply reference power drift.

[0048] Meanwhile, this application generates a first abnormal event report based on the failure chain information, which can filter out false alarms caused by transient interference and ensure that the generated report contains all the contextual information required for subsequent response strategies, thus providing a basis for accurate handling. It also provides a foundation for obtaining targeted response strategies, effectively avoiding blind responses due to missing information.

[0049] The first response strategy can be understood as a pre-defined handling plan based on FMEA analysis, matched to a specific failure mode and risk level. In obtaining the first response strategy, this application can retrieve the corresponding execution command from the linked database by parsing the FM-ID and risk level in the first abnormal event report. This triggers the vehicle's execution end to control the vehicle in motion, achieving closed-loop control from anomaly detection to risk elimination. This significantly improves the safety and reliability of the vehicle when facing failure risks, ensuring the safety of passengers.

[0050] Specifically, the first response strategy can be designed according to the risk level. For high-risk events, the first response strategy may include immediately triggering emergency braking, quickly downgrading to assisted driving mode, cutting off the power to relevant functional modules and issuing audible and visual alarms. For medium- and low-risk events, the first response strategy may include adjusting system parameters, recording fault logs, or restricting some non-core functions.

[0051] The execution unit can be understood as the physical or logical unit on the vehicle that receives and executes the first response strategy, such as the automatic driving controller, the brake control unit (BCU), or the human-machine interface (HMI).

[0052] During the process of controlling a vehicle in motion, the execution end can actively intervene in the vehicle's driving status according to the instructions of the first response strategy. For example, when a high-risk failure of the perception system is detected, the execution end can control the vehicle to decelerate smoothly and pull over to the side of the road.

[0053] In this application, by introducing FMEA risk level guidance to control monitoring frequency and threshold, priority identification and predictive monitoring of high-risk failures are achieved. Anomaly reports are generated using failure chain information to ensure the accuracy of anomaly tracing and to obtain response strategies. This ensures a high degree of matching between handling measures and failure mechanisms, and solves the technical problems of passive monitoring, indiscriminate response, and data fragmentation in existing technologies. This significantly enhances the functional safety level of intelligent connected vehicles in dynamic operating environments.

[0054] In some embodiments, step S120 involves monitoring the critical security system for risks based on the risk level to obtain first risk monitoring parameters, including: determining a first monitoring strategy for monitoring the critical security system for risks based on the risk level; and monitoring the critical security system for risks based on the first monitoring strategy to obtain the first risk monitoring parameters.

[0055] In this embodiment, the first monitoring strategy includes parameter settings such as monitoring frequency, number of monitoring dimensions, data sampling accuracy, and threshold deviation tolerance. The first monitoring strategy can be determined by the risk level in the risk data (such as high, medium, and low risk levels calculated based on S / O / D / RPN), thereby ensuring that high-risk failure modes receive more intensive resource attention, while low-risk items reduce system computing power consumption, achieving optimal configuration of monitoring resources.

[0056] For example, when the risk level is determined to be high risk (e.g., RPN≥80), the first monitoring strategy is multi-dimensional redundant monitoring + high-frequency sampling, with a sampling period of 30ms and a multi-sensor cross-validation mechanism enabled; when the risk level is low risk (e.g., RPN<40), the first monitoring strategy is periodic single-point monitoring, with a sampling period of 500ms, and only core status bits are monitored.

[0057] The first risk monitoring parameter can be understood as a quantitative indicator of the status collected in real time during the operation of a critical safety system, used to characterize the current health status of the system or the degree to which it deviates from normal operating conditions.

[0058] The first risk monitoring parameter can be generated after actual monitoring operations are performed based on the frequency, dimensions and logic specified by the first monitoring strategy. It reflects the real-time operating status of the critical safety system under a specific monitoring intensity, and can provide an accurate data basis for subsequent judgment of whether the system is abnormal. It realizes the transformation from abstract risk level to specific quantitative parameter, and ensures the pertinence and accuracy of monitoring results.

[0059] Specifically, the MSR module reads sensor data, communication signals, or control commands according to the sampling period set by the first monitoring strategy, and forms the first risk monitoring parameters after filtering, noise reduction, and standardization.

[0060] For example, if the first monitoring strategy is to monitor the camera image link at high frequency, then the first risk monitoring parameters include image frame loss rate, data transmission delay time, or power supply voltage fluctuation amplitude, etc.

[0061] In this application, risk level is used as an input variable to dynamically generate an adaptive first monitoring strategy, which solves the contradiction between high-risk early warning and low resource consumption in traditional fixed monitoring modes. Monitoring is executed according to the first monitoring strategy to obtain the first risk monitoring parameters. Then, the perception sensitivity can be automatically adjusted according to the risk severity obtained from FMEA analysis. That is, in high-risk scenarios, high-frequency, multi-dimensional monitoring strategies can quickly capture minor anomalies and improve the early detection rate of faults; in low-risk scenarios, low-frequency, simplified monitoring strategies can reduce system load. This not only significantly improves the prediction accuracy of critical safety system failure risks of intelligent connected vehicles, but also effectively avoids the waste of computing resources caused by over-monitoring, achieving a balance between safety and economy.

[0062] In some embodiments, risk monitoring of a critical safety system is performed according to a first monitoring strategy to obtain a first risk monitoring parameter, including: adjusting the first monitoring strategy to a second monitoring strategy according to the vehicle's driving scenario; and performing risk monitoring of the critical safety system according to the second monitoring strategy to obtain the first risk monitoring parameter.

[0063] In this embodiment, the driving scenario can be understood as the specific operating environment in which the vehicle operates. Driving scenarios can include typical scenarios such as highway driving, urban traffic congestion, switching between autonomous driving modes, and vehicle-to-infrastructure (V2I) data interaction. The second monitoring strategy can be understood as monitoring logic based on the currently identified driving scenario and dynamically adapted to the first monitoring strategy.

[0064] Specifically, this application can collect vehicle positioning data and environmental perception data in real time to identify the current operating status of the vehicle, and automatically adjust the monitoring frequency, threshold deviation range and redundancy requirements according to the preset scene monitoring strategy mapping table.

[0065] For example, when a vehicle enters a highway from an urban road, the driving scenario changes to a high-speed driving scenario. The regular monitoring frequency (e.g., 50ms / time) for medium-risk failure modes can be automatically increased to a high-frequency monitoring frequency (e.g., 30ms / time), and the threshold deviation range can be strictly controlled (e.g., ±5%) to cope with the characteristics of rapid spread of failure risk and serious consequences under high-speed conditions.

[0066] Furthermore, in the scenario of switching autonomous driving modes, the redundant monitoring units of the perception system and decision-making system can be activated immediately to ensure that the monitoring logic matches the scenario risk in real time. This enables the monitoring strategy to adapt to the actual operating conditions of the vehicle, avoiding the lag of fixed strategies in highly dynamic scenarios and significantly improving the timeliness and accuracy of monitoring.

[0067] Specifically, in the process of risk monitoring of critical safety systems according to the second monitoring strategy, the MSR module performs real-time data acquisition and anomaly detection of critical safety systems (such as autonomous driving perception system, vehicle communication module, and power control system) according to the frequency and threshold set by the second monitoring strategy.

[0068] For example, in a high-speed driving scenario, if the second monitoring strategy is set to monitor the power system at high frequency, motor speed and torque data can be collected at a period of 30ms. Instantaneous interference signals can be filtered through multi-dimensional cross-validation to obtain accurate first risk monitoring parameters. This not only effectively avoids false alarms or missed alarms caused by scenario mismatch, but also ensures that failure trends can be predicted in advance in high-risk scenarios, thus improving the reliability of generating the first abnormal event report.

[0069] In this application, by introducing the vehicle driving scenario as a dynamic variable, the monitoring strategy is transformed from static and fixed to dynamic and adaptive. The first monitoring strategy is adjusted to the second monitoring strategy, enabling the monitoring system to make differentiated configurations for the risk exposure level under different operating conditions. This ensures that the acquisition of the first risk monitoring parameters has both high sensitivity in high-risk scenarios and low resource consumption in low-risk scenarios, solving the problem of decreased monitoring efficiency in complex and variable driving scenarios. It significantly improves the accuracy of failure risk prediction and system response reliability of intelligent connected vehicles in dynamic operation.

[0070] In some embodiments, before adjusting the first monitoring strategy to the second monitoring strategy according to the vehicle's driving scenario, the method further includes: acquiring real-time location information and real-time environmental data of the vehicle while it is in motion; and identifying the vehicle's real-time driving scenario in real time based on the real-time location information and real-time environmental data.

[0071] In this embodiment, real-time positioning information can be understood as the precise location coordinates and motion status information of the vehicle in geographic space. Real-time positioning information can be obtained from an onboard Global Navigation Satellite System (GNSS) receiver module, an inertial measurement unit (IMU), or a high-precision map positioning system to determine the vehicle's absolute position and relative trajectory within the road network. Specifically, real-time positioning information may include longitude, latitude, altitude, vehicle speed, heading angle, and lane-level position information.

[0072] Real-time environmental data can be understood as data on the external physical conditions around a vehicle that affect driving safety, which can be collected through an onboard sensor network. Real-time environmental data can include meteorological data (such as rainfall, visibility, and road surface slippage coefficient), lighting data (such as day and night conditions, and changes in light intensity inside and outside tunnels), traffic flow data (such as surrounding vehicle density and average vehicle speed), and road infrastructure data (such as road type, slope, and curvature).

[0073] Real-time driving scenarios can be understood as driving condition categories with specific risk characteristics parsed from multi-source fusion data. These can be obtained by semantically mapping the data obtained above through a preset scenario classification algorithm model.

[0074] Specifically, in the process of identifying the real-time driving scene of a vehicle based on real-time location information and real-time environmental data, this application can use a rule engine or a machine learning classifier to input the real-time location information and real-time environmental data into a pre-trained scene recognition model, output the current scene label, and determine the real-time driving scene of the vehicle through the current scene label.

[0075] In this application, by acquiring real-time positioning information and real-time environmental data, the real-time driving scenario of the vehicle can be identified in real time. This enables the scenario switching judgment to be completed the instant the vehicle enters a high-risk area (such as a tunnel, sharp bend, or road section in severe weather), thereby triggering a smooth transition of the monitoring strategy from the normal mode to the enhanced mode. This not only solves the problems of coarse scene recognition granularity and slow response, but also ensures that the generated second monitoring strategy can strictly match the current actual operational risks, significantly improving the adaptability and reliability of the FMEA-MSR linkage system under complex dynamic working conditions.

[0076] In some embodiments, in step S130, if the first risk monitoring parameter shows an abnormality, a first abnormal event report is generated based on the failure chain information, including: determining whether the first risk monitoring parameter exceeds the threshold deviation corresponding to the risk level; if the first risk monitoring parameter exceeds the threshold deviation, a first abnormal event report is generated based on the failure chain information.

[0077] In this embodiment, in the process of determining whether the first risk monitoring parameter exceeds the threshold deviation corresponding to the risk level, the first risk monitoring parameter collected in real time can be compared with the preset dynamic tolerance range.

[0078] The threshold deviation corresponding to the risk level can be understood as the allowable fluctuation range pre-set according to the FMEA risk level (such as high risk, medium risk, low risk) of the critical safety system. It can be used as a filtering standard to determine whether the system has a substantial abnormality, so as to distinguish normal signal noise from real failure risk.

[0079] In this application, the threshold deviation can be set in a way that is negatively correlated with the risk level. That is, the higher the risk level, the smaller the allowable threshold deviation, so as to ensure continuous high-sensitivity monitoring; conversely, the lower the risk level, the larger the allowable threshold deviation, so as to avoid over-response. Thus, even small parameter fluctuations can be captured in a timely manner in high-risk scenarios to prevent missed detections, and in low-risk scenarios, it can effectively filter transient interference and normal fluctuations to prevent false alarms, thereby significantly improving the robustness and accuracy of anomaly detection.

[0080] For example, for a high-risk autonomous driving braking system, the threshold deviation can be set to ±5%, and the monitoring parameter deviating from the benchmark value by more than 5% is judged as abnormal; for a low-risk in-vehicle entertainment system, the threshold deviation can be set to ±15%.

[0081] During the generation of the first anomaly report based on the failure chain information, pre-stored failure chain information can be retrieved from the lightweight FMEA data unit. This failure chain information is then integrated with the first risk monitoring parameters (such as voltage value and delay time) to form a structured data package containing the anomaly type, associated FM-ID, risk level, occurrence time, and scenario—the first anomaly report. This first anomaly report directly guides subsequent targeted response strategies, avoiding the lag of manual secondary analysis of failure mechanisms required in traditional reports. It also triggers vehicle execution for control, effectively shortening the response latency from anomaly detection to strategy execution and ensuring driving safety. The failure chain information clearly identifies the root cause, specific manifestation, and potential scope of harm of the anomaly, ensuring that the generated report not only includes what happened but also why it happened and what consequences it will lead to. The failure chain information can be obtained from the risk management data that has already been analyzed in the cloud-based FMEA requirement library.

[0082] For example, when the camera power supply voltage monitoring parameter exceeds the threshold deviation of ±5% corresponding to high risk, the failure chain information corresponding to the camera is automatically extracted (such as FC-ID=power reference source drift, FM-ID=output voltage too high, FE-ID=image output failure), and combined with the current vehicle speed, weather and other scene data, a first abnormal event report is generated.

[0083] In some embodiments, if the first risk monitoring parameter exceeds a threshold deviation, generating a first abnormal event report based on the failure chain information includes: if the first risk monitoring parameter exceeds a threshold deviation, preprocessing the first risk monitoring parameter to obtain a preprocessed first risk monitoring parameter; determining the failure chain information based on the preprocessed first risk monitoring parameter; and generating a first abnormal event report based on the failure chain information.

[0084] In this embodiment, preprocessing can be understood as the data cleaning, filtering and denoising, feature extraction, or normalization process performed before the original monitoring data is matched for failure chains. This application preprocesses the first risk monitoring parameter to eliminate false abnormal fluctuations caused by instantaneous sensor interference, signal transmission jitter, or environmental noise, ensuring that the data input to subsequent analysis stages is highly representative and accurate.

[0085] Specifically, when the MSR module detects that the first risk monitoring parameter (such as camera image transmission delay time, power supply voltage amplitude, etc.) exceeds the threshold deviation set by the risk level, it does not immediately determine that it is a permanent failure. Instead, it starts a preprocessing mechanism to preprocess the first risk monitoring parameter, thereby effectively filtering invalid interference signals, reducing the probability of false alarms, and thus obtaining the first risk monitoring parameter that truly reflects the operating status of the critical safety system, i.e., the preprocessed first risk monitoring parameter.

[0086] For example, for continuously acquired voltage signals, a moving average filtering algorithm can be used to remove high-frequency noise; for sudden single out-of-threshold data, historical data within the time window can be combined for trend verification. If the deviation only occurs for a very short time and recovers quickly, it is determined to be transient interference and is eliminated, thus ensuring the accuracy of fault attribution.

[0087] Furthermore, in the process of determining the failure chain information based on the pre-processed first risk monitoring parameters, the cleaned first risk monitoring parameters can be mapped and matched with the pre-stored FMEA knowledge base, thereby achieving rapid location from phenomenon to root cause.

[0088] For example, if the first risk monitoring parameter after preprocessing is that the image data transmission delay is continuously greater than 200ms and accompanied by power supply voltage fluctuations, the corresponding failure chain information will be automatically matched (e.g., FC-ID is power reference point drift, FM-ID is camera output failure, FE-ID is perception function degradation).

[0089] In some embodiments, after obtaining a first response strategy based on the first abnormal event report and the FMEA analysis of the critical safety system to trigger the vehicle's execution terminal to control the vehicle in the driving state, the method further includes: using a preset third monitoring strategy to perform risk monitoring on the critical safety system to obtain a second risk monitoring parameter; if the second risk monitoring parameter indicates an abnormality in the critical safety system, adjusting the first response strategy to the preset second response strategy to trigger the vehicle's execution terminal to control the vehicle in the driving state.

[0090] In this application, the third monitoring strategy can be understood as an independent monitoring logic specifically used to verify the response effect and monitor residual risks in the system after the first response strategy has been executed. The monitoring frequency, sampling dimensions, or threshold judgment criteria in the third monitoring strategy can be adjusted specifically according to the type of the first response strategy.

[0091] For example, if the first response strategy is functional degradation, the third monitoring strategy can be set to perform high-frequency redundancy checks on the core functional modules after degradation; if the first response strategy is emergency braking, the third monitoring strategy can focus on monitoring the vehicle's attitude stability and the braking system pressure maintenance status.

[0092] The second risk monitoring parameter can be understood as a status indicator generated after processing the real-time data collected by executing the third monitoring strategy. It is used to quantitatively characterize the actual operating status of the critical safety system after the first intervention.

[0093] Specifically, this application, through the combined use of the first response strategy and the third monitoring strategy, can form a closed-loop verification mechanism after the initial handling, avoid the system from falling into a false recovery state, ensure the continuous tracking of potential residual risks, and thus effectively prevent the expansion of security incidents caused by the failure of a single response strategy, significantly improving the system's adaptability and robustness in complex dynamic scenarios.

[0094] In this application, in the process of determining that the second risk monitoring parameter shows an anomaly in the critical safety system, it can be determined by judging that the value of the second risk monitoring parameter exceeds the preset safety tolerance range, or by judging that the change trend of the second risk monitoring parameter indicates that the failure mode has not been eliminated or has even deteriorated.

[0095] The second response strategy can be understood as a pre-set escalation plan, which has a higher intervention intensity than the first response strategy in order to deal with more severe or complex failure scenarios.

[0096] For example, when the first response strategy is to limit the vehicle speed to 60 km / h and the second risk monitoring parameter still shows insufficient braking performance, the second response strategy can be automatically adjusted to control the vehicle to pull over and activate the hazard lights; when the first response strategy is to switch to redundant sensors and the second risk monitoring parameter shows that the redundant sensor data is still unreliable, the second response strategy can be adjusted to request the driver to take over immediately or trigger the minimum risk state (MRM).

[0097] In this application, by introducing a continuous monitoring and dynamic strategy adjustment mechanism after the response, a third monitoring strategy can be used to conduct secondary monitoring of critical safety systems after the execution of the first response strategy to obtain second risk monitoring parameters. This allows for the accurate capture of residual risks or newly emerging secondary faults that may have been missed in the first response. If the second risk monitoring parameters confirm that the system is still in an abnormal state, a second response strategy can be activated to upgrade or replace the original first response strategy, triggering stronger intervention measures at the execution end. This not only breaks the short-sighted limitation of ending the response immediately, but also ensures the thoroughness and continuity of risk control through the coordinated cooperation of multi-stage strategies. Furthermore, it allows for flexible adjustment of control intensity based on the actual situation of failure evolution, avoiding safety hazards caused by insufficient response and preventing resource waste or experience degradation caused by over-response. This significantly enhances the overall safety and reliability of intelligent connected vehicles in dynamic operating environments.

[0098] In some embodiments, the FMEA-MSR monitoring and system response method further includes: if the second risk monitoring parameter shows an anomaly in the critical security system, generating a second anomaly event report; and sending at least one of the first risk monitoring parameter, the first anomaly event report, the second risk monitoring parameter, and the second anomaly event report to the FMEA system in the cloud.

[0099] In this embodiment, when the second risk monitoring parameter exceeds a preset safety threshold or shows a deteriorating trend, it can be determined that the critical safety system is still in an abnormal state or has experienced a secondary failure. Based on the current failure chain information (failure cause FC-ID, failure mode FM-ID, and failure impact FE-ID), a second abnormal event report is generated. This can accurately capture risks that the initial response failed to eliminate or further degradation of system performance, facilitating subsequent strategy upgrades or emergency control. The second abnormal event report can record instantaneous data of the anomaly, as well as the effect evaluation data after the execution of the first response strategy, the residual risk level, and the time-series characteristics of the anomaly's duration.

[0100] For example, in an autonomous driving perception system, if the first response strategy is to switch to the redundant sensor mode, and the second risk monitoring parameter shows that the signal-to-noise ratio of the redundant sensor is still below the critical value and decreases over time, then the generated second abnormal event report will be marked as redundant failure and associated with a specific hardware fault ID.

[0101] In this application, the cloud-based FMEA system can be understood as a failure mode and effects analysis database and analysis engine deployed on a remote server cluster, which stores historical failure data, risk parameter models and failure mechanism libraries for all vehicle models.

[0102] Specifically, in the process of sending at least one of the first risk monitoring parameters, the first abnormal event report, the second risk monitoring parameters, and the second abnormal event report to the cloud-based FMEA system, this application can use an in-vehicle communication module (such as T-BOX) to utilize OTA (Over-The-Air) technology or a cellular network via a standardized two-way data synchronization interface to trigger the FMEA system to perform online re-evaluation, thereby breaking the limitation of FMEA relying solely on static data from the R&D stage.

[0103] For example, when a vehicle frequently uploads a second abnormal event report containing a battery thermal runaway warning under a specific high-temperature scenario, the cloud-based FMEA system will automatically retrieve the second abnormal event report, recalculate the frequency (O) and detectability (D) scores of the failure mode, and update the risk priority number (RPN).

[0104] In this application, the second anomaly report ensures that high-value fault evolution data can be captured in a timely manner when the primary response fails or the system state deteriorates. At the same time, the second anomaly report is uploaded to the cloud FMEA system, which can then dynamically correct the failure model based on real road operation data. This not only solves the problem of the disconnect between vehicle monitoring data and the FMEA system, but also enables FMEA analysis to change from static post-event analysis to dynamic real-time evolution. This allows for the rapid discovery of batch design defects or unknown failure modes in specific scenarios, and the optimized risk parameters (such as adjusted monitoring thresholds and updated failure chain logic) are redeployed to the vehicle, thereby significantly improving the safety and reliability of the entire vehicle lifecycle.

[0105] In some embodiments, the FMEA-MSR monitoring and system response method further includes: updating the risk data in response to update information sent by the FMEA system in the cloud, to obtain updated risk data.

[0106] In this embodiment, the updated information can be understood as the instruction data packet generated by the cloud-based FMEA system based on closed-loop analysis of full lifecycle data. The updated information may originate from the cloud-based FMEA system's reassessment of historical fault data, newly discovered failure modes, or optimized risk management requirements. This ensures that the vehicle-side lightweight FMEA data unit can synchronously acquire the latest risk analysis conclusions, resolving the issue of lagging vehicle-side monitoring strategies caused by knowledge iteration at the R&D end.

[0107] Specifically, the updated information may include revised risk level parameters, updated failure chain triples, newly added failure mode definitions, and adjusted monitoring threshold strategies.

[0108] Meanwhile, updated information can be sent to the vehicle terminal via OTA (Over-The-Air) technology through the vehicle's remote communication interface (such as 4G / 5G network), and incremental transmission mode is supported, which means that only the changed data fields are pushed instead of the full data packet, so as to reduce communication bandwidth usage and improve transmission efficiency.

[0109] For example, after receiving a large number of abnormal data reports from vehicles regarding a certain type of sensor under extreme low temperatures, the cloud-based FMEA system can analyze and confirm the data to raise the failure probability (O) rating for that scenario, and generate updated information containing the new failure probability value and corresponding threshold. This information is then sent to the vehicle terminal, enabling rapid synchronization of risk awareness from the R&D end to the operation end, and providing an accurate data source for subsequent real-time updates of local data.

[0110] Furthermore, after receiving the update information, the vehicle-mounted terminal can perform data parsing, verification, and overwrite operations.

[0111] Specifically, the vehicle terminal can perform integrity verification and signature verification on the received update information to ensure the legality of the data source and the integrity of the content; based on the element ID (such as FUNC-ID, FM-ID) in the update information, locate the corresponding entry in the locally stored risk database, and replace the original risk level, failure chain information or monitoring threshold with the new value in the update information to generate updated risk data, which can be directly used as the basis for the MSR module to execute risk monitoring and generate response strategies.

[0112] For example, if the original camera failure risk level stored locally is medium risk, and the received update information indicates that the failure mode should be upgraded to high risk in a high-speed driving scenario, then the risk level field of the local entry will be modified from medium to high, and the corresponding monitoring frequency parameter will be adjusted simultaneously (e.g., from 50ms / time to 30ms / time). This will ultimately form updated risk data containing the latest risk awareness, thereby enabling real-time adaptation to the latest safety strategies without returning to the factory or manual intervention, significantly improving the vehicle's proactive defense capabilities when facing new failure risks.

[0113] In this application, by responding to the update information of the cloud-based FMEA system and updating the local risk data in real time, not only is the high consistency between the vehicle-side monitoring logic and the latest risk analysis conclusions in the cloud-based system ensured, but the problem of difficulty in dynamically adjusting FMEA data after deployment is also effectively solved. The updated risk data can directly drive the MSR module to adjust the monitoring strategy and response threshold, enabling the vehicle to respond to newly identified failure modes or changing risk environments in an instant. This achieves a closed-loop risk management system throughout the entire lifecycle from R&D design to actual operation, significantly reducing maintenance costs and improving the functional safety level of the entire vehicle.

[0114] In the FMEA-MSR monitoring and system response method provided in this embodiment of the invention, risk data containing risk level and failure chain information is acquired, and a differentiated risk monitoring strategy is implemented based on the risk level. This ensures that the monitoring intensity matches the severity of potential risks, thereby obtaining a first risk monitoring parameter reflecting the system status. When an abnormal parameter is detected, the failure chain information can be used for precise source tracing and a first abnormal event report can be generated, avoiding blind alarms. Based on the first abnormal event report, a predefined FMEA response strategy is invoked to trigger the execution end to actively control the vehicle's driving status. This achieves a closed-loop process from risk perception, hierarchical monitoring, anomaly identification to guided response, effectively solving the problem of disconnect between FMEA analysis and MSR monitoring and response. It ensures that high-risk failure modes can be prioritized for identification and rapid handling, while making the response measures closely aligned with the failure mechanism. This significantly improves the functional safety, response accuracy, and system reliability of intelligent connected vehicles in dynamic operating scenarios.

[0115] In some embodiments, the present invention also provides an FMEA-MSR monitoring and system response apparatus 300, which is used to perform any embodiment of the aforementioned FMEA-MSR monitoring and system response method.

[0116] Specifically, please refer to Figure 3 , Figure 3 This is a schematic block diagram of the FMEA-MSR monitoring and system response device 300 provided in an embodiment of the present invention.

[0117] like Figure 3 As shown, the FMEA-MSR monitoring and system response device 300 provided in this application includes: a first acquisition unit 310, a risk monitoring unit 320, a generation unit 330, and a second acquisition unit 340.

[0118] The first acquisition unit 310 is used to acquire risk data of the vehicle's key safety systems; the risk data includes the risk level and failure chain information of the key safety systems; the risk monitoring unit 320 is used to perform risk monitoring on the key safety systems according to the risk level to obtain the first risk monitoring parameters; the generation unit 330 is used to generate a first abnormal event report according to the failure chain information if the first risk monitoring parameters show that the key safety systems are abnormal; the second acquisition unit 340 is used to acquire the first response strategy of the key safety system FMEA analysis according to the first abnormal event report, so as to trigger the vehicle's execution end to control the vehicle in the driving state.

[0119] The FMEA-MSR monitoring and system response device 300 provided in this application embodiment can acquire risk data of the vehicle's critical safety systems; the risk data includes the risk level and failure chain information of the critical safety systems; based on the risk level, the critical safety systems are monitored to obtain first risk monitoring parameters; if the first risk monitoring parameters indicate an anomaly in the critical safety systems, a first abnormal event report is generated based on the failure chain information; based on the first abnormal event report, a first response strategy for the critical safety system FMEA analysis is obtained to trigger the vehicle's execution end to control the vehicle in driving status.

[0120] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned FMEA-MSR monitoring and system response device and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0121] The aforementioned FMEA-MSR monitoring and system response device can be implemented as a computer program, which can, for example... Figure 4 It runs on the electronic device shown.

[0122] Please see Figure 4 , Figure 4 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention.

[0123] See Figure 4 The device 400 includes a processor 402, a memory, and a network interface 405 connected via a system bus 401, wherein the memory may include a storage medium 403 and internal memory 404.

[0124] The storage medium 403 may store an operating system 4031 and a computer program 4032. When the computer program 4032 is executed, it causes the processor 402 to execute the FMEA-MSR monitoring and system response method.

[0125] The processor 402 provides computing and control capabilities to support the operation of the entire device 400.

[0126] The internal memory 404 provides an environment for the execution of the computer program 4032 in the non-volatile storage medium 403. When the computer program 4032 is executed by the processor 402, the processor 402 can execute the FMEA-MSR monitoring and system response method.

[0127] This network interface 405 is used for network communication, such as providing the transmission of definition information. Those skilled in the art will understand that... Figure 4The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the device 400 to which the present invention is applied. The specific device 400 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0128] The processor 402 is used to run the computer program 4032 stored in the memory to perform the following functions: acquiring risk data of the vehicle's key safety systems; the risk data includes the risk level and failure chain information of the key safety systems; monitoring the key safety systems according to the risk level to obtain first risk monitoring parameters; if the first risk monitoring parameters show that the key safety systems are abnormal, generating a first abnormal event report according to the failure chain information; and acquiring a first response strategy based on the first abnormal event report from the FMEA analysis of the key safety systems to trigger the vehicle's execution end to control the vehicle in the driving state.

[0129] Those skilled in the art will understand that Figure 4 The embodiments of device 400 shown do not constitute a limitation on the specific configuration of device 400. In other embodiments, device 400 may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, in some embodiments, device 400 may include only memory and processor 402. In such embodiments, the structure and function of memory and processor 402 are similar to those shown. Figure 4 The embodiments shown are consistent and will not be described again here.

[0130] It should be understood that, in this embodiment of the invention, the processor 402 may be a Central Processing Unit (CPU), or it may be another general-purpose processor 402, a digital signal processor 402 (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor 402 may be a microprocessor 402, or it may be any conventional processor 402, etc.

[0131] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the following steps: acquiring risk data of a vehicle's critical safety system; the risk data including the risk level and failure chain information of the critical safety system; performing risk monitoring on the critical safety system according to the risk level to obtain a first risk monitoring parameter; if the first risk monitoring parameter indicates an anomaly in the critical safety system, generating a first abnormal event report based on the failure chain information; and acquiring a first response strategy based on the first abnormal event report obtained from the critical safety system FMEA analysis to trigger the vehicle's execution end to control the vehicle in its driving state.

[0132] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0133] In another embodiment of the present invention, a computer storage medium is provided. This storage medium can be a non-volatile computer-readable storage medium or a volatile storage medium. The storage medium stores a computer program 4032, which, when executed by a processor 402, performs the following steps: acquiring risk data of a vehicle's critical safety system; the risk data includes the risk level and failure chain information of the critical safety system; monitoring the critical safety system according to the risk level to obtain a first risk monitoring parameter; if the first risk monitoring parameter indicates an anomaly in the critical safety system, generating a first abnormal event report based on the failure chain information; and acquiring a first response strategy based on the first abnormal event report from the critical safety system FMEA analysis to trigger the vehicle's execution end to control the vehicle in its driving state.

[0134] The storage medium can be any computer-readable storage medium that can store program code, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0135] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0137] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0138] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods provided in the various embodiments of this application.

[0139] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for FMEA-MSR monitoring and system response, characterized in that, include: Obtain risk data for the vehicle's critical safety systems; The risk data includes the risk level and failure chain information of the critical security system; Based on the risk level, the critical security system is monitored to obtain the first risk monitoring parameter; If the first risk monitoring parameter indicates an anomaly in the critical safety system, a first anomaly event report is generated based on the failure chain information. Based on the first abnormal event report, the first response strategy of the critical safety system FMEA analysis is obtained to trigger the vehicle's execution terminal to control the vehicle in the driving state.

2. The FMEA-MSR monitoring and system response method according to claim 1, characterized in that, The step of monitoring the critical security system based on the risk level to obtain the first risk monitoring parameter includes: Based on the risk level, a first monitoring strategy for risk monitoring of the critical security system is determined; Based on the first monitoring strategy, risk monitoring is performed on the critical security system to obtain the first risk monitoring parameters.

3. The FMEA-MSR monitoring and system response method according to claim 2, characterized in that, The step of performing risk monitoring on the critical security system according to the first monitoring strategy to obtain the first risk monitoring parameters includes: Based on the vehicle's driving scenario, the first monitoring strategy is adjusted to the second monitoring strategy; Based on the second monitoring strategy, risk monitoring is performed on the critical security system to obtain the first risk monitoring parameters.

4. The FMEA-MSR monitoring and system response method according to claim 3, characterized in that, Before adjusting the first monitoring strategy to the second monitoring strategy based on the vehicle's driving scenario, the method further includes: Obtain the real-time location information and real-time environmental data of the vehicle while it is in motion; Based on the real-time location information and the real-time environmental data, the real-time driving scenario of the vehicle is identified in real time.

5. The FMEA-MSR monitoring and system response method according to claim 1, characterized in that, If the first risk monitoring parameter indicates an anomaly in the critical safety system, a first anomaly event report is generated based on the failure chain information, including: Determine whether the first risk monitoring parameter exceeds the threshold deviation corresponding to the risk level; If the first risk monitoring parameter exceeds the threshold deviation, the first abnormal event report is generated based on the failure chain information.

6. The FMEA-MSR monitoring and system response method according to claim 5, characterized in that, If the first risk monitoring parameter exceeds the threshold deviation, the first abnormal event report is generated based on the failure chain information, including: If the first risk monitoring parameter exceeds the threshold deviation, the first risk monitoring parameter is preprocessed to obtain the preprocessed first risk monitoring parameter. The failure chain information is determined based on the preprocessed first risk monitoring parameters; The first abnormal event report is generated based on the failure chain information.

7. The FMEA-MSR monitoring and system response method according to claim 1, characterized in that, After obtaining the first response strategy based on the first abnormal event report and the FMEA analysis of the critical safety system to trigger the vehicle's execution terminal to control the vehicle in driving state, the method further includes: A preset third monitoring strategy is used to monitor the critical security system for risks, and second risk monitoring parameters are obtained. If the second risk monitoring parameter indicates an anomaly in the critical safety system, the first response strategy is adjusted to a preset second response strategy to trigger the vehicle's execution terminal to control the vehicle in motion.

8. The FMEA-MSR monitoring and system response method according to claim 7, characterized in that, The method further includes: If the second risk monitoring parameter indicates an anomaly in the critical security system, a second anomaly event report is generated. Send at least one of the first risk monitoring parameter, the first abnormal event report, the second risk monitoring parameter, and the second abnormal event report to the FMEA system in the cloud.

9. The FMEA-MSR monitoring and system response method according to any one of claims 1-8, characterized in that, The method further includes: In response to the update information sent by the FMEA system in the cloud, the risk data is updated to obtain the updated risk data.

10. An electronic device, characterized in that, The system includes a memory and a processor, the memory storing a computer program, characterized in that the processor executes the computer program to implement the steps of the FMEA-MSR monitoring and system response method according to any one of claims 1 to 9.

Images