A two-wheeled vehicle area control dual-system switching method and device and storage medium

Abstract

This application discloses a method, device, and storage medium for switching between two-wheeled vehicle domain control systems, relating to the field of electronic control system technology. The method is executed by a domain control SOC module and applied to a two-wheeled vehicle domain controller containing a real-time thread operating system (ROTS) and an Android system. Its core features include: after power-on, ROTS displays the system first; after Android starts up and is ready, a pre-switch consistency check is performed, followed by layer switching using a transactional mechanism including preparation and commit phases, and rollback points are recorded. After switching, Android's health is assessed based on multi-dimensional indicators; if a serious anomaly is encountered, it immediately reverts to ROTS. After rollback, Android restarts and an observation window is used for verification. If the number of failures exceeds a threshold, a degradation mode is entered, retaining only safety-critical functions, with ROTS taking over the main display and automatic switching disabled. This application aims to solve the problems of easy black screens, inaccurate fault identification, and lack of a graded degradation mechanism in two-wheeled vehicle dual-system switching, ensuring system stability and security.

Description

Technical Field

[0001] This invention relates to the field of electronic control system technology, and in particular to a method, device and storage medium for switching between two-wheeled vehicle domain control dual systems. Background Technology

[0002] Currently, most two-wheeled vehicle cockpit systems employ a single operating system architecture. For scenarios emphasizing immediate display upon power-on and real-time driving performance, a real-time operating system is typically deployed; for scenarios seeking a rich application ecosystem, a general-purpose operating system is usually deployed. However, a single system architecture cannot simultaneously meet the dual requirements of rapid response and functional expansion, and the general-purpose operating system lacks operational stability under the unique weak voltage stabilization power supply environment and high-frequency vibration conditions of two-wheeled vehicles.

[0003] In existing technologies, some solutions deploy both types of operating systems simultaneously in the domain controller. However, there are significant shortcomings in the collaborative control between systems: the correlation between display control and operating status is weak, and the triggering conditions for switching actions are singular; recovery methods after anomalies are limited, and there is a lack of mechanisms to suppress the cumulative effects of faults. As a result, in actual operation, situations such as loss of synchronization between systems, abnormal display interruptions, misjudgment of operating status, and uncontrolled fault recovery occur frequently, making it difficult to guarantee the continuous availability of functions related to driving safety. Summary of the Invention

[0004] The main objective of this invention is to provide a method, device, and storage medium for switching between two-wheeled vehicle domain control systems, aiming to solve the problems of insufficient system switching reliability and difficulty in ensuring the continuous availability of driving safety-related functions when the real-time operating system and the general operating system are running in tandem in a two-wheeled vehicle domain controller.

[0005] To achieve the above objectives, the first aspect of this application provides a method for switching between two-wheeled vehicle domain control dual systems, executed by a domain control SOC module, wherein the domain control SOC module includes a real-time thread operating system and an Android system, and the method includes: In response to the power-on command, the real-time thread operating system is started and takes over the main screen display, while the Android system is started; The display switch is performed using a transactional mechanism that includes a preparation phase and a commit phase, wherein the status information for system rollback is recorded as a rollback point during the preparation phase; After switching to the Android system display, the health of the Android system is assessed based on at least two different dimensions of operating metrics; When the health assessment result indicates that the Android system has a serious anomaly, it immediately reverts to the real-time thread operating system taking over the main screen display; After reverting to the real-time thread operating system display, the Android system is restarted; if the restart is successful, an observation window of a preset duration is entered to continuously monitor its stability. If the Android system fails to restart or the cumulative number of stability verification failures during the observation window reaches a preset threshold, it enters a downgrade mode, maintaining the main screen display under the real-time thread operating system and prohibiting subsequent automatic switching to the Android system.

[0006] A second aspect of this application provides a two-wheeled vehicle domain controller, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the computer program to implement the method as described in any of the first aspects.

[0007] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any of the first aspects.

[0008] This application has at least the following beneficial effects: 1. By taking over ROTS in advance, we can achieve rapid power-on and shorten the effective display time.

[0009] 2. By conducting pre-checks and transactional switching, combined with rollback points, we can prevent black screens or loss of control caused by switching interruptions.

[0010] 3. Improve the ability to identify abnormal "false survival" through multi-indicator health assessment.

[0011] 4. Improve the success rate of handover and the duration of stable operation by using tiered recovery and observation windows.

[0012] 5. By using failure thresholds and degradation modes, ensure the continuous availability of critical functions of two-wheeled vehicles and prioritize safety.

[0013] 6. The solution is designed for engineering applications in two-wheeled vehicle scenarios and is characterized by high reliability and low risk. Attached Figure Description

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

[0015] in: Figure 1 This is a schematic diagram of a two-wheeled vehicle domain control dual-system switching method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the software architecture of a two-wheeled vehicle domain controller provided in an embodiment of this application. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0017] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0018] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. Embodiments of this application are described below with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart illustrating a domain control dual-system switching method for a two-wheeled vehicle, as provided in an embodiment of this application. The method can be executed by a domain control SOC module, which includes a real-time thread operating system and an Android system.

[0020] The Real-time Operating Threaded System (ROTS) mentioned in this application embodiment is mainly used for the rapid startup of two-wheeled vehicles after power-on and for carrying out key functions.

[0021] The Android system mentioned in this application embodiment is an application ecosystem that can support advanced application capabilities such as navigation, communication, and entertainment in vehicles.

[0022] The domain controller SOC module mentioned in this application embodiment is the main computing platform of the two-wheeled vehicle domain controller, which is responsible for dual system startup, layer switching, health monitoring and fault recovery, etc.

[0023] like Figure 1 As shown, the method includes: 101. In response to the power-on command, the aforementioned ROTS is started and takes over the main screen display, while the aforementioned Android system is started.

[0024] Specifically, after the vehicle is powered on, the MCU on the central control board can read the body bus cycle data and synchronize it to the domain controller SOC; the domain controller SOC prioritizes starting ROTS and simultaneously starts the Android preheating process, with ROTS taking over the display first. ROTS completes the interface rendering based on the body bus data, and the ROTS layer fully covers the main screen and pushes it to the LCD, ensuring a stable and visible interface upon power-on.

[0025] 102. A transactional mechanism including a preparation phase and a commit phase is used to perform the display switch. In the preparation phase, the status information used for system rollback is recorded as a rollback point.

[0026] Specifically, the "transactional mechanism" in this application embodiment mainly includes two stages: Preparation phase: Freeze the input event queue. During the preparation phase before switching, the distribution of input events from hardware such as touchscreens and buttons to the currently or soon-to-be-activated system can be paused to prevent user input from triggering unpredictable behavior or race conditions during state transition.

[0027] The aforementioned rollback point can be understood as state information used for system rollback; it is an archive point at the moment before the system executes Commit. The information recorded therein is to ensure that in the event of a switchover failure, the state can be accurately and without damage restored.

[0028] Optionally, the state information recorded at the rollback point for system rollback includes at least one of the following: input event queue state, display stack state, and audio focus state.

[0029] Commit phase: Hides the ROTS layer, and the Android layer fully covers the main screen and pushes the LCD. This operation is performed only after ensuring the preparation phase has been successfully completed (input is frozen, rollback point is recorded). This operation itself is fast and indivisible, enabling an instantaneous switch of the display stack and transferring primary display control to the Android system.

[0030] In one alternative implementation, after the Android system has started and is ready, a pre-switch consistency check is performed before the display switch from ROTS to the Android system is executed.

[0031] The switching pre-conformity check may include at least one of the following: input channel validity check, display channel validity check, audio focus consistency check, and bus subscription consistency check.

[0032] If the conditions are not met, keep ROTS displayed and retry after a delay.

[0033] 103. After switching to the above Android system display, perform a health assessment of the above Android system based on at least two different dimensions of operating indicators.

[0034] The HealthScore mentioned in this application embodiment is a quantitative result of system stability based on a series of multi-dimensional operational indicators.

[0035] ROTS can continuously monitor the Android status and calculate health indicators, including at least heart rate, ANR, main thread blocking, frame rate, memory level, temperature, and watchdog results.

[0036] Specifically, for the responsiveness and reliability dimension, metrics may include heartbeat (to determine whether core processes are alive), application unresponsiveness (ANR), and critical service responsiveness (such as SystemServer and rendering services). These metrics directly reflect the system's availability to user interactions and internal requests.

[0037] For performance metrics, frame rate can be included, which can directly reflect the smoothness of the user interface (UI) and determine whether there is "stuttering" or "freezing".

[0038] For the resource and load dimensions, metrics can include memory level and temperature, which reflect the system's resource usage and hardware load. Memory leaks or overheating can lead to system instability or even crashes.

[0039] For the monitoring mechanism dimension, indicators can include watchdog results. This is a separate hardware or software timer used to monitor whether the system performs a "watchdog feed" operation within a specified time, detecting whether the system has experienced deep blocking or deadlock.

[0040] The entire evaluation process in this step is a closed loop. First, the monitoring service collects raw data from the Android system using various technical means. Specific methods may include: Obtain system-level performance and status information through extended debug bridge commands (such as ADB commands) or custom system service interfaces; obtain physical layer data by directly reading hardware drivers (such as temperature sensors).

[0041] The collected metrics are as described above. For example, "critical process heartbeats" are checked through periodic inter-process communication; "application unresponsiveness" events are captured by real-time parsing of system logs; "critical service response" speed is evaluated by initiating remote calls to a lightweight probe service deployed on the Android side and measuring its round-trip latency; "display frame rate" is queried through the system graphics service interface; "memory level" is calculated by reading memory information files; "system temperature" is obtained by reading chip temperature sensors; in addition, a software watchdog thread is set up on the ROTS side, and high-priority services in Android periodically "feed the watchdog" to monitor whether the system is deeply blocked, which is the "watchdog result".

[0042] The health score calculation logic in this embodiment can be adjusted as needed. The collected raw data will be input into a quantitative scoring algorithm. For example, this embodiment uses a "weighted deduction system" for illustration: Assume the health score is out of 100. Specific thresholds and deduction rules are set for each evaluation metric. For example, a single "critical process heartbeat" loss may directly deduct 50 points; each "application unresponsive" event deducts 15 points; "service response latency" exceeding 500 milliseconds deducts 10 points; "display frame rate" below 30 frames per second deducts 15 points; "available memory" below 10% deducts 20 points; "system temperature" exceeding 95 degrees Celsius deducts 25 points; and a "watchdog" timeout directly deducts 100 points. Within a fixed evaluation period, the total deductions for all metrics are summed, and this total is subtracted from 100 to obtain the "health score" for the current period. This score is limited to between 0 and 100.

[0043] The calculated health score directly drives subsequent tiered processing strategies. For example, a score of 80 or higher indicates a "healthy" state, with no system-wide abnormality handling. A score between 50 and 80 indicates a "minor abnormality," at which point the health monitoring service sets an "abnormality under control" flag and can restrict non-critical high-load applications on the Android side (such as closing background video streams) to attempt to alleviate the problem without the user noticing. A score below 50 is considered a "serious abnormality," and the monitoring service immediately sets a "crash and restart" flag, triggering the transactional rollback process defined in the claims. ROTS forcibly takes over the main screen display, quickly restoring basic security features before the user experiences noticeable lag or a black screen.

[0044] For example, in practical applications, after the vehicle is powered on and the system switches to Android display, this health monitoring service begins to work periodically. For instance, when the Android system experiences a slight interface lag but not a complete crash due to an application malfunction, the monitoring service may collect data on "application unresponsive" events and "frame rate drop." After calculating the score, if it falls into the "mild anomaly" range, the system will automatically take measures to restrict background applications. If the Android system freezes completely due to a serious malfunction, the monitoring service will simultaneously detect "heartbeat loss," "zero frame rate," and "watchdog timeout" within a very short time (e.g., within 1-2 seconds), and the score will immediately drop to zero, indicating a "serious anomaly." This will immediately trigger the rollback mechanism, instantly restoring the display of critical information such as the dashboard.

[0045] 104. When the above health assessment results indicate that the above Android system has a serious abnormality, immediately revert to the main screen display being taken over by the above ROTS.

[0046] The purpose of this step is to bypass the regular reboot process and perform the highest priority emergency recovery action when the Android system experiences a fatal failure that may cause the user to experience a freeze, black screen, or loss of function. This ensures that even in the worst software failure scenario, the vehicle's basic safety functions (such as speed, battery display, and warning lights) can be restored to usability in a very short time, meeting the rigid requirement of "safety first" for two-wheeled vehicles.

[0047] The judgment criteria for the aforementioned "serious anomalies" can be set according to the corresponding judgment rules as needed. Specifically, when the calculated health score is lower than the preset serious anomaly threshold, or when a "veto" event is directly detected (such as continuous loss of core process heartbeat or watchdog timeout), the system can determine that it is a "serious anomaly".

[0048] The aforementioned severe anomalies mainly refer to the state of "system crash or unresponsive timeout". This corresponds to the simultaneous deterioration of multiple key indicators in the health assessment, such as: loss of system heartbeat; failure to receive a "feed the watchdog" signal after the software watchdog times out; a persistent frame rate of 0; and multiple consecutive occurrences of application unresponsive events, etc.

[0049] If a serious anomaly occurs in the Android system, the system can immediately set the "crash and restart flag" as the formal instruction to execute this rollback step.

[0050] In this application's embodiments, "immediate rollback" is a high-priority operation, which can be understood as interrupting any current low-priority task. Its goal is to restore a reliable display interface in the shortest possible time. Specifically: Upon receiving a "serious anomaly" signal, the display management subsystem in the domain controller SOC module will immediately interrupt the rendering and output of the current Android layer; The system will call the rollback point recorded during the preparation phase of the most recent successful transactional switch. This rollback point saves a precise snapshot of the state (such as the exact layer stack structure) when ROTS had full control of the display before the switch. Based on this rollback point information, the system can hide or destroy the currently abnormal Android foreground layer and push the ROTS layer, which is waiting in the background, back to the top of the display stack and onto the LCD. In practical applications, this process is hardware-accelerated and extremely fast, enabling rapid recovery with no noticeable or only a momentary flicker for the user.

[0051] Through the above steps, the main screen display can be instantly switched from the faulty Android interface back to the stable and reliable ROTS interface (usually displaying core instrument information such as vehicle speed, battery level, and mileage), and the display of user interaction and vehicle safety-critical information can be restored.

[0052] 105. After returning to the above ROTS display, restart the above Android system; if the restart is successful, enter the observation window for a preset duration to continuously monitor its stability.

[0053] After reverting to the aforementioned ROTS display, the system can automatically trigger the subsequent Android restart and observation window verification process, attempting to restore the Android system in the background to ensure that only a truly stable Android system will be authorized to take over the display again.

[0054] Specifically, the system management service of the domain controller SOC module can reload the Android kernel, start system services, and application framework according to a predefined cold boot or warm boot process. This process is similar to the initial power-on boot and will not be described in detail here.

[0055] A successful Android system reboot can usually be determined by checking whether the basic services of the Android system (such as the init process and system_server) have started and completed initialization.

[0056] The observation window mentioned in this embodiment is a preset, continuous time period T. During this period, the system will not immediately attempt to switch back to Android, but will instead allow it to run in the background.

[0057] Within the observation window, the aforementioned health assessment mechanism will remain active throughout, continuously monitoring the Android system running in the background across multiple dimensions (heart rate, ANR, frame rate, memory, temperature, etc.). Its goal is to verify the stability of Android over a longer period, ensuring it does not immediately crash again after a switch.

[0058] The health assessment mechanism at this stage can be the same as the core logic and indicators of the Android foreground runtime, but there can be differences in data collection targets, collection methods and evaluation emphasis of some indicators, so as to achieve effective monitoring of the background system.

[0059] For example, after a successful Android reboot, the system does not dismantle the inter-process communication links established for health assessment. The "Health Monitoring Service" on the ROTS side automatically re-establishes or restores the connection with the rebooted Android system, including the Socket connection for sending PING commands, the listening channel for receiving ANR and other event notifications, and the shared memory or message queue for "feeding the watchdog." This is the technical prerequisite for the observation window to start.

[0060] Because Android operates in the background, its SurfaceFlinger may not be compositing the user-facing UI layer. Therefore, metrics such as "frame rate," which heavily rely on the foreground UI, may not be applicable or require different data collection strategies. Monitoring at this stage focuses more on the following types of metrics: Core process and service survival and responsiveness: ROTS continuously checks the heartbeats of critical daemons such as Android's system_server and surfaceflinger, and periodically calls the "probe service" to measure RPC response latency. Any heartbeat loss or severe response timeout will be considered a verification failure.

[0061] System resources and abnormal events: Memory and ANR: Continuously monitor system memory levels and ANR events in logcat.

[0062] CPU and Temperature: Monitor the CPU usage and SoC temperature of background Android processes. Abnormally high load or overheating indicates that there may be uncontrolled processes or resource contention in the background.

[0063] Watchdog monitoring: The background "watchdog" service must run continuously. Any time the "software watchdog" times out during the observation window directly proves that the Android main thread or system service is deeply blocked, and is immediately judged as verification failure.

[0064] Optionally, the monitoring service can collect data and calculate scores in shorter intervals (e.g., 1-2 seconds).

[0065] Specifically, within the entire preset observation window duration T, the system will set a stricter pass threshold. For example, it may require the health score to always be no lower than 70 points, and absolutely prohibit "veto" events such as watchdog timeout or core heartbeat loss.

[0066] If all monitored metrics meet stability requirements throughout the entire window period T, the system determines that the restart was successful and Android has returned to stability. Subsequently, the "Observation window successful" flag will be set, triggering the subsequent transactional switchback back to Android. If a serious anomaly is detected at any time during the window period T (such as a score below 50 or a veto event), the observation window is immediately terminated, and this attempt is recorded as a failure. The failure counter is incremented and used as the basis for deciding whether to trigger the final "degradation mode".

[0067] 106. If the above Android system fails to restart or the cumulative number of stability verification failures during the above observation window reaches a preset threshold, then enter the downgrade mode, keep the main screen display by the above ROTS and prohibit subsequent automatic switching to the Android system.

[0068] If stability is achieved within the observation window, the system can automatically trigger a new round of pre-switch checks and transactional switching, returning the main screen display to the now stable Android system, thus achieving full functional recovery. If Android experiences another serious anomaly during the observation window (i.e., the health assessment result fails to meet the standards), this restart observation process will be marked as a failed attempt, as detailed in the preceding steps.

[0069] This step can proactively terminate futile recovery attempts and force the system to lock into a known safe operating state when the Android system exhibits an unrecoverable, persistent failure.

[0070] The aforementioned reboot failure refers to the failure of the action of "rebooting the Android system after rollback" itself. For example, the Android kernel may fail to start, or system services may crash repeatedly and fail to enter a ready state. Each reboot failure is counted as one failure. The above observation window verification failure means that although Android can start, it fails the stability verification (health assessment fails) during the observation window period. Each time the verification is terminated prematurely due to a serious anomaly during the observation window period, it is counted as one failure.

[0071] The system maintains a failure counter to accumulate the number of occurrences of the two scenarios mentioned above. When the accumulated count reaches a pre-set threshold N, the system determines that the Android system is "unrecoverable" or "will no longer attempt recovery" within the current runtime. At this point, the degradation mode will be officially triggered. The threshold N can be configured according to the vehicle model's reliability and strategy (e.g., N=3), and is not limited here.

[0072] Once in downgrade mode, the system will perform a series of irreversible configuration operations (or operations that can only be restored under specific conditions such as manual intervention or a vehicle power-on restart), including: The home screen will remain under the aforementioned ROTS, and automatic switching to the Android system will be disabled. Regardless of whether Android recovers automatically later, the system will prohibit any automatic switching commands from ROTS to Android, including transactional switching.

[0073] Only safety-critical functions are retained. In downgraded mode, the system will proactively limit or disable all unnecessary, high-load functions. Specifically, entertainment, navigation, and advanced settings functions carried by the Android system will be disabled or strictly limited. However, critical functions carried by ROTS, such as instrument information directly related to driving safety, such as vehicle speed, battery level, mileage, gear position, light status, and hazard warning lights, must be guaranteed and continuously operated.

[0074] By setting preset thresholds and implementing explicit degradation behaviors, this method ensures that even if complex functions fail, the driver can still obtain the most basic and necessary driving information throughout the entire journey of the two-wheeled vehicle, greatly improving the overall safety level of the system.

[0075] In an alternative implementation, the health assessment in this application may be replaced by a dynamic threshold (e.g., adaptive to temperature, load, and voltage fluctuations).

[0076] Temperature-adaptive: For example, when the chip temperature is low (e.g., below 50°C), the memory utilization threshold can be set to 85%; however, when the temperature rises (e.g., reaching 85°C), to prevent overheating, the system will dynamically lower the memory utilization threshold to 70%. Once this dynamic threshold is exceeded, more severe alarms or throttling measures will be triggered to prevent crashes caused by high temperature and high load.

[0077] Adaptive to load: When the system detects that a high-load application is running (such as navigation while playing music), the strict requirements for the average frame rate can be appropriately relaxed (for example, allowing it to drop to 50 FPS for a short period of time); however, in low-load scenarios, the high standard for the frame rate is maintained (such as it must be kept at 60 FPS) in order to pursue the best smooth experience.

[0078] Adaptive to voltage fluctuations: When the domain controller input voltage (typically from the vehicle battery) falls below its nominal value, the system may be in an undervoltage and unstable state. In this situation, health assessments become more sensitive; for example, the tolerance threshold for process response delays is shortened, and any slight delay may be considered an anomaly, thus triggering protective backoffs earlier to avoid unpredictable failures due to insufficient power.

[0079] The above methods enable the system to have environmental awareness and risk prediction capabilities, and can adopt the most appropriate health standards under different operating conditions. This avoids misjudgment under harsh conditions and prevents missed judgment under good conditions, thereby further improving the accuracy of fault identification and the robustness of the system.

[0080] In one alternative implementation, the transactional switching in this application can be extended to a three-phase process to enhance post-switching verification.

[0081] Furthermore, in addition to the aforementioned two-phase transaction (Prepare / Commit), a final confirmation phase is added to form a more rigorous switching protocol.

[0082] Specifically, the Prepare and Commit phases are the same as described above. A new Validate phase is added: After the commit operation is completed, the transaction does not immediately end, but enters a brief verification period. During this phase, the system immediately performs a quick but critical post-switch check. For example: Perform a display channel verification to confirm that the Android layer has been successfully displayed and that the frame buffer has been updated. To perform critical service handshake verification, ROTS immediately sends a verification request to Android's "probe service" to confirm that the communication link is immediately restored after the switch. Perform input channel verification, unfreeze the input event queue, and test whether a virtual touch event can be correctly received by the Android side.

[0083] The entire transactional switch is considered a final success only if all checks in the Validate phase pass. If Validate fails, the rollback point recorded in the Prepare phase is used to perform a transaction rollback, undoing the Commit operation and reverting to the ROTS explicit state. This adds an eventual consistency guarantee.

[0084] In one alternative implementation, the degradation strategy in this application can be tiered by functional domain. This is a specific implementation of the principle of "retaining only safety-critical functions" in the aforementioned degradation mode.

[0085] Specifically, when entering degraded mode, the system no longer simply restricts non-security functions in general, but rather disables system functions in a modular and hierarchical manner according to predefined functional safety levels. For example: The highest safety level (must be retained): Instrument panel (vehicle speed, RPM, battery level, mileage), warning panel (malfunction indicator lamps, ABS / TCS status indicators, seatbelt reminder). These are information directly related to the basic safe operation of the vehicle and are the sole responsibility of ROTS to ensure their proper functioning.

[0086] Second highest safety / comfort level (restrictable): Body control domain. In downgraded mode, these functions can be restricted to operation via physical buttons only, or a simplified interface can be provided.

[0087] Non-critical level (directly disabled): Infotainment domain. This includes all functions supported by the Android system, such as navigation, music playback, and advanced settings menus, which will be completely disabled or forcibly shut down. The system will release all CPU, memory, and display resources used by these functions.

[0088] The above methods enable more refined resource management and security assurance. By classifying resources by domain, the system resources allocated to ROTS can be maximized while ensuring the highest level of security, thereby further improving the stability and reliability of ROTS in degraded mode.

[0089] In one optional implementation, the observation window duration T and failure threshold N in this application can be configured according to vehicle model to meet the differentiated needs of different vehicle models, different hardware platforms and different quality objectives.

[0090] Specifically, different observation window durations can be set for different vehicle models in the factory configuration or after-sales service tools. For example, for high-performance models or models with powerful hardware platforms, a shorter observation window (such as T=30 seconds) can be set because their system recovery speed is fast and their stability is expected to be high, aiming to quickly restore full functionality; for economy models or models used in harsh environments, a longer observation window (such as T=90 seconds or longer) can be set to conduct more thorough and conservative stability verification to ensure that nothing goes wrong.

[0091] Similarly, the number of allowed failures, N, before triggering downgrade mode can also be configured. For models that emphasize continuous user experience, a larger number of attempts (e.g., N=5) can be allowed, giving the system more opportunities to self-heal. For models with extremely stringent security requirements, a stricter strategy (e.g., N=2) can be adopted. If Android fails twice consecutively within a short period of time, it will immediately enter downgrade mode to ensure that security functions are absolutely reliable.

[0092] The dual-system switching method provided in this application, by introducing pre-checks, transactional mechanisms, multi-dimensional monitoring, and tiered degradation strategies, effectively overcomes the shortcomings of blind switching processes, lack of fault tolerance, and absence of termination mechanisms, bringing significant technological advancements and engineering benefits. 1. Significantly improves system stability and user experience.

[0093] By employing pre-switch consistency checks, transactional switching, and rollback point mechanisms, the display switching becomes predictable and controllable, fundamentally reducing the black screen, freezing, and repeated restarts that may occur in traditional solutions where "switching occurs immediately after startup." Simultaneously, the introduction of an observation window stability verification mechanism ensures that the Android system has a real and stable operating state before taking over the display, significantly improving the success rate of takeover and effectively reducing user-perceived functional interruptions.

[0094] 2. Ensure the absolute security and high availability of critical functions.

[0095] By assessing health using multiple indicators and monitoring system status in real time, combined with failure thresholds and degradation modes, the system can quickly and safely revert to the ROTS main display in severe abnormal scenarios. This "tiered governance" strategy ensures that even in extreme cases where the Android system completely fails, critical safety functions such as the vehicle's instrument panel remain available, resulting in a substantial improvement in overall security.

[0096] 3. Construct a complete closed-loop governance system with outstanding engineering practicality.

[0097] Compared to existing technologies that only operate at a simple listen-restart level, this application establishes a complete closed-loop control logic encompassing "detection-switching-verification-rollback-degradation." Furthermore, this solution demonstrates high adaptability and practicality in engineering implementation, effectively meeting the stringent requirements for highly reliable human-machine interaction systems in the complex operating environments of two-wheeled vehicles.

[0098] Based on the aforementioned method embodiments, this application also provides a two-wheeled vehicle domain controller, including a memory and a processor. The memory stores a computer program, and the processor is used to execute the computer program to implement the steps of any of the two-wheeled vehicle domain controller dual-system switching methods of this application, which will not be repeated here.

[0099] Specifically, the domain controller uses a domain controller SOC module as its main computing platform. This module includes a multi-core processor, memory, storage units, and a display controller. The display controller supports at least two independent display layer inputs. The domain controller SOC module connects to the vehicle network via an onboard bus interface (such as a CAN bus) to acquire vehicle body data.

[0100] Figure 2 This is a schematic diagram of the software architecture of a two-wheeled vehicle domain controller provided in an embodiment of this application.

[0101] On the aforementioned hardware platform, the Real-Time Thread Operating System (ROTS) 21 and the Android system 22 are implemented through system software. ROTS 21 is used to run safety-critical functions such as vehicle instrument clusters, while Android system 22 is used to run advanced applications such as infotainment. Core functional modules are integrated on the ROTS 21 side, including: The health monitoring module 201 is used to establish and maintain communication with the Android system 22, periodically collect its operating indicators (including but not limited to process heartbeat, application unresponsiveness, display frame rate, memory usage, system temperature and watchdog status), and calculate the health score according to a preset algorithm.

[0102] The transactional switching control module 202 is used to manage the switching of display layers. It performs transactional operations that include a preparation phase and a commit phase: in the preparation phase, the system state is recorded as a rollback point; in the commit phase, the display controller is controlled to complete the display switching from the ROTS layer to the Android layer.

[0103] The policy management module 203 is used to execute complete control logic. Based on the output of the health monitoring module, when a serious anomaly is detected, it controls the transactional switching control module to immediately fall back to the ROTS 21 display. After falling back, it manages the restart process of the Android system 22. After the Android restarts successfully, it starts an observation window of a preset duration and calls the health monitoring module to continuously verify its stability during this period. If the Android restart fails or the cumulative number of verification failures during the observation window period reaches a preset threshold N, the control domain controller enters a degraded mode. In this mode, the ROTS 21 is permanently kept as the primary display, and subsequent automatic switching to the Android system 22 is prohibited.

[0104] Based on the foregoing method embodiments, this application also provides a computer-readable storage medium storing a computer program thereon, characterized in that, when the computer program is executed by a processor, it implements the steps of any of the two-wheeled vehicle domain control dual-system switching methods of this application, which will not be repeated here.

[0105] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0106] The embodiments described above are merely examples of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application.

Claims

1. A method for switching between two-wheeled vehicle domain control dual systems, characterized in that, Executed by a domain controller SOC module, the domain controller SOC module comprising a real-time thread operating system and an Android system, the method includes: In response to the power-on command, the real-time thread operating system is started and takes over the main screen display, while the Android system is started; The display switch is performed using a transactional mechanism that includes a preparation phase and a commit phase, wherein the status information for system rollback is recorded as a rollback point during the preparation phase; After switching to the Android system display, the health of the Android system is assessed based on at least two different dimensions of operating metrics; When the health assessment result indicates that the Android system has a serious anomaly, it immediately reverts to the real-time thread operating system taking over the main screen display; After reverting to the real-time thread operating system display, the Android system is restarted; if the restart is successful, an observation window of a preset duration is entered to continuously monitor its stability. If the Android system fails to restart or the cumulative number of stability verification failures during the observation window reaches a preset threshold, it enters a downgrade mode, maintaining the main screen display under the real-time thread operating system and prohibiting subsequent automatic switching to the Android system.

2. The two-wheeled vehicle domain control dual-system switching method according to claim 1, characterized in that, The method further includes: After the Android system starts up and is ready, a pre-switch consistency check is performed before the display switch from the real-time thread operating system to the Android system.

3. The two-wheeled vehicle domain control dual-system switching method according to claim 2, characterized in that, The pre-switch consistency check includes: At least one of the following: input channel validity check, display channel validity check, audio focus consistency check, and bus subscription consistency check.

4. The two-wheeled vehicle domain control dual-system switching method according to claim 1, characterized in that, The rollback point records the status information for system rollback, including at least one of the following: Input event queue status, display stack status, and audio focus status.

5. The two-wheeled vehicle domain control dual-system switching method according to claim 1, characterized in that, The transactional switching mechanism includes: During the preparation phase, the input event queue is frozen; During the submission phase, the ROTS layer is hidden and the Android layer covers the main screen.

6. The two-wheeled vehicle domain control dual-system switching method according to claim 1, characterized in that, The operational indicators upon which the health assessment is based include at least two of the following: System heartbeat, application unresponsiveness, critical service response status, display frame rate, memory usage, system temperature, and watchdog timeout information.

7. The two-wheeled vehicle domain control dual-system switching method according to claim 1, characterized in that, The method further includes: When the health assessment result is slightly abnormal, the abnormality control flag is set and the operation of high-load applications is restricted.

8. The two-wheeled vehicle domain control dual-system switching method according to claim 1, characterized in that, The method further includes: If the Android system runs stably within the observation window, the display switch is executed again.

9. A two-wheeled vehicle domain controller, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, The processor is used to implement the method as described in any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images