Cabin system control method, device, equipment and medium of two-wheeled vehicle

Abstract

Embodiments of the present application disclose a cockpit system control method, device, equipment and medium for a two-wheeled vehicle, wherein the method dynamically determines the running state by collecting resource parameters and constructing constraint conditions, and then performs dynamic loading or cutting control according to the priority and dependency relationship, and performs rollback, recovery and isolation operations when updating fails or is abnormal, thereby improving the safety, continuity and maintainability of the cockpit system of the two-wheeled vehicle under resource constraints, upgrade maintenance and abnormal scenarios.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of vehicle control technology, and in particular to a method, apparatus, equipment, and medium for controlling the cockpit system of a two-wheeled vehicle. Background Technology

[0002] With the rapid development of the electronic and electrical architecture of two-wheeled vehicles, their functions have gradually evolved from a single instrument display to an intelligent cockpit platform integrating multiple functions such as navigation, voice interaction, media playback, trip logs, remote diagnostics, and risk warnings. This trend of functional integration has led to a continuous increase in the scale and complexity of cockpit software, while the differentiated needs between different vehicle models are becoming increasingly significant.

[0003] Currently, most two-wheeled vehicle cockpit systems in the industry still adopt a monolithic integrated development architecture. In this architecture, functional modules such as navigation, voice, media, logging, diagnostics, and risk alerts are directly coupled to the same application or tightly coupled service stack. This design leads to unclear module boundaries, unstable interface definitions, and the deployment of the entire system heavily relies on a fixed, indivisible system image. Summary of the Invention

[0004] In view of this, embodiments of this application provide at least one method, apparatus, device, and medium for controlling the cockpit system of a two-wheeled vehicle.

[0005] The technical solution of this application embodiment is implemented as follows: On one hand, embodiments of this application provide a cockpit system control method for a two-wheeled vehicle, the method comprising: Collect system resource parameters, which include at least three of the following: processor utilization, memory utilization, message queue length, display link status, and communication link status; Based on the system resource parameters and module dependencies, operational constraints are constructed, and the system operating state is determined according to the operational constraints. The system operating state includes a complete operating state, a restricted operating state, and a recovery operating state. Dynamic loading or pruning control is performed based on module priority and module dependencies under different operating states; When a module update fails, a version rollback and service binding recovery are performed. In case of an anomaly, module isolation is performed, and the abnormal module is restarted to keep the system running.

[0006] On the other hand, embodiments of this application provide a cockpit system control device for a two-wheeled vehicle, the method comprising: The acquisition module is used to acquire system resource parameters, which include at least three of the following: processor utilization, memory utilization, message queue length, display link status, and communication link status. The processing module is used to construct operating constraints based on the system resource parameters and module dependencies, and determine the system operating state according to the operating constraints. The system operating state includes a complete operating state, a restricted operating state, and a recovery operating state. The control module is used to perform dynamic loading or pruning control based on module priority and module dependencies under different operating states; When a module update fails, a version rollback and service binding recovery are performed. In case of an anomaly, module isolation is performed, and the abnormal module is restarted to keep the system running.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described cockpit system control method for two-wheeled vehicles.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described cockpit system control method for two-wheeled vehicles.

[0009] In another aspect, embodiments of this application provide a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps in the above-described cockpit system control method for two-wheeled vehicles.

[0010] In another aspect, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described cockpit system control method for two-wheeled vehicles.

[0011] This application embodiment collects resource parameters and constructs constraints to dynamically determine the operating status, then performs dynamic loading or pruning control according to priority and dependency, and performs rollback, recovery and isolation operations when update fails or anomalies occur, thereby improving the safety, continuity and maintainability of the two-wheeled vehicle cockpit system under resource-constrained, upgrade maintenance and abnormal scenarios.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0014] Figure 1 A schematic diagram illustrating the implementation process of a cockpit system control method for a two-wheeled vehicle provided in this application embodiment; Figure 2 A schematic diagram of the composition structure of a cockpit system control device for a two-wheeled vehicle provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0017] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0019] This application provides a cockpit system control method for a two-wheeled vehicle, which can be executed by a processor of a computer device. The computer device can refer to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (such as a mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other similar computer equipment. Figure 1 This is a schematic diagram illustrating the implementation process of a cockpit system control method for a two-wheeled vehicle provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: Step 101: Collect system resource parameters, which include at least three of the following: processor utilization, memory utilization, message queue length, display link status, and communication link status.

[0020] In this embodiment, system resource parameters are a set of data characterizing the hardware and software resource status of the two-wheeled vehicle cockpit system during operation, such as processor utilization, memory utilization, message queue length, display link status, and communication link status.

[0021] The system first activates the resource monitor, which is responsible for periodically acquiring various operational metrics of the cockpit from both operational and hardware driver perspectives. These metrics specifically include processor utilization (the percentage of the central processing unit currently in use); memory utilization (the percentage of random access memory currently in use); message queue length (the backlog of messages between service modules); display link status (the connection quality and health of the screen display channel); and communication link status (the connection quality and health of network or internal bus communication). Data is collected from at least three of these metrics as the basis for subsequent decision-making.

[0022] Step 102: Construct operating constraints based on the system resource parameters and module dependencies, and determine the system operating state according to the operating constraints. The system operating state includes complete operating state, restricted operating state, and recovery operating state.

[0023] In this embodiment, module dependency is a set of rules describing the logical relationships between different service modules, such as calls and being called, existence and non-existence. For example, a navigation module strongly depends on map data services. Operational constraints are a set of rules jointly formulated based on resource parameters and module dependencies to determine whether the system can operate normally. For example, when memory usage exceeds 80%, the system enters a restricted operating state. The operating state is the current overall working mode determined by the operational constraints, including a complete operating state capable of running all modules, a restricted operating state where only some key modules can run, and a recovery operating state after recovering from an anomaly.

[0024] Based on this data, the system constructs operational constraints, which are a set of logical rules. For example, if the processor utilization rate is greater than 90% or the memory utilization rate is greater than 85%, the system enters a restricted operating state. Based on these constraints, the system automatically determines the current operating state. If resources are sufficient and there are no anomalies, it is determined to be in a complete operating state; if resources are insufficient, it is determined to be in a restricted operating state; if the system is recovering from resource insufficiency or anomalies, it is determined to be in a recovery operating state.

[0025] Step 103: Perform dynamic loading or pruning control based on module priority and module dependencies under different operating states.

[0026] In this embodiment, dynamic loading is the process of loading service modules from storage media into memory and starting them during operation, based on the current state and requirements. Trimming control is the process of actively stopping and unloading non-critical service modules during operation to release resources or isolate faults. Module priority is an importance level assigned to each service module to determine its retention or discard order in resource contention or abnormal situations; for example, the risk warning module has a higher priority than the media module.

[0027] Query the priority of each module and their dependencies. In full runtime, perform dynamic loading, starting all authorized modules in dependency order. In restricted runtime, perform pruning control, deactivating non-critical modules (e.g., media modules) based on module priority from low to high and dependencies to free up resources, ensuring that high-priority risk warning and diagnostic modules can continue to run.

[0028] Step 104: If the module update fails, perform version rollback and service binding recovery, and in case of abnormality, perform module isolation and restart the abnormal module to keep the system running.

[0029] In this embodiment, version rollback is the process of restoring the software version of a module to its pre-update state after a module update failure. Service binding recovery is the process of re-establishing the original communication and calling relationships between the old version module and other modules after version rollback. Module isolation is the process of isolating the operating environment of a module from other parts when an anomaly is detected, thus limiting the scope of its failure impact.

[0030] When the update manager fails to update a module, such as due to a failed health check or dependency verification, the system immediately initiates a version rollback mechanism, restoring the failed module to its previous version. Simultaneously, service binding recovery is performed, re-establishing the original interface calls and message communication relationships between the old version module and other modules to ensure functional continuity. During operation, if an anomaly is detected in a module, such as prolonged unresponsiveness or memory overflow, module isolation is implemented, placing the abnormal module in an isolated, restricted runtime environment. Subsequently, only the abnormal module is restarted, without restarting the entire system, thus maintaining a minimal running state for other healthy modules.

[0031] This application embodiment collects resource parameters and constructs constraints to dynamically determine the operating status, then performs dynamic loading or pruning control according to priority and dependency, and performs rollback, recovery and isolation operations when update fails or anomalies occur, thereby improving the safety, continuity and maintainability of the two-wheeled vehicle cockpit system under resource-constrained, upgrade maintenance and abnormal scenarios.

[0032] Optionally, step 101 includes: Step 1011: The processor utilization rate is calculated by reading the processor timestamp difference in the operating system process control block through the resource monitor according to the sampling period specified by the preset standard.

[0033] In this embodiment, the resource monitor is a component used to monitor the status of running resources, such as processor usage and memory usage. The preset standard is a predefined rule or specification used to define parameters such as the sampling period. The sampling period is a fixed time interval between two data reads by the resource monitor. The operation process control block is a data structure used by the operation kernel to manage each process, containing information such as the process's processor timestamp. The processor timestamp difference refers to the difference between processor timestamps read at two different times, used to calculate the processor's usage time within that time period.

[0034] The system uses a resource monitor to periodically read the process control block (PCB) of each process from the operating kernel according to a preset sampling period. It extracts the processor timestamp of the current moment from the PCB and compares it with the timestamp read in the previous sampling period, calculating the difference between these two timestamps. This difference is then divided by the duration of the sampling period to calculate the processor utilization rate, which reflects the processor's workload during the sampling period.

[0035] Step 1012: Obtain the ratio of allocated heap memory to total heap memory through the heap memory allocator interface, and calculate the memory occupancy rate.

[0036] In this embodiment, the heap memory allocator is a component in the operation or runtime library responsible for managing dynamic memory allocation and deallocation. The heap memory allocator interface is a programming interface used to interact with the heap memory allocator. Allocated heap memory refers to the total amount of heap memory currently requested and used by an application or service module. Total heap memory refers to the maximum available memory capacity configured for the heap memory region.

[0037] The system calls the heap memory allocator interface to send a query request to the heap memory allocator. This interface retrieves the currently allocated heap memory and the total heap memory. The ratio of allocated heap memory to total heap memory is calculated; this ratio is the memory utilization rate, used to measure the degree of memory resource consumption.

[0038] Step 1013: Obtain the message queue length by reading the number of queue nodes of messages to be processed in the message middleware.

[0039] In this embodiment, the message middleware is a software component used for asynchronous communication between service modules. A message to be processed refers to a message that has been sent to the message middleware but has not yet been received and processed by the target service module. A queue node is a basic data structure unit in the message middleware used to store a single message.

[0040] The system directly accesses the message middleware to query its internal queue for storing messages awaiting processing. It reads the number of currently existing queue nodes, which represents the number of unprocessed messages. This number is recorded as the message queue length, reflecting the backlog of internal message communication.

[0041] Step 1014: The display link status is obtained by comparing the timeout count of the vertical synchronization signal returned by the display driver layer with the display link health threshold specified by the preset standard.

[0042] In this embodiment, the display driver layer is a software module within the operating kernel responsible for controlling the display hardware. The vertical synchronization signal is a synchronization signal emitted by the display hardware after completing a frame refresh, used to coordinate the rhythm of display content updates. The vertical synchronization signal timeout count is the number of times the vertical synchronization signal fails to return within the expected time. The display link health threshold is a value defined in a preset standard, used to determine whether the display link is working properly.

[0043] The system sends a query command to the display driver layer to read the vertical synchronization signal timeout count recorded internally by the display driver layer. This count is then compared to the display link health threshold specified in a preset standard. If the timeout count is lower than or equal to the display link health threshold, the display link status is determined to be normal; if the timeout count is higher than the display link health threshold, the display link status is determined to be abnormal or degraded.

[0044] Step 1015: The communication link status is obtained by comparing the cyclic redundancy check error frame count in the communication controller with the communication link health threshold specified by the preset standard.

[0045] In this embodiment, the communication controller is a hardware or software component responsible for managing network or bus communication. The Cyclic Redundancy Check (CRC) frame count is the number of frames that experience CRC errors during communication, as counted by the communication controller. The communication link health threshold is a value defined in a preset standard, used to determine whether the communication link is stable and reliable.

[0046] The system sends a read command to the communication controller to obtain the cyclic redundancy check (CRC) error frame count recorded internally by the controller. This count is then compared to a communication link health threshold specified in a preset standard. If the count is lower than or equal to the communication link health threshold, the communication link is considered normal; otherwise, the count is considered abnormal or degraded.

[0047] This application embodiment collects five key resource parameters—processor utilization, memory utilization, message queue length, display link status, and communication link status—to comprehensively and quantitatively assess the current resource health status of the two-wheeled vehicle cabin, providing an accurate and real-time data foundation for subsequent constraint-based operational status determination and dynamic control.

[0048] Optionally, step 102 includes: Step 1021: Compare the processor utilization rate with the high and low processor utilization thresholds specified in the preset standard; compare the memory utilization rate with the high and low memory utilization thresholds specified in the preset standard; compare the message queue length with the queue length congestion threshold specified in the preset standard; compare the displayed link status with the displayed link degradation threshold specified in the preset standard; compare the communication link status with the communication link degradation threshold specified in the preset standard; and generate resource constraints.

[0049] In this embodiment, processor utilization is the proportion of time the central processing unit (CPU) is occupied by programs, reflecting the processor's workload. Memory utilization is the proportion of used memory space to total memory space, reflecting memory scarcity. Message queue length is the number of messages piling up in the queue, reflecting the bottleneck in processing capacity. Display link status is the connection quality and operating status of the display output channel, reflecting the stability of the interface display. Communication link status is the connection quality and operating status of the network communication channel, reflecting the reliability of data transmission. Resource constraints are a set of rules restricting hardware resource usage, used to determine whether resources are sufficient.

[0050] The system compares the collected processor utilization rate with the high and low processor utilization thresholds specified in the preset standards. It also compares the collected memory utilization rate with the high and low memory utilization thresholds specified in the preset standards. The system compares the collected message queue length with the queue length congestion threshold specified in the preset standards. Finally, it compares the collected displayed link status with the displayed link degradation threshold specified in the preset standards. And the system compares the collected communication link status with the communication link degradation threshold specified in the preset standards. Through all these comparisons, a resource constraint condition is generated that includes the results of whether the usage of each resource is exceeded or degraded.

[0051] Step 1022: Based on the dependency list of each service module stored in the module registration repository, identify strong dependencies, weak dependencies, and mutually exclusive dependencies, and generate dependency constraints.

[0052] In this embodiment, the module registry repository is a database or storage area used to store all service module definition information. The dependency list is a list of other modules declared by each service module that it requires to run. A strong dependency means that module A must start before or run simultaneously with module B; otherwise, module A cannot function properly. A weak dependency means that module A gains enhanced functionality when module B exists, but module A can still run independently even if module B does not exist. A mutual exclusion dependency means that module A and module B cannot be running simultaneously; otherwise, a conflict will occur. Dependency constraints are a set of rules regarding the startup and running order of service modules, used to ensure the correctness of inter-module collaboration.

[0053] The system reads the dependency list of each service module stored in the module registry repository. Based on these dependency lists, it analyzes and identifies strong dependencies, weak dependencies, and mutual exclusion dependencies between modules. For example, the navigation module might declare a strong dependency on the location service and a weak dependency on voice navigation. Based on these identified dependency relationships, a dependency constraint condition containing the startup order and coexistence rules among all modules is generated.

[0054] Step 1023: Based on the running priorities of each service module stored in the module registration repository, determine that the priority of the risk warning module is higher than that of the navigation module, the priority of the risk warning module is higher than that of the voice module, and the priority of the risk warning module is higher than that of the media module, and generate priority constraints.

[0055] In this embodiment, the running priority is a numerical value assigned to each service module to indicate its importance when resources are scarce. The risk warning module is responsible for issuing hazard warnings to the driver, such as collision warnings or fault alerts. The navigation module provides route planning and guidance. The voice module handles voice recognition and voice broadcasting. The media module is responsible for audio and video playback. Priority constraints are rules that define the order of importance among different modules, used to determine the retention of modules when resources are limited.

[0056] The system reads the running priorities of each service module stored in the module registry repository. Based on these priority values, it determines that the risk warning module has a higher priority than the navigation module. The risk warning module also has a higher priority than the voice module. Finally, it determines that the risk warning module has a higher priority than the media module. Based on these priorities, a priority constraint is generated that clearly defines the service retention order between critical and non-critical modules.

[0057] Step 1024: The resource constraints, the dependency constraints, and the priority constraints are collectively used as the runtime constraints.

[0058] In this embodiment of the application, the running constraints are a set of rules generated by the system based on the current resource status, module dependencies and module priorities, which are used to guide the switching of system running states and module management.

[0059] The system merges and encapsulates resource constraints, dependency constraints, and priority constraints. These constraints are then used together as the final runtime constraints to determine the system's operational status and to perform dynamic loading or pruning control.

[0060] This application embodiment quantifies resource parameters, module dependencies, and module priorities into resource constraints, dependency constraints, and priority constraints, which together serve as operational constraints, thereby enabling the system to dynamically and accurately determine its own operational status based on multi-dimensional rules.

[0061] Optionally, step 102 further includes: Step 1025: When the processor utilization rate is lower than the processor utilization high threshold specified by the preset standard, the memory utilization rate is lower than the memory utilization high threshold specified by the preset standard, the message queue length is lower than the queue length congestion threshold specified by the preset standard, the display link status is higher than the display link degradation threshold specified by the preset standard, and the communication link status is higher than the communication link degradation threshold specified by the preset standard, the system operating state is determined as the complete operating state.

[0062] In this embodiment, processor utilization is the proportion of time the processor is processing tasks out of the total time, reflecting the processor's workload. Memory utilization is the proportion of currently used memory capacity out of the total memory capacity, reflecting memory scarcity. Message queue length is the number of messages waiting to be processed in the queue, reflecting message processing congestion. Display link status indicates the current working condition of the link, such as normal or degraded. Communication link status indicates the current working condition of the communication link, such as normal or degraded. Preset criteria are a pre-defined set of values ​​or conditions used to evaluate resource status. High processor utilization threshold is the highest allowed value for processor utilization as defined in the preset criteria. High memory utilization threshold is the highest allowed value for memory utilization as defined in the preset criteria. Queue length congestion threshold is the highest allowed value for message queue length as defined in the preset criteria. Display link degradation threshold is the lowest allowed value for displaying link status as defined in the preset criteria. Communication link degradation threshold is the lowest allowed value for communication link status as defined in the preset criteria. Running status is the current running mode. Full running state is a running state where resources are sufficient to run all authorized target modules.

[0063] The system acquires five resource parameters: processor utilization, memory utilization, message queue length, displayed link status, and communication link status. Each of these parameters is compared to its corresponding threshold in a preset standard. Specifically, it checks whether the processor utilization is below the high threshold, the memory utilization is below the high threshold, the message queue length is below the queue length congestion threshold, the displayed link status is above the displayed link degradation threshold, and the communication link status is above the communication link degradation threshold. Only when all five conditions are simultaneously met is the current running state determined to be the complete running state.

[0064] Step 1026: When the processor utilization rate is higher than the processor utilization high threshold specified by the preset standard, or the memory utilization rate is higher than the memory utilization high threshold specified by the preset standard, or the message queue length is higher than the queue length congestion threshold specified by the preset standard, or the display link status is lower than the display link degradation threshold specified by the preset standard, or the communication link status is lower than the communication link degradation threshold specified by the preset standard, the system operating state is determined to be the restricted operating state.

[0065] In this embodiment, five resource parameters are acquired: processor utilization, memory utilization, message queue length, display link status, and communication link status. These five parameters are then compared one by one with corresponding thresholds in a preset standard. It is determined whether the processor utilization is higher than the high processor utilization threshold, the memory utilization is higher than the high memory utilization threshold, the message queue length is higher than the queue length congestion threshold, the display link status is lower than the display link degradation threshold, and the communication link status is lower than the communication link degradation threshold. If any one or more of these five conditions are met, the current operating state is determined to be a restricted operating state.

[0066] Step 1027: When the processor utilization rate recovers from above the high threshold of processor utilization specified by the preset standard to below the low threshold of processor utilization, and the memory utilization rate recovers from above the high threshold of memory utilization to below the low threshold of memory utilization, and the message queue length decreases to below the queue length congestion threshold, and the display link status recovers to above the display link degradation threshold, and the communication link status recovers to above the communication link degradation threshold, the system operating state is determined to be the recovered operating state.

[0067] In this embodiment, the system acquires five resource parameters: processor utilization, memory utilization, message queue length, display link status, and communication link status. These five parameters are then compared one by one with the corresponding thresholds in a preset standard. The system determines whether the processor utilization has recovered from above the high threshold to below the low threshold, whether the memory utilization has recovered from above the high threshold to below the low threshold, whether the message queue length has decreased to below the queue length congestion threshold, whether the display link status has recovered to above the display link degradation threshold, and whether the communication link status has recovered to above the communication link degradation threshold. Only when all five conditions are simultaneously met is the current operating state determined to be the recovered operating state.

[0068] This application embodiment dynamically divides the system operating state into a complete operating state, a restricted operating state, and a recovery operating state by comparing the processor utilization rate, memory utilization rate, message queue length, display link status, and communication link status with the thresholds in the preset standard. This enables the system to automatically switch operating modes according to real-time resource conditions, thereby providing full functionality when resources are sufficient, prioritizing critical functions when resources are limited, and orderly restoring non-critical functions after resources are restored.

[0069] Optionally, step 103 includes: Step 1031: In the complete running state, perform topological sorting on all authorized target service modules according to the strong dependencies in the module dependency relationship, and load all authorized target service modules in sequence according to the topological sorting result.

[0070] In this embodiment, the complete running state is a running state in which the system, with sufficient resources and all dependencies satisfied, carries all authorized target service modules. Module dependencies are the associations between service modules in function calls or data exchanges. Strong dependencies mean that one module must depend on another module to start and run normally; if the dependent module is unavailable, the dependent module cannot start. Topological sorting is an algorithm for linearly sorting the vertices of a directed acyclic graph. In the system context, it is used to determine the loading order of service modules, ensuring that all strongly dependent modules of a module are loaded before that module. All authorized target service modules are the set of all service modules that the system determines need to be loaded and run based on vehicle model configuration and user authorization.

[0071] When the system determines that it is currently in a fully running state, it reads the module definition files of all authorized target service modules and extracts a list of strong dependencies for each module. Based on these strong dependencies, a directed acyclic graph (DAG) is constructed, where each node represents a service module and each directed edge represents a strong dependency. Subsequently, a topological sorting algorithm is performed on this dependency graph to generate a loading order list that satisfies dependency constraints, ensuring that all strongly dependent modules of any module are already loaded or running before it is loaded. According to this topological sorting result, pre-validation, loading, initialization, interface registration, and health checks are performed sequentially on each service module in the list until all authorized target service modules have successfully entered the running state.

[0072] Step 1032: Under the restricted operating state, mark the risk warning module and the diagnostic module as non-removable modules according to the module priority, identify at least one non-critical module according to the weak dependency relationship in the module dependency relationship, the non-critical module includes media module, multi-window interface module and high resource consumption animation module, disable the non-critical module and release the processor resources and memory resources occupied by the non-critical module.

[0073] In this embodiment, the restricted operating state is a system state in which critical modules are retained and at least one non-critical module is disabled when resources are limited or links are degraded. Module priority is a pre-defined importance level for each service module, used to determine the order of module retention or removal in case of resource conflicts. The risk warning module is a service module responsible for sending vehicle risk warning information to the driver, such as collision warnings and abnormal tire pressure warnings. The diagnostic module is a service module responsible for detecting and analyzing the system's own operating status, the health status of each module, and communication links. A non-removable module is a service module whose availability must be guaranteed and cannot be disabled when resources are limited or a failure occurs. A weak dependency is a type of module dependency, indicating that the dependency of one module on another is non-mandatory; if the dependent module is unavailable, the dependent module can still operate in a degraded manner or have some functions affected but not necessarily crash. Non-critical modules are service modules that, relative to critical modules such as risk warnings and diagnostics, can be preferentially disabled to release resources when resources are scarce. Processor resources refer to the computing power of the central processing unit, including processing time and the number of cores. Memory resources refer to the storage space of random access memory.

[0074] When the system determines that it is currently in a restricted operating state, it queries the priority configuration of all service modules and marks the risk warning module and diagnostic module as non-removable modules. It iterates through all loaded service modules and, based on the list of weak dependencies in their module definition files, identifies service modules that only depend on weak dependencies and are not critical modules, such as media modules, multi-window interface modules, and resource-intensive animation modules, and defines them as non-critical modules. It then performs a shutdown operation, unloading instances of these non-critical modules and reclaiming the processor and memory resources they occupy. Throughout this process, it ensures that the risk warning module and diagnostic module remain running and are unaffected by resource release operations.

[0075] Step 1033: In the restored running state, the disabled modules are restored sequentially in reverse order of their original loading order according to the strong dependencies in the module dependency relationship.

[0076] In this embodiment, restoring the running state refers to restoring previously disabled modules to their current running state according to their dependency order after resource recovery or anomaly elimination. Strong dependencies are relationships between service modules in terms of function calls or data exchange, indicating that one module must depend on another to start and run normally. Disabled modules are service modules that were actively unloaded or stopped under restricted running conditions. The original loading order is the order in which all modules are initially loaded, determined by a topological sorting algorithm in the complete running state.

[0077] When the system detects that resources have been restored or the anomaly that caused it to enter the restricted running state has been eliminated, and thus enters the restored running state, it first retrieves the list of previously disabled modules. It then queries the module definition files of these disabled modules to obtain their strong dependencies. Based on these strong dependencies and the original loading order recorded in the full running state, it calculates the restoration loading order. This order is the reverse of the original loading order; that is, the last disabled module is restored first, while ensuring that all its strongly dependent modules are running before a module is restored. Following this reverse order, it sequentially performs loading, initialization, interface registration, and health checks on each disabled module, bringing it back to the running state.

[0078] This application embodiment dynamically switches between full running state, restricted running state, and restored running state according to the resource status, and performs topology sorting loading, critical module protection and non-critical module pruning, and reverse order restoration operations respectively. This allows for dynamic adjustment of the system function set when resources change, prioritizing the availability of critical security functions, and orderly restoring all functions after resource recovery.

[0079] Optionally, step 104 includes: Step 1041: Before performing the update operation on the module to be updated, save the pre-update version image, pre-update running configuration, and pre-update state summary of the module to be updated to the rollback storage area specified by the preset standard.

[0080] In this embodiment, the module to be updated is an independently packaged service unit that needs to be upgraded, such as a navigation module, voice module, or media module. The pre-update version image is an exact copy of the complete executable package of the module to be updated before the update operation begins. The pre-update runtime configuration is a collection of all parameter settings and runtime environment variables used by the module to be updated before the update. The pre-update state summary is a brief record of key runtime state information of the module to be updated before the update, such as its current working mode or cached data snapshot. Predefined standards are a series of predefined rules or specifications used to guide the update operation process and parameters. The rollback storage area is a dedicated independent storage space in the system used to securely save pre-update data for recovery in case of update failure.

[0081] Before executing the update operation, the system first copies and saves the complete pre-update version image of the module to be updated, its current pre-update running configuration, and a summary of its key running states to the rollback storage area specified by preset criteria. This operation ensures that even if any unexpected events occur during the update process, there is a complete and consistent recovery point that can be used to restore the module to its original state before the update.

[0082] Step 1042: Perform digital signature verification and hash value verification on the obtained target update package. After the verification is successful, create a sandbox running instance for the module to be updated.

[0083] In this embodiment, the target update package is a set of new version program files obtained through a network or local storage medium, used to replace the module to be updated. Digital signature verification is a security verification process used to confirm whether the source of the target update package is trustworthy and whether its content has been tampered with during transmission. Hash value verification is another integrity verification process, which calculates the hash value of the target update package and compares it with the hash value provided by the official source to confirm that the file has not been corrupted or modified. The sandbox runtime instance is an isolated, temporary runtime environment in which the target update package is loaded and tested without affecting the normal operation of other parts.

[0084] After data backup is complete, the system performs digital signature verification and hash value verification on the acquired target update package to ensure that the update package's source is trustworthy, its content is complete, and it has not been tampered with. Once both verifications pass, a sandbox runtime instance is created for the module to be updated. In this sandbox environment, the content of the target update package is loaded, and it is provided with an independent, isolated runtime space to facilitate subsequent compatibility and stability testing.

[0085] Step 1043: Perform interface availability detection, resource usage detection, and heartbeat detection on the sandbox running instance. If the interface availability detection returns a failure, or the resource usage detection exceeds the sandbox resource threshold specified by the preset standard, or the number of consecutive failures of the heartbeat detection exceeds the heartbeat failure number threshold specified by the preset standard, the update is determined to have failed.

[0086] In this embodiment, interface availability testing is a process of testing the connectivity and responsiveness of all service interfaces provided by the sandbox instance to ensure that the new version module can be called normally by other parts. Resource usage testing is a process of monitoring the consumption of resources such as CPU and memory by the sandbox instance during operation. Heartbeat testing is a process of periodically sending check signals to the sandbox instance and waiting for its response to determine whether the instance is still running normally and has not deadlocked or crashed. The sandbox resource threshold is the upper limit of resource usage set for the sandbox instance in the preset standard. The heartbeat failure threshold is the maximum number of consecutive heartbeat failures allowed as specified in the preset standard.

[0087] After the sandbox instance is created and started, the system sequentially performs interface availability checks, resource usage checks, and heartbeat checks on the instance. If the interface availability check fails, it indicates that the interface of the new version module cannot function properly; if the resource usage check result exceeds the sandbox resource threshold specified by the preset standard, it indicates that the resource requirements of the new version module exceed the acceptable range; if the number of consecutive heartbeat check failures exceeds the heartbeat failure count threshold specified by the preset standard, it indicates that the new version module may have crashed or entered an infinite loop. If any of the above conditions occur, the update is deemed a failure.

[0088] Step 1044: Read the pre-update version image, the pre-update running configuration, and the pre-update state summary from the rollback storage area, roll back the module to be updated to the pre-update version, and restore the service binding relationship between the module to be updated and the service bus.

[0089] In this embodiment, the rollback storage area is a dedicated independent storage space for securely storing data from before the update, enabling recovery in case of update failure. The pre-update version image is an exact copy of the complete executable package of the module to be updated before the update operation begins. The pre-update runtime configuration is a collection of all parameter settings and runtime environment variables used by the module to be updated before the update. The pre-update state summary is a brief record of key runtime state information of the module to be updated before the update. The service bus is a unified channel for message communication and interface calls among all service modules in the system. The service binding relationship is the connection information, such as the interface address and communication protocol, registered by the module to be updated on the service bus.

[0090] When the system determines that an update has failed, it immediately performs a rollback operation. It reads the previously saved pre-update version image, pre-update runtime configuration, and pre-update state summary from the rollback storage area. Then, it uses this data to replace the current module to be updated with its pre-update version, restoring all its pre-update configuration and runtime state. Finally, it restores the service binding relationship between the module to be updated and the service bus, enabling the module to be rediscovered and invoked by other parts, thus restoring it to its stable runtime state before the update.

[0091] This application embodiment improves the reliability and maintainability of online upgrades for two-wheeled vehicle cockpit systems by using methods such as data backup before updates, update package verification, sandbox testing, and rollback after failure.

[0092] Optionally, step 104 further includes: Step 1045: The lifecycle manager monitors the heartbeat reporting events and abnormal reporting events of each service module. When no heartbeat reporting event of the first service module is received within the heartbeat timeout threshold specified by the preset standard, the first service module is marked as an abnormal module.

[0093] In this embodiment, the lifecycle manager is a management component responsible for managing the state transitions of each service module throughout its entire lifecycle, from discovery to termination. A service module is a functional unit that can be independently encapsulated, loaded, and updated, such as a navigation module or a voice module. A heartbeat reporting event is a signal periodically sent by a service module to indicate its normal operating status. An anomaly reporting event is a signal sent by a service module to indicate an anomaly when it detects an error or fault. The heartbeat timeout threshold is a preset time limit used to determine whether a service module has stopped sending heartbeat signals due to a fault. The first service module is a specific service module with a unique identifier that is monitored in the system. An abnormal module is a service module that is determined to have malfunctioned or lost response.

[0094] The system continuously monitors heartbeat and anomaly reporting events for all registered service modules through a lifecycle manager. When the lifecycle manager detects that no heartbeat reporting event has been received from a specific service module within the preset heartbeat timeout threshold, it determines that the first service module has become unresponsive or has experienced a serious failure. Based on this determination, the first service module is marked as an abnormal module.

[0095] Step 1046: Send an unbinding command to the service bus to remove all interface bindings between the abnormal module and the service bus, and migrate the state of the abnormal module to the isolation state.

[0096] In this embodiment, the service bus is the core channel providing unified message distribution, interface addressing, and communication for all service modules. The unbinding command is a control command issued to sever all communication connections between the faulty module and the service bus. Interface binding relationships are the interface connections registered by the service module on the service bus for data interaction with other modules. The isolation state is a special operating state set for the faulty module, in which communication with other parts is cut off to prevent the fault from propagating.

[0097] After marking the first service module as an abnormal module, the system immediately sends an unbinding command to the service bus. Upon receiving this command, the service bus executes the operation to remove all interface bindings between the abnormal module and the service bus. After the interface unbinding is completed, the abnormal module's state is transitioned from its previous running state to an isolated state. In this way, the abnormal module is completely isolated from other normal parts, preventing its failure from affecting the operation of other critical modules.

[0098] Step 1047: Call the stop interface and uninstall interface of the abnormal module, and reload the initial image of the abnormal module. After the reload is completed, the state of the abnormal module is transferred to the running state.

[0099] In this embodiment, the stop interface is a standard API call provided by the service module to instruct the system to stop its operation. The uninstall interface is a standard API call provided by the service module to instruct the system to remove it from the runtime environment. The initial image is a complete file copy containing all its code and configuration, saved when the service module is initially installed or deployed. Reloading is the process by which the system redeploys the initial image of the faulty module to the runtime environment. The running state is the state in which the service module is running normally and providing services.

[0100] After isolating the faulty module, the system attempts to restore it. The system calls the module's stop interface to command it to halt its current running process. Then, it calls the module's uninstall interface to completely remove it from the runtime environment. Next, it obtains the module's initial image and reloads it into the runtime environment. After reloading, the restored service module's state is transitioned from isolated to running, allowing it to resume providing normal service.

[0101] Step 1048: Keep the risk event detection and alarm output functions of the risk warning module available, keep the abnormal event detection and log recording functions of the diagnostic module available, keep the basic instrument display function available, keep the message distribution and interface addressing functions of the service bus available, and keep the state transition control function of the lifecycle manager available.

[0102] In this embodiment, the risk warning module is a key functional module specifically responsible for detecting driving risks and issuing alarms, and it has the highest priority. The risk event detection and alarm output function is the core function of the risk warning module, used to identify dangerous situations and issue warnings. The diagnostic module is a key functional module responsible for recording and analyzing abnormal operational events. The abnormal event detection and log recording function is the core function of the diagnostic module, used to detect faults and record logs. The basic instrument display function provides the most basic interface functions for displaying key information such as vehicle speed and battery level. The message distribution and interface addressing function is the basic core function of the service bus, ensuring smooth communication between modules. The state transition control function is the core function of the lifecycle manager, used to manage the state transitions of modules.

[0103] During system operation, regardless of whether other modules experience anomalies or are in recovery mode, the risk event detection and alarm output functions of the risk warning module and the anomaly detection and logging functions of the diagnostic module are always ensured to be available. Simultaneously, the basic instrument display functions remain available to ensure the driver can obtain the most basic driving information. Furthermore, the message distribution and interface addressing functions of the service bus remain available to maintain the basic communication channels between modules. Finally, the state transition control function of the lifecycle manager remains available for continuous management of module states. Through these measures, the core safety and basic functions are guaranteed to continue operating normally even when some modules fail.

[0104] This application embodiment achieves effective limitation of fault propagation, rapid service recovery, and continuous output of core security functions when a module fails by systematically detecting, isolating, recovering, and keeping critical functions alive.

[0105] Based on the foregoing embodiments, this application provides a cockpit system control device for a two-wheeled vehicle. The device includes various units and modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0106] Figure 2 A schematic diagram of the composition structure of a cockpit system control device for a two-wheeled vehicle provided in this application embodiment is shown below. Figure 2 As shown, the cockpit system control device 20 of the two-wheeled vehicle includes: The acquisition module 201 is used to acquire system resource parameters, which include at least three of the following: processor utilization rate, memory utilization rate, message queue length, display link status, and communication link status. The processing module 202 is used to construct operating constraints based on the system resource parameters and module dependencies, and determine the system operating state according to the operating constraints. The system operating state includes a complete operating state, a restricted operating state, and a recovery operating state. Control module 203 is used to perform dynamic loading or pruning control according to module priority and module dependency relationship under different operating states; When a module update fails, a version rollback and service binding recovery are performed. In case of an anomaly, module isolation is performed, and the abnormal module is restarted to keep the system running.

[0107] Optionally, the acquisition module 201 is further configured to: The processor utilization rate is calculated by reading the processor timestamp difference in the operating system process control block through the resource monitor according to the sampling period specified by the preset standard; The ratio of allocated heap memory to total heap memory is obtained through the heap memory allocator interface, and the memory occupancy rate is calculated. The message queue length is obtained by reading the number of queue nodes of messages to be processed in the message middleware; The display link status is obtained by comparing the timeout count of the vertical synchronization signal returned by the display driver layer with the display link health threshold specified by a preset standard. The communication link status is obtained by comparing the cyclic redundancy check error frame count in the communication controller with the communication link health threshold specified by a preset standard.

[0108] Optionally, the processing module 202 is further configured to: The processor utilization rate is compared with the high and low processor utilization thresholds specified by the preset standard; the memory utilization rate is compared with the high and low memory utilization thresholds specified by the preset standard; the message queue length is compared with the queue length congestion threshold specified by the preset standard; the displayed link status is compared with the displayed link degradation threshold specified by the preset standard; and the communication link status is compared with the communication link degradation threshold specified by the preset standard to generate resource constraints. Based on the dependency list of each service module stored in the module registration repository, identify strong dependencies, weak dependencies, and mutual exclusion dependencies, and generate dependency constraints. Based on the running priorities of each service module stored in the module registration repository, the priority of the risk warning module is determined to be higher than that of the navigation module, higher than that of the voice module, and higher than that of the media module, and priority constraints are generated. The resource constraints, the dependency constraints, and the priority constraints are collectively used as the runtime constraints.

[0109] Optionally, the processing module 202 is further configured to: When the processor utilization rate is lower than the processor utilization high threshold specified by the preset standard, the memory utilization rate is lower than the memory utilization high threshold specified by the preset standard, the message queue length is lower than the queue length congestion threshold specified by the preset standard, the display link status is higher than the display link degradation threshold specified by the preset standard, and the communication link status is higher than the communication link degradation threshold specified by the preset standard, the system operating state is determined to be the complete operating state.

[0110] When the processor utilization rate is higher than the processor utilization high threshold specified by the preset standard, or the memory utilization rate is higher than the memory utilization high threshold specified by the preset standard, or the message queue length is higher than the queue length congestion threshold specified by the preset standard, or the display link status is lower than the display link degradation threshold specified by the preset standard, or the communication link status is lower than the communication link degradation threshold specified by the preset standard, the system operating state is determined to be the restricted operating state.

[0111] When the processor utilization rate recovers from above the high threshold of processor utilization specified by the preset standard to below the low threshold of processor utilization, and the memory utilization rate recovers from above the high threshold of memory utilization to below the low threshold of memory utilization, and the message queue length decreases to below the queue length congestion threshold, and the display link status recovers to above the display link degradation threshold, and the communication link status recovers to above the communication link degradation threshold, the system operating state is determined to be the recovered operating state.

[0112] Optionally, the control module 203 is further configured to: In the complete running state, a topological sort is performed on all authorized target service modules according to the strong dependencies in the module dependency relationship, and all authorized target service modules are loaded in sequence according to the topological sort result; Under the restricted operating state, the risk warning module and the diagnosis module are marked as non-removable modules according to the module priority. At least one non-critical module is identified according to the weak dependency relationship in the module dependency relationship. The non-critical module includes the media module, the multi-window interface module and the high resource consumption animation module. The non-critical module is disabled and the processor resources and memory resources occupied by the non-critical module are released. In the restored running state, the disabled modules are restored sequentially in reverse order of their original loading order, according to the strong dependencies in the module dependency relationship.

[0113] Optionally, the control module 203 is further configured to: Before performing an update operation on the module to be updated, the update manager saves the pre-update version image, pre-update running configuration, and pre-update state summary of the module to be updated to the rollback storage area specified by the preset standard. The update manager performs digital signature verification and hash value verification on the obtained target update package. After the verification is successful, a sandbox running instance is created for the module to be updated. The update manager performs interface availability detection, resource usage detection, and heartbeat detection on the sandbox running instance. When the interface availability detection returns failure, or the resource usage detection exceeds the sandbox resource threshold specified by the preset standard, or the number of consecutive failures of the heartbeat detection exceeds the heartbeat failure number threshold specified by the preset standard, the update is determined to be failed. The update manager reads the pre-update version image, the pre-update running configuration, and the pre-update state summary from the rollback storage area, rolls the module to be updated back to the pre-update version, and restores the service binding relationship between the module to be updated and the service bus.

[0114] Optionally, the control module 203 is further configured to: The lifecycle manager monitors the heartbeat reporting events and abnormal reporting events of each service module. When no heartbeat reporting event is received from the first service module within the heartbeat timeout threshold specified by the preset standard, the first service module is marked as an abnormal module. The lifecycle manager sends an unbinding command to the service bus to remove all interface bindings between the abnormal module and the service bus, and migrates the state of the abnormal module to the isolation state. The lifecycle manager calls the stop and uninstall interfaces of the abnormal module, reloads the initial image of the abnormal module, and after the reload is completed, migrates the state of the abnormal module to the running state. Keep the risk event detection and alarm output functions of the risk warning module, the abnormal event detection and log recording functions of the diagnostic module, the basic instrument display functions, the message distribution and interface addressing functions of the service bus, and the state transition control functions of the lifecycle manager available.

[0115] This application embodiment collects resource parameters and constructs constraints to dynamically determine the operating status, then performs dynamic loading or pruning control according to priority and dependency, and performs rollback, recovery and isolation operations when update fails or anomalies occur, thereby improving the safety, continuity and maintainability of the two-wheeled vehicle cockpit system under resource-constrained, upgrade maintenance and abnormal scenarios.

[0116] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0117] It should be noted that, in the embodiments of this application, if the above-described cockpit system control method for two-wheeled vehicles is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0118] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0119] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0120] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0121] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0122] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0123] It should be noted that, Figure 3 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 3 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0124] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0125] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 700 includes one or more cores.

[0126] It should be noted that the computer device may include multiple processors 701, and each processor 701 can interact with each other through aggregated communication methods such as all-to-all, all-gather, or all-reduce. The processors 701 may be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors may also be single-core or multi-core processors. The processor may consist of a CPU and hardware chips. The hardware chips may be ASICs, PLDs, or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0127] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0128] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0129] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0130] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0131] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0133] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0134] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0135] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0136] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0137] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for controlling the cockpit system of a two-wheeled vehicle, characterized in that, The method includes: Collect system resource parameters, which include at least three of the following: processor utilization, memory utilization, message queue length, display link status, and communication link status; Based on the system resource parameters and module dependencies, operational constraints are constructed, and the system operating state is determined according to the operational constraints. The system operating state includes a complete operating state, a restricted operating state, and a recovery operating state. Dynamic loading or pruning control is performed based on module priority and module dependencies under different operating states; When a module update fails, a version rollback and service binding recovery are performed. In case of an anomaly, module isolation is performed, and the abnormal module is restarted to keep the system running.

2. The method according to claim 1, characterized in that, The resource parameters of the acquisition system include: The processor utilization rate is calculated by reading the processor timestamp difference in the operating system process control block through the resource monitor according to the sampling period specified by the preset standard; The ratio of allocated heap memory to total heap memory is obtained through the heap memory allocator interface, and the memory occupancy rate is calculated. The message queue length is obtained by reading the number of queue nodes of messages to be processed in the message middleware; The display link status is obtained by comparing the timeout count of the vertical synchronization signal returned by the display driver layer with the display link health threshold specified by a preset standard. The communication link status is obtained by comparing the cyclic redundancy check error frame count in the communication controller with the communication link health threshold specified by a preset standard.

3. The method according to claim 1, characterized in that, The construction of runtime constraints based on the system resource parameters and module dependencies includes: The processor utilization rate is compared with the high and low processor utilization thresholds specified by the preset standard; the memory utilization rate is compared with the high and low memory utilization thresholds specified by the preset standard; the message queue length is compared with the queue length congestion threshold specified by the preset standard; the displayed link status is compared with the displayed link degradation threshold specified by the preset standard; and the communication link status is compared with the communication link degradation threshold specified by the preset standard to generate resource constraints. Based on the dependency list of each service module stored in the module registration repository, identify strong dependencies, weak dependencies, and mutual exclusion dependencies, and generate dependency constraints. Based on the running priorities of each service module stored in the module registration repository, the priority of the risk warning module is determined to be higher than that of the navigation module, higher than that of the voice module, and higher than that of the media module, and priority constraints are generated. The resource constraints, the dependency constraints, and the priority constraints are collectively used as the runtime constraints.

4. The method according to claim 1, characterized in that, Determining the system operating state based on the operating constraints includes: When the processor utilization rate is lower than the processor utilization high threshold specified by the preset standard, the memory utilization rate is lower than the memory utilization high threshold specified by the preset standard, the message queue length is lower than the queue length congestion threshold specified by the preset standard, the display link status is higher than the display link degradation threshold specified by the preset standard, and the communication link status is higher than the communication link degradation threshold specified by the preset standard, the system operating state is determined to be the complete operating state. When the processor utilization rate is higher than the processor utilization high threshold specified by the preset standard, or the memory utilization rate is higher than the memory utilization high threshold specified by the preset standard, or the message queue length is higher than the queue length congestion threshold specified by the preset standard, or the display link status is lower than the display link degradation threshold specified by the preset standard, or the communication link status is lower than the communication link degradation threshold specified by the preset standard, the system operating state is determined to be the restricted operating state. When the processor utilization rate recovers from above the high threshold of processor utilization specified by the preset standard to below the low threshold of processor utilization, and the memory utilization rate recovers from above the high threshold of memory utilization to below the low threshold of memory utilization, and the message queue length decreases to below the queue length congestion threshold, and the display link status recovers to above the display link degradation threshold, and the communication link status recovers to above the communication link degradation threshold, the system operating state is determined to be the recovered operating state.

5. The method according to claim 1, characterized in that, The dynamic loading or pruning control based on module priority and module dependencies under different operating states includes: In the complete running state, a topological sort is performed on all authorized target service modules according to the strong dependencies in the module dependency relationship, and all authorized target service modules are loaded in sequence according to the topological sort result; Under the restricted operating state, the risk warning module and the diagnosis module are marked as non-removable modules according to the module priority. At least one non-critical module is identified according to the weak dependency relationship in the module dependency relationship. The non-critical module includes the media module, the multi-window interface module and the high resource consumption animation module. The non-critical module is disabled and the processor resources and memory resources occupied by the non-critical module are released. In the restored running state, the disabled modules are restored sequentially in reverse order of their original loading order, according to the strong dependencies in the module dependency relationship.

6. The method according to claim 1, characterized in that, The process of performing version rollback and service binding recovery when a module update fails includes: Before performing an update operation on the module to be updated, the update manager saves the pre-update version image, pre-update running configuration, and pre-update state summary of the module to be updated to the rollback storage area specified by the preset standard. The update manager performs digital signature verification and hash value verification on the obtained target update package. After the verification is successful, a sandbox running instance is created for the module to be updated. The update manager performs interface availability detection, resource usage detection, and heartbeat detection on the sandbox running instance. When the interface availability detection returns failure, or the resource usage detection exceeds the sandbox resource threshold specified by the preset standard, or the number of consecutive failures of the heartbeat detection exceeds the heartbeat failure number threshold specified by the preset standard, the update is determined to be failed. The update manager reads the pre-update version image, the pre-update running configuration, and the pre-update state summary from the rollback storage area, rolls the module to be updated back to the pre-update version, and restores the service binding relationship between the module to be updated and the service bus.

7. The method according to claim 1, characterized in that, The method of performing module isolation and restarting the faulty module to maintain system operation under abnormal conditions includes: The lifecycle manager monitors the heartbeat reporting events and abnormal reporting events of each service module. When no heartbeat reporting event is received from the first service module within the heartbeat timeout threshold specified by the preset standard, the first service module is marked as an abnormal module. The lifecycle manager sends an unbinding command to the service bus to remove all interface bindings between the abnormal module and the service bus, and migrates the state of the abnormal module to the isolation state. The lifecycle manager calls the stop and uninstall interfaces of the abnormal module, reloads the initial image of the abnormal module, and after the reload is completed, migrates the state of the abnormal module to the running state. Keep the risk event detection and alarm output functions of the risk warning module, the abnormal event detection and log recording functions of the diagnostic module, the basic instrument display functions, the message distribution and interface addressing functions of the service bus, and the state transition control functions of the lifecycle manager available.

8. A cockpit system control device for a two-wheeled vehicle, characterized in that, The device includes: The acquisition module is used to acquire system resource parameters, which include at least three of the following: processor utilization, memory utilization, message queue length, display link status, and communication link status. The processing module is used to construct operating constraints based on the system resource parameters and module dependencies, and determine the system operating state according to the operating constraints. The system operating state includes a complete operating state, a restricted operating state, and a recovery operating state. The control module is used to perform dynamic loading or pruning control based on module priority and module dependencies under different operating states; When a module update fails, a version rollback and service binding recovery are performed. In case of an anomaly, module isolation is performed, and the abnormal module is restarted to keep the system running.

9. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the cockpit system control method for a two-wheeled vehicle according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps in the cockpit system control method for a two-wheeled vehicle according to any one of claims 1 to 7.

Images