Vehicle dynamic control method and device, vehicle end control equipment, readable storage medium and program product

Abstract

The application relates to a vehicle dynamic control method and device, a vehicle end control device, a readable storage medium and a program product. The method comprises the following steps: acquiring multi-source sensing data of a vehicle, performing space-time alignment processing on the multi-source sensing data to generate scene description data; determining a risk coefficient of a current driving scene based on the scene description data, mapping the risk coefficient to a scene level of the driving scene, in the case that a multi-source control instruction is received and conflicts exist between the multi-source control instructions, triggering a preset multi-modal arbitration mechanism based on the scene level to generate a target control instruction, the multi-modal arbitration mechanism is a dynamic arbitration mechanism in which kinematic constraints are prioritized and coordinated with functional safety degradation, and the vehicle is controlled based on the target control instruction. The method can significantly improve the reliability of the vehicle in a complex interaction scene.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a vehicle dynamic control method, device, vehicle-side control equipment, readable storage medium, and program product. Background Technology

[0002] Against the backdrop of the rapid development of smart cockpit and vehicle-to-everything (V2X) technologies, in-vehicle electronic and electrical architectures are gradually evolving towards a domain-centralized approach. Existing cockpit system service management architectures typically include service request units, priority management units based on fixed lists, and resource allocation units, with communication between these units via CAN bus or Ethernet.

[0003] However, this architecture mainly relies on static priority allocation or simple rule adjustment schemes based on a single parameter (such as vehicle speed). The system is difficult to dynamically adapt to the safety requirements of actual driving scenarios, which makes it difficult to achieve reliable vehicle control in high-risk scenarios. Summary of the Invention

[0004] Based on this, this application addresses the aforementioned technical problems by providing a more reliable vehicle dynamic control method, device, vehicle-side control equipment, computer-readable storage medium, and computer program product.

[0005] Firstly, this application provides a vehicle dynamic control method, the method comprising:

[0006] Acquire multi-source sensor data of the vehicle, perform spatiotemporal alignment processing on the multi-source sensor data, and generate scene description data;

[0007] Based on the scenario description data, determine the risk coefficient of the current driving scenario;

[0008] The risk coefficient is mapped to the scenario level of the driving scenario;

[0009] When a multi-source control command is received and there are conflicts among the multi-source control commands, a preset multimodal arbitration mechanism is triggered based on the scenario level to generate a target control command. The multimodal arbitration mechanism is a dynamic arbitration mechanism that combines kinematic constraint priority with functional safety degradation.

[0010] The vehicle is controlled based on the target control command.

[0011] The aforementioned vehicle dynamic control method generates scene description data and determines the driving scene type and risk coefficient by performing spatiotemporal alignment processing on multi-source sensor data. It then maps the risk level to a scene level, accurately identifying the complexity and safety requirements of the current driving environment in real time. Based on this, when faced with conflicts in multi-source control commands, a dynamic arbitration mechanism combining "kinematic constraint priority and functional safety degradation" is triggered according to the scene level. Kinematic constraint priority ensures that the generated target control commands always adhere to vehicle kinematic constraints (such as tire friction limits), guaranteeing the physical feasibility and smoothness of the underlying execution. Meanwhile, "functional safety degradation," as a safety fallback strategy, effectively reduces the potential risk of system crashes or loss of control in extreme or high-risk scenarios. The entire solution significantly improves the reliability of the vehicle in complex interactive scenarios.

[0012] In an optional embodiment of the first aspect, determining the risk coefficient of the current driving scenario based on the scenario description data includes:

[0013] Based on the scenario description data, the current driving scenario type is determined;

[0014] By fusing the scenario description data and the driving scenario type, a fused feature vector is obtained. The fused feature vector is then input into a trained safety assessment model for analysis and reasoning to obtain the risk coefficient of the current driving scenario output by the safety assessment model.

[0015] The security assessment model is obtained by training a cascaded neural network with a channel attention mechanism based on historical multi-source sensor data carrying risk coefficient labels.

[0016] In this embodiment, by fusing scene description data with the identified scene type and using a cascaded neural network with a channel attention mechanism for safety assessment, the system can adaptively focus on key features that significantly impact risk and suppress redundant information, thereby significantly improving the accuracy and robustness of risk coefficient assessment in complex and variable driving scenarios.

[0017] In an optional embodiment of the first aspect, the analytical reasoning process of the security assessment model includes the following steps:

[0018] Local nonlinear coupling relationships between adjacent features in the fused feature vector are extracted using one-dimensional convolution operations.

[0019] The extracted local nonlinear coupling relationships are globally compressed and the nonlinear dependencies between channels are learned to generate dynamic weight vectors for each feature channel.

[0020] Based on the dynamic weight vector, the local nonlinear coupling relationship is recalibrated channel by channel, and the recalibrated features are mapped to risk coefficients to obtain the risk coefficients of the current driving scenario output by the safety assessment model.

[0021] In this embodiment, the local nonlinear coupling relationship between adjacent features can be effectively captured through one-dimensional convolution and channel recalibration mechanism, and the weight of each feature channel can be dynamically adjusted according to the actual state of the input data, thereby improving the model's sensitivity to potential risk features in complex driving scenarios and the accuracy of risk coefficient assessment.

[0022] In an optional embodiment of the first aspect, the step of triggering a preset multimodal arbitration mechanism based on the scene level to generate target control instructions includes:

[0023] The multi-source control commands are projected onto a unified preset coordinate system to determine the trajectory deviation within the preset prediction time domain;

[0024] The conflict index is determined based on the trajectory deviation and the risk coefficient;

[0025] If the conflict index is greater than a preset index threshold, it is determined that there is a target type conflict among the multi-source control commands. Based on the risk coefficient, a safety boundary condition is constructed, and the multi-source control commands are adjusted according to the safety boundary condition to generate target control commands.

[0026] In this embodiment, by projecting multi-source control commands onto a unified coordinate system and combining them with risk coefficients to calculate the conflict index, a safety boundary can be dynamically constructed and the commands adjusted when a substantial conflict is identified, thereby effectively ensuring the driving safety of the vehicle and the consistency of control commands in complex interaction scenarios.

[0027] In an optional embodiment of the first aspect, adjusting the multi-source control command according to the security boundary conditions to generate the target control command includes:

[0028] For each control instruction in the multi-source control instructions, determine whether the execution of the control instruction will cause the vehicle to exceed the safety boundary conditions;

[0029] If the execution of the control command would cause the vehicle to exceed the safety boundary conditions, the priority of the control command is intercepted, and a target control command is generated based on a preset safety policy.

[0030] If the vehicle does not exceed the safety boundary conditions after each control command is executed, the confidence level of each control command is obtained, a fusion weight is assigned based on the confidence level of each control command, and a weighted smooth fusion is performed on each control command based on the fusion weight of each control command to generate the target control command.

[0031] In this embodiment, by dynamically adjusting the command priority based on the safety boundary and combining it with confidence for weighted fusion, a smooth switching of multi-source commands can be achieved while ensuring that the vehicle does not cross the boundary, thereby improving the comfort and safety of the driving experience.

[0032] In an optional embodiment of the first aspect, the spatiotemporal alignment processing of the multi-source sensing data includes:

[0033] The multi-source sensor data is synchronized in time by combining hardware triggering and software compensation, and the multi-source sensor data is mapped to a unified time reference.

[0034] The multi-source sensor data is spatially aligned using a spatial transformation method based on the extrinsic calibration matrix, transforming the multi-source sensor data to a unified vehicle coordinate system.

[0035] In this embodiment, the combination of hardware and software time synchronization and spatial transformation based on extrinsic matrix effectively eliminates the inconsistency in acquisition time and installation location of heterogeneous multi-source sensors, providing an accurate and reliable spatiotemporal reference for subsequent high-precision data fusion.

[0036] In an optional embodiment of the first aspect, after generating the target control command by triggering a preset multimodal arbitration mechanism based on the scene level, the method further includes:

[0037] Based on the aforementioned scenario level, on-board computing and communication resources are scheduled in a tiered manner.

[0038] In this embodiment, through a scenario-level-based fine-grained hierarchical scheduling mechanism, the controller can achieve reasonable resource allocation under limited hardware conditions.

[0039] In an optional embodiment of the first aspect, the method further includes:

[0040] During the resource allocation process, a snapshot of the state of the interrupted service is recorded;

[0041] When the scenario level switches from a high level to a low level, the running context of the interrupted service is restored based on the state snapshot.

[0042] In an optional embodiment of the first aspect, the method further includes:

[0043] Failure detection is performed on the sensors of the vehicle;

[0044] In the event of a single sensor failure, data from a similar sensor to the failed sensor is used to complete the detection.

[0045] If the number of failures of key sensors reaches a preset number, the risk coefficient is adjusted to a preset first risk value, triggering the first mode, which retains only the basic driving assistance function. The key sensor is a sensor whose influence weight exceeds a preset threshold.

[0046] If all sensors are detected to be malfunctioning, the risk coefficient is adjusted to a preset second risk value, triggering the second mode;

[0047] Wherein, the first risk value is less than the second risk value, and the types of in-vehicle services in the first mode are more than the types of in-vehicle services in the second mode.

[0048] In this embodiment, by recording state snapshots and restoring the runtime context when the scene level decreases, seamless interruption and rapid recovery of non-core services are achieved, optimizing the user experience during system resource scheduling.

[0049] Secondly, this application also provides a vehicle dynamic control device, the device comprising:

[0050] The data processing module is used to acquire multi-source sensor data of the vehicle, perform spatiotemporal alignment processing on the multi-source sensor data, and generate scene description data.

[0051] The driving scenario perception module is used to determine the risk coefficient of the current driving scenario based on the scenario description data.

[0052] The scenario level determination module is used to map the risk coefficient to the scenario level of the driving scenario;

[0053] The arbitration module is used to trigger a preset multimodal arbitration mechanism based on the scenario level when receiving multi-source control commands and there are conflicts among the multi-source control commands, generate a target control command, and control the vehicle based on the target control command.

[0054] Thirdly, this application also provides a vehicle-side control device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0055] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0056] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the above aspects.

[0057] Regarding the beneficial effects of any of the technical solutions in the second to fifth aspects mentioned above, refer to the beneficial effects of the corresponding technical solutions in the first aspect; repeated examples will not be listed here. Attached Figure Description

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

[0059] Figure 1 This is a schematic diagram of an optional application environment for a vehicle dynamic control method in one embodiment.

[0060] Figure 2 This is a flowchart illustrating a vehicle dynamic control method in one embodiment;

[0061] Figure 3 This is a flowchart illustrating the vehicle dynamic control method in another embodiment;

[0062] Figure 4 This is a schematic diagram of an optional process for generating target control instructions in one embodiment;

[0063] Figure 5 This is an optional flowchart illustrating the steps for generating target control instructions in another embodiment;

[0064] Figure 6 This is a flowchart illustrating the vehicle dynamic control method in yet another embodiment;

[0065] Figure 7 This is a schematic diagram of an optional structure of the vehicle dynamic control device in one embodiment;

[0066] Figure 8 This is a schematic diagram of an optional structure of the vehicle dynamics control device in another embodiment;

[0067] Figure 9 This is a schematic diagram of an optional internal structure of the vehicle-side control device in one embodiment. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0069] The terms "first," "second," etc., used in this application may be used to describe various elements, but these elements are not limited by these terms. These terms are used only to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0070] The in-vehicle service interaction control method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, vehicle 102 communicates with cloud server 104 (hereinafter referred to as server 104) via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on other network servers.

[0071] Specifically, vehicle 102 can acquire multi-source sensor data in real time through various sensors and in-vehicle networks, and upload it to server 104 in real time. After receiving the multi-source sensor data from the vehicle, server 104 performs spatiotemporal alignment processing on the multi-source sensor data to generate scene description data. Based on the scene description data, it determines the risk coefficient of the current driving scenario and maps the risk coefficient to the scene level of the driving scenario. When multi-source control commands are received and there are conflicts between the multi-source control commands, a preset multimodal arbitration mechanism is triggered based on the scene level to generate target control commands. The multimodal arbitration mechanism is a dynamic arbitration mechanism that combines kinematic constraint priority with functional safety degradation, and controls the vehicle based on the target control commands.

[0072] Among them, server 104 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services.

[0073] In one exemplary embodiment, such as Figure 2 As shown, a vehicle dynamic control method is provided. This embodiment applies this method to... Figure 1 Taking cloud server 104 (hereinafter referred to as the server) as an example, the method includes steps 100 to 500. Wherein:

[0074] Step 100: Acquire multi-source sensor data of the vehicle, perform spatiotemporal alignment processing on the multi-source sensor data, and generate scene description data.

[0075] Multi-source sensor data refers to the raw environmental information and the vehicle's own state information collected by various heterogeneous sensors such as lidar, cameras, millimeter-wave radar, and inertial measurement units. Spatiotemporal alignment processing refers to eliminating the asynchronous differences in data acquisition time between different sensors and the spatial coordinate differences caused by their installation locations, transforming multi-source data into a unified time reference and spatial coordinate system. Scene description data refers to a structured data set that, after spatiotemporal alignment processing, integrates multi-sensor features and objectively reflects the geometric structure and dynamic attributes of the vehicle's surrounding environment.

[0076] In this embodiment, the deployment of a multi-source sensor array in the vehicle's perception layer is used as an example for illustration. The multi-source sensor array includes: a 77GHz millimeter-wave radar (detection range 200m), a forward-looking camera (120° wide angle), an infrared camera (capturing passenger facial features), a steering wheel grip force sensor, a steering wheel angle sensor (accuracy ±0.5°), and a wheel speed sensor (sampling rate 100Hz), etc.

[0077] In practical applications, during vehicle startup and driver operation, the controller can receive heterogeneous multi-source sensor data in real time via the vehicle's Ethernet or CAN bus interface, including point cloud data from LiDAR, image data from cameras, and inertial data from IMUs, and simultaneously upload this multi-source sensor data to the server. Since the perception layer connects to multiple heterogeneous sensors with different data formats, sampling frequencies, coordinate systems, and transmission delays, spatiotemporal alignment of the received raw multi-source heterogeneous sensor data is necessary to achieve a unified scene description and subsequent data processing. For example, the server can employ a hardware-level clock synchronization strategy and a software-level data alignment strategy to map data collected by different sensors to a unified 50ms time base, achieving time synchronization. Subsequently, the server reads a pre-stored extrinsic calibration matrix, which defines the rotation and translation relationships of each sensor's coordinate system relative to the vehicle's center coordinate system. Based on this extrinsic calibration matrix, the target and environmental information detected by different sensors is uniformly expressed in the Vehicle Coordinate System (VCS), completing spatial alignment. Finally, the time-synchronized and spatially aligned data are fused to generate scene description data containing multi-dimensional information such as obstacle distance, orientation, and speed.

[0078] Step 200: Determine the risk coefficient of the current driving scenario based on the scenario description data.

[0079] Driving scenario type refers to the type of environment in which the vehicle is currently located, identified based on road topology, traffic participant behavior, and environmental characteristics in the scenario description data. In this embodiment, driving scenario types include, but are not limited to, urban roads, highway cruising, parking, congested following, and cornering. Risk coefficient is a numerical indicator that quantifies the potential danger level of the current driving scenario. This value comprehensively reflects the probability of a collision between the vehicle and an obstacle and the severity of the potential consequences.

[0080] After generating scene description data through spatiotemporal alignment, the server can first extract key elements of the scene using feature extraction algorithms, such as lane curvature, relative speeds of surrounding vehicles, and pedestrian distances. Next, it can iterate through the logical rules in the scene definition library, substituting key elements from the scene description data (such as lane type, traffic light status, and road network topology) into the rules for judgment. The scene type is determined by matching these logical rules; once a set of rules is met (e.g., "traffic light detected and number of lanes > 2"), the current driving scene type is locked as urban road. Then, based on the determined driving scene type, a preset risk coefficient calculation formula is called to calculate the risk coefficient corresponding to the current driving scene. For example, specific variables required for the risk coefficient calculation formula can be extracted from the scene description data, such as time-to-collision (TTC), relative distance to obstacles, and relative speed. Substituting these extracted variables into the risk coefficient calculation formula yields the risk coefficient for the current driving scene.

[0081] In other embodiments, scene description data can be input into a pre-trained scene classification model to identify the driving scene type, and then the risk coefficient can be determined based on the driving scene type and a preset risk coefficient calculation formula. The scene classification model can be trained using offline supervised learning. Specifically, a dataset containing a large number of driving scene fragments can be constructed, covering various typical scenarios such as highways, urban congestion, intersections, and ramp merging. Each scene fragment is labeled with a corresponding scene category label to obtain a model training set. Then, a deep neural network is trained using the model training set to obtain a scene classification model capable of identifying driving scene types.

[0082] In other embodiments, scene description data can be input into a trained multi-task neural network model, simultaneously outputting scene classification results and risk coefficients. For example, a deep neural network containing a shared backbone and two independent heads can be constructed first. Then, sensor data covering various operating conditions (highways, urban areas, rain and snow, etc.) can be collected and labeled with corresponding scene category labels (e.g., "intersection") and risk coefficients (floating-point numbers between 0 and 1) to obtain a model training set. The model training set is then input into the deep neural network, where the backbone extracts high-dimensional semantic features. The classification head outputs scene probabilities through a Softmax function, and the regression head outputs risk coefficients through a fully connected layer. The loss function is a weighted sum of classification cross-entropy loss and regression mean squared error loss, and the network parameters are jointly optimized through gradient descent to obtain the trained multi-task model. In practical applications, the server inputs standardized scene description data (including lane topology and obstacle state vector tensors) into the trained multi-task model. The model's shared backbone performs convolution or attention operations on the input data to generate feature maps containing environmental context information. The model's classification branch performs global pooling and classification mapping on the feature map, outputting the probability distribution of each preset driving scenario type, and taking the type corresponding to the highest probability as the final "driving scenario type". The regression branch performs numerical fitting on the feature map and outputs the risk coefficient.

[0083] It is understood that, in other embodiments, the driving scenario type and risk coefficient can be determined separately using the scenario classification model and the risk assessment model, respectively.

[0084] Step 300: Map the risk factor to the scenario level of the driving scenario.

[0085] The scenario level refers to the level obtained by discretizing the continuously changing risk coefficient, used to characterize the urgency of the current driving task and the required system response level. In this embodiment, the scenario level can be divided into different levels such as low risk, medium risk, high risk, and emergency risk.

[0086] In this embodiment, a preset risk coefficient mapping table stored internally by the server is used as an example. This risk coefficient mapping table contains a correspondence between "risk coefficient ranges" and "scenario levels." During actual execution, after the server determines the risk coefficient S∈[0,100] of the current driving scenario, it searches and matches it in this mapping table. If the calculated risk coefficient falls within the numerical range corresponding to an emergency scenario (e.g., 90-100), the server classifies the current driving scenario as an emergency scenario (e.g., collision warning triggered, extreme lane departure); if the risk coefficient falls within the numerical range corresponding to a high-risk scenario (e.g., 70-89), it is classified as a high-risk scenario (e.g., following distance <2 cm, severe driver distraction); if the risk coefficient falls within the numerical range corresponding to a medium-risk scenario (e.g., 40-69), the current driving scenario is classified as a medium-risk scenario (e.g., complex traffic flow, driving on a sharp curve). If the risk coefficient falls within the numerical range corresponding to a low-risk scenario (e.g., 0-39), the current driving scenario is classified as a low-risk scenario (e.g., straight-line cruising, parking).

[0087] In other embodiments, the risk coefficient can be mapped to the scene level by pre-setting a piecewise function model with the risk coefficient as the independent variable and the scene level as the dependent variable. For example, the server substitutes the obtained current risk coefficient into this piecewise function for conditional judgment and calculation. If the substituted risk coefficient meets the triggering condition of the first piecewise function (i.e., S≥90), the current driving scene is determined to be an emergency scene; if the substituted risk coefficient meets the triggering condition of the second piecewise function (i.e., 70≤S<90), the current driving scene is determined to be a high-risk scene; if the substituted risk coefficient meets the triggering condition of the third piecewise function (i.e., 40≤S<70), the current driving scene is determined to be a low-risk scene; if the substituted risk coefficient meets the triggering condition of the third piecewise function (i.e., S<40), the current driving scene is determined to be a low-risk scene. It is understood that the scene level division and the corresponding risk threshold in the above embodiments can be adjusted according to actual circumstances and are not limited here.

[0088] In other embodiments, upper and lower thresholds are set to prevent frequent jumps in scene level caused by fluctuations in the risk coefficient around a threshold. For example, a risk coefficient greater than 75 is required to move from a medium-risk scene to a high-risk scene, while a risk coefficient less than 65 is required to move from a high-risk scene back to a low-risk scene, thereby ensuring the stability of system state switching.

[0089] Step 400: When receiving multi-source control commands and there are conflicts among the multi-source control commands, a preset multimodal arbitration mechanism is triggered based on the scenario level to generate target control commands. The multimodal arbitration mechanism is a dynamic arbitration mechanism that combines kinematic constraint priority with functional safety degradation.

[0090] In this embodiment, multi-source control commands refer to control commands from different functional modules of the vehicle (such as the autonomous driving domain, intelligent cockpit domain, remote manual takeover (5G / V2X cloud driver), and driver operation). Command conflicts refer to situations where multiple control commands are mutually exclusive or inconsistent in terms of control objectives, execution timing, or resource usage. The target control command refers to the unique control signal ultimately determined after arbitration, used to drive the vehicle's actuators. The multimodal arbitration mechanism is the core coordination logic for conflict detection, risk assessment, and dynamic adjudication, making a final consistent decision. Specifically, the multimodal arbitration mechanism can be derived from the semantic conflict types and confidence distribution of multi-source sensor data under spatiotemporal alignment, combined with priority rules, weighted fusion algorithms, or by introducing third-party verification / large model inference for comprehensive evaluation.

[0091] In this embodiment, kinematic constraint priority is the principle of prioritizing ensuring that the output commands conform to the physical motion laws of the vehicle (such as maximum steering angle and maximum acceleration limits). Functional safety degradation refers to a strategy that allows the system to automatically switch to a lower-risk and still controlled operating state when a fault occurs.

[0092] In practical applications, if the server simultaneously receives steering wheel angle requests (Instruction A) from the driver and steering wheel angle requests (Instruction B) from the lane keeping assist system, and detects that Instruction A and Instruction B are in opposite directions and the difference exceeds a threshold, the server determines that Instruction A and Instruction B conflict. At this point, the server reads the scenario level. If the scenario level is high-risk (e.g., impending collision), the arbitration mechanism immediately triggers the "functional safety downgrade" logic, forcibly downgrading the driver's high-priority instructions and directly generating emergency obstacle avoidance or braking target control instructions. If the scenario level is low-risk, the arbitration mechanism enters the "kinematic constraint priority" logic, inputting Instruction A and Instruction B into the vehicle dynamics model for verification, eliminating components exceeding the vehicle's physical limits (e.g., excessive lateral acceleration), and weightedly fusing the remaining feasible instructions to generate target control instructions that both conform to the driver's intent and meet physical constraints.

[0093] In other embodiments, the weights of each instruction can be dynamically adjusted based on the scene level. Specifically, the weights of each instruction can be dynamically adjusted according to the scene level. The lower the scene level, the more the original characteristics of the driver's instructions are preserved, and the greater the weight of the driver's instructions are, in order to ensure the driver's driving experience.

[0094] Step 500: Control the vehicle based on the target control command.

[0095] After generating the target control commands, the server parses and sends them to the corresponding actuator nodes. The actuators then use internal closed-loop control algorithms (such as PID or MPC) to convert these macroscopic commands into precise physical execution quantities. During execution, the server continuously collects feedback data from vehicle status sensors, compares it with the target control commands in real time, and performs error compensation to ensure that the vehicle's dynamic response meets the expected commands.

[0096] The aforementioned vehicle dynamic control method generates scene description data and determines the driving scene type and risk coefficient by performing spatiotemporal alignment processing on multi-source sensor data. It then maps the risk level to a scene level, accurately identifying the complexity and safety requirements of the current driving environment in real time. Based on this, when faced with conflicts in multi-source control commands, a dynamic arbitration mechanism combining "kinematic constraint priority and functional safety degradation" is triggered according to the scene level. Kinematic constraint priority ensures that the generated target control commands always adhere to vehicle kinematic constraints (such as tire friction limits), guaranteeing the physical feasibility and smoothness of the underlying execution. Meanwhile, "functional safety degradation," as a safety fallback strategy, effectively reduces the potential risk of system crashes or loss of control in extreme or high-risk scenarios. The entire solution significantly improves the reliability of the vehicle in complex interactive scenarios.

[0097] In one exemplary embodiment, such as Figure 3 As shown, step 200 includes:

[0098] Step 210: Based on the scene description data, determine the current driving scene type, fuse the scene feature vector and the driving scene type to obtain a fused feature vector, input the fused feature vector into the trained safety assessment model for analysis and reasoning, and obtain the risk coefficient of the current driving scene output by the safety assessment model. The safety assessment model is trained on a cascaded neural network with a channel attention mechanism based on historical multi-source sensor data carrying risk coefficient labels.

[0099] In this embodiment, the scene feature vector refers to a "set of features" that can describe the current driving environment. The safety assessment model is a deep network architecture composed of multiple neural network modules connected in sequence. The output of the previous stage serves as the input of the next stage, which is used to gradually extract deep abstract features to complete complex tasks.

[0100] In this embodiment, the security assessment model is a 3-layer one-dimensional convolutional neural network (1D-CNN) that incorporates a channel attention mechanism. Specifically, the model structure of the security assessment model is as follows:

[0101] Layer 1 (Local Feature Coupling Layer): One-dimensional convolution (1D-Conv) operation is used, and multiple convolution kernels of different sizes are set (such as KernelSize=2 and 3) to extract local nonlinear coupling relationships between adjacent features with strong physical correlation (such as extracting the TTC latent features coupled from "vehicle distance" and "relative speed", and the environmental visibility features coupled from "light" and "weather").

[0102] Layer 2 (Channel Attention and Dynamic Weights): This layer introduces a Squeeze-and-Excitation (SE) channel attention module. Spatial features are compressed into channel descriptors through global average pooling (Squeeze); then, the non-linear dependencies between feature channels are learned through two fully connected layers (Excitation), outputting a 12-dimensional dynamic weight vector (the weights sum to 1).

[0103] Layer 3 (Output and Activation Layer): The high-dimensional features are reduced to a 1-dimensional scalar through a fully connected layer, and then mapped to the [0,1] interval through the Sigmoid activation function. Finally, the risk coefficient S∈[0,100] is multiplied by 100.

[0104] Specifically, the safety assessment model can be trained as follows: First, a large-scale dataset containing diverse driving scenarios (such as highways in sunny weather, traffic jams in heavy rain, etc.) is constructed. The input samples are preprocessed fused feature vectors containing 12-dimensional scene feature vectors and driving scenario types, with labels added to the fused feature vectors indicating the true risk coefficients. During the training phase, the input samples are fed into a 3-layer one-dimensional convolutional neural network (1D-CNN). After local feature extraction by convolutional kernels of different sizes in the first layer and dynamic weight allocation by the SE module in the second layer, the predicted risk coefficients are output by the fully connected layer in the third layer. Next, by calculating the loss between the predicted value and the true label (such as mean squared error), the gradient is calculated using the backpropagation algorithm, and the parameters of the fully connected network in the SE module of the second layer and the weights of the convolutional kernels in the first layer are updated, enabling the model to automatically learn the importance of each feature channel in different scenarios. After multiple rounds of iterative training until the loss function converges, the model has the ability to automatically adjust feature weights based on real-time input and accurately assess risk coefficients.

[0105] In practice, after spatiotemporally aligning the original multi-source sensor data, the server extracts features from the spatiotemporally aligned multi-source sensor data to extract scene description data containing multiple key attribute features. In this embodiment, scene description data containing 12-dimensional feature vectors is used as an example. Specifically, the scene description data includes vehicle distance, relative speed, vehicle speed, TTC (Total Traffic Control), steering wheel angle, lane departure angle, driver eye movement frequency, blink frequency, hand grip torque, weather conditions, light intensity, and road curvature. It is understood that in other embodiments, the dimensions of the scene feature vectors can be adjusted according to actual conditions, and are not limited to a single dimension here.

[0106] The server inputs the scene description data into a trained scene classification model (such as an SVM-based scene classifier), which identifies the specific category of the current driving environment, thus obtaining the current driving scene type. The scene classifier uses a non-linear SVM, pre-trained offline using a labeled scene dataset. The classifier maps the input vector to a high-dimensional space using a kernel function to address the linear inseparability between multiple scene classes; the preferred kernel function is the radial basis function (RBF).

[0107] To differentiate between N preset driving scenarios (including city roads, highway cruising, parking, traffic jam following, and cornering), a "one-vs-one" decomposition strategy is adopted, and a total of A binary SVM subclassifier.

[0108] Subsequently, a basic driving mode switch is triggered. The identified driving scenario type is used as a priori context condition and encoded into a 5-dimensional driving scenario type vector using one-hot encoding. This vector is then concatenated with a 12-dimensional scene feature vector to construct a 17-dimensional fused feature vector containing rich contextual information. This vector not only preserves the physical features of the environment but also adds semantic information about the scene. Next, the server inputs this fused feature vector into a preset safety assessment model and outputs a risk coefficient.

[0109] In this embodiment, by fusing scene description data with the identified scene type and using a cascaded neural network with a channel attention mechanism for safety assessment, the system can adaptively focus on key features that significantly impact risk and suppress redundant information, thereby significantly improving the accuracy and robustness of risk coefficient assessment in complex and variable driving scenarios.

[0110] In some exemplary embodiments, the safety assessment model obtains the risk coefficient of the current driving scenario in the following manner:

[0111] The local nonlinear coupling relationship between adjacent features in the fused feature vector is extracted by one-dimensional convolution operation. The extracted local nonlinear coupling relationship is then globally compressed and the nonlinear dependency relationship between channels is learned to generate dynamic weight vectors for each feature channel. Based on the dynamic weight vectors, the local nonlinear coupling relationship is recalibrated channel by channel, and the recalibrated features are mapped to risk coefficients.

[0112] In practice, after the fused feature vectors are input into the safety assessment model, the first convolutional layer immediately extracts local nonlinear relationships, such as the TTC latent features coupled with "vehicle distance and relative speed," using convolutional kernels of different sizes. Subsequently, the data enters the core second-layer SE channel attention module. This module first compresses spatial features into channel descriptors through global average pooling (Squeeze), and then learns the nonlinear dependencies between feature channels through two fully connected layers (Excitation). Weights are automatically assigned based on the real-time context, outputting a 12-dimensional dynamic weight vector (with a weight sum of 1). For example, when "heavy rain" feature activation is detected, the weights of the "vehicle distance" and "lighting" channels are automatically and significantly increased, while the weight of "lane departure angle" is decreased. Afterward, the dynamic weights are multiplied (scaled) channel-by-channel with the feature map of the first layer to complete feature recalibration.

[0113] Finally, the recalibrated feature map is fed into the third fully connected layer for dimensionality reduction, and the result is mapped to the [0,1] interval through the Sigmoid activation function. Finally, it is multiplied by 100 to output the current risk coefficient S. For example, if the model evaluates the current scene as extremely dangerous, the output risk coefficient will be mapped to the lower limit of the preset interval (such as close to 100), and if the scene is extremely safe, it will be mapped to the upper limit (such as close to 0).

[0114] In this embodiment, the local nonlinear coupling relationship between adjacent features can be effectively captured through one-dimensional convolution and channel recalibration mechanism, and the weight of each feature channel can be dynamically adjusted according to the actual state of the input data, thereby improving the model's sensitivity to potential risk features in complex driving scenarios and the accuracy of risk coefficient assessment.

[0115] The specific details of the multimodal arbitration mechanism can be set according to the actual situation. For example... Figure 4 As shown, in an exemplary embodiment, a preset multimodal arbitration mechanism is triggered based on the scene level to generate target control instructions, including:

[0116] Step 410: Project the multi-source control commands onto a unified preset coordinate system and determine the trajectory deviation in the preset prediction time domain.

[0117] Step 420: Determine the conflict index based on trajectory deviation and risk coefficient.

[0118] Step 430: If the conflict index is greater than the preset index threshold, it is determined that there is a target type conflict between the multi-source control commands. Based on the risk coefficient, a safety boundary condition is constructed, and the multi-source control commands are adjusted according to the safety boundary condition to generate the target control command.

[0119] In this embodiment, the preset coordinate system can be the Frenet coordinate system (also known as the Frenet-Serret Frame), a local coordinate system commonly used in differential geometry and autonomous driving path planning. Essentially, it is a local coordinate system that dynamically changes with the reference path. In this embodiment, the Frenet coordinate system is a local coordinate system dynamically established by projecting the vehicle's current position onto the reference path, with the projection point as the origin, the path tangent as the vertical axis, and the path normal as the horizontal axis. Trajectory deviation refers to the degree of difference in spatial position, direction, or speed between the future driving paths planned by different control sources within a preset prediction time domain. The preset prediction time domain is a finite time window (e.g., 1 second, 3 seconds, or 5 seconds in the future) used to predict the vehicle's future dynamic behavior. Specifically, the prediction time domain can be set based on the vehicle's current motion state (e.g., speed), real-time computing power constraints, and the response characteristics of the target control task. The conflict index is used to comprehensively measure the severity of inconsistencies or potential collision risks between multi-source control commands. In this embodiment, target type conflict, also known as substantial conflict, refers to a dangerous state where the divergence between multi-source control commands is too great to be resolved through simple weighted fusion, necessitating intervention. Safety boundary conditions refer to the physical constraints (such as maximum permissible lateral acceleration, minimum turning radius, etc.) set based on the current risk level to ensure that the vehicle remains within a safe operating envelope under all circumstances.

[0120] In practical applications, when autonomous driving algorithms (ADAS), remote manual takeover (5G / V2X cloud-based driver), and in-vehicle driver intervention simultaneously issue control commands, intent conflicts are highly likely to occur. When conflicts are determined to exist between commands, adjustments to the multi-source control commands are necessary to generate target control commands. Specifically, since control commands may originate from different computing nodes and their coordinate systems may have slight differences, the server can first project these multi-source control commands onto a unified Frenet coordinate system to eliminate spatial inconsistencies. Next, within a preset prediction time domain (e.g., the next 3 seconds), the expected driving trajectory corresponding to each command is calculated, and the trajectory deviation between the lateral and longitudinal trajectories is determined. Subsequently, the server calculates the calculated trajectory deviation and a risk coefficient to determine the current conflict index. For example, when the trajectory deviation is large and the risk coefficient indicates a high environmental risk, an extremely high conflict index is obtained. Then, the server compares this conflict index with a preset index threshold. If the conflict index is greater than the threshold, a target type conflict is determined to exist between the multi-source control commands. At this point, the server immediately triggers arbitration logic, constructing strict safety boundary conditions based on the current risk coefficient (such as the maximum permissible lateral acceleration in the current scenario). For example, if the risk coefficient indicates high risk, the limit on the maximum permissible steering angular velocity may be tightened. Finally, the server adjusts conflicting multi-source control commands based on these safety boundary conditions (such as truncating command components that exceed the boundaries or performing smooth dimensionality reduction on the commands), ultimately generating the target control command that meets both safety requirements and responds as responsively as possible to the intended intent.

[0121] In this embodiment, by projecting multi-source control commands onto a unified coordinate system and combining them with risk coefficients to calculate the conflict index, a safety boundary can be dynamically constructed and the commands adjusted when a substantial conflict is identified, thereby effectively ensuring the driving safety of the vehicle and the consistency of control commands in complex interaction scenarios.

[0122] There are no restrictions on how multi-source control commands are adjusted based on safety boundary conditions. For example... Figure 5 As shown, in an exemplary embodiment, the multi-source control commands are adjusted according to security boundary conditions to generate target control commands, including:

[0123] Step 431: For each control command in the multi-source control command, determine whether the execution of the control command will cause the vehicle to exceed the safety boundary conditions.

[0124] Step 432: If the execution of the control command would cause the vehicle to exceed the safety boundary conditions, the control command is intercepted, and a target control command is generated based on the preset safety strategy.

[0125] Step 433: If the vehicle does not exceed the safety boundary conditions after each control command is executed, obtain the confidence level of each control command, assign fusion weights based on the confidence level of each control command, and perform weighted smooth fusion of each control command based on the fusion weights of each control command to generate the target control command.

[0126] In this embodiment, the preset safety strategy is a set of mandatory safety control logic used to execute "last resort protection" when the control command is detected to exceed the safety boundary or trigger a high-risk state. Specifically, the preset safety strategy can be a set of extreme condition emergency control rules pre-calibrated and solidified in the server based on vehicle dynamics models, physical safety boundary constraints, and national / industry functional safety standards, through systematic risk assessment, hazard analysis, and failure mode and effect analysis.

[0127] In this embodiment, the traditional "absolute fixed priority" principle is broken, and a dynamic arbitration strategy of "physical priority + safety override" is adopted: basic priority: driver active intervention > remote manual takeover > ADAS autonomous driving.

[0128] In practical applications, during the process of adjusting multi-source control commands based on safety boundary conditions and generating target control commands, the server first performs safety boundary verification on each received control command. Specifically, for each control command among the multi-source control commands (such as a steering request issued by the autonomous driving main planning module), the server simulates the execution of the control command and predicts the change in the risk coefficient S in the next cycle. If the prediction result shows that executing the command will cause the vehicle to break through the safety envelope, i.e., an emergency scenario where the risk coefficient S suddenly rises to over 90, the server will determine that the command exceeds the safety boundary conditions, and then forcibly reduce the priority of the high-priority command or intercept the control command. Based on the preset safety strategy, the server generates a target control command, which is used to trigger the system's highest priority AEB (Automatic Emergency Braking) or LKA (Lane Keeping Assist) fallback strategy, thereby physically preventing dangerous behavior.

[0129] However, when the system is in a non-emergency state (i.e., the risk coefficient has not exceeded the critical value or the safety boundary conditions), the server will not blindly follow any single instruction. Instead, it will use an adaptive weighted fusion algorithm to coordinate and obtain the target control instruction. Specifically, the server evaluates the "confidence" of each instruction in real time. This evaluation depth incorporates current contextual factors (such as network latency, driver fatigue, etc.). For example, if the remote takeover instruction is issued via the network, the server will check the network status. If the current network latency is as high as 500 milliseconds, it indicates that the remote instruction may be lagging, and the confidence of the remote instruction will be reduced. In the case of human-machine co-driving, the server will determine the driver's status through factors such as in-vehicle cameras or steering wheel grip sensors. If the driver is detected to be fatigued or distracted, the confidence of the driver's manual instructions will be reduced, and the confidence of the ADAS system will be increased accordingly. Next, based on the above dynamic evaluation results, corresponding fusion weights are assigned to each instruction (e.g., ADAS accounts for 70%, and remote takeover accounts for 30%). Finally, based on the assigned fusion weights, the multi-source control instructions are weighted and smoothly fused to obtain the target control instruction. Taking the weighted smooth fusion of multi-source steering wheel angle and pedal opening as an example, for instance, ADAS suggests turning the steering wheel 10 degrees to the left, while remote control suggests turning it 4 degrees to the left. After fusion with weights of 70% and 30%, a final execution angle of 8.2 degrees is calculated. This weighted fusion mechanism effectively reduces abrupt changes in control commands, ensuring the continuity and gradualness of vehicle actions, thereby significantly improving ride comfort while maintaining vehicle stability.

[0130] In this embodiment, by dynamically adjusting the command priority based on the safety boundary and combining it with confidence for weighted fusion, a smooth switching of multi-source commands can be achieved while ensuring that the vehicle does not cross the boundary, thereby improving the comfort and safety of the driving experience.

[0131] In one exemplary embodiment, spatiotemporal alignment processing of multi-source sensor data includes:

[0132] A combination of hardware triggering and software compensation is used to synchronize the time of multi-source sensor data, mapping the multi-source sensor data to a unified time reference.

[0133] A spatial transformation method based on the extrinsic calibration matrix is ​​used to spatially align multi-source sensor data, transforming the multi-source sensor data to a unified vehicle coordinate system.

[0134] In this embodiment, hardware triggering refers to a technology that uses the physical signal pins of a sensor or a server to directly generate a synchronous pulse signal, thereby forcing multiple heterogeneous sensors to perform data collection at the same time at the physical level. Software compensation refers to a mechanism that estimates and corrects the time delay generated by data during transmission over different communication buses and operating system scheduling through algorithms, so as to compensate for residual errors in hardware synchronization. Extrinsic calibration matrix refers to a mathematical transformation matrix that describes the relative position and attitude relationship between different sensors, which is used to accurately convert data in different local coordinate systems to the same global reference coordinate system.

[0135] In specific implementation, when the server performs spatio-temporal alignment processing on multi-source sensing data, it may first start the time synchronization process, and adopt a method combining hardware triggering and software compensation to accurately map the multi-source sensing data to a unified time reference. Specifically, in terms of hardware-level clock synchronization and triggering, the domain controller is used as the global master clock node. By receiving the GPS pulse per second (PPS) signal, it distributes the high-precision global time reference to each sensor node, ensuring that the relative deviation of the underlying hardware clocks of each sensor is strictly controlled within 1 microsecond. For frame-level high-bandwidth sensors such as forward-looking cameras, a hardware triggering mechanism is introduced, that is, collection is controlled through a dedicated trigger line, ensuring that the midpoint moment of image exposure is strictly aligned with the global time reference, eliminating collection asynchronous errors from the source.

[0136] In terms of software-level data alignment strategy, based on the domain controller master clock, generate a unified sampling beat t0 with a period of 50ms (i.e., 20 Hz), and adopt differentiated alignment algorithms according to the data types and characteristics of different sensors:

[0137] First, for continuous numerical low-frequency or variable-frequency sensors (such as some wheel speed signals), linear interpolation is used to resample to the reference beat t0. Specifically, the server searches for the time stamps t1 and t2 of the two nearest frames of data before and after t0 (satisfying t1<t0<t2), obtains the corresponding data values D1 and D2, and calculates the precise aligned value through a formula to fill the time gap. The alignment formula is as follows:

[0138] D(t0)=D1+(t0-t1) / (t2-t1)×(D2-D1).

[0139] Second, for high-frequency sensors (such as steering wheel grip, angle, wheel speed, etc.), since their sampling frequency is much higher than the output frequency and the maximum time error is ≤5ms, which already meets the accuracy requirements of dynamic scenarios. Therefore, no complicated interpolation operation is performed, and the measurement value whose time stamp is closest to t0 is directly extracted as the alignment result, so as to balance calculation efficiency and real-time performance.

[0140] Third, for frame-level high-bandwidth sensors such as forward-facing cameras, considering the massive amount of image data, pixel-level temporal interpolation is not performed. Instead, the "midpoint timestamp of the exposure" of the image frame is used as a benchmark. After extracting visual features, temporal correlation is performed at the feature level with 50ms benchmark data from other sensors. Simultaneously, to address the time difference caused by the vehicle's high-speed movement, motion compensation is performed using IMU or wheel speed data, accurately projecting the visual features onto the vehicle's pose at time t0, thereby ensuring deep fusion of multimodal data in a unified spatiotemporal coordinate system.

[0141] After completing the temporal alignment, the server then performs spatial alignment. The core objective of spatial alignment is to unify the target and environmental information collected by multiple heterogeneous sensors within the Vehicle Coordinate System (VCS). In this embodiment, a standard vehicle coordinate system definition is adopted: the origin O is located at the ground projection point of the rear axle center of the vehicle, the X-axis points in the vehicle's forward direction, the Y-axis points to the driver's left, and the Z-axis points vertically upward. Each sensor completes spatial coordinate transformation based on a pre-calibrated extrinsic parameter matrix, with the specific strategy as follows:

[0142] (1) Spatial coordinate transformation of millimeter-wave radar: The original output of millimeter-wave radar is the range r, azimuth θ and elevation angle in the radar local polar coordinate system. First, convert it to three-dimensional coordinates in the radar's local Cartesian coordinate system. The conversion formula is: Subsequently, the rotation matrix obtained from radar extrinsic parameter calibration was used. Translation vector By using rigid body transformation, it is precisely mapped to the vehicle coordinate system, that is: .

[0143] (2) Spatial projection and inverse perspective transformation of the forward-looking camera: The output of the forward-looking camera is the 2D image pixel coordinates (u,v). For ground features such as lane lines, it is assumed that the road surface is a locally flat plane (Z=0), and the camera intrinsic parameter matrix K and the extrinsic parameter transformation matrix from the camera to the vehicle coordinate system are combined. and By using inverse perspective mapping (IPM), pixel coordinates are directly mapped to ground 3D coordinates in the vehicle coordinate system. .

[0144] (3) Spatial mapping of in-cabin sensors: The driver monitoring module (such as infrared camera, grip force sensor) and vehicle status module (such as steering angle, wheel speed) are mainly used to describe the vehicle status and driver status, and do not involve the three-dimensional spatial positioning of external environmental targets. Therefore, such data does not need to undergo complex three-dimensional spatial coordinate transformation, but is directly used as a scalar or vehicle status vector, and is logically spliced ​​and aligned with external perception data in the feature extraction stage.

[0145] In this embodiment, the combination of hardware and software time synchronization and spatial transformation based on extrinsic matrix effectively eliminates the inconsistency in acquisition time and installation location of heterogeneous multi-source sensors, providing an accurate and reliable spatiotemporal reference for high-precision data fusion.

[0146] like Figure 6 As shown, in an exemplary embodiment, after generating target control commands by triggering a preset multimodal arbitration mechanism based on scene level, the method further includes:

[0147] Step 600: Based on the scenario level, perform hierarchical scheduling of on-board computing and communication resources.

[0148] In this embodiment, hierarchical scheduling refers to a resource allocation strategy that divides computing and communication resources into different levels according to the importance or urgency of the tasks, and prioritizes the resource allocation for high-level tasks.

[0149] In practical applications, while arbitrating control commands, the server controls the QoS policy engine to perform microsecond-level reallocation of system computing and communication resources based on the security level issued by the decision-making layer, through a hardware acceleration module (integrated FPGA). Specifically, the server can perform hierarchical scheduling of in-vehicle computing and communication resources based on the scenario level. Regarding computing resource scheduling, the server dynamically adjusts the CPU computing power allocation of each functional module according to the risk level of the scenario. For example, when the system identifies a high-risk scenario (such as a sudden obstacle ahead on a highway), the server immediately increases the computing priority of core safety modules such as perception fusion and decision planning, allocating more processor cores and memory bandwidth to them. Simultaneously, to ensure the real-time performance of critical tasks, the server may temporarily reduce or even suspend the resource usage of non-safety-related functions such as in-vehicle entertainment systems and voice assistants, ensuring that the autonomous driving algorithm can run with minimal latency under high load. The server also implements strict priority management for communication resource scheduling. In complex traffic scenarios, CAN bus messages related to vehicle control and V2X (Vehicle-to-Everything) warning information are given the highest communication priority to ensure that control commands and traffic alerts can be transmitted within microseconds. Meanwhile, high-volume, non-real-time data streams such as navigation map updates and OTA upgrade package downloads are allocated to lower-priority channels. If network congestion occurs, the server will proactively limit the transmission rate of these low-priority data, thereby ensuring the unimpeded flow of critical safety data.

[0150] In this embodiment, through a fine-grained hierarchical scheduling mechanism based on scenario level, the server can achieve reasonable resource allocation under limited hardware conditions.

[0151] In one exemplary embodiment, on-board computing and communication resources are scheduled hierarchically based on scenario level, including:

[0152] In the case of an emergency scenario, the first control signal is output to suspend non-safety-related processes, and a preset proportion of central processing unit CPU resources are allocated to ADAS services.

[0153] In high-risk scenarios, a second control signal is output to restrict the image enhancement function of the entertainment system, and the bandwidth of the V2X communication link is increased to a preset bandwidth threshold.

[0154] In scenarios classified as medium-risk, the background OTA download speed will be maintained within a preset range, navigation services and cockpit services will be maintained at baseline priority, and the inference frequency of high-computing-power modules will be limited.

[0155] In low-risk scenarios, a third control signal is output to enable the entertainment system's image quality enhancement mode, allowing background data to be silently upgraded.

[0156] For example, hierarchical scheduling of onboard computing and communication resources based on scenario level can be:

[0157] Emergency Scenario (S≥90): Immediately suspend non-safety-related video decoders and background processes; set the priority of ADAS control-related CAN / Ethernet messages to 0 (maximum 0); allocate over 90% of CPU / GPU resources to ADAS perception and decision-making services; cut off non-critical external network requests. ADAS services refer to the Advanced Driver Assistance System (ADAS), which is responsible for providing core safety functions such as lane keeping and adaptive cruise control.

[0158] High-risk scenarios (70≤S<90): Limit the GPU utilization of the cockpit entertainment system to ≤30%; increase the bandwidth guarantee of V2X communication and remote takeover links to 20Mbps to reduce network jitter; reduce the priority of OTA background downloads.

[0159] Medium-risk scenarios (40≤S<70): Maintain background OTA download speed ≤5Mbps; keep navigation and cockpit services at baseline priority; limit the inference frequency of non-critical AI models with high computing power consumption (such as cockpit gesture recognition).

[0160] Low-risk scenario (S<40): Open all system service resources; enable entertainment system image quality enhancement mode; allow high-bandwidth background data upload and silent system upgrades.

[0161] It is understandable that the strategy for hierarchical scheduling of onboard computing and communication resources can be set according to the actual situation, and no single limitation is made here.

[0162] In this embodiment, computing and communication resources are scheduled in a hierarchical manner based on scenario level, which can prioritize the operation of core safety functions under high load or emergency conditions, thereby improving the overall reliability and response efficiency of the vehicle service system.

[0163] In this embodiment, by setting three progressive priority levels, CPU resource allocation, image quality enhancement, and communication bandwidth can be dynamically adjusted according to scene changes, realizing refined and intelligent scheduling of computing and communication resources under different working conditions.

[0164] In one exemplary embodiment, the method further includes:

[0165] During the resource allocation process, a snapshot of the state of the interrupted service is recorded. When the scenario level switches from a high level to a low level, the running context of the interrupted service is restored based on the snapshot.

[0166] In this embodiment, a state snapshot refers to a complete backup of the current program's register state, memory data, and variable values ​​taken at the moment the service is interrupted. Runtime context recovery refers to the process of reloading the program to its state before the interruption using the saved snapshot data, enabling it to continue execution.

[0167] In practical applications, the server continuously monitors system load and priority changes during the resource allocation execution phase. When it needs to preempt computing resources to ensure high-priority core safety tasks (such as ADAS emergency braking), the server records a state snapshot of the interrupted service. For example, when a user is using non-safety-related processes such as in-vehicle navigation or watching videos, if the scenario level suddenly changes to an emergency scenario, the server will package their current CPU usage, cached data, and program pointers into a state snapshot and temporarily store it in memory before suspending these non-safe processes. Subsequently, the system enters a degraded waiting period. When the environmental risk is eliminated and the scenario level switches from high to low (such as from an emergency scenario to a high-risk or low-risk scenario, or from a high-risk scenario to a low-risk scenario), the server detects the release of available resources and restores the running context of the interrupted service based on the previously saved state snapshot. By rewriting the state data in the snapshot into the corresponding registers and memory space, the suspended navigation or entertainment service can seamlessly resume execution from the point of interruption, rather than restarting the entire application. In addition, the server further triggers the system event bus to asynchronously notify the HMI (Human-Machine Interface) and the cloud data closed-loop platform of the arbitration results, resource scheduling status and conflict logs for driver warning and subsequent algorithm iteration.

[0168] In this embodiment, by recording state snapshots and restoring the runtime context when the scene level decreases, seamless interruption and rapid recovery of non-core services are achieved, optimizing the user experience during system resource scheduling.

[0169] In one exemplary embodiment, the method further includes:

[0170] Sensor failure detection is performed. If a single sensor failure is detected, data from similar sensors is used to complete the failure detection.

[0171] If the number of critical sensor failures reaches a preset number, the risk factor is switched to the first risk value, triggering the first mode, which retains only basic driving assistance functions, and the critical sensors are those whose influence weight exceeds a preset threshold.

[0172] If all sensors are detected to be malfunctioning, the risk factor is adjusted to the second risk value, triggering the second mode.

[0173] Among them, the first risk value is less than the second risk value, and the types of in-vehicle services in the first mode are more than those in the second mode.

[0174] In this embodiment, "same-type sensor data completion" refers to a redundant processing mechanism that uses the output data of other normally functioning sensors of the same type to replace the missing data when a specific type of sensor malfunctions. Key sensors refer to core perception devices in autonomous driving perception systems whose influence weight on overall environmental modeling and decision-making exceeds a preset threshold (influence weight > 30%), such as LiDAR.

[0175] In this embodiment, the first mode can be a restricted service mode, which is a degraded vehicle operation mode in which the system actively restricts some advanced autonomous driving functions, retaining only basic driving assistance functions. The second mode can be a safety mode, which is the final protection state triggered by the vehicle's control system when facing an extremely serious fault. In this mode, the vehicle only maintains the most basic vehicle control functions. The first risk value is determined based on the number of currently failed critical sensors and their impact weights, and is used to trigger the first mode. The second risk value is determined based on the number of currently failed critical sensors and their impact weights, and is used to trigger the second mode. The preset quantity is the maximum fault tolerance threshold obtained through Fault Mode and Effects Analysis (FMEA) based on the hardware redundancy configuration, heterogeneous complementarity capabilities, and minimum perception completeness requirements required for the system to maintain basic driving assistance functions. The preset threshold can be determined based on the perception accuracy, environmental adaptability, and heterogeneous complementarity characteristics of different sensors in various driving scenarios, through adaptive filtering algorithms (such as dynamic weight allocation using the covariance matrix) or scenario-based factor calibration.

[0176] In practical applications, the server performs real-time failure detection on various sensors mounted on the vehicle. If a single sensor failure is detected, the server will immediately use data collected by a similar sensor of the same type as the failed sensor to complete the data, or use Kalman filtering to predict values. For example, if one of the multiple cameras positioned in front of the vehicle fails due to lens obstruction, the server will automatically extract image data from adjacent cameras for field-of-view stitching and information compensation, thereby maintaining the integrity of the perception system. Simultaneously, the server will further count the number of failures of critical sensors (i.e., sensors with an impact weight exceeding 30%). When the number of critical sensor failures reaches a preset number (e.g., 2), it indicates a significant drop in current perception confidence. At this point, the server will switch the risk coefficient to the first risk value (default 70, corresponding to the upper limit of medium-risk scenarios) and control the vehicle to enter a restricted service mode. In this mode, only basic driver assistance functions are retained, and the maximum speed may be automatically limited or automatic lane changing may be prohibited, guiding the driver to take over or directing the vehicle to a safe area at low speed. In the most extreme case, if all sensors fail, meaning the vehicle has completely lost its reliable perception of the external environment, the server will immediately trigger the second mode, the safety mode, and forcibly set the risk factor to the second risk value, such as 100 (i.e., an emergency scenario), maintaining only the most basic vehicle control functions. This operation aims to completely cut off all advanced driver assistance functions that rely on external perception, forcing the underlying actuators to adopt a conservative strategy (such as smoothly braking to a stop) to prevent the vehicle from engaging in dangerous behavior when it has lost its reliable perception of the external environment. It is understood that both the first and second risk values ​​can be set according to actual conditions and are not uniquely limited here.

[0177] In this embodiment, by classifying and responding to sensor failures, the risk coefficient can be dynamically adjusted according to the severity of the fault, and a corresponding degradation strategy can be matched, which effectively improves the safety and robustness of the vehicle in the event of hardware anomalies.

[0178] To provide a clearer explanation of the vehicle dynamic control method provided in this application, a specific embodiment is described below, which includes the following:

[0179] After the vehicle starts, the server first acquires raw data from each sensor through a hardware interface and performs rigorous spatiotemporal synchronization processing to generate unified scene description data. Specifically, at the hardware level, the domain controller serves as the master clock node, and a global time reference is distributed based on the GPS second pulse to ensure that the hardware clock deviation of each sensor is less than 1 microsecond. Hardware trigger lines ensure strict alignment between the exposure midpoint of the forward-looking camera image and the global time. At the software level, a sampling cycle with a period of 50ms is generated. Low-frequency data is resampled using linear interpolation, while high-frequency data uses the most recent timestamp measurement. Image data is motion-compensated using IMU or wheel speed data and projected onto the vehicle pose at the sampling cycle time. At the spatial level, the polar coordinate data from the millimeter-wave radar is transformed to the vehicle coordinate system using an extrinsic parameter matrix. The pixel coordinates of the forward-looking camera are mapped to 3D ground coordinates in the vehicle coordinate system through inverse perspective transformation. Driver and vehicle state data within the cabin are logically concatenated as scalars or state vectors during the feature extraction stage. After completing spatiotemporal alignment, feature extraction is performed on the processed multi-source sensor data to generate scene description data containing 12-dimensional feature vectors. Specifically, the scene description data includes 12 feature vectors: vehicle distance, relative speed, vehicle speed, TTC, steering wheel angle, lane departure angle, driver eye movement frequency, blink frequency, hand grip torque, weather conditions, light intensity, and road curvature.

[0180] Next, the server inputs the scene description data into an SVM-based scene classifier for scene perception, identifies the category of the current driving scene, and determines the current driving scene type. Then, the driving scene type is one-hot encoded, and the encoded driving scene type is concatenated and fused with a 12-dimensional feature vector to obtain a fused feature vector. The fused feature vector is then input into a trained safety assessment model for analysis and reasoning to obtain the risk coefficient of the current driving scene output by the safety assessment model.

[0181] When the server receives multiple control commands and there are conflicts among them, a preset multimodal arbitration mechanism is triggered to generate a target control command. First, for each control command among the multiple sources, the execution of that command is simulated, and the change in the risk coefficient S for the next cycle is predicted. If the prediction shows that executing the command will cause the vehicle to break through the safety envelope, i.e., an emergency scenario where the risk coefficient S suddenly rises to over 90, the server will determine that the command exceeds the safety boundary conditions, then forcibly lower the priority of the high-priority command and immediately trigger a safety strategy, such as triggering the system's highest priority AEB (Automatic Emergency Braking) or LKA (Lane Keeping Assist) safety fallback strategy. When the system is in a non-emergency state (i.e., the risk coefficient has not exceeded the critical value or the safety boundary conditions), an adaptive weighted fusion algorithm is used for coordination to obtain the target control command. After the target command is generated, the server dynamically allocates computing resources and communication bandwidth according to service priority to ensure that high-priority control links are exclusively or preferentially guaranteed.

[0182] Throughout the process, the server continuously monitors the health status of the sensors and performs graded degradation processing: when a single sensor fails, it uses similar data to complete the data or uses Kalman filtering to predict the value, maintaining the normal calculation of the risk coefficient; when two or more critical sensors with an impact weight exceeding 30% fail, it enters the first mode (restricted service mode) that only retains basic driving assistance functions, and switches the risk coefficient to a preset conservative value such as 70 (the threshold for judging medium-risk scenarios); when all sensors fail, it enters the second mode (safe mode), resets all service priorities to the baseline configuration, forcibly sets the risk coefficient to 100, and only maintains the most basic vehicle control functions to achieve system-level fallback takeover.

[0183] The above-mentioned solution effectively eliminates spatiotemporal errors between multi-source heterogeneous sensors by constructing a rigorous data fusion foundation that integrates underlying hardware clock synchronization, software data alignment, and spatial coordinate unification, ensuring accurate and consistent perception information. Based on this, a multimodal arbitration mechanism is dynamically triggered according to the safety factor of the current driving scenario, and adaptive weight allocation and smooth fusion are performed in conjunction with context factors. This not only ensures a safety safety net in emergency scenarios but also reduces control abrupt changes during non-emergency conflicts, significantly improving driving safety and passenger comfort. Simultaneously, in conjunction with a priority-based dynamic resource allocation strategy and a multi-gradient sensor failure degradation handling mechanism, computing power and bandwidth resources can be flexibly allocated under various extreme conditions, ensuring the stability and reliability of the core control link.

[0184] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0185] Based on the same inventive concept, this application also provides a vehicle dynamic control device for implementing the vehicle dynamic control method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more vehicle dynamic control device embodiments provided below can be found in the limitations of the vehicle dynamic control method described above, and will not be repeated here.

[0186] In one exemplary embodiment, such as Figure 7 As shown, a vehicle dynamic control device 600 is provided, including: a data processing module 610, a driving scene perception module 620, a scene level determination module 630, an arbitration module 640, and a control module 650, wherein:

[0187] The data processing module 610 is used to acquire multi-source sensor data of the vehicle, perform spatiotemporal alignment processing on the multi-source sensor data, and generate scene description data.

[0188] The driving scenario perception module 620 is used to determine the risk coefficient of the current driving scenario based on scenario description data.

[0189] The scenario level determination module 630 is used to map the risk coefficient to the scenario level of the driving scenario.

[0190] Arbitration module 640 is used to generate target control commands by triggering a preset multimodal arbitration mechanism based on the scene level when receiving multi-source control commands and there are conflicts between the multi-source control commands.

[0191] Control module 650 is used to control the vehicle based on target control commands.

[0192] In some exemplary embodiments, the driving scene perception module 620 is further configured to determine the current driving scene type based on scene description data; fuse the scene description data and the driving scene type to obtain a fused feature vector; input the fused feature vector into a trained safety assessment model for analysis and reasoning to obtain the risk coefficient of the current driving scene output by the safety assessment model; wherein, the safety assessment model is trained on a cascaded neural network with a channel attention mechanism based on historical multi-source sensor data carrying risk coefficient labels.

[0193] In some exemplary embodiments, the driving scene perception module 620 is further configured to extract local nonlinear coupling relationships between adjacent features in the fused feature vector through one-dimensional convolution operations; perform global compression and channel-to-channel nonlinear dependency learning on the extracted local nonlinear coupling relationships to generate dynamic weight vectors for each feature channel; recalibrate the local nonlinear coupling relationships channel by channel based on the dynamic weight vectors, and map the recalibrated features to risk coefficients to obtain the risk coefficients of the current driving scene output by the safety assessment model.

[0194] In some exemplary embodiments, the arbitration module 640 is further configured to project multi-source control commands onto a unified preset coordinate system, determine the trajectory deviation within a preset prediction time domain, determine a conflict index based on the trajectory deviation and risk coefficient, determine that there is a target type conflict between the multi-source control commands if the conflict index is greater than a preset index threshold, construct safety boundary conditions based on the risk coefficient, adjust the multi-source control commands according to the safety boundary conditions, and generate target control commands.

[0195] In some exemplary embodiments, the arbitration module 640 is further configured to, for each control instruction in the multi-source control instructions, determine whether the execution of the control instruction will cause the vehicle to exceed the safety boundary conditions; if the execution of the control instruction will cause the vehicle to exceed the safety boundary conditions, intercept the control instruction and generate a target control instruction based on a preset safety strategy; if the vehicle does not exceed the safety boundary conditions after the execution of each control instruction, obtain the confidence level of each control instruction, assign fusion weights based on the confidence level of each control instruction, and perform weighted smooth fusion of each control instruction based on the fusion weights of each control instruction to generate the target control instruction.

[0196] In some exemplary embodiments, the data processing module 610 is further configured to synchronize the time of multi-source sensor data by combining hardware triggering and software compensation, mapping the multi-source sensor data to a unified time reference; and to spatially align the multi-source sensor data by using a spatial transformation method based on the extrinsic calibration matrix, transforming the multi-source sensor data to a unified vehicle coordinate system.

[0197] like Figure 8As shown, in some exemplary embodiments, the device further includes a resource scheduling module 660, which is used to perform hierarchical scheduling of on-board computing resources and communication resources based on scene level.

[0198] In some exemplary embodiments, the apparatus further includes a service recovery module 670, which is used to record a state snapshot of the interrupted service during the execution of resource allocation; and to restore the running context of the interrupted service based on the state snapshot when the scenario level switches from a high level to a low level.

[0199] In some exemplary embodiments, the device further includes a sensor detection module 680 for detecting sensor failures in the vehicle; when a single sensor failure is detected, data from similar sensors of the failed sensor is used to complete the detection; when the number of failed critical sensors reaches a preset number, the risk coefficient is adjusted to a preset first risk value, triggering a first mode where only basic driving assistance functions are retained, and critical sensors are those whose influence weight exceeds a preset threshold; when all sensors are detected to be failed, a second mode is triggered, the risk coefficient is adjusted to a preset second risk value, and the second mode is triggered; wherein the first risk value is less than the second risk value, and the number of in-vehicle services in the first mode is greater than the number of in-vehicle services in the second mode.

[0200] Each module in the aforementioned vehicle dynamic control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0201] In one exemplary embodiment, a vehicle-side control device is provided, the internal structure of which can be shown in the following diagram. Figure 9 As shown, the vehicle-side control device includes a processor and a memory. The processor provides computational and control capabilities. The memory includes a non-volatile storage medium storing a computer program. When executed by the processor, the computer program implements a vehicle dynamic control method.

[0202] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the vehicle-side control device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0203] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0204] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0205] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0206] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0207] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program mentioned can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

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

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

Claims

1. A vehicle dynamic control method, characterized in that, The method includes: Acquire multi-source sensor data of the vehicle, perform spatiotemporal alignment processing on the multi-source sensor data, and generate scene description data; Based on the scenario description data, determine the risk coefficient of the current driving scenario; The risk coefficient is mapped to the scenario level of the driving scenario; When a multi-source control command is received and there are conflicts among the multi-source control commands, a preset multimodal arbitration mechanism is triggered based on the scenario level to generate a target control command. The multimodal arbitration mechanism is a dynamic arbitration mechanism that combines kinematic constraint priority with functional safety degradation. The vehicle is controlled based on the target control command.

2. The method according to claim 1, characterized in that, Determining the risk coefficient of the current driving scenario based on the scenario description data includes: Based on the scenario description data, the current driving scenario type is determined; By fusing the scenario description data and the driving scenario type, a fused feature vector is obtained. The fused feature vector is then input into a trained safety assessment model for analysis and reasoning to obtain the risk coefficient of the current driving scenario output by the safety assessment model. The security assessment model is obtained by training a cascaded neural network with a channel attention mechanism based on historical multi-source sensor data carrying risk coefficient labels.

3. The method according to claim 2, characterized in that, The analytical reasoning includes: Local nonlinear coupling relationships between adjacent features in the fused feature vector are extracted using one-dimensional convolution operations. The extracted local nonlinear coupling relationships are globally compressed and the nonlinear dependencies between channels are learned to generate dynamic weight vectors for each feature channel. Based on the dynamic weight vector, the local nonlinear coupling relationship is recalibrated channel by channel, and the recalibrated features are mapped to risk coefficients to obtain the risk coefficients of the current driving scenario output by the safety assessment model.

4. The method according to claim 1, characterized in that, The preset multimodal arbitration mechanism triggered based on the scene level generates target control commands, including: The multi-source control commands are projected onto a unified preset coordinate system to determine the trajectory deviation in the preset prediction time domain; The conflict index is determined based on the trajectory deviation and the risk coefficient; If the conflict index is greater than a preset index threshold, it is determined that there is a target type conflict among the multi-source control commands. Based on the risk coefficient, a safety boundary condition is constructed, and the multi-source control commands are adjusted according to the safety boundary condition to generate target control commands.

5. The method according to claim 4, characterized in that, The step of adjusting the multi-source control commands according to the safety boundary conditions to generate target control commands includes: For each control instruction in the multi-source control instructions, determine whether the execution of the control instruction will cause the vehicle to exceed the safety boundary conditions; If the execution of the control command would cause the vehicle to exceed the safety boundary conditions, the control command would be intercepted, and a target control command would be generated based on a preset safety strategy. If the vehicle does not exceed the safety boundary conditions after each control command is executed, the confidence level of each control command is obtained, a fusion weight is assigned based on the confidence level of each control command, and a weighted smooth fusion is performed on each control command based on the fusion weight of each control command to generate the target control command.

6. The method according to claim 1, characterized in that, The spatiotemporal alignment processing of the multi-source sensor data includes: The multi-source sensor data is synchronized in time by combining hardware triggering and software compensation, and the multi-source sensor data is mapped to a unified time reference. The multi-source sensor data is spatially aligned using a spatial transformation method based on the extrinsic calibration matrix, transforming the multi-source sensor data to a unified vehicle coordinate system.

7. The method according to claim 1, characterized in that, After generating the target control command by triggering a preset multimodal arbitration mechanism based on the scene level, the method further includes: Based on the aforementioned scenario level, on-board computing and communication resources are scheduled in a tiered manner.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: During the resource allocation process, a snapshot of the state of the interrupted service is recorded; When the scenario level switches from a high level to a low level, the running context of the interrupted service is restored based on the state snapshot.

9. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Failure detection is performed on the sensors of the vehicle; In the event of a single sensor failure, data from a similar sensor to the failed sensor is used to complete the detection. If the number of failures of key sensors reaches a preset number, the risk coefficient is adjusted to the first risk value, triggering the first mode, which retains only the basic driving assistance function. The key sensor is a sensor whose influence weight exceeds a preset threshold. If all sensors are detected to be malfunctioning, the risk coefficient is adjusted to a second risk value, triggering the second mode; Wherein, the first risk value is less than the second risk value, and the types of in-vehicle services in the first mode are more than the types of in-vehicle services in the second mode.

10. A vehicle dynamic control device, characterized in that, The device includes: The data processing module is used to acquire multi-source sensor data of the vehicle, perform spatiotemporal alignment processing on the multi-source sensor data, and generate scene description data. The driving scenario perception module is used to determine the risk coefficient of the current driving scenario based on the scenario description data. The scenario level determination module is used to map the risk coefficient to the scenario level of the driving scenario; The arbitration module is used to trigger a preset multimodal arbitration mechanism based on the scenario level when receiving multi-source control commands and there are conflicts among the multi-source control commands, generate a target control command, and control the vehicle based on the target control command.

11. A vehicle-end control device, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images