A vehicle-mounted dual-os heterogeneous coordination startup timing arbitration and fault isolation method

Abstract

The application discloses a kind of vehicle-mounted double OS heterogenous coordination's start timing arbitration and fault isolation method, and the application relates to vehicle-mounted system technical field, solve the problem that conventional scheme lacks the analysis and pre-judgment ability to resource occupation change trend, cannot identify resource depletion risk in advance, the application is monitored CPU, memory resource state by relying on occupation rate curve+change trend algorithm, accurately identify abnormal jump point by quantitative calculation parameter change amplitude, can capture system jam, process anomaly, resource sudden increase and other implicit faults in time, compared with traditional fixed threshold monitoring mode, fault identification sensitivity is higher, positioning is more accurate, can quickly lock abnormal process.

Description

Technical Field

[0001] This invention relates to the field of vehicle system technology, specifically to a method for startup timing arbitration and fault isolation of heterogeneous collaboration between dual OS in a vehicle. Background Technology

[0002] Currently, most in-vehicle smart cockpits adopt a heterogeneous dual-operating system architecture consisting of a secure domain OS and a non-secure domain OS. The secure domain OS carries driving safety-related functions, while the non-secure domain OS is responsible for in-vehicle entertainment, navigation, audio and other application functions.

[0003] While some existing technologies incorporate startup scheduling logic during the dual-OS power-on startup phase, they only perform simple checks on inter-system interaction signals, lacking a multi-dimensional, standardized signal verification mechanism. The in-vehicle operating environment suffers from electromagnetic interference and data transmission distortion, making it prone to issues such as false triggering of interference signals, misjudgment of abnormal messages, and signal timing disorder. This can lead to dual-OS startup linkage failure, timing asynchrony, instrument display delays, and abnormal application loading, making it difficult to guarantee the stability and reliability of the startup process.

[0004] Meanwhile, after the dual OS enters normal operation, traditional monitoring methods mostly use a single fixed threshold to determine system anomalies. They can only identify obvious faults such as system crashes and complete freezes, but cannot accurately capture hidden problems such as instantaneous changes in CPU and memory usage and abnormal increases in process resources. It is difficult to locate abnormal processes. Moreover, conventional solutions lack the ability to analyze and predict the trend of resource usage changes, and cannot identify the risk of resource exhaustion in advance. When a single operating system experiences faults such as resource overflow or continuous high load, it cannot perform isolation actions in time. The fault can easily spread along the hardware resource link, which not only affects the function of the system itself, but also interferes with the normal operation of the other operating system, seriously threatening vehicle driving safety.

[0005] In addition, existing monitoring and fault handling logic is mostly integrated into upper-layer applications of the system and relies on the operating system kernel for implementation, resulting in poor compatibility and failing to meet the high reliability and strong security requirements of automotive-grade applications in the automotive field. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a startup timing arbitration and fault isolation method for heterogeneous collaboration of dual OS in vehicles, which solves the problem that conventional solutions lack the ability to analyze and predict the trend of resource usage changes and cannot identify the risk of resource exhaustion in advance.

[0007] To achieve the above objectives, the present invention provides a method for startup timing arbitration and fault isolation of a vehicle-mounted dual-OS heterogeneous collaboration, comprising the following steps: Step 1: After the system is powered on, the arbitration module triggers the startup of the operating systems in an orderly manner according to the scheduling logic prioritizing the security domain, and realizes the startup linkage and precise timing matching of the front and rear two-stage systems through the synchronous handshake interface; at the same time, it monitors the startup progress of each operating system in real time throughout the whole process, and identifies whether the startup is abnormal in combination with the preset timeout threshold, the specific manner is as follows: The arbitration module issues a startup trigger instruction to the security domain OS through the underlying driver according to the preset priority, starts the first timer at the same time, the status monitoring interface starts periodic polling, reads the startup progress of the security domain OS in real time, and writes it into the status register; After receiving the startup instruction, the security domain OS sequentially completes the initialization of core modules such as kernel loading, core driver initialization, instrument display, and security alarm, responds to the polling of the monitoring interface throughout the whole process, and continuously feeds back its own startup progress; After the security domain OS completes core initialization and determines that it can work normally, the security domain OS calls the synchronous handshake interface to send a startup ready signal to the arbitration module; The specific manner of realizing the startup linkage and precise timing matching of the front and rear two-stage systems through the synchronous handshake interface is as follows: The arbitration module monitors the continuous handshake interface, after capturing the ready signal, it completes the signal validity check. When the check is passed, it is determined that the security domain OS starts normally, the first timer is stopped, and the timing value is cleared; the polling of the startup progress of the security domain OS is suspended, and its operating state is locked; Then the arbitration module issues a startup trigger instruction to the non-security domain OS, starts the second timer, switches the monitoring object, enables the status monitoring interface to start polling the startup progress of the non-security domain OS, and updates the status register; The non-security domain OS receives the startup instruction, sequentially completes the initialization of modules such as execution kernel, entertainment, navigation, and audio, responds to the polling normally until the entire startup process is completed; After the non-security domain OS is started, the second timer is stopped and cleared, the arbitration module closes the startup exclusive scheduling logic, retains the interface path, and enters the background silent on-duty state, the dual OSs officially enter the parallel normal operation phase, and the entire startup timing arbitration process is completely ended; The specific manner of identifying whether the startup is abnormal in combination with the preset timeout threshold is as follows: When the interface detects a valid level / data message input, it is determined that a handshake signal has arrived, the current interface data is latched immediately, a new round of polling is stopped, the signal arrival timestamp is recorded at the same time, and the process enters the signal verification link; Compare the preset feature code / flag bit of the signal header, and it is determined as a valid service signal only when the data header is completely consistent with the agreed "security domain ready identifier"; if the identifier does not match, it is directly determined as an interference signal, the data is discarded, and the system returns to the continuous interface monitoring state; Check the length of the data frame transmitted this time and compare it with the preset handshake message standard length. If the length is abnormal, it is considered a transmission error. Discard the signal and resume listening. Extract the status field from the message and verify whether the field value is the preset "startup ready status code"; The local calculation result is compared with the checksum attached to the signal: if they do not match, the current signal is discarded, the interface continues to listen, and waits for a new handshake signal; if they match, the verification proceeds to the next stage. Retrieve the current timer value and, based on the preset valid timing window, determine that the ready signal must arrive within the range of "0 - timeout threshold (5s)". If a single verification fails or a startup timeout occurs, the startup process will be automatically restarted. If the startup still fails after three automatic restarts, the startup process will be terminated, the system will enter a safety degradation mode, report standard fault codes, and display the fault through the vehicle's instrument panel, without repeating the restart.

[0008] If it is within the legal time range: the timing check passes, and the handshake signal is deemed to be completely legal and valid; Step 2: After the vehicle-mounted dual-OS system starts normally, monitor the operation process of the vehicle-mounted dual-OS system in real time to confirm the CPU utilization and memory usage. Also, identify any abnormal jump points by monitoring the process and the parameter changes of the corresponding monitored items, thereby locking down the associated abnormal processes. The specific method is as follows: Real-time collection of CPU utilization and memory usage of dual OS, generating corresponding resource usage change curves, with the horizontal axis representing time and the vertical axis representing resource usage values; For a single set of change curves: using the current time as the calibration point, extract 100 consecutive sets of historical sampling data (the number of samples is configurable): determine the resource occupancy rate associated with the previous time step as Z1, the resource occupancy rate associated with the next time step as Z2, and the unit duration between adjacent time steps as Sc. Use the formula: |Z1-Z2|÷Sc=change trend, and perform mean processing to confirm the mean trend. Identify the change trend Bq associated with the current time step and the next time step. If Bq≥2×mean trend, then directly mark the next time step as an abnormal jump point; if Bq<2×mean trend, then determine that the operation status is normal and continue monitoring. The specific method for locking abnormal processes is as follows: Within the corresponding system, identify the process associated with the abnormal jump point, and simultaneously extract the occupancy range set for the corresponding process. If the current process's occupancy rate is within or below the occupancy range, no processing is required; if it exceeds the occupancy range, mark the corresponding process as an abnormal process. Step 3: For the marked abnormal processes, extract the growth characteristics of CPU usage or memory occupancy generated by the corresponding abnormal processes in the past. Based on the growth characteristics, comprehensively evaluate the overall occupancy in the dual system and identify whether it is necessary to execute the fault isolation process. The specific method is as follows: From the partial curves extracted from the CPU utilization rate change curve and the memory utilization rate change curve, identify the CPU utilization rate or memory utilization rate associated with the corresponding abnormal process, and identify the growth value associated with adjacent time points. Select the maximum value from the identified multiple sets of growth values, and record the maximum associated CPU utilization rate as the CPU growth feature and the maximum associated memory utilization rate as the memory growth feature. The specific method for identifying whether a fault isolation process needs to be executed is as follows: Based on the real-time generated CPU utilization and memory utilization curves, the CPU utilization and memory utilization associated with the current moment are confirmed. Based on the determined memory growth characteristics and CPU growth characteristics, the CPU utilization or memory utilization associated with the next moment is determined. If a utilization rate meets the condition of ≥98%, the current system is directly marked as an isolated system and actively isolated. A restart signal is generated synchronously to the main page. Otherwise, the abnormal processes are continuously identified, and the utilization rate characteristics associated with the next moment are predicted in real time. The determination of whether the determined utilization rate exceeds the standard is assessed, and the system to which it belongs is actively isolated.

[0009] This invention provides a method for startup timing arbitration and fault isolation in vehicle-mounted dual-OS heterogeneous collaboration. Compared with existing technologies, it has the following advantages: By employing a startup arbitration mechanism that combines layered handshake verification with timing, the dual-OS startup handshake signal undergoes multi-dimensional legality verification, including feature code, message length, status code, check code, and timing window. This effectively filters out electromagnetic interference, transmission distortion, and signal mis-triggering, ensuring the authenticity and reliability of startup interaction signals. It avoids issues such as dual-OS startup timing disorder and command mis-response from the bottom layer, achieving precise linkage between the startup processes of the security domain OS and the non-security domain OS, and significantly improving the stability and timing synchronization accuracy of the vehicle system during the power-on startup phase. Based on the utilization rate curve and change trend algorithm, the system monitors the status of CPU and memory resources in real time. By quantifying the change of parameters, it accurately identifies abnormal jump points and can promptly capture hidden faults such as system lag, process abnormality, and sudden increase in resources. Compared with the traditional fixed threshold monitoring method, the fault identification sensitivity is higher and the location is more accurate, and it can quickly lock down abnormal processes. Based on historical resource growth characteristics, the system predicts future resource usage trends and uses high occupancy thresholds to determine whether fault isolation should be triggered, achieving closed-loop management of early warning and proactive isolation for anomalies. When system resources are nearing exhaustion, isolation operations can be performed promptly to prevent the spread of faults and ensure the continued normal operation of another operating system; simultaneously, a manual restart selection mechanism is provided to balance system security and usage flexibility. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

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

[0012] First Embodiment Please see Figure 1 This application provides a startup timing arbitration and fault isolation method for heterogeneous collaboration of dual OS in vehicles, including the following steps: Step 1: After the system is powered on, the arbitration module triggers the operating system to start in an orderly manner according to the scheduling logic of security domain priority. It realizes the startup linkage and precise timing matching of the front and rear systems through the synchronous handshake interface. At the same time, it monitors the startup progress of each operating system in real time and identifies whether the startup is abnormal by combining the preset timeout threshold. Step 2: After the vehicle dual OS system starts normally, monitor the operation process of the vehicle dual OS system in real time, confirm the CPU usage and memory usage, and confirm whether there are abnormal jump points from the changes in the monitoring process and the corresponding monitoring items, so as to lock the associated abnormal process. Step 3: For the marked abnormal processes, extract the growth characteristics of CPU usage or memory occupancy generated by the corresponding abnormal processes in the past. Based on the growth characteristics, comprehensively evaluate the overall occupancy in the dual system and identify whether it is necessary to execute the fault isolation process.

[0013] Second Embodiment In a specific implementation process, this embodiment is a further implementation of the first embodiment, specifically including: Step 1, the specific method for achieving startup linkage and precise timing matching between the front-end and back-end systems through the synchronous handshake interface is as follows: According to the preset priority, the arbitration module sends a startup trigger command to the security domain OS through the underlying driver, starts the first timer (to time the startup duration of the security domain OS), starts the status monitoring interface to start periodic polling, reads the startup progress of the security domain OS in real time, and writes it to the status register; The security domain OS receives the startup command and sequentially completes the initialization of core modules such as kernel loading, core drivers, instrument display, and security alarms. It responds to the polling of the monitoring interface throughout the process and continuously reports its own startup progress. After the security domain OS completes core initialization and determines that it can work normally, the security domain OS calls the synchronous handshake interface and sends a startup ready signal to the arbitration module. The arbitration module listens to the handshake interface, captures the ready signal, completes the signal validity verification, and when the verification passes, it determines that the security domain OS has started normally, stops the first timer, and clears the timer value; it also pauses the polling of the security domain OS's startup progress and locks its running status. The arbitration module sends a startup trigger command to the non-security domain OS, starts the second timer (to time the startup duration of the non-security domain OS), switches the monitoring object, starts the status monitoring interface to poll the startup progress of the non-security domain OS, and updates the status register. The non-security domain OS receives instructions, executes the initialization of modules such as kernel, entertainment, navigation, and audio, responds normally to polling, and completes the entire boot process; Once the non-security domain OS has started up, the second timer stops and is cleared. The arbitration module shuts down its dedicated scheduling logic, retains the interface path, and enters a silent background monitoring state. The dual OSes officially enter the parallel normal operation phase, and the entire startup timing arbitration process is complete.

[0014] The specific method for identifying whether the startup is abnormal (signal validity verification) by combining a preset timeout threshold is as follows: After the security domain OS starts, the arbitration module continuously polls the signal register of the synchronous handshake interface to detect whether there is a data / level change in real time. When the interface detects a valid level / data packet input, it determines that a handshake signal has arrived, immediately latches the current interface data, stops the new round of polling, enters the signal verification stage, and records the signal arrival timestamp for subsequent timing compliance judgment. The signal header is compared with the preset feature code / identifier bit. Only when the data header is completely consistent with the agreed "security domain ready identifier" is it determined to be a valid service signal. If the identifier does not match, it is directly determined to be an interference signal, the data is discarded, and the interface returns to continuous listening state. The length of the data frame transmitted this time is checked and compared with the preset handshake message standard length. If the length is abnormal (too long / too short), it is considered a transmission abnormality, the signal is discarded, and listening is resumed. Extract the status field from the message and verify if the field value is the preset "startup ready status code". If the status code is a non-ready type code (such as starting, startup failed, error, etc.), it is determined that the security domain OS has not been initialized, and subsequent actions are not executed. The process returns to the interface listening + progress polling process. If the status code matches the "ready" definition, proceed to the next step. The arbitration module calculates the checksum locally based on the captured message content. It then compares the calculated result with the checksum attached to the message: if they do not match, it determines that the signal has been lost, tampered with, or distorted during transmission; the current message is discarded, the interface continues listening, and waits for the security domain OS to resend the handshake signal; if they match, it confirms that the message data is complete and error-free, and the verification proceeds to the next stage. Retrieve the current timer value of the first channel and combine it with the preset valid timing window for judgment. Rule: The OS ready signal for the security domain must arrive within the range of "0 - timeout threshold (5s)": If the signal arrival time exceeds the timeout window: it is determined to be a timeout exception, this process is terminated and restarted; If within the legal time frame: the timing check passes, and the handshake signal is deemed completely legal and valid.

[0015] Step 2, the specific method for confirming whether there are abnormal jump points from the monitoring data is as follows: The system monitors the CPU usage and memory usage in the vehicle's dual OS system (safety system or entertainment system) in real time, and generates CPU usage change curves and memory usage change curves in real time. The horizontal axis of the curves is the time line, and the vertical axis is the usage parameter. For a single set of change curves: using the current time as the calibration time, extract the partial curves associated with the first 100 unit times. From the partial curves, confirm the change trend of the occupancy rate parameter associated with adjacent times: set the occupancy rate associated with the previous time as Z1, the occupancy rate associated with the next time as Z2, and the unit duration between adjacent times as Sc. Use: |Z1-Z2|÷Sc=change trend. Then, perform mean processing on the several sets of change trends confirmed in the partial curves to confirm the mean trend. Identify the change trend Bq associated with the current time and the next time. If Bq≥2×mean trend, then directly mark the next time as an abnormal jump point time; otherwise, continue monitoring. The specific method for locking associated processes is as follows: Within the corresponding system, identify the process associated with the abnormal jump point and simultaneously extract the occupancy range set for the corresponding process. If the current process's occupancy rate is within or below the occupancy range, no processing is required. If it exceeds the occupancy range, mark the corresponding process as an abnormal process.

[0016] Step 3, the specific method for determining growth characteristics is as follows: From the partial curves extracted from the CPU utilization change curve and the memory utilization change curve, identify the CPU utilization or memory utilization associated with the corresponding abnormal process, and identify the associated growth value at adjacent time points. If the value decreases, no determination is required. Select the maximum value from the identified multiple sets of growth values, and record the associated maximum CPU utilization as the CPU growth characteristic and the associated maximum memory utilization as the memory growth characteristic. As the corresponding curves are generated in real time, the determined CPU growth characteristics and memory growth characteristics will also be updated and change in real time. The specific method for identifying whether a fault isolation process needs to be executed is as follows: Based on the real-time generated CPU utilization and memory utilization curves, the CPU utilization and memory utilization associated with the current moment are confirmed. Based on the determined memory growth characteristics and CPU growth characteristics, the CPU utilization or memory utilization associated with the next moment is determined. If a utilization rate meets the condition of ≥98%, the current system is directly marked as an isolated system and actively isolated. A restart signal is generated synchronously to the main page, and the driver can decide whether to restart. Otherwise, the abnormal processes are continuously identified, and the utilization rate characteristics associated with the next moment are predicted in real time. The determination of whether the identified utilization rate exceeds the standard is assessed, and the system to which it belongs is actively isolated.

[0017] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0018] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A method for startup timing arbitration and fault isolation in vehicle-mounted dual-OS heterogeneous collaboration, characterized in that, Includes the following steps: Step 1: After the system is powered on, the arbitration module triggers the operating system to start in an orderly manner according to the scheduling logic of security domain priority. It realizes the startup linkage and precise timing matching of the front and rear systems through the synchronous handshake interface. At the same time, it monitors the startup progress of each operating system in real time, identifies whether the startup is abnormal in combination with the preset timeout threshold, and executes the corresponding degradation handling strategy. Step 2: After the vehicle dual OS system has started up and entered normal operation, monitor the operation process of the vehicle dual OS system in real time, confirm the CPU usage and memory usage, and identify abnormal jump points by combining the monitoring process and parameter change characteristics, and accurately locate the associated abnormal processes. Step 3: For the marked abnormal processes, extract the growth characteristics of CPU usage or memory occupancy generated by the corresponding abnormal processes in the past. Based on the growth characteristics, comprehensively evaluate the overall occupancy in the dual system and identify whether it is necessary to execute the fault isolation process.

2. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 1, characterized in that, In step one, the arbitration module triggers the operating system startup in an orderly manner according to the security domain priority scheduling logic as follows: The arbitration module sends a startup trigger command to the security domain OS through the underlying driver according to the preset priority. At the same time, it starts the first timer and the status monitoring interface starts periodically polling to read the startup progress of the security domain OS in real time and write it to the status register. After receiving the startup command, the security domain OS sequentially completes the initialization of core modules such as kernel loading, core driver initialization, instrument display, and security alarms, responding to the polling of the monitoring interface throughout the process and continuously providing feedback on its startup progress. After the security domain OS completes the initialization of the core modules and determines that it can work normally, the security domain OS calls the synchronous handshake interface and sends a start-ready signal to the arbitration module.

3. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 2, characterized in that, In step one, the specific method for achieving startup linkage and precise timing matching between the front-end and rear-end systems through the synchronous handshake interface is as follows: The arbitration module listens to the handshake interface, captures the ready signal, completes the signal validity verification, and when the verification passes, it determines that the security domain OS has started normally, stops the first timer, and clears the timer value; it also suspends the polling of the security domain OS's startup progress and locks its running status. Subsequently, the arbitration module sends a startup trigger command to the non-security domain OS, starts the second timer, switches the monitoring object, starts the status monitoring interface to poll the startup progress of the non-security domain OS, and updates the status register. When the non-security domain OS receives the boot command, it sequentially executes the initialization of modules such as kernel, entertainment, navigation, and audio, responds normally to polling, and completes the entire boot process. After the non-security domain OS starts up, the second timer stops and is cleared. The arbitration module shuts down the startup-specific scheduling logic, retains the interface path, and enters the background silent monitoring state. The dual OS officially enters the parallel normal operation stage, and the entire startup timing arbitration process is completed.

4. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 3, characterized in that, In step one, the specific method for identifying whether the startup is abnormal by combining the preset timeout threshold is as follows: When the interface detects a valid level / data packet input, it determines that a handshake signal has arrived, immediately latches the current interface data, stops the new round of polling, enters the signal verification stage, and records the signal arrival timestamp. The signal header is compared with the preset feature code / identifier bit. Only when the data header is completely consistent with the agreed "security domain ready identifier" is it determined to be a valid service signal. If the identifier does not match, it is directly determined to be an interference signal, the data is discarded, the interface returns to continuous listening state, the length of the data frame transmitted this time is checked and compared with the preset handshake message standard length. If the length is abnormal, it is considered a transmission abnormality, the signal is discarded, and listening is resumed. Extract the status field from the message and verify whether the field value is the preset "startup ready status code"; The local calculation result is compared with the checksum attached to the message: if they do not match, the current message is discarded, the interface continues to listen, and waits for the security domain OS to resend the handshake signal; if they match, the verification proceeds to the next stage. Retrieve the current timer value of the first channel and combine it with the preset valid timing window. The OS ready signal in the security domain must arrive within the range of "0 - timeout threshold (5s)". If the signal arrival time exceeds the timeout window: it is determined to be a timeout exception, this process is terminated and restarted; If within the legal time frame: the timing check passes, and the handshake signal is deemed completely legal and valid.

5. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 1, characterized in that, In step two, the specific method for confirming the existence of abnormal jump points from the monitoring data is as follows: The system monitors the CPU usage and memory usage in the vehicle's dual-OS system in real time and generates CPU usage and memory usage change curves in real time. The horizontal axis of the curves is the time line, and the vertical axis is the usage parameter. For a single set of change curves: using the current time as the calibration time, extract the partial curves associated with the first 100 unit times. From the partial curves, confirm the change trend of the occupancy rate parameter associated with adjacent times: set the occupancy rate associated with the previous time as Z1, the occupancy rate associated with the next time as Z2, and the unit duration between adjacent times as Sc. Use: |Z1-Z2|÷Sc=change trend. Then, perform mean processing on the several sets of change trends confirmed in the partial curves to confirm the mean trend. Identify the change trend Bq associated with the current time and the next time. If Bq≥2×mean trend, then directly mark the next time as an abnormal jump point time.

6. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 5, characterized in that, If Bq < 2 × mean trend, then continue monitoring.

7. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 5, characterized in that, In step two, the specific method for locking the associated process is as follows: Within the corresponding system, identify the process associated with the abnormal jump point and simultaneously extract the occupancy range set for the corresponding process. If the current process's occupancy rate is within or below the occupancy range, no processing is required. If it exceeds the occupancy range, mark the corresponding process as an abnormal process.

8. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 1, characterized in that, In step three, the specific method for determining the growth characteristics is as follows: From the partial curves extracted from the CPU utilization change curve and the memory utilization change curve, identify the CPU utilization or memory utilization associated with the corresponding abnormal process, and identify the associated growth value at adjacent time points. Select the maximum value from the identified multiple sets of growth values, and record the associated maximum CPU utilization as the CPU growth feature and the associated maximum memory utilization as the memory growth feature.

9. The method for startup timing arbitration and fault isolation of in-vehicle dual-OS heterogeneous collaboration according to claim 8, characterized in that, In step three, the specific method for identifying whether a fault isolation process needs to be executed is as follows: Based on the real-time generated CPU utilization and memory utilization curves, the CPU utilization and memory utilization associated with the current moment are confirmed. Based on the determined memory growth characteristics and CPU growth characteristics, the CPU utilization or memory utilization associated with the next moment is determined. If a utilization rate meets the condition of ≥98%, the current system is directly marked as an isolated system and actively isolated. A restart signal is generated synchronously to the main page. Otherwise, the abnormal processes are continuously identified, and the utilization rate characteristics associated with the next moment are predicted in real time. The determination of whether the determined utilization rate exceeds the standard is assessed, and the system to which it belongs is actively isolated.

Images