An on-vehicle instrument redundancy switching method, device, equipment and medium

Abstract

The application provides a vehicle-mounted instrument redundancy switching method, device, equipment and medium. The method comprises the following steps: acquiring multi-dimensional time sequence data of a vehicle-mounted instrument in a vehicle operation system; generating a fault probability prediction value of the vehicle operation system within a future preset time length through a preset prediction model; calculating a system health score value in combination with multi-dimensional feature parameters and preset weights and determining a health level in combination with the fault probability prediction value; triggering a redundancy operation instruction based on the health level; and executing preloading control of a backup system or atomic switching operation of a primary and backup system to realize predictive fault response and hierarchical accurate switching. The method effectively solves the problems of switching lag, single decision basis and resource waste in traditional technologies, and significantly improves the reliability and driving safety of the vehicle-mounted instrument.

Description

Technical Field

[0001] This application relates to the field of vehicle instrument technology, and in particular to a method, device, equipment and medium for redundancy switching of vehicle instruments. Background Technology

[0002] Existing aftermarket instrument cluster redundancy switching technologies for vehicles have significant limitations. Traditional solutions often rely on hardware heartbeat signals, triggering the switchover between primary and backup systems through threshold-based methods such as communication interruptions or CPU overload. However, these methods cannot predict potential faults, resulting in severe switching lag, failing to meet real-time requirements, and posing driving safety hazards. Furthermore, switching decisions are based solely on current states such as heartbeat detection, lacking in-depth analysis of historical data, which can easily lead to misjudgments or omissions, reducing the reliability of the redundant system.

[0003] Meanwhile, to ensure redundancy and reliability, existing technologies generally employ hot backup systems, which, while enabling rapid response, consume significant resources, significantly increasing vehicle energy consumption and costs. In summary, existing technologies have obvious shortcomings in terms of switchover timeliness, comprehensiveness of decision-making criteria, and resource efficiency. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for redundancy switching of vehicle instruments to solve the technical problems of switching lag, single decision-making basis, and resource waste in existing equipment switching methods.

[0005] This application provides a method for redundant switching of vehicle instrument clusters. The method includes: acquiring multi-dimensional time-series data of vehicle instrument clusters in a vehicle operating system; generating a predicted failure probability value of the vehicle operating system within a preset time period based on the multi-dimensional time-series data using a preset prediction model; calculating a health score value of the vehicle operating system according to the feature parameters and preset weights of the multi-dimensional time-series data, and determining the health level of the vehicle operating system in conjunction with the predicted failure probability value; triggering a corresponding redundancy operation instruction based on the health level, and executing the redundancy operation instruction to achieve pre-loading control of the standby system or atomic switching operation of the primary / standby system of the instrument cluster.

[0006] In one embodiment of this application, after executing the redundant operation instructions, the method further includes: continuously monitoring the heartbeat signals of the data acquisition link and operation execution link of the vehicle operation system; when the heartbeat signal is detected to be interrupted, cutting off the main system display output, switching to the backup system, and synchronizing real-time vehicle data to the backup system; after the main system restarts, calculating the main system self-check health score based on the multi-dimensional time-series data and preset weights; if the self-check health score continuously reaches a preset normal threshold, freezing the backup system output and restoring the main system control and data link.

[0007] In one embodiment of this application, generating a predicted failure probability value of the vehicle operating system within a preset future time period includes: preprocessing the multidimensional time-series data, the preprocessing including at least cleaning abnormal and missing data; inputting the preprocessed multidimensional time-series data into a preset prediction model to extract the time-series features of the multidimensional time-series data; calculating the importance score of each time-series feature, and assigning dynamic weight coefficients to each time-series feature according to the importance score; multiplying the obtained dynamic weight coefficients with the corresponding time-series features to obtain a weighted feature vector, and aggregating all the weighted feature vectors to form a fusion feature; and outputting the predicted failure probability value of the vehicle operating system within a preset future time period based on the fusion feature.

[0008] In one embodiment of this application, calculating the health score of the vehicle operating system includes: extracting hardware operating status characteristic parameters, software behavior characteristic parameters, and environmental parameter characteristic parameters from the multidimensional time-series data; assigning preset weight coefficients to each characteristic parameter, and performing weighted calculations on each characteristic parameter and its corresponding weight coefficient to generate a basic health score; converting the fault probability prediction value into a corresponding health correction factor, and superimposing the basic health score and the health correction factor to obtain the final health score.

[0009] In one embodiment of this application, determining the health level of the vehicle operating system based on the fault probability prediction value includes: detecting the changing trend of the fault probability prediction value; if the fault probability prediction value continuously increases and the rate of change exceeds a preset evolution threshold, then determining that the vehicle operating system is in a fault evolution state; when the health score value is greater than or equal to a first preset threshold, determining the health level as a normal level; when the health score value is less than the first preset threshold but greater than or equal to a second preset threshold, if the vehicle operating system is not in a fault evolution state, determining the health level as a normal level; if the vehicle operating system is in a fault evolution state, determining the health level as a warning level; when the health score value is less than the second preset threshold, determining the health level as a fault level.

[0010] In one embodiment of this application, the atomic switching operation includes: if the health level is determined to be a warning level, then loading the interface display resources of the standby system into the cache, synchronizing the real-time vehicle operation data of the main system into the background buffer of the standby system, and keeping the standby system in a low-power standby state; if the health level is determined to be a fault level, then freezing the display output of the main system, activating the display interface of the standby system and switching to the foreground display, submitting the real-time data of the background buffer of the main system to the foreground display of the standby system, and triggering the main system restart process.

[0011] This application provides a vehicle instrument redundancy switching device, the device comprising: a data acquisition module for acquiring multi-dimensional time-series data of the vehicle instrument in the vehicle operating system, the multi-dimensional time-series data including hardware operating status data, software behavior characteristic data, and environmental parameter data; a fault prediction module for generating a fault probability prediction value of the vehicle operating system within a preset time period based on the multi-dimensional time-series data and a preset prediction model; a health assessment module for calculating a health score value based on the feature parameters and preset weights of the multi-dimensional time-series data, and determining the health level of the vehicle operating system in conjunction with the fault probability prediction value; and a switching execution module for triggering a redundancy operation command based on the health level to execute a pre-load control of the standby system or an atomic switching operation of the primary / standby system of the instrument equipment.

[0012] In one embodiment of this application, the device further includes: a heartbeat monitoring module, used to continuously monitor the heartbeat signals of the data acquisition link and operation execution link of the vehicle instrument in the vehicle operation system; a failover module, used to cut off the main system display output and switch to the backup system display interface when the heartbeat signal is detected to be interrupted, and synchronize real-time vehicle data to the backup system; a self-healing control module, used to calculate a self-check health score based on the re-acquired multi-dimensional time-series data, and if the self-check health score meets the preset recovery conditions, freeze the backup system output and restore the main system control; a preloading submodule, embedded in the switching execution module, used to load the interface display resources of the backup system into the cache area and synchronize the real-time data of the main system to the background buffer of the backup system when the health level is a warning level; and an atomic switching submodule, embedded in the switching execution module, used to freeze the main system display screen, activate the backup system display interface, and submit the real-time data of the background buffer to the front end of the backup system when the health level is a fault level.

[0013] This application provides an electronic device, which includes: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the electronic device to implement the vehicle instrument redundancy switching method as described above.

[0014] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the vehicle instrument redundancy switching method as described above.

[0015] The beneficial effects of this invention are as follows: The vehicle instrument redundancy switching method proposed in this invention collects multi-dimensional time-series data from vehicle instruments and combines it with a predictive model to generate fault probability and health scores, constructing a dynamic health assessment system and realizing closed-loop management from fault prediction to redundant operation. Specifically, data-driven fault probability prediction can identify potential risks in advance, transforming redundant switching from a passive response to proactive prevention, effectively reducing the probability of system failure due to sudden faults; the multi-dimensional health assessment system quantifies the degree of system degradation through weighted calculation of feature parameters, avoiding the waste of redundant resources caused by misjudgment of a single indicator; the hierarchical redundancy strategy triggers differentiated operations based on health level: for minor anomalies, pre-loading control reduces switching latency, and for severe faults, atomic switching of the primary and backup systems is performed to ensure operational integrity, balancing safety and resource efficiency. This method significantly improves the availability and fault tolerance of vehicle instrument systems, especially suitable for high-reliability scenarios such as autonomous driving, while optimizing redundant resource usage through a hierarchical response mechanism, achieving energy efficiency balance while ensuring system safety. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] In the attached diagram:

[0018] Figure 1 A schematic diagram illustrating the implementation environment of the vehicle instrument redundancy switching method provided in an embodiment of this application;

[0019] Figure 2 This is an overall flowchart of the vehicle instrument redundancy switching method provided in one embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the overall steps of the vehicle instrument redundancy switching method provided in one embodiment of this application;

[0021] Figure 4 This is a schematic diagram of a dual-modal neural network structure provided in one embodiment of this application;

[0022] Figure 5 This is a block diagram illustrating an in-vehicle instrument redundancy switching device, as shown in an exemplary embodiment of this application;

[0023] Figure 6 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0024] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0025] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0026] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0027] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating the implementation environment of the vehicle instrument redundancy switching method provided in an embodiment of this application.

[0028] like Figure 1 As shown, the implementation environment of the vehicle instrument redundancy switching method includes a data acquisition module 101 and a vehicle infotainment system 102.

[0029] The data acquisition module 101 captures real-time vehicle system operating status information through multi-dimensional sensors. The hardware status monitoring unit is integrated into the vehicle's main control chipset, continuously collecting processor temperature, memory usage, and storage device performance indicators. The software behavior monitoring unit is embedded in the instrument system kernel, dynamically tracking characteristics such as program crash frequency, thread blocking duration, and communication latency. The environmental parameter acquisition unit is deployed on the vehicle body vibration sensors and temperature probes, recording the vibration intensity inside the vehicle and changes in the external ambient temperature, providing a physical environment basis for system stability analysis. The fault injection simulation unit generates a standardized test dataset through a pre-set abnormal operating condition database, which is used to train the AI ​​prediction model.

[0030] The vehicle infotainment system 102, as the core processing unit, specifically includes a data cleaning module, an AI prediction engine, a health assessment module, a dynamic switching controller, and a failover module. The functions of each module are as follows:

[0031] The data cleaning module performs multi-dimensional preprocessing and feature extraction on the raw data. It uses a sliding window algorithm to remove outliers, interpolation to fill in missing data, and normalization to eliminate dimensional differences. The AI ​​prediction engine is based on a dual-modal neural network architecture. The LSTM layer analyzes time-dependent features such as processor load change trends, and the Attention mechanism dynamically weights key abnormal events, outputting a health score and fault probability assessment for the near future. The health assessment module calculates real-time health using a multi-dimensional feature weighted model and triggers corresponding strategies based on grading criteria. The dynamic switching controller includes a preloading mechanism that caches backup system modules such as the navigation interface and warning icons during the early warning phase. The atomic switching strategy quickly freezes the main system screen and activates the backup system display during the fault phase through hardware-level operations. Combined with a double buffering mechanism and transaction rollback protocol, it ensures data consistency. The self-healing mechanism supports health self-checks after the main system restarts and automatically switches back to the main system to form a closed-loop recovery link when conditions are met. The failure fallback module continuously monitors the operation status of the data acquisition, AI prediction, and decision-making links. If a program abnormality or interruption is detected, it can directly activate the instrument panel system to ensure basic functions and ensure driving safety.

[0032] It is understandable that, such as Figure 1 The implementation environment shown realizes a complete closed loop from data collection to fault prediction, health assessment, dynamic switching and failure fallback. Compared with the traditional threshold-triggered switching scheme, the AI ​​prediction triggers redundant switching in advance, which significantly improves system response efficiency, effectively reduces the risk of misjudgment, and optimizes resource consumption.

[0033] Figure 2 This is an overall flowchart of the vehicle instrument redundancy switching method provided in one embodiment of this application.

[0034] like Figure 2 As shown, in an exemplary embodiment, the instrument redundancy switching method includes at least steps S210 to S240, which are described in detail below:

[0035] Step S210: Obtain multi-dimensional time-series data of the vehicle operation system.

[0036] In one embodiment of this application, multi-dimensional time-series data of the vehicle operating system is first collected in real time through the system interface between the vehicle-mounted sensors and the vehicle operating system, covering three major categories: hardware status, software behavior, and environmental parameters.

[0037] The hardware status data includes CPU and GPU temperature variation curves, memory usage fluctuations, and dynamic monitoring of battery voltage. This data is acquired periodically through the On-Board Diagnostics (OBD) interface and hardware monitoring module, with a sampling frequency set to 10 times per second to capture transient anomalies. Software behavior data is collected through system log analysis and process monitoring tools, recording the crash frequency of critical processes, task scheduling latency, and packet loss rate of communication protocols. CAN bus analysis tools are also used to track communication latency changes between vehicle control units. Furthermore, environmental parameter data is jointly collected by onboard cameras, accelerometers, and temperature sensors, including spectral analysis of in-vehicle vibration intensity, real-time changes in external ambient temperature, and dynamic fluctuations in light intensity.

[0038] The collected raw data is then further cleaned by a preprocessing module to remove outliers, noise, and missing data segments. Missing values ​​are filled in using a linear interpolation algorithm to ensure data continuity. Subsequently, the multidimensional feature data is normalized to map indicators of different dimensions to a uniform numerical range (0-1) to eliminate the impact of dimensional differences on model training.

[0039] Finally, the preprocessed data is divided into training set, validation set and test set. The training set contains tens of thousands of sets of multi-dimensional time series data under normal driving scenarios, covering typical road conditions such as urban roads and highways. Tens of thousands of sets of fault scenario data are generated by simulating extreme working conditions as negative samples to provide a comprehensive data foundation for the prediction model and achieve accurate prediction of the system health status.

[0040] Step S220: Based on multi-dimensional time series data, generate a predicted value of the failure probability of the vehicle operation system within a preset time period in the future through a preset prediction model.

[0041] In one embodiment of this application, a dual-modal neural network model is used as an example of a preset prediction model.

[0042] First, the preprocessed multidimensional time-series data is input into a bimodal neural network model, which consists of an LSTM layer and an Attention mechanism. The LSTM layer extracts long-term dependent features of the system state, such as CPU load trends or GPU temperature changes. The Attention mechanism dynamically weights key features, such as sudden increases in communication latency or abnormal memory fragmentation rates, to enhance fault sensitivity. The input layer receives normalized hardware status data, such as CPU / GPU temperature and memory usage, software behaviors, such as process crash frequency and communication packet loss rate, as well as environmental parameters such as vibration intensity and ambient temperature. The model outputs a health score (0-1) and a fault probability (0-100%) for the next 50ms.

[0043] Secondly, mean squared error is used as the loss function during the training phase, and the parameters are optimized until convergence through backpropagation. The training data includes a large number of normal driving scenarios and fault scenarios, and the ability to identify sudden faults is improved through extreme operating conditions. The final model achieves a fault probability prediction accuracy of ≤±0.05 on the test set, and can generate fault prediction values ​​for the vehicle operating system in real time for the next 50ms, providing an accurate basis for health assessment and redundancy switching decisions.

[0044] In one embodiment of this application, generating a predicted failure probability value for a vehicle operating system within a preset future time period includes: preprocessing multidimensional time-series data, the preprocessing including at least cleaning abnormal and missing data; inputting the preprocessed multidimensional time-series data into a preset prediction model to extract time-series features of the multidimensional time-series data, including long-term state-dependent features; calculating the importance score of each time-series feature, and assigning dynamic weight coefficients to each time-series feature according to the importance score; multiplying the obtained dynamic weight coefficients with the corresponding time-series features to obtain a weighted feature vector, and aggregating all weighted feature vectors to form a fusion feature; and outputting the predicted failure probability value of the vehicle operating system within a preset future time period based on the fusion feature.

[0045] In one specific embodiment of this application, the collected multidimensional time-series data is first preprocessed to improve data quality. During the data cleaning stage, an outlier detection algorithm identifies and removes hardware status data that exceeds a reasonable range, such as a sudden spike in CPU temperature to 120°C or a sudden increase in process crash frequency to an outlier value in software behavior data. Simultaneously, a linear interpolation algorithm is used to complete missing data segments caused by sensor malfunctions, such as missing memory usage values ​​during CAN bus communication interruptions. Subsequently, the cleaned data is normalized, mapping indicators of different dimensions to a unified numerical range (0-1) to eliminate the impact of dimensional differences on model training.

[0046] The preprocessed data is fed into a pre-defined bimodal neural network model, which includes LSTM layers and an attention mechanism. The LSTM layers capture long-term dependencies in the system state through temporal modeling, such as the trend of CPU load gradually increasing from 40% to 85% over 10 consecutive seconds, and the continuous rise in GPU temperature under high-temperature environments. The attention mechanism dynamically weights key features; for example, when a sudden increase in communication latency from an average of 20ms to 50ms is detected, this feature is given a higher weight of 0.35, while the weights of other features, such as memory fragmentation rate, are correspondingly reduced to 0.15, thereby enhancing the model's sensitivity to sudden failures.

[0047] In the feature weighting stage, based on a preset multi-dimensional feature weight allocation scheme, such as "CPU load 30%, GPU temperature 25%, communication latency 20%, memory fragmentation rate 15%, and environmental interference 10%", the extracted long-term state-dependent features are weighted and fused. For example, when the system is in a high-temperature environment and the GPU temperature is above 85°C for 5 consecutive seconds, the model will generate a higher failure probability prediction value. The final model outputs the failure probability prediction value (range 0-100%) within the next 50ms, and optimizes the model parameters through the mean squared error (MSE) loss function to ensure that the prediction accuracy error is controlled within ±0.05. This prediction value serves as the core basis for subsequent health assessment and redundancy switching strategies, realizing a proactive early warning of vehicle operating system failures.

[0048] Step S230: Calculate the health score of the vehicle operating system based on the feature parameters and preset weights of the multidimensional time series data, and determine the health level of the vehicle operating system by combining the fault probability prediction value.

[0049] In one embodiment of this application, the health score of the vehicle operating system is first calculated based on the feature parameters of multidimensional time-series data and preset weights. The weight allocation scheme is set according to the importance of key system indicators, such as CPU load 30%, GPU temperature 25%, communication latency 20%, memory fragmentation rate 15%, and environmental interference 10%. During calculation, the normalized value (0-1) of each feature parameter is multiplied by the corresponding weight and then summed. For example, when the normalized value of CPU load is 0.8, the normalized value of GPU temperature is 0.7, the normalized value of communication latency is 0.6, the normalized value of memory fragmentation rate is 0.5, and the normalized value of environmental interference is 0.4, the health score is 0.8×0.3+0.7×0.25+0.6×0.2+0.5×0.15+0.4×0.1=0.645.

[0050] The health score is then fused with the predicted failure probability (0-100%) output by the bimodal neural network model for the next 50ms to determine the status: if the health score is ≥0.8 and the failure probability is <10%, it is considered normal; if the health score is between 0.5 and 0.8 and the failure probability is between 10% and 30%, an alert is triggered and preloading is performed; if the health score is <0.5 or the failure probability is >70%, it is directly determined as a failure and a forced switchover is performed.

[0051] In one embodiment of this application, calculating the health score of a vehicle operating system includes: extracting hardware operating status characteristic parameters, software behavior characteristic parameters, and environmental parameter characteristic parameters from multi-dimensional time-series data; assigning preset weight coefficients to each characteristic parameter, and performing weighted calculations on each characteristic parameter and its corresponding weight coefficients to generate a basic health score; converting the fault probability prediction value into a corresponding health correction factor, and superimposing the basic health score and the health correction factor to obtain the final health score.

[0052] In one specific embodiment of this application, hardware operating status characteristic parameters, software behavior characteristic parameters, and environmental parameter characteristic parameters are first extracted from multi-dimensional time-series data as the basis for calculating the health score. Hardware operating status characteristic parameters include indicators such as CPU load, GPU temperature, memory usage, and battery voltage, which are periodically collected through the on-board diagnostic interface (OBD) and hardware monitoring module, with a sampling frequency set to 10 times per second to capture transient anomalies. Software behavior characteristic parameters cover the crash frequency of critical processes, task scheduling latency, and communication protocol packet loss rate, which are obtained in real time through system log analysis tools and the CAN bus monitoring module. Environmental parameter characteristic parameters include in-vehicle vibration intensity, external ambient temperature (range -20℃ to 60℃), and light intensity, which are jointly collected by an on-board camera, accelerometer, and temperature sensor.

[0053] After normalization, the extracted feature parameters are weighted according to preset weight coefficients to generate a basic health score. The preset weight coefficients are based on the importance of key system indicators, for example, assigning a weight of 30% to CPU load, 25% to GPU temperature, 20% to communication latency, 15% to memory fragmentation rate, and 10% to environmental interference. Specifically, the calculation method involves multiplying the normalized value (0-1) of each feature parameter by its corresponding weight and then summing the results. For example, when the normalized value of CPU load is 0.8, the normalized value of GPU temperature is 0.7, the normalized value of communication latency is 0.6, the normalized value of memory fragmentation rate is 0.5, and the normalized value of environmental interference is 0.4, the basic health score is 0.8×0.3+0.7×0.25+0.6×0.2+0.5×0.15+0.4×0.1=0.645.

[0054] The predicted failure probability (range 0-100%) output by the bimodal neural network model within the next 50ms is then converted into a corresponding health correction factor, which is added to the base health score to obtain the final health score. The correction factor for the predicted failure probability is converted to a range of 0.8-1.2 using a linear mapping function. The correction factor is 1 when the predicted failure probability is 0%, 0.8 when the predicted failure probability is 70%, and other values ​​are interpolated proportionally. For example, if the base health score is 0.645 and the predicted failure probability is 20%, the correction factor is 1 - (20% × 0.05) = 0.9, and the final health score is 0.645 × 0.9 = 0.5805.

[0055] By dynamically integrating the basic health score with the failure probability correction factor, the system retains the stability assessment driven by historical data while enhancing the sensitivity to sudden failures. This enables accurate determination of the system's health level and dynamic adaptation of redundancy strategies, providing a precise basis for subsequent health level determination and redundancy switching strategies.

[0056] In one embodiment of this application, determining the health level of a vehicle operating system based on fault probability prediction values ​​includes: detecting the changing trend of fault probability prediction values; if the fault probability prediction value continuously increases and the rate of change exceeds a preset evolution threshold, then determining that the vehicle operating system is in a fault evolution state; when the health score value is greater than or equal to a first preset threshold, determining the health level as a normal level; when the health score value is less than the first preset threshold but greater than or equal to a second preset threshold, if the vehicle operating system is not in a fault evolution state, determining the health level as a normal level, and if the vehicle operating system is in a fault evolution state, determining the health level as a warning level; when the health score value is less than the second preset threshold, determining the health level as a fault level.

[0057] In one specific embodiment of this application, the fault probability prediction value output by the dual-modal neural network model is first continuously monitored for its changing trend within the next 50ms. If the fault probability prediction value shows a continuous increase and the rate of change exceeds a preset evolution threshold, such as an increase of 3% per second, the vehicle operating system is determined to be in a fault evolution state. For example, when the fault probability prediction value increases from an initial 10% to 20% within 5 seconds at a rate of 2% per second, and this growth rate exceeds the preset evolution threshold of 1.5% per second, the system triggers a fault evolution state indicator.

[0058] Subsequently, the health level is determined based on a joint judgment rule of health score and fault evolution status. When the health score is greater than or equal to the first preset threshold, such as 0.8, it is judged as normal regardless of whether a fault evolution status exists, and the system does not need to intervene and maintains the operation of the main system. When the health score is less than the first preset threshold but greater than or equal to the second preset threshold, such as 0.5, the fault evolution status is further judged: if it is not in a fault evolution status, it is judged as normal; if it is in a fault evolution status, it is judged as a warning level and a preloading strategy is triggered, such as caching the navigation interface and warning icons. When the health score is less than the second preset threshold, it is directly judged as a fault level and an atomic switch is forcibly executed, freezing the main system screen and activating the standby system display.

[0059] Understandably, the solution proposed in this embodiment, by dynamically fusing the changing trend of the fault probability prediction value and the dual judgment logic of the health score value, retains the long-term reliance on system stability assessment while enhancing the ability to sensitively detect sudden faults. For example, when the health score is 0.6, between 0.5 and 0.8, and the fault probability prediction value increases at a rate of 4% per second to 30%, exceeding the preset evolution threshold of 1.5% per second, the system adjusts the health level from normal to warning and preloads key modules to shorten the subsequent switching response time. Ultimately, through a multi-dimensional dynamic adaptation mechanism, the system achieves accurate determination of the vehicle operating system's health level and forward-looking decision-making on redundancy switching strategies.

[0060] Step S240: Based on the health level, trigger the corresponding redundant operation instruction, execute the redundant operation instruction, and realize the pre-load control of the standby system or the atomic switching operation of the primary and standby systems of the instrument equipment.

[0061] In one embodiment of this application, redundant operation instructions are dynamically triggered and specific control logic is executed based on the health level. When the health level is determined to be in a normal state, the main system continues to operate and the data link is continuously monitored without additional operation. When the health level enters a warning state, a preloading instruction is triggered, and the standby system is woken up through a cold backup mechanism. Critical modules such as the navigation interface and warning icons are cached, and the preloading process takes less than 15ms to reserve resources for subsequent switching. If the health level drops to a fault state, an atomic switching instruction is immediately executed. Hardware-level operations are used to freeze the main system screen and activate the standby system display within 1ms, while data consistency is ensured through a double buffering mechanism and a transaction rollback protocol. After the switch, the main system enters a self-check process. When the health level recovers to above the first preset threshold, the system automatically switches back to the main system and releases the standby resources.

[0062] In one embodiment of this application, the atomic switching operation of the primary and backup systems includes: if the health level is determined to be a warning level, loading the interface display resources of the backup system into the cache, synchronizing the real-time vehicle operation data of the primary system to the background buffer of the backup system, and keeping the backup system in a low-power standby state; if the health level is determined to be a fault level, freezing the display output of the primary system, activating the display interface of the backup system and switching to the foreground display, submitting the real-time data of the background buffer of the primary system to the foreground display of the backup system, performing a fault isolation operation on the primary system and triggering the primary system restart process; after the primary system completes the restart, re-collecting the multi-dimensional time-series data of the primary system and calculating the self-check health score value; if the self-check health score value continuously meets the preset recovery conditions, freezing the display output of the backup system, restoring the display control and data link of the primary system, and switching the backup system back to the standby state.

[0063] In one specific embodiment of this application, the atomic switching operation of the primary / standby system is dynamically triggered and specific control logic is executed based on the health level. Specifically:

[0064] When the health level is determined to be a warning level, the system activates the backup system's preloading mechanism. First, critical interface display resources such as the navigation interface and warning icons are loaded into the backup system's cache. Simultaneously, real-time vehicle operation data from the primary system, such as vehicle speed, engine speed, and fault codes, are synchronized to the backup system's background buffer. Meanwhile, the low-power management module keeps the backup system in standby mode, consuming only about 5% of system resources to reduce energy consumption. If the health level further deteriorates to a fault level, the primary system's display output is immediately frozen. Hardware-level signal control activates the backup system's display interface within 1ms and switches it to the foreground display. At the same time, real-time data from the primary system's background buffer, such as current vehicle speed and battery status, is submitted to the backup system's foreground display to ensure data consistency. During this process, the primary system performs fault isolation operations, cutting off the power supply or communication link to the faulty module and triggering the primary system restart process.

[0065] After the main system restarts, it re-collects multi-dimensional timing data such as CPU temperature, GPU load, and communication latency, and calculates a self-test health score. If the self-test health score consistently meets preset recovery conditions, such as a score ≥ 0.8 for 5 consecutive seconds, the display output of the standby system is frozen, the display control and data link of the main system are restored, and the standby system is switched back to a low-power standby state through a double-buffering mechanism. For example, if the health score gradually recovers from 0.6 to 0.85 after the main system restarts, and the score fluctuation does not exceed ±0.05 within 30 consecutive seconds, the system determines that it has returned to normal, automatically releases the standby system resources, and terminates the pre-loading cache.

[0066] It is understandable that the solution proposed in this embodiment, through hierarchical triggering and dynamic control, not only achieves resource pre-setting before a fault, but also ensures millisecond-level switching and recovery during a fault, thus taking into account both redundancy reliability and resource efficiency.

[0067] In one embodiment of this application, after executing the redundant operation command, the vehicle instrument redundancy switching method further includes: continuously monitoring the heartbeat signals of the data acquisition link and operation execution link of the vehicle operating system; when the heartbeat signal is detected to be interrupted, cutting off the main system display output, switching to the backup system display interface, and synchronizing real-time vehicle data to the backup system; after the main system restarts, calculating the main system self-check health score based on multi-dimensional time-series data and preset weights; if the self-check health score continuously reaches the preset normal threshold, freezing the backup system output and restoring the main system display control and data link.

[0068] In one specific embodiment of this application, after executing the redundancy operation command, the on-board instrument redundancy switching method further includes continuously monitoring the heartbeat signals of the data acquisition link and the operation execution link of the vehicle operating system. The data acquisition link heartbeat signal is detected by periodically polling the response status of each sensor interface, such as the OBD bus or CAN bus, while the operation execution link heartbeat signal is detected by the health status report at a message exchange frequency between the primary and backup systems, such as 10 times per second. When the heartbeat signal of either link is detected to be interrupted, for example, if the data acquisition link does not receive OBD interface data for 3 consecutive seconds due to abnormal sensor power supply, or if the operation execution link's message reporting frequency drops sharply to less than once per second due to the primary system freezing, a takeover control operation is immediately triggered.

[0069] The takeover control operation consists of three steps: First, the main system's display output is cut off, and the main system's screen refresh is frozen via hardware-level signal control; second, the standby system's display interface is activated and switched to the foreground display, ensuring real-time visualization of basic dashboard functions such as vehicle speed, RPM, and fault codes; finally, real-time vehicle data, such as current vehicle speed, battery voltage, and fault codes, from the main system's background buffer are synchronized to the standby system's foreground display, ensuring data consistency through a dual-buffering mechanism. During this period, the main system enters a forced restart process, cutting off the power supply or communication links to abnormal modules, such as isolating navigation processes that crash due to memory leaks.

[0070] After the main system restarts, it re-collects multi-dimensional time-series data, such as CPU temperature, GPU load, and communication latency, and calculates a self-check health score based on preset weights. If the self-check health score consistently meets a preset normal threshold, such as a score ≥ 0.8 for 5 consecutive seconds, the display output of the standby system is frozen. A double-buffering mechanism restores display control and data links to the main system, while the standby system is switched back to low-power standby mode. For example, if the health score gradually recovers from 0.6 to 0.85 after the main system restarts, and the score fluctuation does not exceed ±0.05 within 30 consecutive seconds, the system determines that it has returned to normal, automatically releases standby system resources, and terminates pre-loading cache.

[0071] It is understandable that the solution proposed in this embodiment, through dynamic monitoring of heartbeat signals and a hierarchical takeover mechanism, not only ensures rapid takeover when the main system is abnormal, but also achieves seamless switching after the main system recovers, taking into account both redundancy reliability and resource efficiency.

[0072] Figure 3 This is a schematic diagram of the overall steps of the vehicle instrument redundancy switching method provided in one embodiment of this application.

[0073] In one specific embodiment of this application, a method for redundant switching of in-vehicle instrument clusters based on an AI prediction engine is proposed. The specific steps are as follows: Figure 3 As shown, the system first acquires raw data such as hardware status, software behavior, and environmental parameters through a data acquisition module. This data is then input into an AI prediction engine composed of an LSTM layer and an Attention layer for processing. The LSTM layer uses a Long Short-Term Memory network to capture long-term dependencies in time-series data, such as identifying trends like continuously increasing CPU load or sudden increases in GPU temperature. The Attention mechanism layer dynamically weights the processed features, focusing on key time points or features such as sudden increases in communication latency or abnormal memory fragmentation rates to improve prediction accuracy. The processed data enters a multi-dimensional feature weighting model, which calculates a health score using preset weights (e.g., 30% CPU load, 25% GPU temperature) to quantitatively assess the system status. The assessment results are categorized into normal, warning, or fault levels by a three-level health assessment module. Based on the assessment results, corresponding switching strategies are triggered: in a normal state, the main system continues to run; in a warning state, preloading the cache is executed; and in a fault state, hardware-level signal control freezes the main system screen and activates the backup system display within 1ms, while ensuring data consistency. The entire process embodies closed-loop management from data collection to intelligent decision-making, highlighting the core role of AI technology in improving system reliability and resource efficiency.

[0074] Figure 4 This is a schematic diagram of a dual-modal neural network structure provided in one embodiment of this application.

[0075] In one specific embodiment of this application, a dual-modal neural network structure is used to achieve the redundancy switching of the aforementioned vehicle-mounted equipment. For example... Figure 4 As shown, its core process consists of five parts: the input layer receives multi-dimensional feature data covering hardware status such as device temperature and voltage, software behavior such as process running status and communication frequency, and time-series information such as environmental parameters such as temperature and humidity; the data first enters the LSTM layer, which captures the dynamic relationship of features changing over time through a long short-term memory network; subsequently, the Attention mechanism layer dynamically weights the processed features, focusing on the key features that have the greatest impact on fault prediction; the fully connected layer integrates and abstracts the output of the Attention layer, extracting higher-dimensional correlation information; finally, the output layer generates a "fault and probability" prediction based on the integration result, clarifying the current fault state of the device and its probability of occurrence. This architecture, through the combination of temporal modeling and the attention mechanism, achieves high-precision prediction of faults in complex systems, and is suitable for scenarios requiring real-time performance and stability, such as industrial equipment monitoring and vehicle system health management.

[0076] Finally, it is important to emphasize that the in-vehicle instrument redundancy switching method proposed in this application achieves significant optimizations in reliability, resource efficiency, and safety through the combination of AI prediction and dynamic evaluation. First, the AI ​​prediction engine based on LSTM and Attention mechanisms can identify fault trends in advance, such as sudden increases in communication latency or GPU temperature spikes, significantly shortening the response time compared to traditional threshold-triggered mechanisms. Second, by using a multi-dimensional feature weighted model combining hardware status, software behavior, and environmental parameters, combined with fault probability prediction values, the health level is dynamically determined, effectively reducing the false positive rate. Simultaneously, a cold backup and pre-loading strategy is adopted, caching only critical modules during the early warning phase. Pre-loading time is extremely short, significantly reducing the standby power consumption of the backup system compared to traditional hot backup systems. After the main system restarts, a health score is generated through multi-dimensional data self-check. Once the conditions are met, the system automatically switches back to the main system and releases backup resources, achieving seamless switching without manual intervention. This method supports a hierarchical strategy, covering normal, early warning, and fault states, adapting to different fault evolution rates, and ensuring data consistency through a double-buffering mechanism and transaction rollback protocol. Compared to traditional mechanical braking redundancy solutions, this solution effectively controls the fluctuation range of vehicle braking force during the switching process, taking into account both user experience and resource efficiency, and providing an innovative path for vehicle instrument redundancy that is both forward-looking and practical.

[0077] Figure 5 This is a block diagram illustrating a vehicle instrument redundancy switching device according to an exemplary embodiment of this application. The device can be applied to… Figure 1 The implementation environment shown is illustrated. This device can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0078] like Figure 5 As shown, the exemplary vehicle instrument redundancy switching device includes: a data acquisition module 510, a fault prediction module 520, a health assessment module 530, and a switching execution module 540.

[0079] The system includes: a data acquisition module 510 for acquiring multi-dimensional time-series data of the vehicle operating system, including hardware operating status data, software behavior characteristic data, and environmental parameter data; a fault prediction module 520 for generating a predicted fault probability value of the vehicle operating system within a preset time period based on the multi-dimensional time-series data and a preset prediction model; a health assessment module 530 for calculating a health score value based on the characteristic parameters and preset weights of the multi-dimensional time-series data, and determining the health level of the vehicle operating system in conjunction with the predicted fault probability value; and a switching execution module 540 for triggering redundant operation instructions based on the health level to execute pre-loading control of the standby system or atomic switching operation of the primary / standby system.

[0080] In one embodiment of this application, the above-mentioned vehicle instrument redundancy switching device further includes: a heartbeat monitoring module, a failure takeover module, a self-healing control module, a preloading submodule, and an atomic switching submodule.

[0081] The system includes: a heartbeat monitoring module for continuously monitoring the heartbeat signals of the data acquisition and operation execution links of the vehicle operation system; a failover module for cutting off the main system display output and switching to the backup system display interface when the heartbeat signal is detected to be interrupted, and synchronizing real-time vehicle data to the backup system; a self-healing control module for calculating a self-check health score based on the re-acquired multi-dimensional time-series data, and freezing the backup system output and restoring control of the main system if the self-check health score continuously meets the preset recovery conditions; a preloading submodule, embedded in the switching execution module, for loading the interface display resources of the backup system into the cache and synchronizing real-time data of the main system to the backup system background buffer when the health level is a warning level; and an atomic switching submodule, embedded in the switching execution module, for freezing the main system display screen, activating the backup system display interface, and submitting real-time data from the background buffer to the backup system front end when the health level is a fault level.

[0082] It should be noted that the in-vehicle instrument redundancy switching device and the in-vehicle instrument redundancy switching method provided in the above embodiments belong to the same concept. The specific operation methods of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the in-vehicle instrument redundancy switching device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0083] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the vehicle instrument redundancy switching method provided in the above embodiments.

[0084] Figure 6 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 6 The computer system 600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 6 As shown, the computer system 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 602 or programs loaded from Storage Unit 608 into Random Access Memory (RAM) 603, such as performing the methods described in the above embodiments. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 604.

[0086] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0087] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs various functions defined in the system of this application.

[0088] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0089] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0090] The units involved in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the unit itself under certain circumstances.

[0091] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a computer's processor, causes the computer to perform the aforementioned in-vehicle instrument redundancy switching method. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0092] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle instrument redundancy switching method provided in the various embodiments described above.

[0093] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for redundancy switching of vehicle instrument clusters, characterized in that, The method includes: Acquire multi-dimensional time-series data from onboard instruments in the vehicle operating system; Based on the multidimensional time series data, a predicted failure probability value of the vehicle operation system within a preset time period is generated through a preset prediction model. Based on the feature parameters and preset weights of the multidimensional time series data, the health score of the vehicle operation system is calculated, and the health level of the vehicle operation system is determined by combining the fault probability prediction value. Determining the health level of the vehicle operating system based on the predicted failure probability values ​​includes: The trend of the predicted fault probability value is detected. If the predicted fault probability value rises continuously and the rate of change exceeds a preset evolution threshold, the vehicle operating system is determined to be in a fault evolution state. When the health score is greater than or equal to the first preset threshold, the health level is determined to be normal. When the health score is less than the first preset threshold and greater than or equal to the second preset threshold, if the vehicle operating system is not in a fault evolution state, the health level is determined to be normal; if the vehicle operating system is in a fault evolution state, the health level is determined to be warning level. When the health score is less than the second preset threshold, the health level is determined to be a fault level; Based on the health level, trigger the corresponding redundant operation instruction, execute the redundant operation instruction, so as to realize the pre-load control of the standby system or the atomic switching operation of the primary and standby systems of the instrument equipment. After executing the redundant operation instructions, the method further includes: Continuously monitor the heartbeat signals of the data acquisition link and operation execution link of the vehicle operation system; When the heartbeat signal is detected to be interrupted, the main system display output is cut off, the system is switched to the backup system, and real-time vehicle data is synchronized to the backup system. After the main system restarts, a self-check health score is calculated based on the multi-dimensional time-series data and preset weights. If the self-test health score continues to reach the preset normal threshold, the backup system output is frozen, and the main system control and data link are restored.

2. The vehicle instrument redundancy switching method according to claim 1, characterized in that, Generating a predicted failure probability value for the vehicle operating system over a preset future time period includes: The multidimensional time-series data is preprocessed, and the preprocessing includes at least cleaning up abnormal and missing data; The preprocessed multidimensional time series data is input into a preset prediction model to extract the time series features of the multidimensional time series data; Calculate the importance score of each time series feature, and assign dynamic weight coefficients to each time series feature based on the importance score; The obtained dynamic weight coefficients are multiplied by the corresponding time-series features to obtain a weighted feature vector, and all the weighted feature vectors are aggregated to form a fused feature; Based on the fusion features, the predicted failure probability value of the vehicle operation system within a preset time period is output.

3. The vehicle instrument redundancy switching method according to claim 1, characterized in that, Calculating the health score of the vehicle operating system includes: Hardware operating status characteristic parameters, software behavior characteristic parameters, and environmental parameter characteristic parameters are extracted from the multidimensional time series data. Assign preset weight coefficients to each feature parameter, and calculate the weighted average of each feature parameter with its corresponding weight coefficient to generate a basic health score. The predicted failure probability value is converted into a corresponding health correction factor, and the basic health score value is superimposed with the health correction factor to obtain the final health score value.

4. The vehicle instrument redundancy switching method according to any one of claims 1-3, characterized in that, Atomic switching operations include: If the health level is determined to be a warning level, the interface display resources of the backup system are loaded into the cache area, the real-time vehicle operation data of the main system is synchronized to the background buffer of the backup system, and the backup system is kept in a low-power standby state. If the health level is determined to be a fault level, the main system's display output is frozen, the standby system's display interface is activated and switched to the foreground display, the real-time data in the main system's background buffer is submitted to the standby system's foreground display, and the main system restart process is triggered.

5. A vehicle-mounted instrument redundancy switching device, characterized in that, The device includes: The data acquisition module is used to acquire multi-dimensional time-series data of the on-board instruments in the vehicle operation system. The multi-dimensional time-series data includes hardware operation status data, software behavior characteristic data, and environmental parameter data. The fault prediction module is used to generate a predicted fault probability value of the vehicle operating system within a preset time period in the future based on the multi-dimensional time series data and a preset prediction model. The health assessment module is used to calculate a health score based on the feature parameters and preset weights of the multidimensional time series data, and to determine the health level of the vehicle operation system in combination with the fault probability prediction value. The switching execution module is used to trigger redundant operation instructions based on the health level, and to execute the pre-loaded control of the standby system or the atomic switching operation of the primary and standby systems of the instrument equipment. The heartbeat monitoring module is used to continuously monitor the heartbeat signals of the data acquisition link and operation execution link of the vehicle instrument in the vehicle operation system; The failover module is used to cut off the main system display output and switch to the backup system display interface when the heartbeat signal is detected to be interrupted, and synchronize real-time vehicle data to the backup system. The self-healing control module is used to calculate a self-check health score based on the re-acquired multi-dimensional time-series data. If the self-check health score meets the preset recovery conditions, the backup system output is frozen and the main system control is restored. The preloaded submodule, embedded in the switching execution module, is used to load the interface display resources of the standby system into the cache area and synchronize the real-time data of the main system to the background buffer of the standby system when the health level is the warning level. The atomic switching submodule, embedded in the switching execution module, is used to freeze the main system display screen, activate the standby system display interface, and submit the real-time data in the background buffer to the standby system front end when the health level is a fault level.

6. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the vehicle instrument redundancy switching method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the computer's processor, causes the computer to perform the vehicle instrument redundancy switching method as described in any one of claims 1 to 4.

Images