A dual-domain controller task scheduling method and system for two-wheeled vehicles

Abstract

This invention provides a task scheduling method and system for a dual-domain controller in two-wheeled vehicles, relating to the fields of vehicle electronic and electrical architecture and embedded real-time scheduling technology. It addresses the problems of resource contention between safety control tasks and cockpit tasks in high-risk riding scenarios, unauthorized control of power or braking by the cockpit domain, and insufficient safety closed-loop in abnormal states. The method acquires the current vehicle speed, tilt angle change rate, obstacle risk value, and maximum design speed; calculates the risk value and determines the risk level; and dynamically adjusts the control parameters for computing resources and communication resources. The intelligent cockpit domain only generates control requests involving power or braking. The safety control domain performs legality verification based on vehicle constraints. If the verification passes, the control action is executed and the execution result is fed back; if the verification fails, execution is rejected and a rejection response command with a rejection reason code is fed back. This invention is used for safety scheduling and cross-domain control permission management of a dual-domain controller for two-wheeled vehicles.

Description

Technical Field

[0001] This invention relates to the fields of vehicle electronic and electrical architecture, embedded real-time scheduling and functional safety control technology, and in particular to a dual-domain controller task scheduling method and system for two-wheeled vehicles. Background Technology

[0002] Existing two-wheeled vehicles generally employ a single-controller or loosely distributed control architecture, which mixes power control, safety warnings, navigation, voice, and entertainment functions. While this architecture can meet basic requirements under low system load, safety control tasks and non-critical tasks can easily compete for processor, memory, and bus resources during high-speed driving, emergency braking, sudden attitude changes, or high-concurrency cockpit applications, leading to a decrease in control determinism.

[0003] As vehicles become more intelligent, some are adopting dual-domain or multi-domain control architectures to separate safety control functions from information interaction functions. However, existing solutions still generally suffer from the following problems: First, there is a lack of risk modeling methods for two-wheeled vehicle riding scenarios, making it difficult to dynamically adjust dual-domain resources based on vehicle speed, tilt angle change rate, and environmental risks; second, cross-domain control lacks strict permission boundaries, and the cockpit domain may exercise unauthorized control over actions affecting power or braking; third, communication mechanisms typically only handle message transmission and lack a complete closed loop of request, verification, confirmation, execution, and feedback; fourth, anomaly handling and scheduling strategies are disconnected, and in the event of cockpit failure, link packet loss, or safety failure, the system cannot quickly switch to the minimum set of safety functions.

[0004] Existing technologies already include solutions for vehicle domain controllers and cockpit domain controllers. For example, Chinese invention patent application CN113219951A discloses an intelligent cockpit domain controller and its control method for automobiles. This controller connects to body domain controllers, powertrain domain controllers, chassis domain controllers, and ADAS domain controllers, and incorporates signal acquisition and execution modules in each domain controller to reduce redundant information acquisition and improve vehicle information interactivity and reliability. Another example is Chinese invention patent application CN112947235A, which discloses a cockpit domain controller system and its application method based on the X9 platform and Xen technology. This system, by configuring a core processor, MCU chip, and multiple operating systems within the cockpit domain controller, enables multi-system operation, CAN communication, signal acquisition, and multi-screen interaction within the cockpit domain. However, the aforementioned solutions primarily focus on the functional integration, information interaction, and multi-operating system operation of the vehicle cockpit domain controller. They do not establish risk quantification models for easily unstable scenarios such as high-speed driving, rapid changes in tilt angle, and obstacle approach in two-wheeled vehicles. Furthermore, they do not disclose the dynamic adjustment of computing and communication resources between the safety control domain and the intelligent cockpit domain based on vehicle speed, tilt angle change rate, and environmental risks. Simultaneously, these solutions do not explicitly limit the intelligent cockpit domain to only requesting permissions for operations involving vehicle power or braking, with the safety control domain performing legality verification, execution, or rejection and providing feedback. Therefore, existing technologies still struggle to balance cockpit functional scalability and real-time underlying safety control in high-risk riding scenarios for two-wheeled vehicles.

[0005] Therefore, it is necessary to provide a dual-domain controller system architecture and task scheduling method for two-wheeled vehicles to ensure real-time safety control and system robustness while improving functional scalability. Summary of the Invention

[0006] This invention provides a dual-domain controller task scheduling method for two-wheeled vehicles, applied to a dual-domain controller system, the dual-domain controller system including a safety control domain and a smart cockpit domain, the method comprising:

[0007] The current riding status parameters, vehicle preset parameters, and environmental risk parameters of the two-wheeled vehicle are obtained. The current riding status parameters include the current vehicle speed and the rate of change of tilt angle. The vehicle preset parameters include the maximum design speed. The environmental risk parameters include the obstacle risk value.

[0008] Based on the current vehicle speed, the maximum design vehicle speed, the rate of change of tilt angle, and the obstacle risk value, calculate the current risk value of the two-wheeled vehicle;

[0009] The current risk level is determined based on the risk value, and the computational resource control parameters and communication resource control parameters are dynamically adjusted according to the risk level to change the execution priority, execution cycle, task start / stop, resource access quota, communication bandwidth quota, or message transmission cycle of the security control task in the security control domain relative to the non-critical cockpit task in the intelligent cockpit domain. The risk level includes low risk, medium risk, and high risk. A low risk level is defined as the risk value R being less than a first risk threshold; a medium risk level is defined as the risk value R being greater than or equal to the first risk threshold and less than a second risk threshold; and a high risk level is defined as the risk value R being greater than or equal to the second risk threshold. The first risk threshold is less than the second risk threshold.

[0010] The system receives control requests related to vehicle power or braking initiated by the intelligent cockpit domain, and the intelligent cockpit domain only has request permissions for the control requests.

[0011] The safety control domain performs a validity check on the control request based on the current vehicle constraints, which include the current vehicle speed, braking status, fault status, and side support status.

[0012] If the control request meets the current vehicle constraints, the verification is confirmed to be successful. The safety control domain then executes the control action corresponding to the control request and feeds back the execution result, including the execution status of the control action, to the intelligent cockpit domain.

[0013] If the control request does not meet the current vehicle constraints, the verification is determined to fail. The safety control domain refuses to execute the control action corresponding to the control request, generates a rejection response instruction carrying a rejection reason code, and feeds the rejection response instruction back to the smart cockpit domain.

[0014] Preferably, calculating the current risk value of the two-wheeled vehicle includes:

[0015] The risk value R is calculated according to the following formula:

[0016] R=w1·clip(v / Vmax,0,1)+w2·f(|dθ / dt|)+w3·k;

[0017] Where v is the current vehicle speed obtained in real time by the sensor, Vmax is the maximum design speed of the two-wheeled vehicle, clip(v / Vmax, 0, 1) represents the clipping of v / Vmax, taking 0 when v / Vmax is less than 0, taking 1 when v / Vmax is greater than 1, and taking v / Vmax itself when v / Vmax is between 0 and 1; f(|dθ / dt|)=clip(|dθ / dt| / Ωmax, 0, 1) is used to represent the attitude risk factor obtained after normalizing the absolute value of the tilt angle change rate, Ωmax is the preset maximum tilt angle change rate threshold, and the value range of f(|dθ / dt|) is from 0 to 1; k is the obstacle risk value, which is determined based on at least two of the obstacle distance D, relative approach speed Vr, collision time TTC, and target recognition confidence C, and calculated according to the following relationship:

[0018] k=clip[a1·(1-clip(D / Dmax,0,1))+a2·clip(max(Vr,0) / Vrmax,0,1)+a3·(1-clip(TTC / TTCmax,0,1))+a4·C,0,1];

[0019] Wherein, Dmax is the preset maximum perception distance, Vrmax is the preset maximum relative approach speed, TTCmax is the preset maximum collision time threshold, a1, a2, a3, and a4 are non-negative weight coefficients, and the sum of the weight coefficients involved in the calculation is 1; when Vr is positive, it indicates that the obstacle is approaching the two-wheeled vehicle, TTC is determined according to D / max(Vr, ε), and ε is a preset positive number to prevent division by zero; the weight of parameters not involved in the calculation is 0; the smaller the obstacle distance D, the larger the relative approach speed Vr, the smaller the collision time TTC, or the higher the target recognition confidence C, the greater the obstacle risk value k, and k is limited to the range of 0 to 1; w1, w2, and w3 are non-negative preset weight coefficients, and w1+w2+w3=1; θ is the vehicle roll angle; the risk value R ranges from 0 to 1;

[0020] The target recognition confidence level C is output by the environmental perception module of the two-wheeled vehicle based on environmental perception data collected by cameras, millimeter-wave radar, ultrasonic radar, lidar or a combination thereof, after target detection, target classification or multi-sensor fusion recognition of obstacles, and is normalized. The value ranges from 0 to 1. When no valid obstacle is detected, the target recognition confidence level C is 0.

[0021] Preferably, the step of dynamically adjusting the computing resource control parameters and communication resource control parameters according to the risk level includes:

[0022] When the risk value R is greater than or equal to the second risk threshold, or when the current vehicle speed is greater than or equal to a preset vehicle speed threshold:

[0023] Adjust computing resource control parameters, including increasing the thread priority, execution frequency, or continuous processing window of power control, braking control, attitude risk assessment, and legality verification tasks in the safety control domain, and decreasing the execution frequency, resource access quota, or execution priority of navigation refresh, media service, background synchronization, or log upload tasks in the intelligent cockpit domain.

[0024] Freeze or postpone the execution of non-critical cockpit tasks in the smart cockpit domain; and

[0025] Adjust communication resource control parameters, including shortening the transmission cycle of high-priority messages during inter-domain communication, and / or limiting the communication bandwidth, communication rate limiting parameters, or transmission frequency of general service messages;

[0026] The computing resource control parameters include at least one of CPU time slice, thread priority, task execution cycle, continuous processing window, memory access quota, interrupt response priority, task start / stop or task frequency reduction; the communication resource control parameters include at least one of communication bandwidth quota, communication rate limiting parameters, high-priority message sending cycle or general service message sending frequency.

[0027] Preferably, the step of performing a validity check on the control request through the security control domain includes:

[0028] The safety control domain acquires the current vehicle constraints, which include at least the current vehicle speed, braking status, fault status, and side stand status, and also include at least one of the current riding mode, energy recovery level, or vehicle operating status.

[0029] Determine whether the control request satisfies the vehicle constraint conditions;

[0030] The determination of whether the control request meets the vehicle constraint conditions includes at least one of the following: when the vehicle is in motion and the side stand is not retracted, the power output request is rejected; when the vehicle is in a high-speed state or a high tilt angle change rate state, the high-level energy recovery switching request is rejected; when a braking system malfunction is detected, the high-risk riding mode switching request is rejected; when a safety control anomaly is detected and the vehicle enters a safety degradation state, the torque increase request from the smart cockpit domain is rejected.

[0031] The driving state is defined as the current vehicle speed being greater than 0, the wheel speed being greater than a preset wheel speed threshold, or the vehicle being in a riding state; the high-speed state is defined as the current vehicle speed being greater than or equal to a preset high-speed threshold; the high tilt rate state is defined as |dθ / dt| being greater than or equal to a preset tilt rate threshold; the high-level energy recovery switching request is a switching request where the energy recovery level is not lower than a preset energy recovery level; the high-risk riding mode is a riding mode where at least one of the following—output torque upper limit, acceleration response parameter, or energy recovery intensity—exceeds a corresponding preset threshold; and the safety degradation state is the operating state entered after detecting a safety control anomaly.

[0032] If the conditions are met, a confirmation response command indicating successful verification is generated; otherwise, a rejection response command carrying a rejection reason code is generated.

[0033] Preferably, the method further includes a system anomaly degradation step:

[0034] When an inter-domain communication anomaly is detected, the system switches to a redundant communication link and limits the sending frequency or communication bandwidth of general service messages. The inter-domain communication anomaly includes at least one of the following: heartbeat message timeout, message packet loss rate exceeding a preset packet loss threshold, cyclic redundancy check error count exceeding a preset error threshold, or bus shutdown anomaly.

[0035] When an abnormal operation of the intelligent cockpit domain is detected, the cockpit enters a degraded state, freezes non-critical cockpit tasks, and retains basic instruments and necessary alarm outputs. The abnormal operation of the intelligent cockpit domain includes at least one of the following: loss of cockpit domain heartbeat, watchdog reset, application service unresponsiveness, or processor load exceeding a preset load threshold.

[0036] When the safety control domain detects at least one safety control anomaly, such as an abnormality in the power control execution link, an abnormality in the braking control execution link, an abnormality in a critical sensor, or an abnormality in an actuator, it enters a safety degraded state and performs at least one of the following operations: limiting torque, limiting vehicle speed, or prohibiting high-risk modes.

[0037] The present invention also provides a dual-domain controller task scheduling system for two-wheeled vehicles, comprising:

[0038] The status monitoring module is used to acquire the current riding status parameters, vehicle preset parameters, and environmental risk parameters of the two-wheeled vehicle. The current riding status parameters include the current vehicle speed and the rate of change of tilt angle. The vehicle preset parameters include the maximum design speed. The environmental risk parameters include the obstacle risk value.

[0039] The task arbitration module is used to calculate the current risk value based on the current vehicle speed, the maximum design vehicle speed, the tilt angle change rate, and the obstacle risk value, determine the current risk level based on the risk value, and dynamically adjust the calculation resource control parameters and communication resource control parameters according to the risk level, so as to change the execution priority, execution cycle, task start and stop, resource access quota, communication bandwidth quota, or message sending cycle of the safety control task in the safety control domain relative to the non-critical cockpit task in the intelligent cockpit domain;

[0040] The intelligent cockpit domain is used to generate control requests related to vehicle power or braking, and the intelligent cockpit domain only has request permissions for the control requests;

[0041] A safety control domain is used to receive the control request and perform a legality check on the control request based on the current vehicle constraints. The current vehicle constraints include at least the current vehicle speed, braking status, fault status, and side stand status, and also include at least one of the current riding mode, energy recovery level, or vehicle operating status.

[0042] If the control request meets the current vehicle constraint conditions, the safety control domain determines that the verification is successful, executes the control action corresponding to the control request, and generates an execution result including the execution status of the control action.

[0043] If the control request does not meet the current vehicle constraints, the safety control domain determines that the verification fails, refuses to execute the control action corresponding to the control request, and generates a rejection response instruction carrying a rejection reason code.

[0044] An inter-domain communication module is used to establish an interactive link between the security control domain and the intelligent cockpit domain to transmit the control request, the execution result, and the rejection response instruction.

[0045] Preferably, the inter-domain communication module includes a fast channel, a slow channel, and a redundant link;

[0046] The fast channel is used to transmit high-priority messages, which include at least one of torque request messages, braking status messages, attitude risk messages, safety alarm messages, and mode confirmation messages.

[0047] The slow channel is used to transmit general service messages, which include at least one of navigation messages, voice interaction messages, media service messages, log upload messages, background synchronization messages, statistics messages, and non-critical HMI display messages.

[0048] The redundant link is used to maintain the transmission of minimum control commands and status feedback data when a communication failure occurs in the fast channel or the slow channel.

[0049] Preferably, the system is configured with multiple operating states, including riding state, cabin degradation state, safety degradation state, and upgrade preparation state;

[0050] The system is prohibited from performing over-the-air (OTA) upgrades while in the riding state.

[0051] Compared with existing technologies, the present invention has at least the following beneficial effects: First, by using a risk-driven scheduling mechanism, the specific riding parameters of two-wheeled vehicles are directly associated with dual-domain resource allocation, significantly improving the real-time performance of safety control tasks in high-risk scenarios; Second, by using permission isolation and final arbitration mechanisms, the intelligent cockpit domain is prevented from unauthorizedly executing control operations that affect power or braking; Third, by using a hierarchical communication design with fast channels, slow channels, and redundant links, the reliability of the links is enhanced and anomaly fallback is achieved; Fourth, by using a state machine and degradation mechanism, the system can still maintain a minimum set of safety functions when communication anomalies, cockpit anomalies, or safety anomalies occur. Attached Figure Description

[0052] Figure 1 This is a diagram illustrating the inter-domain communication closed-loop and request confirmation execution mechanism of this invention.

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

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

[0055] The core concept of this invention is: "Dynamic reconfiguration of cross-domain resource control parameters based on the unique physical risks of two-wheeled vehicles, and a low-level security isolation mechanism based on asymmetric permissions." Existing technologies in the electronic and electrical architecture of two-wheeled vehicles suffer from the following technical deficiencies: The separation between physical risks and software scheduling. Existing architectures typically employ static resource allocation, failing to perceive the instantaneous computing power demands of two-wheeled vehicles under highly unstable conditions such as high-speed cornering and sudden attitude changes. The risk of cross-domain permission overreach: With the introduction of smart cockpits, the high concurrency of infotainment applications easily consumes the underlying bus bandwidth; simultaneously, if the cockpit domain has direct execution rights over vehicle power or braking, a crash or intrusion of the general operating system will directly trigger a safety incident. The lack of anomaly tolerance mechanisms: Traditional communication mechanisms only address the "sending and receiving" of messages, lacking a complete closed-loop verification from "instruction issuance" to "hardware execution," and failing to quickly converge to a safe state in the event of local hardware or software failures. To address these deficiencies, this invention proposes a technical approach of "perception and identification, dynamic scheduling, permission restriction, and closed-loop verification."

[0056] In this solution, "quantification of the risk formula" provides the triggering basis for "dynamic resource scheduling"; "dynamic resource scheduling" is used to ensure the scheduling priority of security domain legality verification tasks under high load; and "closed-loop communication and redundancy degradation" provide physical network support for the verification mechanism. These dimensions work together to improve the problems of unclear permission boundaries and insufficient scheduling response in the existing vehicle electronic architecture, which is conducive to improving the active safety performance of two-wheeled vehicles in high-risk scenarios.

[0057] An embodiment of the present invention provides a dual-domain controller system deployed in a two-wheeled vehicle. The safety control domain can employ a highly reliable microcontroller or domain controller, running a real-time operating system, to perform power control, braking control, attitude risk assessment, legality verification, and safety output processing. The intelligent cockpit domain can employ a SoC platform, running a general-purpose operating system, to perform HMI display, navigation voice, application services, over-the-air (OTA) upgrades, and log management. The safety control domain and the intelligent cockpit domain exchange data via an inter-domain communication module.

[0058] In this invention, a "domain" is a collection of functions and resources formed according to task attributes, real-time requirements, and functional safety levels. A domain can be defined by the logical aggregation of functions and tasks, an independent software and hardware operating environment, and clear resource and permission boundaries; different domains interact with each other through a well-defined inter-domain communication network to prevent non-real-time or low-security tasks from illegally occupying core control resources.

[0059] The safety control domain carries the core safety and driving control logic of the vehicle, specifically handling power output control, braking system control, vehicle attitude risk assessment and related safety output tasks, and serving as the legality reviewer and final execution entity for control commands.

[0060] The intelligent cockpit domain handles non-real-time, high-concurrency information processing and human-machine interaction loads, mainly processing tasks such as HMI display, navigation and voice interaction, upper-layer application services, over-the-air (OTA) upgrade systems, and log data management. For operations that may interfere with vehicle power or braking performance, this domain is limited to generating and sending action request messages across domains.

[0061] The status monitoring module collects system status parameters at preset intervals. For high real-time control links, it can update vehicle speed, wheel speed, braking status, tilt rate of change, and torque request at intervals of 1ms to 10ms; for cockpit health status, application load, and log information, it can update at intervals of 100ms to 1s. The collected parameters are normalized and then input into the task arbitration module.

[0062] The status monitoring module periodically collects at least some parameters from the following: current vehicle speed v, tilt angle change rate dθ / dt, obstacle risk value k, side support status, wheel speed, braking status, ABS / TCS feedback, processor load, memory usage, inter-domain packet loss rate, and battery charge. It also reads the maximum design speed Vmax from the vehicle's preset parameters. The task arbitration module calculates the risk value R based on these parameters and dynamically adjusts the computational and communication resource control parameters according to the risk level and vehicle status.

[0063] f(|dθ / dt|) is the attitude risk factor obtained after normalizing the rate of change of tilt angle.

[0064] In one embodiment, f(|dθ / dt|) = clip(|dθ / dt| / Ωmax, 0, 1), where Ωmax is a preset maximum tilt angle change rate threshold; when |dθ / dt| / Ωmax is greater than 1, f(|dθ / dt|) is 1.

[0065] In another embodiment, f(|dθ / dt|) can be determined by a preset attitude risk lookup table, which is used to map the absolute value of the tilt angle change rate to an attitude risk factor in the range of 0 to 1.

[0066] The task arbitration module includes a risk value calculation unit, a state identification unit, and a scheduling execution unit. Preferably, w1=0.45, w2=0.30, and w3=0.25. If the vehicle speed v is 48km / h, the maximum design speed Vmax is 100km / h, the normalized value of the tilt angle change rate is 0.35, and the obstacle risk value k is 0.60, then R=0.45×0.48+0.30×0.35+0.25×0.60=0.471. At this time, the state identification unit determines the working condition as medium risk level, and according to the scheduling parameters corresponding to the medium risk level, increases the thread priority of the safety control task by at least one level, or shortens the execution cycle of the attitude risk assessment task and the legality verification task to 60% to 80% of the execution cycle corresponding to the low risk level.

[0067] In one embodiment, the obstacle risk value k is determined based on the obstacle distance D, relative approach speed Vr, collision time TTC, and target recognition confidence C. If no valid obstacle is detected, k is 0; if multiple obstacles are detected, the sub-risk value corresponding to each obstacle is calculated separately, and the maximum value is taken as k. The obstacle risk value k can be determined according to the following relationship:

[0068] k=clip[a1·(1-clip(D / Dmax,0,1))+a2·clip(max(Vr,0) / Vrmax,0,1)+a3·(1-clip(TTC / TTCmax,0,1))+a4·C,0,1];

[0069] Where Dmax is the preset maximum perception distance, Vrmax is the preset maximum relative approach speed, TTCmax is the preset maximum collision time threshold, and a1, a2, a3, and a4 are non-negative weight coefficients, with the sum of the weight coefficients involved in the calculation being 1. A positive Vr value indicates that the obstacle is approaching the vehicle, and TTC is determined based on D / max(Vr, ε), where ε is a preset positive number to prevent division by zero. The weights of parameters not involved in the calculation are set to 0. Therefore, the smaller the obstacle distance D, the larger the relative approach speed Vr, the smaller the TTC, and the higher the target recognition confidence C, the larger k will be, and k is limited to between 0 and 1.

[0070] When the vehicle speed v exceeds 60km / h, or the risk value R reaches or exceeds 0.7, the scheduling execution unit enters a high-risk scheduling mode: First, it increases the thread priority and resource access quota of safety control tasks within the safety control domain 110, enabling power and braking control, attitude risk assessment, and safety output processing to obtain continuous processing windows; Second, it compresses navigation refresh, media services, background synchronization, and non-critical log upload tasks in the intelligent cockpit domain; Third, it shortens the transmission cycle of high-priority messages on the fast channel and reduces the transmission frequency of general service messages on the slow channel.

[0071] Risk levels are categorized into low-risk, medium-risk, and high-risk levels based on a risk value R. Specifically, a risk value R less than a first risk threshold is classified as low-risk; a risk value R greater than or equal to the first risk threshold but less than a second risk threshold is classified as medium-risk; and a risk value R greater than or equal to the second risk threshold is classified as high-risk, where the first risk threshold is less than the second risk threshold. In one embodiment, the first risk threshold is 0.4, and the second risk threshold is 0.7. At the low-risk level, the security control domain and the intelligent cockpit domain maintain relatively balanced resource control parameters. At the medium-risk level, the scheduling intensity of security control tasks is increased, and non-critical background services are restricted. At the high-risk level, the scheduling intensity of security control tasks is further increased, non-critical cockpit tasks are frozen or postponed, and the high-priority message transmission cycle is shortened.

[0072] The inter-domain communication module includes a fast channel, a slow channel, and a redundant link. The fast channel is used to transmit high-priority messages such as torque requests, braking status, attitude risks, safety alarms, and mode confirmations; the slow channel is used to transmit general service messages; and the redundant link is activated when the fast or slow channel fails to maintain the transmission of minimum control commands and status feedback data.

[0073] The intelligent cockpit domain only has request permissions for high-risk actions that affect vehicle power or braking, but not direct execution permissions. Upon receiving a request for such a high-risk action, the safety control domain performs a validity check based on the current vehicle speed, braking status, fault status, side stand status, and riding mode constraints, outputting an Ack confirmation response or a Nack rejection response. When the check passes, the corresponding control action is executed, and the execution result and status information are fed back, forming a closed-loop interaction mechanism of request, check, response, execution, and feedback.

[0074] In this invention, the computing resource control parameters are not limited to the migration of computing power between two physical processors, nor do they require the security control domain and the intelligent cockpit domain to share the same CPU resource pool. Specifically, when the security control domain and the intelligent cockpit domain run on the same domain controller or a platform sharing processing resources, the computing resource control parameters can represent the relative allocation relationship between security control tasks and cockpit tasks in terms of CPU time slices, thread priorities, task queue scheduling order, memory access quotas, or interrupt response priorities. When the security control domain and the intelligent cockpit domain run on independent MCUs, SoCs, or domain controllers, the computing resource control parameters represent the relative scheduling relationship between resource control parameters uniformly configured by the task arbitration module. This includes increasing the thread priority of power control, braking control, attitude risk assessment, and legality verification tasks within the security control domain, shortening their task execution cycle, or increasing the continuous processing window, while reducing the execution frequency, suspension duration, or resource access quota of non-critical tasks such as navigation refresh, media playback, background synchronization, log upload, or voice services within the intelligent cockpit domain. The communication resource control parameters include communication bandwidth quota, communication rate limiting parameters, high-priority message sending period or general service message sending frequency, and can be used to reduce the communication bandwidth or sending frequency of general service messages.

[0075] General service messages refer to communication messages transmitted between the safety control domain and the intelligent cockpit domain, used to carry non-safety-critical cockpit service data. The non-safety-critical cockpit service data refers to cockpit service data that does not directly participate in vehicle power control, braking control, attitude safety control, legality verification, safety alarms, or mode confirmation. General service messages include at least one of the following: navigation messages, voice interaction messages, media service messages, log upload messages, background synchronization messages, statistical messages, or non-critical HMI display messages. Correspondingly, the general service message transmission frequency refers to the number of times the general service message is transmitted per unit time through the inter-domain communication module or the periodic transmission rate, which can be configured through message transmission period, transmission interval, maximum transmission count, or communication rate limiting parameters. When a vehicle is in a high-risk level, inter-domain communication is abnormal, the cockpit is in a degraded state, or the safety is degraded, the system prioritizes the communication bandwidth and transmission cycle of high-priority messages such as torque requests, braking status, attitude risk, safety alarms, mode confirmation, and legality verification confirmation or rejection instructions. The system also limits the transmission frequency, communication bandwidth, or communication rate limiting parameters of general service messages to reduce the impact of non-safety-critical cockpit services on real-time control tasks in the safety control domain and high-priority inter-domain communication.

[0076] In one specific embodiment, when the risk value R is less than 0.4, the system is at a low risk level. Safety control tasks within the safety control domain are executed according to the first task cycle, while navigation refresh, media services, and background synchronization tasks within the intelligent cockpit domain are executed at the normal frequency. When the risk value R is between 0.4 and 0.7, the system is at a medium risk level. The task arbitration module increases the thread priority of safety control tasks by at least one level, shortens the execution cycle of attitude risk assessment and legality verification tasks, and reduces the execution frequency of background synchronization and log upload tasks in the intelligent cockpit domain to less than 50% of the normal frequency. When the risk value R is not less than 0.7 or the current vehicle speed is greater than or equal to a preset vehicle speed threshold, the system is at a high risk level. The task arbitration module further increases the scheduling priority of power control, braking control, and legality verification tasks in the safety control domain, allocates continuous processing windows, and freezes or postpones the execution of media playback, background synchronization, and unnecessary log upload tasks in the intelligent cockpit domain. At the same time, it shortens the sending cycle of high-priority messages in the fast channel and limits the sending frequency of general service messages in the slow channel. In this way, even if the security control domain and the intelligent cockpit domain are deployed on different hardware platforms, risk-driven resource usage priority adjustment can be achieved through configurable parameters such as task priority, execution cycle, task start and stop, communication rate limiting, and message sending cycle.

[0077] like Figure 1As shown, this system, from the underlying operating system architecture level, restricts the intelligent cockpit domain 120 to only have "request permissions" for vehicle power or braking control actions, and not direct "execution permissions." The first step is the request: the user initiates the operation via touchscreen or voice. The request generation unit 126 within the intelligent cockpit domain 120 encapsulates the user operation into a standardized request message and sends it to the safety control domain 110 via fast channel 141.

[0078] The second step is legality verification: As the final verification and execution entity for vehicle power or braking-related control actions, the safety control domain 110, upon receiving a request, does not directly drive the actuator but instead calls its internal legality verification module 113 to perform the verification. This module extracts real-time hardware sensor data and compares it with a preset safety constraint matrix.

[0079] The third step is response: Based on the verification result, if the safe execution conditions are met, an acknowledgment response Ack is generated; if, under the extreme bending conditions described above, switching to strong energy recovery causes the rear wheels to lock up and skid instantly, the legality verification module 113 will generate a rejection response Nack and attach a specific rejection reason code to the message.

[0080] Fourth step, execution: Only when an acknowledgment response Ack is generated will the execution output module 114 in the safety control domain 110 send the specific torque adjustment or mode switching command to the underlying motor controller or hydraulic braking unit for execution.

[0081] Step 5, Status Feedback: After execution is completed (or rejected), the execution output module 114 transmits the final execution status or rejection response Nack reason code back to the status display unit 127 in the intelligent cockpit domain 120 via the slow channel 142. The HMI then displays a pop-up window or provides voice announcements to the user, thus forming a complete closed loop.

[0082] In this embodiment, the redundant link 143 serves as a backup communication link when communication anomalies occur in the fast channel 141 and the slow channel 142. It is used to maintain the transmission of minimum control commands, verification responses, rejection responses, and status feedback data between the intelligent cockpit domain 120 and the safety control domain 110. Specifically, when an anomaly occurs in the fast channel 141, preventing the control request initiated by the intelligent cockpit domain 120 from being transmitted through the fast channel 141, the request generation unit 126 can send control requests related to vehicle power or braking to the safety control domain 110 via the redundant link 143. The control requests transmitted via the redundant link 143 are still subject to legality verification by the legality verification module 113 based on the current vehicle constraints, and do not directly bypass the legality verification module 113 to enter the execution output module 114. When an anomaly occurs in the slow channel 142, preventing the feedback of execution results or status information through the slow channel 142, the safety control domain 110 can feed back the confirmation response, rejection response, rejection reason code, control action execution status, or vehicle status to the status display unit 127 of the intelligent cockpit domain 120 via the redundant link 143. Therefore, redundant link 143 is only used to maintain a minimum safe interaction link in the event of communication failure, without changing the permission boundaries of intelligent cockpit domain 120 having only request permissions and security control domain 110 being responsible for legality verification and final execution.

[0083] In other embodiments, the fast channel 141 can use CANFD, time-sensitive networking, or other bus forms that meet real-time requirements; the slow channel 142 can use ordinary CAN, UART, or serving Ethernet; and the redundant link 143 can use a backup bus or an independent serial link. The technical concept of this invention can be applied as long as it can transmit minimum control and status feedback data when the main link fails.

[0084] like Figure 2 As shown, an embodiment of the present invention provides a dual-domain controller task scheduling method for two-wheeled vehicles. The method first executes step S101 to obtain the current riding state parameters, preset vehicle parameters, and environmental risk parameters of the two-wheeled vehicle. The current riding state parameters include at least the current vehicle speed and the rate of change of lean angle; the preset vehicle parameters include the maximum design speed; and the environmental risk parameters include obstacle risk values. Then, step S102 is executed to calculate the current risk value of the vehicle based on the current vehicle speed, the maximum design speed, the rate of change of lean angle, and the obstacle risk value.

[0085] In step S103, the system determines the current risk level based on the risk value and dynamically adjusts the computational resource control parameters and communication resource control parameters according to the risk level. This ensures that safety control tasks in the safety control domain have corresponding execution priorities, execution cycles, task start / stop, resource access quotas, communication bandwidth quotas, or message transmission cycles compared to non-critical cockpit tasks in the intelligent cockpit domain. Then, step S104 is executed, receiving control requests related to vehicle power or braking initiated solely by the intelligent cockpit domain with request permissions.

[0086] In step S105, the safety control domain performs a validity check on the control request based on the current vehicle constraints and determines whether the control request meets the current vehicle constraints. If the control request meets the current vehicle constraints, the check is deemed successful, and step S106 is executed, whereby the safety control domain executes the control action corresponding to the control request and feeds back the execution result, including the execution status of the control action, to the intelligent cockpit domain. If the control request does not meet the current vehicle constraints, the check is deemed unsuccessful, and step S107 is executed, whereby the safety control domain refuses to execute the control action corresponding to the control request, generates a rejection response command carrying a rejection reason code, and feeds back the rejection response command to the intelligent cockpit domain.

[0087] In summary, this invention, through a dual-domain architecture, risk-driven scheduling, closed-loop access control, and anomaly degradation mechanism, forms a complete and feasible control scheme applicable to two-wheeled vehicles.

Claims

1. A task scheduling method for a dual-domain controller for two-wheeled vehicles, applied to a dual-domain controller system, the dual-domain controller system comprising a safety control domain and a smart cockpit domain, characterized in that, The method includes: The current riding status parameters, vehicle preset parameters, and environmental risk parameters of the two-wheeled vehicle are obtained. The current riding status parameters include the current vehicle speed and the rate of change of tilt angle. The vehicle preset parameters include the maximum design speed. The environmental risk parameters include the obstacle risk value. Based on the current vehicle speed, the maximum design vehicle speed, the tilt angle change rate, and the obstacle risk value, calculate the current risk value of the two-wheeled vehicle; The current risk level is determined based on the risk value, and the computational resource control parameters and communication resource control parameters are dynamically adjusted according to the risk level to change the execution priority, execution cycle, task start / stop, resource access quota, communication bandwidth quota, or message transmission cycle of the security control task in the security control domain relative to the non-critical cockpit task in the intelligent cockpit domain. The risk level includes low risk, medium risk, and high risk. A low risk level is defined as the risk value R being less than a first risk threshold; a medium risk level is defined as the risk value R being greater than or equal to the first risk threshold and less than a second risk threshold; and a high risk level is defined as the risk value R being greater than or equal to the second risk threshold. The first risk threshold is less than the second risk threshold. The system receives control requests related to vehicle power or braking initiated by the intelligent cockpit domain, and the intelligent cockpit domain only has request permissions for the control requests. The safety control domain performs a validity check on the control request based on the current vehicle constraints, which include the current vehicle speed, braking status, fault status, and side support status. If the control request meets the current vehicle constraints, the verification is confirmed to be successful. The safety control domain then executes the control action corresponding to the control request and feeds back the execution result, including the execution status of the control action, to the intelligent cockpit domain. If the control request does not meet the current vehicle constraints, the verification is determined to fail. The safety control domain refuses to execute the control action corresponding to the control request, generates a rejection response instruction carrying a rejection reason code, and feeds the rejection response instruction back to the smart cockpit domain.

2. The method according to claim 1, characterized in that, Calculating the current risk value of the two-wheeled vehicle includes: The risk value R is calculated according to the following formula: R=w1·clip(v / Vmax,0,1)+w2·f(|dθ / dt|)+w3·k; Where v is the current vehicle speed obtained in real time by the sensor, Vmax is the maximum design speed of the two-wheeled vehicle, clip(v / Vmax, 0, 1) represents the clipping of v / Vmax, taking 0 when v / Vmax is less than 0, taking 1 when v / Vmax is greater than 1, and taking v / Vmax itself when v / Vmax is between 0 and 1; f(|dθ / dt|)=clip(|dθ / dt| / Ωmax, 0, 1) is used to represent the attitude risk factor obtained after normalizing the absolute value of the tilt angle change rate, Ωmax is the preset maximum tilt angle change rate threshold, and the value range of f(|dθ / dt|) is from 0 to 1; k is the obstacle risk value, which is determined based on at least two of the obstacle distance D, relative approach speed Vr, collision time TTC, and target recognition confidence C, and calculated according to the following relationship: k=clip[a1·(1-clip(D / Dmax,0,1))+a2·clip(max(Vr,0) / Vrmax,0,1)+a3·(1-clip(TTC / TTCmax,0,1))+a4·C,0,1]; Wherein, Dmax is the preset maximum perception distance, Vrmax is the preset maximum relative approach speed, TTCmax is the preset maximum collision time threshold, a1, a2, a3, and a4 are non-negative weight coefficients, and the sum of the weight coefficients involved in the calculation is 1; when Vr is positive, it indicates that the obstacle is approaching the two-wheeled vehicle, TTC is determined according to D / max(Vr, ε), and ε is a preset positive number to prevent division by zero; the weight of parameters not involved in the calculation is 0; the smaller the obstacle distance D, the larger the relative approach speed Vr, the smaller the collision time TTC, or the higher the target recognition confidence C, the greater the obstacle risk value k, and k is limited to the range of 0 to 1; w1, w2, and w3 are non-negative preset weight coefficients, and w1+w2+w3=1; θ is the vehicle roll angle; the risk value R ranges from 0 to 1; The target recognition confidence level C is output by the environmental perception module of the two-wheeled vehicle based on environmental perception data collected by cameras, millimeter-wave radar, ultrasonic radar, lidar or a combination thereof, after target detection, target classification or multi-sensor fusion recognition of obstacles, and is normalized. The value ranges from 0 to 1. When no valid obstacle is detected, the target recognition confidence level C is 0.

3. The method according to claim 1 or 2, characterized in that, The dynamic adjustment of computing resource control parameters and communication resource control parameters based on the risk level includes: When the risk value R is greater than or equal to the second risk threshold, or when the current vehicle speed is greater than or equal to a preset vehicle speed threshold: Adjust computing resource control parameters, including increasing the thread priority, execution frequency, or continuous processing window of power control, braking control, attitude risk assessment, and legality verification tasks in the safety control domain, and decreasing the execution frequency, resource access quota, or execution priority of navigation refresh, media service, background synchronization, or log upload tasks in the intelligent cockpit domain. Freeze or postpone the execution of non-critical cockpit tasks in the smart cockpit domain; and Adjust communication resource control parameters, including shortening the transmission cycle of high-priority messages during inter-domain communication, and / or limiting the communication bandwidth, communication rate limiting parameters, or transmission frequency of general service messages; The computing resource control parameters include at least one of CPU time slice, thread priority, task execution cycle, continuous processing window, memory access quota, interrupt response priority, task start / stop or task frequency reduction; the communication resource control parameters include at least one of communication bandwidth quota, communication rate limiting parameters, high-priority message sending cycle or general service message sending frequency.

4. The method according to claim 1, characterized in that, The step of performing a validity check on the control request through the security control domain includes: The safety control domain acquires the current vehicle constraints, which include at least the current vehicle speed, braking status, fault status, and side stand status, and also include at least one of the current riding mode, energy recovery level, or vehicle operating status. Determine whether the control request satisfies the vehicle constraint conditions; The determination of whether the control request meets the vehicle constraint conditions includes at least one of the following: when the vehicle is in motion and the side stand is not retracted, the power output request is rejected; when the vehicle is in a high-speed state or a high tilt angle change rate state, the high-level energy recovery switching request is rejected; when a braking system malfunction is detected, the high-risk riding mode switching request is rejected; when a safety control anomaly is detected and the vehicle enters a safety degradation state, the torque increase request from the smart cockpit domain is rejected. The driving state is defined as the current vehicle speed being greater than 0, the wheel speed being greater than a preset wheel speed threshold, or the vehicle being in a riding state; the high-speed state is defined as the current vehicle speed being greater than or equal to a preset high-speed threshold; the high tilt rate state is defined as |dθ / dt| being greater than or equal to a preset tilt rate threshold; the high-level energy recovery switching request is a switching request where the energy recovery level is not lower than a preset energy recovery level; the high-risk riding mode is a riding mode where at least one of the following—output torque upper limit, acceleration response parameter, or energy recovery intensity—exceeds a corresponding preset threshold; and the safety degradation state is the operating state entered after detecting a safety control anomaly. If the conditions are met, a confirmation response command indicating successful verification is generated; otherwise, a rejection response command carrying a rejection reason code is generated.

5. The method according to claim 1, characterized in that, The method also includes a system anomaly degradation step: When an inter-domain communication anomaly is detected, the system switches to a redundant communication link and limits the sending frequency or communication bandwidth of general service messages. The inter-domain communication anomaly includes at least one of the following: heartbeat message timeout, message packet loss rate exceeding a preset packet loss threshold, cyclic redundancy check error count exceeding a preset error threshold, or bus shutdown anomaly. When an abnormal operation of the intelligent cockpit domain is detected, the cockpit enters a degraded state, freezes non-critical cockpit tasks, and retains basic instruments and necessary alarm outputs. The abnormal operation of the intelligent cockpit domain includes at least one of the following: loss of cockpit domain heartbeat, watchdog reset, application service unresponsiveness, or processor load exceeding a preset load threshold. When the safety control domain detects at least one safety control anomaly, such as an abnormality in the power control execution link, an abnormality in the braking control execution link, an abnormality in a critical sensor, or an abnormality in an actuator, it enters a safety degraded state and performs at least one of the following operations: limiting torque, limiting vehicle speed, or prohibiting high-risk modes.

6. A dual-domain controller task scheduling system for two-wheeled vehicles, characterized in that, include: The status monitoring module is used to acquire the current riding status parameters, vehicle preset parameters, and environmental risk parameters of the two-wheeled vehicle. The current riding status parameters include the current vehicle speed and the rate of change of tilt angle. The vehicle preset parameters include the maximum design speed. The environmental risk parameters include the obstacle risk value. The task arbitration module is used to calculate the current risk value based on the current vehicle speed, the maximum design vehicle speed, the tilt angle change rate, and the obstacle risk value, determine the current risk level based on the risk value, and dynamically adjust the calculation resource control parameters and communication resource control parameters according to the risk level, so as to change the execution priority, execution cycle, task start and stop, resource access quota, communication bandwidth quota, or message sending cycle of the safety control task in the safety control domain relative to the non-critical cockpit task in the intelligent cockpit domain; The intelligent cockpit domain is used to generate control requests related to vehicle power or braking, and the intelligent cockpit domain only has request permissions for the control requests; A safety control domain is used to receive the control request and perform a legality check on the control request based on the current vehicle constraints. The current vehicle constraints include at least the current vehicle speed, braking status, fault status, and side stand status, and also include at least one of the current riding mode, energy recovery level, or vehicle operating status. If the control request meets the current vehicle constraint conditions, the safety control domain determines that the verification is successful, executes the control action corresponding to the control request, and generates an execution result including the execution status of the control action. If the control request does not meet the current vehicle constraints, the safety control domain determines that the verification fails, refuses to execute the control action corresponding to the control request, and generates a rejection response instruction carrying a rejection reason code. An inter-domain communication module is used to establish an interactive link between the security control domain and the intelligent cockpit domain to transmit the control request, the execution result, and the rejection response instruction.

7. The system according to claim 6, characterized in that, The inter-domain communication module includes a fast channel, a slow channel, and redundant links; The fast channel is used to transmit high-priority messages, which include at least one of torque request messages, braking status messages, attitude risk messages, safety alarm messages, and mode confirmation messages. The slow channel is used to transmit general service messages, which include at least one of navigation messages, voice interaction messages, media service messages, log upload messages, background synchronization messages, statistics messages, and non-critical HMI display messages. The redundant link is used to maintain the transmission of minimum control commands and status feedback data when a communication failure occurs in the fast channel or the slow channel.

8. The system according to claim 6, characterized in that, The system is configured with multiple operating states, including riding mode, cabin degradation mode, safety degradation mode, and upgrade preparation mode; The system is prohibited from performing over-the-air (OTA) upgrades while in the riding state.

Images