A method and system for controlling a constrained drive lightweight cabin operating system

Abstract

The present application relates to the technical field of two-wheeled vehicle operation system and vehicle-mounted software platform, and discloses a kind of restraint drive lightweight cabin operation system control method and system.The method collects processor occupancy, memory occupancy, service bus delay, task queue length and power fluctuation parameters, calculates resource constraint value after normalization, limiting and filtering;Determine the operating state according to double threshold hysteresis rule;In limited operating state, according to the cutting score and module dependency graph, the loadable module is executed dynamically cut, and the service bus queue quota and congestion control are adjusted synchronously;When application exception, isolate target application and non-mandatory reserved associated services, only rebuild the conversation or message subscription relationship for mandatory reserved services, maintain lightweight kernel, device abstraction layer, minimum display link and basic service link operation and execute local restart.The present application is used to improve the stability of key display link and message dispatch under limited resource conditions.

Description

Technical Field

[0001] This invention relates to the field of two-wheeled vehicle operating systems and in-vehicle software platforms, and in particular to a constraint-driven lightweight cockpit operating system control method and system suitable for resource-constrained scenarios of motorcycles or electric two-wheeled vehicles.

[0002] More specifically, this invention integrates resource constraint functions, dual-threshold state machines, score-based dynamic pruning, hierarchical message bus scheduling, and local anomaly isolation and recovery into a unified closed-loop control mechanism to solve the problem of stable operation of two-wheeled vehicle cockpit platforms under limited computing power, limited storage, power supply fluctuations, and high vibration environments. Background Technology

[0003] Existing in-vehicle cockpit operating systems are typically designed for high processor computing power, large memory capacity, and sufficient heat dissipation. On automotive platforms, they can achieve rich human-computer interaction functions through complex graphics frameworks, large middleware, and multi-process models.

[0004] However, two-wheeled vehicle platforms generally use low-to-medium power SoCs, with typical memory capacities ranging from 512MB to 2GB and flash memory capacities ranging from 4GB to 32GB. Furthermore, their operating environment is characterized by frequent power-on / off cycles, instantaneous voltage fluctuations, continuous vibration, rain exposure, and thermal variations. Directly porting heavy-duty cockpit software to two-wheeled vehicles can easily lead to problems such as excessively long startup times, high peak memory usage, bus message congestion, abnormal diffusion of single modules, and instability in critical instrument display links.

[0005] While existing technologies offer various implementation methods such as task priority scheduling, service communication, module pruning, and process isolation, most of them rely on static architecture descriptions or single-function optimizations. They lack a complete control loop that uses calculable resource constraints as its core, drives system state switching and coordinates pruning, message scheduling, and local anomaly isolation and recovery.

[0006] Especially in the scenario of two-wheeled vehicles, if a fixed on / off strategy is still used to determine which modules are enabled, which messages are retained, and how to recover after an anomaly, it is easy to cause state oscillations, untimely recovery, and non-critical services competing for critical resources in actual road conditions, affecting the continuous display of riding safety-related information. Summary of the Invention

[0007] The purpose of this invention is to provide a constraint-driven lightweight cockpit operating system control method and system for two-wheeled vehicles. The system uses the resource constraint value C(k) as the core control variable and unifies dynamic pruning, queue scheduling, and local anomaly isolation and recovery into the same control link through a dual-threshold state machine, thereby improving the startup determinism, message latency determinism, and anomaly localization processing capabilities on a limited resource platform.

[0008] To achieve the above objectives, the present invention proposes the following technical solution: within the sampling window, processor utilization, memory utilization, service bus latency, task queue length, power fluctuation amplitude, and optional flash memory utilization, graphics buffer utilization, and service load value are collected; after normalizing and filtering the above parameters, the resource constraint value C(k) is calculated, and the system is determined to be in a complete running state, a restricted running state, or a restored running state based on the relationship between C(k) and the dual thresholds T1, T2 and the continuous sampling periods N1, N2, N3.

[0009] This invention provides a constraint-driven lightweight cockpit operating system control method, which is applied to a lightweight cockpit operating system for two-wheeled vehicles. The method includes the following steps:

[0010] S1: Collect system resource parameters of the cockpit operating system according to the preset sampling window. The system resource parameters include at least processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters.

[0011] S2: Normalize the system resource parameters to obtain a normalized resource vector, and use a preset weighted constraint function to calculate the normalized resource vector to obtain resource constraint values;

[0012] S3: Compare the resource constraint value with a preset double threshold, and combine the number of sampling windows in which the resource constraint value continuously satisfies the preset double threshold condition to determine the operating state of the cockpit operating system. The operating state includes a complete operating state, a restricted operating state, and a restored operating state.

[0013] S4: When the running state switches to the restricted running state, a pruning score is calculated for each loadable module in the system. The loadable module is a functional module that can be unloaded, paused, disabled, have its refresh frequency reduced, or have its message injection stopped during runtime, except for the minimum display link and the basic service link. The minimum display link includes at least the instrument application, display device driver, graphics buffer management module, instrument refresh service, and risk warning display service. The basic service link includes at least the service bus core module, permission service module, resource monitoring module, and anomaly capture module. Combined with the pre-built module dependency graph, dynamic pruning is performed on each loadable module in order of pruning score from low to high. At the same time, according to the running state, the scheduling quotas and congestion control strategies of the high-priority queue, medium-priority queue, and low-priority queue in the service bus are adjusted synchronously.

[0014] S5: Monitor the running status of each application in real time. When an abnormal event such as crash, freeze or illegal resource access is detected in an application other than the modules or services in the minimum display link and the basic service link, the abnormal application is taken as the target application, and the target application and its associated services are transferred to the local abnormal isolation and recovery process.

[0015] Preferably, in step S2, the normalization processing of the system resource parameters to obtain a normalized resource vector specifically includes: dividing the processor utilization rate, the memory utilization rate, the service bus latency, the task queue length, and the power fluctuation parameter by their respective reference upper limits, and then limiting the resulting ratios to obtain normalized components x_cpu, x_mem, x_bus, x_queue, and x_pwr, with values ​​ranging from 0 to 1; wherein x_cpu represents the normalized value of the processor utilization rate, x_mem represents the normalized value of the memory utilization rate, x_bus represents the normalized value of the service bus latency, x_queue represents the normalized value of the task queue length, and x_pwr represents the normalized value of the power fluctuation parameter, and the normalized resource vector is composed of the above-mentioned normalized components.

[0016] Preferably, in step S2, the normalized resource vector is calculated using a preset weighted constraint function to obtain the resource constraint value. Specifically, the calculation is performed according to the following constraint function: C(k) = w1·x_cpu(k) + w2·x_mem(k) + w3·x_bus(k) + w4·x_queue(k) + w5·x_pwr(k), where C(k) represents the resource constraint value of the k-th sampling window; w1, w2, w3, w4, and w5 are non-negative preset weight coefficients, and satisfy w1 + w2 + w3 + w4 + w5 = 1.

[0017] Preferably, before calculating the resource constraint value, the method further includes performing a moving average filter or an exponential smoothing filter on at least one of the normalized components.

[0018] Preferably, the preset dual thresholds include a first threshold and a second threshold that is less than the first threshold; in step S3, the determination of the operating state of the cockpit operating system adopts the following dual threshold hysteresis judgment rule: when the system is in a complete operating state or a recovery operating state, and the resource constraint value is greater than or equal to the first threshold for a first preset number of sampling windows, the system switches to the restricted operating state; when the system is in a restricted operating state, and the resource constraint value is less than or equal to the second threshold for a second preset number of sampling windows, the system switches to the recovery operating state; when the system is in the recovery operating state, and after the trimmed module completes recovery according to a preset recovery order, the resource constraint value is still less than or equal to the second threshold for a third preset number of sampling windows, the system switches to the complete operating state.

[0019] Preferably, in step S4, for the i-th loadable module, its corresponding trimming score is calculated according to the following formula: CutScore_i = α·Pri_i + β·Dep_i + γ·Rec_i - δ·Rel_i, where CutScore_i represents the trimming score of the i-th loadable module, and the trimming score is a ranking index used to determine the trimming order; Pri_i represents the business priority level, Dep_i represents the dependency retention level in the module dependency graph, Rec_i represents the recovery cost level, and Rel_i represents the releasable level. The normalized value of the resource quantity is used; Pri_i, Dep_i, Rec_i, and Rel_i all range from 0 to 1. A larger Pri_i indicates a higher business priority, a larger Dep_i indicates a higher degree of retention of dependence on critical links, a larger Rec_i indicates a higher recovery cost, and a larger Rel_i indicates a larger amount of resources that can be released by pruning the module; α, β, γ, and δ are all preset weight coefficients greater than 0, and satisfy α+β+γ+δ=1; a smaller CutScore_i indicates that the corresponding loadable module will be pruned more preferentially in subsequent dynamic pruning.

[0020] Preferably, the step of performing dynamic pruning on each loadable module according to the pruning score in ascending order specifically includes: selecting modules or groups of modules to be pruned in ascending order of the pruning score; the pruning includes at least one runtime processing action among unloading, pausing, disabling, reducing refresh frequency, or stopping message injection; after each pruning is completed, the current resource constraint value is recalculated until the current resource constraint value is lower than a preset pruning exit threshold, or the candidate loadable module set is exhausted; wherein, the pruning exit threshold is less than the first threshold and greater than or equal to the second threshold.

[0021] Preferably, the module dependency graph includes multiple module nodes and service nodes, and records the forward dependencies between the module nodes and service nodes. These forward dependencies at least cover the module nodes and service nodes in the instrument display link, basic navigation link, basic voice link, permission service link, and log link. During the dynamic pruning process, the minimum display link and basic service link are forcibly retained. The minimum display link includes at least the instrument application, display device driver, graphics buffer management module, instrument refresh service, and risk warning display service. The basic service link includes at least the service bus core module, permission service module, resource monitoring module, and anomaly capture module. The loadable modules do not include the instrument application, display device driver, graphics buffer management module, instrument refresh service, and risk warning display service in the minimum display link, nor do they include the service bus core module, permission service module, resource monitoring module, and anomaly capture module in the basic service link.

[0022] Preferably, the step of synchronously adjusting the scheduling quotas and congestion control strategies of high-priority queues, medium-priority queues, and low-priority queues in the service bus according to the operating state specifically includes: configuring corresponding token quotas or distribution shares for the high-priority queues, medium-priority queues, and low-priority queues in each scheduling window according to the current operating state, and configuring at least one congestion control strategy among backpressure control, rate limiting control, tail discarding control, or oldest message discarding control according to the queue length.

[0023] Preferably, under the restricted operating state, the adjustment strategy for each queue specifically includes: increasing the scheduling share of the high-priority queue and decreasing the scheduling share of the low-priority queue; when the number of messages to be dispatched in the high-priority queue is greater than a preset congestion threshold, limiting the injection rate of low-priority messages into the low-priority queue, and / or performing tail-drop control or oldest-message-drop control on the cached messages in the low-priority queue.

[0024] Preferably, the service bus adopts the following message mapping rules: instrument refresh messages, risk warning messages, and input event messages are mapped to the high-priority queue; navigation guidance messages, voice control messages, and Bluetooth management messages are mapped to the medium-priority queue; and media status synchronization messages, log upload messages, and background statistics messages are mapped to the low-priority queue.

[0025] This invention provides a constraint-driven lightweight cockpit operating system control system, comprising: an application layer, a service bus layer, a device abstraction layer, and a lightweight kernel and constraint control layer; wherein: the lightweight kernel and constraint control layer is used to collect system resource parameters according to a preset sampling window, calculate resource constraint values, execute state machine judgment based on preset dual thresholds to determine the operating state, and trigger dynamic pruning and local anomaly isolation and recovery; the service bus layer is used to establish high-priority queues, medium-priority queues, and low-priority queues, and adjust the scheduling share and congestion control strategy of each queue according to the operating state; the device abstraction layer is used to uniformly manage display devices, audio devices, Bluetooth devices, positioning devices, button devices, network devices, and storage devices; the application layer is used to load and run instrument applications, navigation applications, voice applications, media applications, settings applications, and communication applications.

[0026] Preferably, the lightweight kernel and constraint control layer specifically include: a fixed priority preemptive scheduling module, a time-slice round-robin scheduling module, a resource monitoring module, a constraint calculation module, a state machine control module, a watchdog module, and an exception capture module.

[0027] Preferably, the lightweight kernel and constraint control layer further includes a strategy engine and a dependency graph storage module; the strategy engine is used to read the priority level, dependency retention level, recovery cost level and releasable resource quantity parameters of the module to calculate the pruning score used to guide the dynamic pruning.

[0028] The beneficial effects of this invention are: when conventional vehicle-mounted systems are ported to two-wheeled vehicle platforms where computing power and storage are limited, they are highly susceptible to interface freezing or system crashes due to sudden high loads or power supply fluctuations. This invention breaks through the traditional crude static module shutdown or one-size-fits-all process killing strategies, and constructs an adaptive degradation and isolation recovery architecture with resource constraints as the control core.

[0029] The solution transforms multi-dimensional underlying resource parameters into unified quantitative indicators. Combined with a dual-threshold hysteresis judgment mechanism, it effectively filters out false judgments caused by transient hardware fluctuations, preventing system state oscillations near critical loads. When resource constraints are detected, the system performs gradual service stripping with fallback protection based on a dynamic scoring system that includes business priority, dependency relationships, and recovery costs, while simultaneously allocating bus scheduling quotas to high-priority queues. This mechanism, while orderly releasing memory and reducing bus load, preserves the computing power and message dispatching capabilities required for the minimum display links and basic service links from a control logic perspective.

[0030] Furthermore, for sudden scenarios such as single application crashes or unauthorized access, this invention employs a sandbox-based context freezing and partial restart strategy to isolate the fault within the smallest service unit. This design avoids the risk of a system-wide restart caused by non-critical module anomalies, helps ensure the persistent operation of the lightweight kernel and the minimum display link, and reduces the risk of basic interaction interruptions on low-spec hardware platforms under extreme conditions. Attached Figure Description

[0031] Figure 1 This is a layered architecture diagram of the constraint-driven lightweight cockpit operating system of the present invention.

[0032] Figure 2 This is a flowchart of the present invention. Detailed Implementation

[0033] The inventive concept of this invention will be described below.

[0034] Due to cost, power consumption, and heat dissipation limitations, two-wheeled vehicle cockpit hardware platforms typically employ low-to-mid-range SoCs with limited memory and storage space. Furthermore, they are subject to frequent power-on / off cycles, transient voltage fluctuations, and continuous physical vibrations during operation. Directly adopting an automotive cockpit operating system can easily lead to slow startup, lag in critical instrument information, or system-level restarts due to complex process communication and high resource consumption. To address these issues, this implementation constructs a closed-loop control mechanism based on resource constraints: First, processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters are collected and normalized, limited, and filtered to calculate resource constraints. Then, a dual-threshold hysteresis rule is used to determine the complete running state, restricted running state, and recovery running state. When entering the restricted running state, the loadable modules are progressively pruned based on pruning scores and module dependency graphs, while simultaneously adjusting service bus queue quotas and congestion control strategies. When a single application crashes, freezes, or experiences illegal resource access, a partial restart is performed through sandbox isolation and associated service location, while maintaining the continuous operation of the lightweight kernel, device abstraction layer, and minimum display link. The aforementioned control chain establishes a clear execution order and feedback relationship between resource monitoring, status determination, module pruning, message scheduling, and local anomaly isolation and recovery.

[0035] The meanings of the English abbreviations and letters used in this implementation are explained below.

[0036] In this embodiment, SoC represents System-on-a-Chip, CPU represents Central Processing Unit, MEM represents Memory, BUS represents Service Bus, QUEUE represents Task Queue, PWR represents Power Supply, and API represents Application Programming Interface. CPU-related metrics primarily refer to processor utilization or processor resource usage status; MEM-related metrics primarily refer to memory utilization; BUS-related metrics primarily refer to Service Bus latency; QUEUE-related metrics primarily refer to Task Queue length; and PWR-related metrics primarily refer to power supply fluctuation parameters. P95 latency represents the 95th percentile Service Bus message dispatch latency within the sampling window, and P99 latency represents the 99th percentile Service Bus message dispatch latency within the sampling window. MB and GB represent megabytes and gigabytes, respectively, and ms represents milliseconds.

[0037] W represents the sampling window, k represents the sampling window number, and C(k) represents the resource constraint value of the k-th sampling window; w1, w2, w3, w4, and w5 represent the weighting coefficients corresponding to processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters, respectively; x_cpu, x_mem, x_bus, x_queue, and x_pwr represent the normalized values ​​of processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters, respectively; in an optional implementation, x_flash, x_gbuf, and x_srv represent the normalized values ​​of flash memory utilization, graphics buffer utilization, and service load value, respectively, wherein the service load value can be a statistical value obtained by normalizing at least one of the following within the sampling window: service call count, service processing time, service thread utilization, or service request queue count, according to a preset statistical caliber.

[0038] CutScore_i represents the trimming score of the i-th loadable module, where i represents the loadable module number; Pri_i represents the business priority level of the i-th loadable module, Dep_i represents the dependency retention level of the i-th loadable module, Rec_i represents the recovery cost level of the i-th loadable module, and Rel_i represents the normalized value of the releaseable resources of the i-th loadable module; α, β, γ, and δ represent the weight coefficients corresponding to Pri_i, Dep_i, Rec_i, and Rel_i, respectively. Qh represents the high-priority queue, Qm represents the medium-priority queue, and Ql represents the low-priority queue; Lh represents the high-priority queue congestion threshold; Nr represents the repeated crash threshold for the same application within a single ignition cycle.

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments, but the scope of protection of the present invention is not limited to the following embodiments. Equivalent substitutions without substantial changes should fall within the scope of protection of the present invention.

[0040] The cockpit operating system in this embodiment consists of an application layer, a service bus layer, a device abstraction layer, and a lightweight kernel and constraint control layer. The application layer includes instrument, navigation, voice, media, settings, and communication applications; the service bus layer includes a message bus, permission service, log service, and upgrade control module, and is used to provide message dispatch status and queue status to the resource monitoring module; the device abstraction layer includes drivers for display, audio, Bluetooth, positioning, buttons, network, and storage devices; the lightweight kernel and constraint control layer includes a fixed-priority preemptive scheduling module, a time-slice round-robin scheduling module, a resource monitoring module, a constraint calculation module, a state machine control module, a policy engine, a dependency graph storage module, a watchdog module, and an exception handling module.

[0041] In this implementation, the permission policy is generated by the policy engine based on the application's identity, application service type, current running state, module dependency graph, and anomaly isolation status. Specifically, in the full running state, the permission service module grants display, audio, Bluetooth, location, network, and log access permissions to each application according to the application's preset permission table; in the restricted running state, the permission service module restricts non-critical applications' access to audio, Bluetooth, network, and log resources, and prioritizes retaining the permissions required by the meter application, risk warning display service, service bus core module, resource monitoring module, and anomaly capture module; when an anomaly occurs in a target application, the permission service module revokes or freezes the target application's relevant access permissions, and retains only the necessary permissions for local anomaly isolation recovery and minimum display link operation.

[0042] In this embodiment, the minimum display link includes at least the instrument application, display device driver, graphics buffer management module, instrument refresh service, and risk warning display service; the basic service link includes at least the service bus core module, permission service module, resource monitoring module, and anomaly capture module; the associated service refers to a service that has process communication dependency, permission call dependency, display output dependency, or resource sharing dependency with the target application in the service dependency table or module dependency graph, and does not include modules or services in the minimum display link and basic service link that are subject to mandatory retention. When there is a display session, message subscription, permission binding, or resource sharing relationship between the target application and the mandatory retention service, only the connection state, session state, or message subscription relationship on the target application side is rebuilt, and the mandatory retention service is not restarted.

[0043] In this embodiment, the limiting processing refers to taking 0 when the ratio value is less than 0, taking 1 when the ratio value is greater than 1, and maintaining the ratio value when the ratio value is between 0 and 1; the preset ignition cycle refers to the operating cycle of the two-wheeled vehicle from the start of a power-on or ignition to the end of the current power-off or shutdown.

[0044] In this embodiment, the power fluctuation parameter is the difference between the maximum and minimum power supply voltage within the sampling window, the maximum deviation ratio of the power supply voltage relative to the rated voltage within the sampling window, or a combination of the above two; the reference upper limit value is an upper limit value pre-calibrated for each system resource parameter, used to map the corresponding parameter to a normalized component in the range of 0 to 1.

[0045] For example, the reference upper limit for processor utilization can be 100%, the reference upper limit for memory utilization can be 100%, the reference upper limit for service bus latency can be 100ms, the reference upper limit for task queue length can be 64 messages, and the reference upper limit for power fluctuation parameters can be 20% of the rated voltage. The above values ​​are only examples, and different two-wheeled vehicle platforms can be calibrated according to SoC performance, memory capacity, power supply system, and bus implementation.

[0046] In this embodiment, the service bus latency is any one of the preset statistical methods, such as the average latency, maximum latency, P95 latency, or P99 latency, from the time a message enters the service bus to the time it is dispatched within the sampling window, and it remains consistent within the same vehicle configuration; the task queue length is any one of the preset statistical methods, such as the maximum value of the length of each scheduling queue within the sampling window, the weighted sum, or the length of the high-priority queue.

[0047] In this embodiment, the pruning is a runtime processing action, including at least one of the following: unloading, pausing, disabling, reducing refresh frequency, reducing background task execution frequency, or stopping message injection into the service bus; the freezing is determined by at least one of the following: application heartbeat timeout, main thread unresponsiveness, watchdog timeout, or multiple consecutive sampling windows failing to complete status reporting; the illegal resource access is determined by at least one of the following: permission service intercepting unauthorized API calls, unauthorized device handle access, out-of-bounds storage access, or unauthorized service bus topic access.

[0048] In this embodiment, the loadable modules are functional modules that, apart from the minimum display link and the basic service link, can be unloaded, paused, disabled, have their refresh frequency reduced, their background task execution frequency reduced, or their message injection into the service bus stopped during runtime. The loadable modules do not include the instrument application, display device driver, graphics buffer management module, instrument refresh service, and risk warning display service in the minimum display link, nor do they include the service bus core module, permission service module, resource monitoring module, and anomaly capture module in the basic service link. These modules are forcibly retained during dynamic pruning to ensure the continuous display of cycling safety-related information and anomaly recovery capabilities.

[0049] The system uses a sampling window W as its basic control cycle. Within each sampling window, a resource monitoring module located in the lightweight kernel and constraint control layer collects processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters, and performs normalization processing. For transient jitter common in two-wheeled vehicle platforms, a moving average filter can be applied to processor utilization, bus latency, and queue length to reduce misjudgments caused by short-term spikes.

[0050] In this embodiment, the sampling window W can be 100ms, the preferred weighting coefficients are w1=0.30, w2=0.30, w3=0.15, w4=0.15, w5=0.10, the preferred dual thresholds are T1=0.72, T2=0.58, and the preferred number of consecutive sampling periods is N1=3, N2=5, N3=3. These values ​​are merely examples and can be calibrated based on the hardware configuration and functional objectives of different vehicle models. In this embodiment, the high-priority queue congestion threshold Lh can be 32 messages, and the repeated crash threshold Nr for the same application within a single ignition cycle can be 3 times. These values ​​are also merely examples and can be calibrated based on the hardware configuration, service bus implementation method, and system security strategy of different vehicle models.

[0051] The aforementioned weighting coefficients w1, w2, w3, w4, and w5 were obtained through factory calibration of the target two-wheeled vehicle platform, rather than arbitrary empirical values. Specifically, during the calibration phase, the cockpit operating system was run under various conditions, including instrument display, navigation guidance, voice interaction, media playback, log uploading, background statistics, and power fluctuation simulation. Processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters were collected within different sampling windows. Simultaneously, instrument refresh latency, high-priority message dispatch latency, application stuttering times, and local anomaly recovery times were recorded. For each system resource parameter, the impact of its increase on critical display link latency, service bus congestion, and system recovery stability was statistically analyzed, and the normalized impact levels were used as the basis for determining the corresponding weighting coefficients. In the two-wheeled vehicle platform corresponding to this embodiment, the processor utilization rate and memory utilization rate have a high impact on the risk of system lag and restart. The service bus latency and task queue length have a secondary impact on the determinism of message dispatch. The power fluctuation parameter is used as a condition correction item in the vehicle operating environment. Therefore, w1 and w2 are calibrated to 0.30, w3 and w4 are calibrated to 0.15, and w5 is calibrated to 0.10.

[0052] The aforementioned first threshold T1 and second threshold T2 are obtained through the operational condition distribution calibration of the resource constraint value C(k). Specifically, C(k) within a continuous sampling window is calculated under complete operating conditions, critical high-load conditions, and abnormal load conditions. The C(k) interval corresponding to the start of sustained latency degradation in critical display links, the start of bus congestion caused by low-priority messages, or a significant increase in the probability of application lag is designated as the restricted operating state interval, and the first threshold T1 is determined accordingly. The C(k) interval corresponding to the continuous and stable operation of critical display links, service bus dispatch, and basic service links after system pruning or load reduction is designated as the recovery judgment interval, and the second threshold T2 is determined accordingly. A hysteresis interval is set between T1 and T2 to avoid frequent switching between complete operating state, restricted operating state, and recovery operating state caused by vehicle vibration, instantaneous power fluctuations, or short-term task spikes. In the platform sample corresponding to this embodiment, when C(k) reaches around 0.72, the high-priority message dispatch latency and instrument refresh latency begin to rise continuously; when C(k) falls back to below 0.58, the system can stably restore the pruned modules and maintain the operation of critical links. Therefore, T1=0.72 and T2=0.58 are preferred. For different vehicle models or different hardware configurations, the values ​​of w1-w5, T1, and T2 can be re-determined according to the above calibration process.

[0053] For example, on a low-configuration platform, when the normalized values ​​of x_cpu=0.80, x_mem=0.85, x_bus=0.70, x_queue=0.60, and x_pwr=0.40, we obtain C(k)=0.73. If this result is greater than or equal to T1 for three consecutive sampling windows, the system switches to a restricted operating state.

[0054] Once the system enters restricted operation mode, the policy engine reads the business priority level, dependency retention level, recovery cost level, and amount of releasable resources for each module, and calculates the pruning order of candidate modules according to the CutScore. Modules with higher business priority, higher dependency level, and higher recovery cost typically have a larger CutScore; modules with a larger amount of releasable resources typically have a smaller CutScore.

[0055] In this embodiment, CutScore is a pruning ranking metric rather than a physical quantity of resource consumption. When the amount of releasable resources Rel_i is large, CutScore may take a negative value, but this value is only used to sort relative to the CutScore of other candidate modules and does not affect the rule of executing dynamic pruning in ascending order.

[0056] In this embodiment, Pri_i can be determined by the service type to which the module belongs, with modules related to meter display, risk warning, and input events configured as high priority, and modules related to media, logs, and background statistics configured as low priority; Dep_i can be determined based on whether the module is located in the minimum display link, basic service link, or critical service front path in the module dependency graph, with modules located in the critical path taking a higher value; Rec_i can be obtained by normalizing the module's restart time, context recovery data volume, and recovery failure impact range; Rel_i can be obtained by normalizing at least one of the following: memory capacity released after trimming the module, CPU utilization decrease, and service bus message injection decrease. The above parameters can be pre-stored in the module resource profile table and read by the policy engine when entering the restricted running state.

[0057] For example, the instrument application, risk warning display service, and service bus core module belong to the minimum display link or basic service link and are not included in the pruning candidate set as mandatory retention objects; the media service, multi-window interface, and log visualization module can be included in the pruning candidate set according to their business priority, dependency retention level, recovery cost level, and amount of releasable resources, and will be processed by unloading, pausing, disabling, reducing refresh frequency, or stopping message injection in order of pruning score from low to high.

[0058] In this embodiment, dynamic pruning does not shut down all non-critical modules at once. Instead, candidate modules are selected sequentially from low to high based on CutScore, and C(k) is recalculated after each memory release, task reduction, or bus load reduction. If C(k) still does not meet the exit condition, the next candidate module is processed, thus making the control process gradual and reversible.

[0059] To prevent cascading effects on critical services, the dependency graph records the prerequisite dependencies between modules. For example, a multi-window interface depends on a graphics composition component and a window management component; media services depend on a decoding component and a buffering service; and basic navigation depends on a location service, a map service, and a display service. During dynamic trimming, if removing a candidate module would disrupt the minimum display link or the basic service link, that module is skipped, and the next candidate module is selected.

[0060] The service bus layer employs a high-priority queue Qh, a medium-priority queue Qm, and a low-priority queue Ql. In the full runtime state, the focus is on functional integrity; in the constrained runtime state, the focus is on the deterministic latency of critical messages; and in the recovery runtime state, the scheduling share of low-priority services is restored in stages. For example, when the queue length of Qh exceeds the threshold Lh, the system first limits the injection rate of new low-priority messages; if congestion persists, the oldest messages are discarded from Ql to prevent log uploads, media state synchronization, or background statistical tasks from continuously consuming bus bandwidth.

[0061] For local anomaly isolation and recovery, this embodiment uses an independent sandbox environment to run each application. If an application crashes, freezes, or accesses unauthorized resources, the anomaly capture module first freezes its scheduling context and records the fault information. Then, it locates its associated services based on the service dependency table and only restarts the abnormal application and its non-mandatory-retained associated services. If there is a display session, message subscription, permission binding, or resource sharing relationship between the abnormal application and the mandatory-retained service, only the connection state, session state, or message subscription relationship on the abnormal application side is rebuilt, and the mandatory-retained service is not restarted. At this time, the lightweight kernel, device abstraction layer, and minimal display link continue to run to reduce the risk of interruption of instrument display and risk warning.

[0062] In full operational mode, the service bus layer can configure the scheduling shares of high-priority queue Qh, medium-priority queue Qm, and low-priority queue Ql in a 5:3:2 ratio to balance the dispatch of critical messages and ordinary business messages. In restricted operational mode, the system can adjust the above scheduling shares to 7:2:1 and implement backpressure, rate limiting, or oldest message discarding control for low-priority messages, thereby prioritizing the dispatch of instrument refresh messages, risk warning messages, and input event messages. In recovery operational mode, the system can gradually restore the scheduling shares to 5:3:2 and gradually increase the injection rate of low-priority messages.

[0063] After the abnormal application recovers, the system recalculates C(k). If C(k) is still higher than T1 after recovery, the restricted running state is maintained and the pruning result is preserved. If C(k) is less than or equal to T2 for N2 consecutive sampling windows after recovery, the system enters the recovery running state from the restricted running state. In the recovery running state, if C(k) is still less than or equal to T2 for N3 consecutive sampling windows after the pruned module completes recovery according to the preset recovery order, the system switches to the full running state.

[0064] If the same application crashes multiple times in a single ignition cycle, and the number of crashes is greater than or equal to Nr, the system will mark the application as disabled for the current ignition cycle, retaining only core services related to riding safety and basic human-computer interaction, in order to avoid resource fluctuations and user-perceived jitter caused by repeated recovery.

[0065] In a specific example, on a platform with 1024MB of memory and 16GB of flash memory, the system loads the kernel layer, device abstraction layer, and service bus layer in budgeted order, followed by instrumentation, basic navigation, basic voice, and then media and multi-window interface. Since C(k) is less than or equal to T2, the system remains in full running state, allowing background logging and statistics services to run at full-state quotas.

[0066] In another specific example, a platform with 512MB of RAM and 8GB of flash memory, under combined conditions of high temperature and frequent navigation refreshes, experienced C(k) exceeding T1 for three consecutive sampling windows, causing the system to switch to a restricted operating state. The policy engine first pruned the multi-window interface and media backend, then paused log visualization; simultaneously, it adjusted the queue scheduling share to 7:2:1, ensuring that dashboard refreshes and risk alert messages still received priority.

[0067] After the aforementioned low-configuration platform returns to normal operation, if C(k) is less than or equal to T2 for five consecutive sampling windows, the system enters recovery mode. In recovery mode, all modules are not reloaded at once; instead, the log service is restored first, followed by the media service based on remaining resources, and finally, a decision is made based on the actual configuration whether to restore the multi-window interface.

[0068] Therefore, it can be seen that the present invention organizes multiple existing scattered functions into a technical solution with clear causal links and control sequences by linking constraint functions, state machines, pruning scoring, queue scheduling and local anomaly isolation and recovery. This is more suitable for expressing the engineering implementation of a lightweight cockpit operating system for two-wheeled vehicles under resource boundary conditions.

[0069] Combination Figure 1 As shown, the constraint-driven lightweight cockpit operating system adopts a layered design in its overall architecture, consisting of an application layer 510, a service bus layer 520, a device abstraction layer 530, and a lightweight kernel and constraint control layer 540 from top to bottom. These four layers, combined with independently acquired constraint parameter inputs, constitute the basic operating framework for the system to implement constraint-driven control.

[0070] In response to external environment and system status, the system acquires various constraint parameters in real time as input conditions, specifically covering processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters. These constraint parameter inputs directly interface with various levels of the system, providing a data foundation for subsequent dynamic allocation and status determination.

[0071] Regarding the specific functional module configurations at each level:

[0072] The application layer 510 deploys interactive and business functions for end users, and is configured with meter applications, basic navigation, basic voice, media services, multi-window interface, and settings and communication applications.

[0073] The service bus layer 520 provides cross-process communication and system-level message dispatch capabilities, integrates message bus, permission service, log service and upgrade control module internally, and provides message dispatch status and queue status to the resource monitoring module in the lightweight kernel and constraint control layer 540.

[0074] The Device Abstraction Layer 530 is used to perform standardized encapsulation of the underlying heterogeneous hardware, establish a unified abstract model including display, audio, Bluetooth, positioning, buttons, network, storage and helmet interface, and shield the implementation differences of the underlying physical hardware.

[0075] The lightweight kernel and constraint control layer 540 serve as the underlying foundation, carrying the core resource allocation algorithm and system state transition. It includes a built-in strategy engine, dependency graph storage module, hybrid scheduling, constraint function calculation, dual threshold state machine, pruning decision, exception handling, and watchdog and recovery control unit.

[0076] The following describes the specific process of constraint value calculation and the transition logic of the dual-threshold state machine driven by the constraint value.

[0077] On the system parameter acquisition side, resource parameter sampling is first performed on the current underlying operating indicators. The sampling monitoring dimensions cover processor utilization (CPU), memory utilization (MEM), service bus latency (BUS), task queue length (QUEUE), and power fluctuation parameters (PWR). The acquired heterogeneous raw parameters then enter the data preprocessing stage. After normalization and filtering, the dimensional differences are eliminated and high-frequency noise is filtered out, and the data is converted into a normalized component sequence (x_cpu to x_pwr) that is uniformly recognized by the system.

[0078] The constraint function calculation unit receives the above normalized components and applies a linear weighted algorithm (specifically expressed as the equation C(k) = w1·x_cpu + w2·x_mem + w3·x_bus + w4·x_queue + w5·x_pwr) to output a resource constraint value C(k) that comprehensively represents the current hardware load boundary of the system. This constraint value is then sent to the comparison and determination node as the core basis for state determination.

[0079] When optional monitoring items such as flash memory utilization, graphics buffer utilization, or service load are enabled, the constraint function calculation unit can normalize them into x_flash, x_gbuf, and x_srv respectively, and add them to a linear weighting function with non-negative weights; the weights of optional monitoring items that are not enabled are 0, thereby ensuring that the calculation of the resource constraint value C(k) is consistent with the actual collected resource parameters.

[0080] At the state machine control level, the system constructs a dual-threshold hysteresis decision rule by pre-setting an entry threshold T1 for restricted operating state and an exit and recovery threshold T2 for restricted operating state, thereby managing the transition between three discrete system states. When the system is in a complete operating state or a recovered operating state, and C(k) is greater than or equal to T1 for N1 consecutive sampling windows, the system switches to the restricted operating state to perform subsequent resource degradation or isolation actions.

[0081] In the constrained operating state, if successful resource recovery causes the constraint value to fall back, and C(k) is less than or equal to T2 for N2 consecutive sampling windows, the system state transitions to the recovery operating state. During the gradual reload of the pruned modules in the recovery operating state, the system continuously feeds back the real-time resource status to the preceding constraint function calculation stage for dynamic verification. When C(k) remains less than or equal to T2 for N3 consecutive sampling windows after the reload is completed, the system switches to the full operating state. This dual-threshold hysteresis mechanism utilizes the numerical difference between T1 and T2 to form a dead zone, reducing the impact of data glitches caused by instantaneous sensor or power supply fluctuations under complex vehicle operating conditions, and ensuring the deterministic state switching of the cockpit operating system under resource boundary conditions.

[0082] The following section explains the system's dynamic pruning control logic, which includes the calculation of pruning scores, the determination of dependency retention, and the final sorting and decision output.

[0083] During the evaluation phase, the trimming score calculation module obtains the trimming score input factors for each candidate module, specifically including: Pri_i representing the business priority level, Dep_i representing the dependency retention level, Rec_i representing the recovery cost level, and Rel_i representing the normalized value of the amount of resources that can be released. The values ​​of Pri_i, Dep_i, Rec_i, and Rel_i all range from 0 to 1, with larger values ​​for Pri_i, Dep_i, and Rec_i indicating less pruning potential, and larger values ​​for Rel_i indicating greater resource release benefits from trimming the module. This calculation module performs a weighted calculation on the above input factors according to the formula CutScore_i = α·Pri_i + β·Dep_i + γ·Rec_i - δ·Rel_i, where α, β, γ, and δ are preset weight coefficients greater than 0 and summing to 1, resulting in a trimming score CutScore_i for each module. Subsequently, the candidate modules are sorted in ascending order of this score, with smaller CutScore_i indicating a higher priority for trimming the corresponding candidate module.

[0084] In this embodiment, the service priority level Pri_i and dependency retention level Dep_i characterize the impact of module pruning on critical display links and basic service links. The recovery cost level Rec_i characterizes the time and resources required to recover after module pruning. The amount of resources that can be released Rel_i characterizes the resource release benefits that can be brought about by pruning the module. Therefore, when the system control objective is to prioritize instrument display, risk warning, and basic message dispatch, α and β are set to higher weights; when the system control objective is to reduce the risk of repeated restarts and recovery failures, γ is set to higher weights; and when the system control objective is to quickly release memory, reduce bus load, or reduce processor utilization, δ is set to higher weights.

[0085] As a specific calibration method, on the target two-wheeled vehicle platform, candidate modules are first classified according to their business security relevance, dependency tightness, recovery time, and resource release benefits. Then, the pruning results are verified against a preset pruning order and the actual pruning effect, ensuring that the pruning results satisfy the following: the minimum display link and basic service link are not pruned; modules with low business priority, low dependency retention level, low recovery cost, and high resource release benefits are prioritized for pruning. In the platform corresponding to this embodiment, α, β, γ, and δ can be preset to 0.35, 0.30, 0.20, and 0.15, respectively. These values ​​give business priority and dependency retention level a high weight in the pruning ranking, while retaining the influence of the amount of releasable resources on the pruning priority. Under different vehicle models, different hardware configurations, or different functional pruning strategies, the values ​​of α, β, γ, and δ can be re-determined according to the above module resource profile table and pruning strategy calibration table, ensuring that α, β, γ, and δ are all greater than 0 and α+β+γ+δ=1.

[0086] α, β, γ, and δ are preset through the module resource profile table and the pruning strategy calibration table. The module resource profile table records at least the service type of each loadable module, whether it is associated with the minimum display link, whether it is associated with the basic service link, the number of prerequisites, restart time, context recovery data volume, freeable memory capacity, reduceable processor utilization, and reduceable service bus message injection volume. After entering the restricted running state, the strategy engine reads the above module resource profile table and determines the relative sizes of α, β, γ, and δ according to the control objectives of the vehicle cockpit system.

[0087] The trimming score is a ranking metric, and its value can be positive, zero, or negative. The system only sorts and filters based on the relative size of the trimming scores of different candidate modules, and does not interpret the absolute value of the trimming score as a physical quantity of actual memory, CPU, or bus load.

[0088] During the sorting and filtering process, the system simultaneously introduces dependency retention rules to constrain the scope of trimming. This rule forces the retention of the minimum display links and basic service links; for basic navigation links, basic voice links, and log links, only the minimum necessary parts related to key displays or basic services are retained, while other enhanced function modules can still enter the candidate trimming sequence based on trimming scores.

[0089] Based on the ranking results of the trimming score and the filtering of dependency retention rules, the system generates corresponding trimming decision outputs. At the execution level, the multi-window interface is prioritized for trimming due to its score or attribute setting, the media backend is placed in a conditional trimming state, and log visualization execution is conditionally paused. Modules belonging to the minimum display link or basic service link, such as the meter refresh service, risk warning display service, and service bus core module, remain running. Enhanced capabilities of basic navigation and basic voice can be downgraded or paused according to the trimming score. When dynamically executing the above trimming decisions, after completing the trimming action of each module, the system recalculates the resource constraint value C(k) and evaluates whether to continue trimming the next module based on the new constraint value, until the conditions for exiting trimming are met.

[0090] Combination Figure 2 As shown, this embodiment provides a constraint-driven lightweight cockpit operating system control method. First, in step S1, the system collects system resource parameters of the cockpit operating system according to a preset sampling window. The system resource parameters include at least processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters.

[0091] Subsequently, in step S2, the collected system resource parameters are normalized to obtain a normalized resource vector, and the normalized resource vector is calculated using a preset weighted constraint function to obtain a resource constraint value that characterizes the current system resource limitation level.

[0092] In step S3, the resource constraint value is compared with a preset dual threshold, and the number of sampling windows in which the resource constraint value continuously meets the threshold conditions is combined to determine whether the cockpit operating system is currently in a complete running state, a restricted running state, or a restored running state.

[0093] When the system operation state switches to the restricted operation state, in step S4, the system calculates the pruning score for each loadable module, and performs dynamic pruning on the loadable modules according to the pruning score order based on the pre-built module dependency graph. At the same time, the system synchronously adjusts the scheduling quotas and congestion control strategies of the high-priority queue, medium-priority queue and low-priority queue in the service bus according to the current operation state, so as to prioritize the operation of critical display and basic service links.

[0094] In step S5, the system monitors the running status of each application in real time. When an abnormal event such as a crash, freeze, or illegal resource access is detected in an application other than a module or service in the minimum display link and basic service link, that application is designated as the target application, and the target application and its associated services are transferred to the local anomaly isolation and recovery process. Through the above steps, the system can maintain the continuous operation of the lightweight kernel, minimum display link, and basic service link even under resource constraints or single application anomalies.

[0095] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. All equivalent substitutions, improvements, and modifications made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A constraint-driven lightweight cockpit operating system control method, characterized in that, The method is applied to a lightweight cockpit operating system for two-wheeled vehicles, and the method includes the following steps: S1: Collect system resource parameters of the cockpit operating system according to the preset sampling window. The system resource parameters include at least processor utilization, memory utilization, service bus latency, task queue length, and power fluctuation parameters. S2: Normalize the system resource parameters to obtain a normalized resource vector, and use a preset weighted constraint function to calculate the normalized resource vector to obtain resource constraint values; S3: Compare the resource constraint value with a preset double threshold, and combine the number of sampling windows in which the resource constraint value continuously satisfies the preset double threshold condition to determine the operating state of the cockpit operating system. The operating state includes a complete operating state, a restricted operating state, and a restored operating state. S4: When the running state switches to the restricted running state, a pruning score is calculated for each loadable module in the system. The loadable module is a functional module that can be unloaded, paused, disabled, have its refresh frequency reduced, or have its message injection stopped during runtime, except for the minimum display link and the basic service link. The minimum display link includes at least the instrument application, display device driver, graphics buffer management module, instrument refresh service, and risk warning display service. The basic service link includes at least the service bus core module, permission service module, resource monitoring module, and anomaly capture module. Combined with the pre-built module dependency graph, dynamic pruning is performed on each loadable module in order of pruning score from low to high. At the same time, according to the running state, the scheduling quotas and congestion control strategies of the high-priority queue, medium-priority queue, and low-priority queue in the service bus are adjusted synchronously. S5: Monitor the running status of each application in real time. When an abnormal event such as crash, freeze or illegal resource access is detected in an application other than the modules or services in the minimum display link and the basic service link, the abnormal application is taken as the target application, and the target application and its associated services are transferred to the local abnormal isolation and recovery process.

2. The constraint-driven lightweight cockpit operating system control method according to claim 1, characterized in that, In step S2, the normalization process of the system resource parameters to obtain a normalized resource vector specifically includes: dividing the processor utilization rate, the memory utilization rate, the service bus latency, the task queue length, and the power fluctuation parameter by their respective reference upper limits, and then limiting the resulting ratios to obtain normalized components x_cpu, x_mem, x_bus, x_queue, and x_pwr, with values ​​ranging from 0 to 1; wherein x_cpu represents the normalized value of the processor utilization rate, x_mem represents the normalized value of the memory utilization rate, x_bus represents the normalized value of the service bus latency, x_queue represents the normalized value of the task queue length, and x_pwr represents the normalized value of the power fluctuation parameter, and the normalized resource vector is composed of the above normalized components.

3. The constraint-driven lightweight cockpit operating system control method according to claim 2, characterized in that, In step S2, the normalized resource vector is calculated using a preset weighted constraint function to obtain the resource constraint value. Specifically, the calculation is performed according to the following constraint function: C(k) = w1·x_cpu(k) + w2·x_mem(k) + w3·x_bus(k) + w4·x_queue(k) + w5·x_pwr(k), where C(k) represents the resource constraint value of the k-th sampling window; w1, w2, w3, w4, and w5 are non-negative preset weight coefficients, and satisfy w1 + w2 + w3 + w4 + w5 = 1.

4. The constraint-driven lightweight cockpit operating system control method according to claim 3, characterized in that, Before calculating the resource constraint value, the method further includes performing a moving average filter or an exponential smoothing filter on at least one of the normalized components.

5. The constraint-driven lightweight cockpit operating system control method according to claim 1, characterized in that, The preset dual thresholds include a first threshold and a second threshold that is less than the first threshold; in step S3, the determination of the operating state of the cockpit operating system adopts the following dual threshold hysteresis judgment rule: when the system is in a complete operating state or a restored operating state, and the resource constraint value is greater than or equal to the first threshold for a first preset number of sampling windows, the system switches to the restricted operating state; When the system is in a restricted operating state, and the resource constraint value is less than or equal to the second threshold for a second preset number of consecutive sampling windows, the system switches to the restored operating state. When the system is in the recovery running state, and the trimmed modules have completed the recovery according to the preset recovery order, if the resource constraint value is still less than or equal to the second threshold for the third consecutive preset number of sampling windows, the system switches to the complete running state.

6. The constraint-driven lightweight cockpit operating system control method according to claim 5, characterized in that, In step S4, for the i-th loadable module, its corresponding trimming score is calculated according to the following formula: CutScore_i = α·Pri_i + β·Dep_i + γ·Rec_i - δ·Rel_i, where CutScore_i represents the trimming score of the i-th loadable module, and the trimming score is a ranking index used to determine the trimming order; Pri_i represents the business priority level, Dep_i represents the dependency retention level in the module dependency graph, Rec_i represents the recovery cost level, and Rel_i represents the releasable resources. The normalized value of the source quantity; Pri_i, Dep_i, Rec_i and Rel_i all range from 0 to 1. The larger Pri_i is, the higher the business priority; the larger Dep_i is, the higher the degree of retention of the dependence on the critical link; the larger Rec_i is, the higher the recovery cost; the larger Rel_i is, the greater the amount of resources that can be released by pruning the module; α, β, γ and δ are all preset weight coefficients greater than 0, and satisfy α+β+γ+δ=1; the smaller CutScore_i is, the higher the priority of the corresponding loadable module in subsequent dynamic pruning.

7. The constraint-driven lightweight cockpit operating system control method according to claim 6, characterized in that, The step of dynamically pruning each loadable module according to the pruning score in ascending order specifically includes: selecting modules or groups of modules to be pruned in ascending order of the pruning score; the pruning includes at least one runtime processing action among unloading, pausing, disabling, reducing refresh frequency, or stopping message injection; after each pruning is completed, the current resource constraint value is recalculated until the current resource constraint value is lower than a preset pruning exit threshold, or the candidate loadable module set is exhausted; wherein, the pruning exit threshold is less than the first threshold and greater than or equal to the second threshold.

8. A constraint-driven lightweight cockpit operating system control system, characterized in that, The system comprises: an application layer, a service bus layer, a device abstraction layer, and a lightweight kernel and constraint control layer; wherein: the lightweight kernel and constraint control layer is used to collect system resource parameters according to a preset sampling window, calculate resource constraint values, execute state machine judgment based on preset dual thresholds to determine the running state, and trigger dynamic pruning and local anomaly isolation and recovery; the service bus layer is used to establish high-priority queues, medium-priority queues, and low-priority queues, and adjust the scheduling share and congestion control strategy of each queue according to the running state; the device abstraction layer is used to uniformly manage display devices, audio devices, Bluetooth devices, positioning devices, button devices, network devices, and storage devices; the application layer is used to load and run instrument applications, navigation applications, voice applications, media applications, settings applications, and communication applications. The constraint-driven lightweight cockpit operating system control system performs the constraint-driven lightweight cockpit operating system control method according to any one of claims 1 to 7.

9. The constraint-driven lightweight cockpit operating system control system according to claim 8, characterized in that, The lightweight kernel and constraint control layer specifically include: a fixed priority preemptive scheduling module, a time-slice round-robin scheduling module, a resource monitoring module, a constraint calculation module, a state machine control module, a watchdog module, and an exception capture module.

10. The constraint-driven lightweight cockpit operating system control system according to claim 8, characterized in that, The lightweight kernel and constraint control layer also include a policy engine and a dependency graph storage module; the policy engine is used to read the priority level, dependency retention level, recovery cost level and releasable resource quantity parameters of the module to calculate the pruning score used to guide the dynamic pruning.

Images