Vehicle control system

Abstract

The invention is applicable to the technical field of automobiles, and provides a vehicle control system, which comprises a context management module, a control module, a control module and a control module, wherein the context management module is used for acquiring environment data and constructing an environment model based on the environment data; the scheduling module is used for determining a target processing model based on the environment model and sending a model loading request to the model management module; the model loading request carries a target processing model; the model management module is used for loading a target processing model based on the model loading request; the scheduling module is further used for receiving the model processing result and generating a control instruction based on the model processing result so that the vehicle can run based on the control instruction. The model processing result is obtained by deploying the target processing model at the target computing node for processing by the scheduling module. The distributed architecture of the system improves the reliability of the system and reduces the complexity of the system. Meanwhile, the system loads the model as required and allocates the model to the corresponding computing node for processing, so that the resource utilization rate is improved, and the system performance is further improved.

Description

Technical Field

[0001] This application belongs to the field of automotive technology, and in particular relates to a vehicle control system. Background Technology

[0002] In practical applications, autonomous driving systems are intelligent systems that rely on technologies such as sensors, artificial intelligence algorithms, and high-precision maps to enable vehicles to drive autonomously or with assistance. Their core is to complete driving tasks through a closed-loop technology system of perception, decision-making, and execution. However, existing autonomous driving systems typically employ a centralized architecture, which suffers from insufficient comprehensiveness and difficulty in meeting actual needs. Summary of the Invention

[0003] This application provides a vehicle control system to address the problem that existing technologies are not comprehensive enough and fail to meet practical needs.

[0004] In a first aspect, embodiments of this application provide a vehicle control system, including: The context management module is used to acquire environmental data and construct an environmental model based on the environmental data. The scheduling module is used to determine the target processing model based on the environment model and send a model loading request to the model management module; the model loading request carries the target processing model. The model management module is used to load the target processing model based on the model loading request; The scheduling module is also used to receive model processing results and generate control commands based on the model processing results so that the vehicle can drive based on the control commands; the model processing results are obtained by the scheduling module deploying the target processing model on the target computing node for processing.

[0005] This application provides a vehicle control system, including a context management module for acquiring environmental data and constructing an environmental model based on the environmental data; a scheduling module for determining a target processing model based on the environmental model and sending a model loading request to a model management module; the model loading request carries the target processing model; the model management module loads the target processing model based on the model loading request; the scheduling module also receives the model processing results and generates control commands based on the model processing results, so that the vehicle can drive according to the control commands; the model processing results are obtained by the scheduling module deploying the target processing model on the target computing node for processing. The distributed architecture of this system improves system reliability and reduces system complexity. At the same time, the system's on-demand model loading and allocation of models to corresponding computing nodes for processing improves resource utilization and thus improves system performance.

[0006] Optionally, the environmental data includes initial data collected by different sensors, and the construction of an environmental model based on the environmental data includes: Based on the initial data, the scene complexity is determined; Based on the aforementioned scenario complexity, a target fusion strategy is determined; Based on the target fusion strategy, all the initial data are fused to obtain fused data; The environment model is constructed based on the fused data.

[0007] In the above implementation, the scene complexity is first determined by the initial data, which enables the context management module to accurately identify the complexity of the current driving scene and avoid a one-size-fits-all approach. Then, the target fusion strategy is matched based on the scene complexity, which can ensure that sensor data can be integrated in the best way under different complexity scenarios, reducing the problem of data redundancy or missing key information, making the final constructed environment model more in line with the real road conditions, thereby improving the accuracy of environmental perception.

[0008] Optionally, determining the target processing model based on the environment model includes: The environmental model is analyzed to determine its environmental complexity. Based on the environmental complexity, the target processing model is determined.

[0009] In the above implementation, the environmental model is first analyzed and the environmental complexity is determined, which can accurately anchor the core characteristics and decision-making needs of the current vehicle environment. Then, the target processing model is matched based on the environmental complexity, which avoids the waste of resources in using high-end models to process simple scenarios and also eliminates the inadequacy of using basic models to deal with complex scenarios. This allows the processing model to fully adapt to the decision-making needs of the current environment, thereby optimizing the allocation of computing resources.

[0010] Optionally, before determining the target processing model based on the environment model, the scheduling module is further configured to: The current task is generated based on the environment model, and the task priority of the current task is determined; Obtain the computing resource status of the vehicle control system; Based on the task priority and the computing resource status, the resource allocation information for the current task is determined, and the resource allocation information is sent to each computing node associated with the current task.

[0011] In the above implementation, the tasks generated based on the environment model are highly correlated with the current driving scenario. Then, resources are allocated by combining task priority with real-time computing resource status, making task processing more targeted in different scenarios. At the same time, allocating resources based on task priority and real-time computing resource status avoids resource idleness or overload, ensuring the processing efficiency of core tasks while fully utilizing idle resources to complete non-core tasks, thereby improving system resource utilization.

[0012] Optionally, the vehicle control system further includes a perception module and a planning and control module; the target processing model includes a first processing model corresponding to the perception module and a second processing model corresponding to the planning and control module; the model processing result includes perception-side data and decision-side data. The sensing module is used to input the environmental data into the first processing model for processing to obtain the sensing side data; The planning and control module is used to input the environmental data and the sensing data into the second processing model for processing to obtain the decision-side data.

[0013] In the above implementation, the perception module focuses on generating perception-side data by processing environmental data through a first processing model, while the planning and control module focuses on generating decision-side data by combining environmental data and perception-side data through a second processing model, thus achieving hierarchical and specialized processing of perception and decision-making. Simultaneously, each module focuses on its core task, avoiding the problem of excessive processing pressure and decreased accuracy caused by a single module simultaneously undertaking both perception and decision-making tasks.

[0014] Optionally, the first processing model includes multiple heterogeneous sub-models, wherein the environmental data is input into the first processing model for processing to obtain the sensing-side data. The environmental data is sequentially input into each of the heterogeneous sub-models for processing, and the processing results corresponding to each of the heterogeneous sub-models are obtained. The processing results are matched to obtain the matching results; The sensing-side data is obtained based on the matching results.

[0015] In the above implementation, since each heterogeneous sub-model has different perception advantages, by sequentially inputting environmental data into each heterogeneous sub-model for processing, multi-dimensional and multi-perspective perception results can be obtained. Then, by matching and integrating the advantages through the results, the perception shortcomings of a single model can be made up for, making the final output perception data more comprehensive and accurate.

[0016] Optionally, the first processing model includes multiple heterogeneous sub-models, and the step of inputting the environmental data into the first processing model for processing to obtain the sensing-side data includes: The environmental data is input into the first heterogeneous sub-model for processing to obtain initial sensing data; If the initial sensing data is abnormal, the environmental data is input into the second heterogeneous sub-model for processing to obtain the sensing-side data.

[0017] In the above implementation, the first heterogeneous sub-model is responsible for rapid perception of normal scenarios, while the second heterogeneous sub-model serves as a backup solution to handle abnormal situations, forming a dual guarantee of the main model and the backup model. This avoids the perception interruption problem caused by the failure of a single model, ensures that the perception process is not interrupted, and provides continuous and stable input for subsequent decision-making.

[0018] Optionally, the model processing result includes perception-side data and decision-side data, wherein the decision-side data includes at least one alternative driving trajectory; generating control commands based on the model processing result includes: The decision-side data is evaluated based on the perception-side data to obtain evaluation results of the decision-side data in different dimensions; Based on the evaluation results of the decision-side data in different dimensions, a total score is obtained for each of the at least one alternative driving trajectory. The target driving trajectory is determined based on the total scores mentioned above; The control command is generated based on the target driving trajectory.

[0019] In the above implementation, the candidate driving trajectory is evaluated from multiple dimensions by combining the data from the perception side, which avoids closed-door decision-making that relies solely on the output of the decision model and is divorced from the actual environment. Then, the multi-dimensional evaluation results are converted into a total score of the candidate trajectory. The optimal trajectory is selected by quantitative comparison, which replaces the subjective or single-dimensional decision-making method. This ensures that the target trajectory not only conforms to the actual environment, but also takes into account multiple requirements such as safety, efficiency, and compliance, and greatly improves the accuracy of decision-making.

[0020] Optionally, the context management module is further configured to receive system status data from the vehicle control system and generate a system health structured data block based on the system status data; The scheduling module is also used to determine abnormal results based on the system health structured data block, determine a degradation processing strategy based on the abnormal results, and generate configuration instructions based on the degradation processing strategy. The context management module is also used to perform operations corresponding to the configuration instructions.

[0021] In the above implementation, the context management module receives system status data in real time and generates structured health data blocks, which can accurately and comprehensively monitor the operating status of each component of the system and realize early identification of anomalies. The scheduling module quickly determines the abnormal results based on the health data blocks and formulates corresponding degradation processing strategies based on the abnormal results to ensure that the system can maintain its core functions even when it is not in a fully healthy state. Finally, the configuration instructions generated by the scheduling module are directly executed by the context management module, forming a closed-loop adjustment mechanism from anomaly monitoring to strategy formulation and instruction execution, thereby enabling the system to achieve "self-healing" adjustment.

[0022] Optionally, the context management module is further configured to: After executing the operation corresponding to the configuration instruction, the degradation processing result of the vehicle control system is obtained; If the degradation process results in the first result, then a system recovery operation is performed; the first result is used to characterize the disappearance of the anomaly. If the degradation process results in the second result, the degradation operation continues; the second result is used to characterize the persistence of the anomaly.

[0023] In the above implementation, after executing the configuration command, the abnormal state can be verified a second time by obtaining the degradation processing result: if the abnormality disappears (first result), a system recovery operation is triggered, allowing the system to return to normal operating mode and avoiding functional limitations caused by prolonged degradation; if the abnormality persists (second result), degradation continues, ensuring the system is always in a safe and controllable state. This closed-loop logic of execution-feedback-adjustment solves the problems of ineffectiveness (such as the abnormality being eliminated after degradation but not being restored) or insufficient security (such as the abnormality still existing after degradation but not being further processed) that may exist in traditional one-time degradation, making abnormality handling more accurate and efficient. At the same time, the automatic feedback and operation adjustment of the abnormality handling result can complete the entire process from degradation to verification, and then to recovery / continued degradation without manual intervention, improving the system's self-healing efficiency and reducing the need for manual intervention. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram of the structure of a vehicle control system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the specific implementation of the construction environment model provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of a vehicle control system provided in another embodiment of this application; Figure 4 This is a flowchart illustrating the specific implementation of obtaining sensing-side data according to an embodiment of this application; Figure 5 This is a flowchart illustrating the specific implementation of obtaining sensing-side data according to another embodiment of this application; Figure 6 This is a flowchart illustrating the specific implementation of the generation control instructions provided in one embodiment of this application; Figure 7 This is a flowchart illustrating the specific implementation of the context management module provided in one embodiment of this application. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0027] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0028] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0030] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0032] In practical applications, autonomous driving systems are intelligent systems that rely on technologies such as sensors, artificial intelligence algorithms, and high-precision maps to enable vehicles to drive autonomously or with assistance. Their core is to complete driving tasks through a closed-loop technology system of perception, decision-making, and execution. Currently, mainstream autonomous driving systems typically employ a centralized architecture, which suffers from low system performance.

[0033] Therefore, this application provides a vehicle control system that, through a distributed architecture consisting of a context management module, a scheduling module, and a model management module, can improve resource utilization and system performance.

[0034] Please see Figure 1 , Figure 1 This is a schematic diagram of a vehicle control system provided in one embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown, and are described in detail below: like Figure 1 As shown, the vehicle control system 1 includes: a context management module 10, a scheduling module 20, and a model management module 30.

[0035] It should be noted that the context management module 10, the scheduling module 20, and the model management module 30 can all communicate with each other through the Model Context Protocol (MCP).

[0036] In practical applications, MCP is an open protocol that can be called a universal interaction language in the field of artificial intelligence (AI). MCP defines a unified data format, interface specifications, and communication mechanism, enabling efficient context passing and collaboration between different AI models and between models and external systems.

[0037] In this embodiment, the context management module 10 is used to acquire environmental data and construct an environmental model based on the environmental data.

[0038] The scheduling module 20 is used to determine the target processing model based on the environment model and send a model loading request to the model management module.

[0039] The model management module 30 is used to load the target processing model based on the model loading request.

[0040] The scheduling module 20 is also used to receive the model processing results and generate control commands based on the model processing results so that the vehicle can drive according to the control commands.

[0041] In this embodiment, after the vehicle control system is started, the context management module 10 can acquire environmental data of the area where the target vehicle is located in real time through a data acquisition device wirelessly connected to it. The data acquisition device can be different types of sensors, such as cameras (e.g., forward-looking, surround-view, infrared), lidar (e.g., mechanical / solid-state), millimeter-wave radar (e.g., forward-facing, angle radar), ultrasonic radar, V2X communication units (e.g., DSRC / 5G-V2X), and high-precision map boxes (which can be considered static data sources), etc.

[0042] Environmental data includes, but is not limited to, traffic light status, pedestrian behavior, the location of surrounding vehicles, and weather conditions.

[0043] After obtaining the aforementioned environmental data, the context management module 10 can extract features from the environmental data to obtain environmental features, and construct a structured environmental model based on these environmental features. These environmental features include, but are not limited to, the number of obstacles, road type, pedestrian density, and weather level.

[0044] It should be noted that the above environmental model includes the following dimensions: Static dimensions: road topology (e.g., number of lanes, turning rules), traffic signs (e.g., speed limits, traffic lights), and fixed obstacles (e.g., guardrails, streetlights); Dynamic dimension: Prediction of the position, speed, and trajectory of moving targets (such as vehicles, pedestrians, and non-motorized vehicles); Environmental dimensions: weather level, visibility, and road surface friction coefficient; Vehicle dimension: The target vehicle's coordinates, heading angle, and relative distance to surrounding vehicles in the environment.

[0045] In some possible embodiments, the above-described environment model can be stored in ProtoBuf format, carrying a timestamp and data confidence level (0-100%).

[0046] After obtaining the above environment model, the context management module 10 can send the environment model to the scheduling module 20 through the MCP protocol.

[0047] In this embodiment of the application, after receiving the above-mentioned environment model, the scheduling module 20 can determine the target processing model based on the environment model.

[0048] Specifically, the scheduling module can determine the target processing model corresponding to the environment model obtained at this time based on the environment model obtained at this time and the pre-stored correspondence between different environment models and different processing models.

[0049] It should be noted that the above target processing model can be one or multiple.

[0050] In some possible embodiments, in order to ensure that the target processing model fully adapts to the decision-making needs of the current environment and optimizes the allocation of computing resources, the scheduling module 20 may specifically determine the target processing model according to the following steps, detailed below: Analyze the environmental model to determine its environmental complexity; Based on the complexity of the environment, the target processing model is determined.

[0051] In this embodiment, the scheduling module 20 can analyze the environment model and determine the environmental complexity of the environment model.

[0052] Specifically, the scheduling module 20 can first parse the data of each dimension used for determining the environment complexity from the environment model.

[0053] The data for each dimension includes: Dynamic target dimension: number of moving targets (vehicles / pedestrians / non-motorized vehicles) and dynamic target density (number of targets per square kilometer); Road dimensions: road type (expressway / urban / rural), road structure (straight / curve / intersection), and road condition (construction / closure). Environmental dimensions: visibility (m), weather type (sunny / rainy / foggy / snowy) and lighting conditions (daytime / nighttime / tunnel); Vehicle status dimensions: current vehicle speed (km / h), distance to the nearest dynamic target (m); Traffic rules dimension: Is it a school / hospital area (which requires speed limits)? Are there traffic lights / zebra crossings?

[0054] After obtaining the data for each dimension, the scheduling module 20 can compare the data for each dimension with the corresponding thresholds in the predefined complexity grading system to determine the complexity level tendency of each dimension.

[0055] It should be noted that the above complexity classification system includes thresholds for each dimension of data corresponding to different complexity levels. The thresholds for each dimension of data corresponding to different complexity levels can be determined according to actual needs, and are not restricted here.

[0056] Then, the scheduling module 20 can count the number of data tendencies at each complexity level based on the complexity level tendencies corresponding to the data in each dimension, and directly determine the complexity level with the largest number of data tendencies as the environment complexity of the environment model.

[0057] After determining the environmental complexity of the environment model, the scheduling module 20 can determine the target processing model based on the determined environmental complexity and the pre-stored correspondence between different complexity levels and different processing models. These different processing models include, but are not limited to, the BEV+Transformer model and a lightweight CNN model.

[0058] The scheduling module 20 can generate a model loading request based on the target processing model and send the model loading request to the model management module 30. The model loading request carries the target processing model 30.

[0059] In this embodiment of the application, after receiving the above-mentioned model loading request, the model management module 30 can select the target processing model from its own model library for loading based on the model loading request.

[0060] When the scheduling module 20 detects that the target processing model has been loaded, it can deploy the target processing model to the target computing node to trigger model inference.

[0061] After completing model inference and obtaining the model processing result, the target computing node can send the model processing result back to the scheduling module 20 via the MCP protocol.

[0062] In one embodiment of this application, the target computing node may also send the above model processing results to the context management module 10 via the MCP protocol.

[0063] In this embodiment of the application, after receiving the receiving model processing result, the scheduling module 20 can generate control commands based on the model processing result so that the vehicle can drive based on the control commands.

[0064] It should be noted that the model processing results include, but are not limited to, perception-side data and decision-side data.

[0065] Perception-side data includes, but is not limited to: 3-D detection boxes, segmentation masks, and target trajectory predictions; decision-side data includes, but is not limited to: at least one alternative driving trajectory.

[0066] Among them, the 3-D detection frame is used to clarify the spatial relationship between the trajectory and obstacles.

[0067] Target trajectory prediction is used to anticipate the time dimension of dynamic risks.

[0068] The segmentation mask is used to define the legal driving range of at least one alternative driving trajectory.

[0069] In this embodiment of the application, the scheduling module 20 can evaluate the above-mentioned at least one alternative driving trajectory based on the sensing side data, obtain the total score of each of the at least one alternative driving trajectory, and generate control instructions based on the alternative driving trajectory with the highest total score.

[0070] Subsequently, the scheduling module 20 can send the aforementioned control commands to the execution layer (such as ECU / domain controller) of the target vehicle, and the execution layer controls the power system, steering system and braking system of the target vehicle according to the control commands.

[0071] In some possible embodiments, the context management module 10 can continuously receive environmental data after the target vehicle executes the above control commands and continue to build an environmental model based on the data to form a closed loop of perception-decision-execution-feedback.

[0072] As can be seen from the above, the vehicle control system provided in this application includes a context management module for acquiring environmental data and constructing an environmental model based on the environmental data; a scheduling module for determining a target processing model based on the environmental model and sending a model loading request to a model management module; the model loading request carries the target processing model; the model management module is used to load the target processing model based on the model loading request; the scheduling module is also used to receive the model processing result and generate control commands based on the model processing result so that the vehicle can drive according to the control commands; the model processing result is obtained by the scheduling module deploying the target processing model on the target computing node for processing. The distributed architecture of this system improves system reliability and reduces system complexity. At the same time, the system loads models on demand and allocates models to corresponding computing nodes for processing, improving resource utilization and thus improving system performance.

[0073] In one embodiment of this application, when the environmental data includes initial data collected by different sensors, in order to ensure that the sensor data can be optimally integrated in scenarios of varying complexity to reduce data redundancy or missing key information, and to make the final constructed environmental model more closely resemble real road conditions, thereby improving the accuracy of environmental perception, please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating the specific implementation of the construction environment model provided in one embodiment of this application. For example... Figure 2 As shown in this embodiment, the context management module can determine the constructed environment model according to the following steps, detailed below: In S101, the scene complexity is determined based on the initial data.

[0074] It should be noted that the initial data collected by different sensors may include: Visual: Image / video streams from cameras (e.g., forward-looking / surround-view); Ranging data: point cloud data corresponding to lidar, and radar distance / velocity data corresponding to millimeter wave radar; Environmental data: high-precision map data, GPS / BeiDou positioning data, traffic broadcast (V2X), and weather sensor data (such as rainfall / visibility). Vehicle status data: CAN bus data such as vehicle speed, steering angle, braking pressure, and throttle opening.

[0075] In this embodiment, the context management module can preprocess the initial data collected by different sensors to obtain standard data that eliminates format and noise differences. Then, the context management module can extract features from the standard data to obtain feature data.

[0076] The feature data includes: Camera data includes: number of moving targets (vehicles / pedestrians / non-motorized vehicles), road type (straight / curved / intersection), and weather conditions; Millimeter-wave radar data: range, velocity, azimuth, and target density of dynamic targets; LiDAR data: Position and road contour accuracy of static obstacles (guardrails / construction barriers); Environmental sensor data: visibility, rainfall, and light intensity; High-precision map / GPS data: current road segment type (highway / city / rural), and whether it is a school / construction area, etc.

[0077] In this embodiment, the context management module can compare each feature data with its corresponding threshold in the predefined complexity grading rules to determine the complexity level tendency of each feature data.

[0078] It should be noted that the above complexity grading rules include thresholds for each feature data corresponding to different complexity levels. The thresholds for each feature data corresponding to different complexity levels can be determined according to actual needs, and are not restricted here.

[0079] Then, the context management module can count the number of data tendencies at each complexity level based on the complexity level tendencies corresponding to each feature data, and directly determine the complexity level with the most data tendencies as the scene complexity.

[0080] In S102, the target fusion strategy is determined based on the scene complexity.

[0081] In this embodiment, after determining the scene complexity, the context management module can determine the target fusion strategy based on the determined scene complexity and the pre-stored correspondence between different scene complexities and different fusion strategies.

[0082] Different fusion strategies include, but are not limited to: BEV fusion and multi-view Transformer fusion.

[0083] BEV fusion refers to projecting point clouds from cameras, various radars, and lasers onto a bird's-eye view grid of a set size, and using CNN / Transformer models to extract voxel / pillar features, so as to map the initial data from different sensors to a unified bird's-eye view coordinate system.

[0084] Multi-View Transformer Fusion (MVT) is a computational paradigm based on the Transformer architecture that aims to learn the feature extraction and fusion process uniformly from observation data from multiple perspectives to enhance the understanding of 3D scenes or targets.

[0085] In S103, all initial data are fused based on the target fusion strategy to obtain fused data.

[0086] In S104, an environmental model is constructed based on the fused data.

[0087] In this embodiment, the context management module can fuse initial data collected by different sensors based on a determined target fusion strategy to obtain fused data.

[0088] Then, the context management module can obtain a structured environment model based on the above fused data.

[0089] Specifically, the context management module can build an environment model framework based on the three-dimensional framework of the static environment layer, the dynamic environment layer, and the vehicle's own environment layer.

[0090] It should be noted that the static environment layer needs to include road topology (number of lanes, turning rules, road boundaries), fixed facilities (traffic lights, guardrails, road signs), and geographic information (GPS coordinates, altitude, map matching results), etc.

[0091] The dynamic environment layer needs to include the real-time location, velocity, motion trajectory prediction (e.g., in the next 5 seconds) of all dynamic targets, as well as target priority (pedestrians > non-motorized vehicles > vehicles).

[0092] The vehicle's own environment layer needs to include the target vehicle's current position (i.e., road coordinates), speed, steering angle, relative distance to surrounding vehicles, and the vehicle's drivable area.

[0093] Afterwards, the context management module can populate the obtained fused data into the above environment model framework to obtain the final environment model.

[0094] As can be seen from the above, the vehicle control system provided in this embodiment first determines the scene complexity through initial data, enabling the context management module to accurately identify the complexity of the current driving scene and avoid a one-size-fits-all approach. Then, based on the scene complexity, a target fusion strategy is matched to ensure that sensor data can be integrated in the optimal way under different levels of complexity, reducing data redundancy or missing key information, making the final constructed environment model more consistent with real road conditions, thereby improving the accuracy of environmental perception.

[0095] In another embodiment of this application, in order to achieve reasonable allocation of computing resources so that subsequent task processing in different scenarios is more targeted, the scheduling module 20 may further perform the following steps before determining the target processing model based on the environment model, as detailed below: The current task is generated based on the environment model, and the task priority of the current task is determined. Obtain the computing resource status of the vehicle control system; Based on task priority and computing resource status, the resource allocation information for the current task is determined and sent to each computing node associated with the current task.

[0096] In this embodiment, the scheduling module can determine the environmental scenario based on the environmental model, and determine the required current task based on the environmental scenario. The environmental scenario includes, but is not limited to: simple scenario (such as a highway scenario), complex scenario (such as an urban intersection or construction section), and extreme scenario (such as a congested road section due to heavy rain).

[0097] It should be noted that the tasks corresponding to the simple scenarios mentioned above can be routine patrol missions, the tasks corresponding to complex scenarios can be intersection traffic decision-making missions or route replanning missions, and the tasks corresponding to extreme scenarios can be emergency avoidance missions.

[0098] There can be one or more tasks at present.

[0099] In this embodiment, the scheduling module can determine the task priority based on the degree of impact of the current task on vehicle safety. The task with the greater impact on vehicle safety has a higher priority, meaning it will be executed earlier.

[0100] It should be noted that the computing resource status describes the computing resource utilization of each computing node in the vehicle control system. These computing nodes include, but are not limited to, onboard MCUs, domain controllers, and edge computing units. Computing resource utilization includes, but is not limited to, idle computing power and load rate.

[0101] In this embodiment, the scheduling module can filter computing nodes that meet the task requirements from the global resource state pool, i.e., those currently associated with the task. These task requirements include, but are not limited to, hardware matching (e.g., node type matching the task association model), computing power matching (e.g., the node's idle computing power is greater than or equal to the current task's computing power requirement), and state matching (e.g., the node's load rate is less than a set threshold).

[0102] Then, the scheduling module can determine the resource allocation information for the current task based on a priority-first and efficiency-optimized rule. The specific rules for priority-first and efficiency-optimized are as follows: Priority First: High-priority tasks will be given priority to select the best node (such as one with sufficient idle computing power and low load rate). High-priority tasks can preempt resources of low-priority tasks (after preemption, the low-priority tasks will be migrated to other idle nodes). Optimal efficiency: For tasks of the same priority, select the node with the lowest load rate and the pre-loaded model associated with the task (to reduce model loading time).

[0103] Afterwards, the scheduling module can send the resource allocation information determined above to each computing node associated with the current task.

[0104] As can be seen from the above, the vehicle control system provided in this embodiment generates tasks based on the environment model that are highly correlated with the current driving scenario. Then, by combining task priority and real-time computing resource status, resources are allocated, making task processing more targeted in different scenarios. At the same time, allocating resources based on task priority and real-time computing resource status avoids the problems of resource idleness or resource overload, ensuring the processing efficiency of core tasks while fully utilizing idle resources to complete non-core tasks, thereby improving system resource utilization.

[0105] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a vehicle control system provided in another embodiment of this application. For example... Figure 3 As shown, the vehicle control system 1 may further include a perception module 40 and a planning and control module 50. Correspondingly, the target processing model includes a first processing model corresponding to the perception module 40 and a second processing model corresponding to the planning and control module 50. The model processing results include perception-side data and decision-side data.

[0106] In this embodiment, the sensing module 40 can input environmental data into the first processing model for processing to obtain sensing side data, and send the sensing side data to the scheduling module 20 and the planning and control module 50.

[0107] Subsequently, the planning and control module 50 can input environmental data and sensing data into the second processing model for processing to obtain decision-making data.

[0108] In this embodiment, the perception module focuses on generating perception-side data by processing environmental data through a first processing model, while the planning and control module focuses on generating decision-side data by combining environmental data and perception-side data through a second processing model, thus achieving hierarchical and specialized processing of perception and decision-making. Simultaneously, each module focuses on its core task, avoiding the problem of excessive processing pressure and decreased accuracy caused by a single module simultaneously undertaking both perception and decision-making tasks.

[0109] In another embodiment of this application, when the first processing model includes multiple heterogeneous sub-models, in order to ensure that the final output perception-side data is more comprehensive and accurate, please refer to [reference needed]. Figure 4 , Figure 4 This is a flowchart illustrating the specific implementation of obtaining sensing-side data according to an embodiment of this application. Figure 4 As shown, in this embodiment, the sensing module can obtain sensing-side data according to the following steps, detailed below: In S201, environmental data is sequentially input into each heterogeneous sub-model for processing, and the processing results corresponding to each heterogeneous sub-model are obtained.

[0110] In S202, the various processing results are matched to obtain the matching result.

[0111] In S203, sensing-side data is obtained based on the matching results.

[0112] It should be noted that the various heterogeneous sub-models include, but are not limited to, CNN models and Transformer models.

[0113] In this embodiment, the perception module can unify the format of the processing results output by each heterogeneous sub-model to obtain processing results in a unified format.

[0114] Afterwards, the perception module can perform spatial intersection-union-comparison matching on the various processing results in a unified format to obtain the matching result.

[0115] Specifically, spatial IoU matching refers to calculating the IoU between the detection boxes output by any two heterogeneous sub-models. If the IoU is greater than or equal to the set crossover-union ratio, then the detection boxes output by the heterogeneous sub-models are considered as the same target candidate.

[0116] Matching results include, but are not limited to: complete match, partial match, and conflict match.

[0117] Among them, perfect matching is used to characterize that at least two heterogeneous sub-models detect the same target, and the IoU is met and the categories are consistent.

[0118] Partial matching is used to characterize that only one heterogeneous sub-model detects the target, while other heterogeneous sub-models have no results.

[0119] Conflict matching is used to characterize multiple heterogeneous sub-models that detect the same target but have large differences in class / location.

[0120] In this embodiment, when the sensing module detects that the matching result is a complete match or a partial match, it can fuse the various processing results and determine the fused processing result as the sensing side data; when the sensing module detects that the matching result is a conflict match, it can directly delete the processing result corresponding to the conflict match, fuse the remaining processing results, and determine the fused remaining processing results as the sensing side data.

[0121] As can be seen from the above, the vehicle control system provided in this embodiment has different perception advantages for each heterogeneous sub-model. Therefore, the perception module sequentially inputs environmental data into each heterogeneous sub-model for processing, which can obtain multi-dimensional and multi-view perception results. Then, by matching and integrating the advantages of the results, the perception shortcomings of a single model can be made up for, so that the final output perception data is more comprehensive and accurate.

[0122] In another embodiment of this application, when the first processing model includes multiple heterogeneous sub-models, to avoid the perception interruption problem caused by the failure of a single model, please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a flowchart illustrating the specific implementation of obtaining sensing-side data according to another embodiment of this application. For example... Figure 5 As shown, in this embodiment, the sensing module can obtain sensing-side data according to the following steps, detailed below: In S301, environmental data is input into the first heterogeneous sub-model for processing to obtain initial sensing data.

[0123] In S302, if the initial sensing data is abnormal, the environmental data is input into the second heterogeneous sub-model for processing to obtain sensing-side data.

[0124] It should be noted that the initial sensing data carries the confidence level of each data point.

[0125] In this embodiment, when the perception module detects data in the initial perception data output by the first heterogeneous sub-model where the confidence level change is greater than a first magnitude, it can determine that the initial perception data is abnormal, meaning that the first heterogeneous sub-model has failed. Therefore, to ensure uninterrupted perception and provide continuous and stable input for subsequent decision-making, the perception module can input environmental data into the second heterogeneous sub-model for processing to obtain the final perception-side data. The first magnitude can be determined according to actual needs and is not limited here.

[0126] It should be noted that the second isomeric model refers to the non-failed isomeric model.

[0127] In one embodiment of this application, the perception module can specifically determine whether the second heterogeneous sub-model has failed through frame-level transient determination and sliding window trend determination.

[0128] In this embodiment, the specific process of determining the frame-level transient is as follows: For the same sensor input, the initial sensing data output by the second heterogeneous sub-model and any of the other sub-models are compared as follows: ① Comparison of quantity differences: If |N1-N2| / max(N1, N2)>30%, then the anomaly count is incremented by 1; where N1 represents the number of initial sensing data output by the second heterogeneous sub-model, and N2 represents the number of initial sensing data output by any of the other sub-models. ② Position difference comparison: For a matched target, if IoU < 0.5 or center distance > 0.5 m, the anomaly count is incremented by 1; ③ Confidence difference comparison: If |score1-score2|>0.4 and the confidence of either side<0.5, then the anomaly count is incremented by 1; where score1 represents the confidence of the initial perception data output by the second heterogeneous sub-model, and score2 represents the confidence of the initial perception data output by any of the other sub-models.

[0129] Among them, the remaining sub-models specifically refer to the heterogeneous sub-models other than the first and second heterogeneous sub-models.

[0130] In this embodiment, when the sensing module detects that the abnormal count of the second heterogeneous sub-model is less than a set count (such as 2), it can mark it as transient and not suspicious.

[0131] Subsequently, the perception module can perform sliding window trend determination on the second heterogeneous sub-model based on the sliding window trend determination method. This method includes: statistically analyzing a 10-frame sliding window to determine whether the proportion of suspicious frames is greater than the first proportion (e.g., 50%), whether the average confidence decrease is less than the second decrease (e.g., 25%), and whether the deviation from the third-party ground truth continuously increases. The third-party ground truth can be determined according to actual needs and is not restricted here.

[0132] In this embodiment, when the perception module detects that the proportion of suspicious frames is less than the first proportion, the average confidence decrease is less than the second magnitude, and the third-party truth proxy bias does not continue to increase, the perception module can determine that the second heterogeneous sub-model has not failed.

[0133] As can be seen from the above, the vehicle control system provided in this embodiment has a first heterogeneous sub-model responsible for rapid perception of normal scenarios, and a second heterogeneous sub-model as a backup solution to handle abnormal situations, forming a dual guarantee of the main model and the backup model. This can avoid the perception interruption problem caused by the failure of a single model, ensure that the perception link is not interrupted, and provide continuous and stable input for subsequent decision-making.

[0134] In yet another embodiment of this application, to improve decision-making accuracy, please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the specific implementation of the generation control instructions provided in one embodiment of this application. For example... Figure 6 As shown, in this embodiment, the scheduling module can generate control commands according to the following steps, detailed below: In S401, the decision-side data is evaluated based on the perception-side data to obtain the evaluation results of the decision-side data in different dimensions.

[0135] It should be noted that the different dimensions include, but are not limited to, security, compliance, comfort, efficiency, and resource adaptation.

[0136] In this embodiment, the scheduling module can calculate the minimum distance between each candidate driving trajectory and static obstacles (construction barriers, guardrails) and dynamic targets (pedestrians, vehicles) by using the target position and size (length / width / height) of the 3-D detection box in the perception side data. Based on each minimum distance, the safety score of each candidate driving trajectory is obtained, thereby obtaining the evaluation result of each candidate driving trajectory in the safety dimension.

[0137] The scheduling module can detect whether the vehicle speed and direction of each candidate driving trajectory are compliant by segmenting and identifying traffic signs (such as speed limit signs and traffic lights) and road types (such as highways / urban roads) using the traffic signs (such as speed limit signs and traffic lights) and road types (such as highways / urban roads). (For example, if the vehicle speed of a candidate trajectory is less than 60 km / h in a highway scenario, it is determined to be a non-compliant trajectory.) This module obtains a compliance score for each candidate driving trajectory, thereby obtaining an evaluation result for each candidate driving trajectory in terms of compliance.

[0138] The scheduling module can extract the steering angle change rate and acceleration parameters of each candidate driving trajectory, and compare these steering angle change rate and acceleration parameters with their respective corresponding thresholds to obtain the comfort score of each candidate driving trajectory, thereby obtaining the evaluation results of each candidate driving trajectory in the comfort dimension.

[0139] The scheduling module can calculate the ratio of the travel time of each alternative travel trajectory to the shortest path travel time, and obtain the efficiency score of each alternative travel trajectory based on each ratio, thereby obtaining the evaluation result of each alternative travel trajectory in the efficiency dimension.

[0140] The scheduling module can determine the sensor / computing resources required for the execution of each candidate driving trajectory, and obtain the resource adaptability score of each candidate driving trajectory based on the number of sensor / computing resources required, thereby obtaining the evaluation result of each candidate driving trajectory in the resource adaptability dimension.

[0141] In S402, based on the evaluation results of decision-side data in different dimensions, a total score is obtained for each of the at least one alternative driving trajectory.

[0142] In S403, the target driving trajectory is determined based on the total scores.

[0143] In S404, control commands are generated based on the target driving trajectory.

[0144] In this embodiment, after obtaining the evaluation results of at least one candidate driving trajectory in the decision-side data in different dimensions, the scheduling module can perform a weighted summation of the evaluation results of the candidate driving trajectory in different dimensions for any candidate driving trajectory to obtain the total score of the candidate driving trajectory.

[0145] Based on this, the scheduling module can obtain the total score corresponding to at least one alternative driving trajectory.

[0146] In this embodiment, after obtaining the total score corresponding to at least one candidate driving trajectory, the scheduling module can compare each total score and directly determine the candidate driving trajectory with the highest total score as the target driving trajectory.

[0147] After determining the target driving trajectory, the scheduling module can convert the target driving trajectory into sub-commands for the accelerator, brake and steering wheel of the target vehicle, and determine the control parameters carried by each sub-command based on the perception side data, thereby obtaining the final control command.

[0148] Specifically, the scheduling module can calculate the specific opening of the brake / accelerator based on the distance and speed of the target in the 3-D detection box in the perception side data, thereby obtaining the control parameters for the sub-commands of the brake / accelerator.

[0149] The scheduling module can determine the steering angle and execution timing of the steering wheel based on the road curvature and lane width in the segmentation mask of the perception side data, thereby obtaining the control parameters for the sub-commands of the steering wheel.

[0150] The scheduling module can set the effective time of each sub-instruction based on the time node of the target trajectory prediction in the perception side data (such as triggering the sub-instruction for braking 1.5 seconds in advance) to ensure that the instruction matches the time of risk occurrence.

[0151] As can be seen from the above, the vehicle control system provided in this embodiment can perform multi-dimensional evaluation of candidate driving trajectories by combining perception-side data, avoiding closed-door decision-making that relies solely on the output of the decision model and is divorced from the actual environment. Then, the multi-dimensional evaluation results are transformed into a total score of the candidate trajectories, and the optimal trajectory is selected through quantitative comparison, replacing subjective or single-dimensional decision-making methods. This ensures that the target trajectory not only conforms to the actual environment, but also takes into account multiple requirements such as safety, efficiency, and compliance, and greatly improves the accuracy of decision-making.

[0152] In another embodiment of this application, in order to ensure the safe and stable operation of the vehicle control system in complex scenarios and to realize the system's "self-healing" adjustment, the context management module is also used to receive the system status data of the vehicle control system in real time and generate a system health structured data block based on the system status data.

[0153] It should be noted that system status data includes, but is not limited to: the load rate, temperature, and idle computing power of computing nodes (MCU / domain controller), the working status and data transmission rate of data acquisition devices (such as cameras / radar), and the inference time, confidence level, and loading success rate of the target processing model.

[0154] In this embodiment, the context management module can compare the aforementioned system status data with their respective corresponding indicator thresholds to determine abnormal indicators. Then, the context management module can encapsulate the system status data and abnormal indicators to obtain a structured data block of system health.

[0155] The system health structured data block (HealthBlock) may include fields such as model_perf[], resource_usage, and anomaly_bits.

[0156] It should be noted that model_perf[] is used for the sliding window average confidence, latency, and GPU utilization of the standard object processing model.

[0157] resource_usage is used to characterize CPU / GPU usage, temperature, memory leak rate, etc.

[0158] `anomaly_bits` is used to mark perceived anomalies, planning timeouts, or CAN frame drops using 4 bits. Afterwards, the context management module can send the aforementioned system health structured data block to the scheduling module via the MCP protocol.

[0159] In this embodiment, after receiving the above-mentioned system health structured data block, the scheduling module can determine the abnormal results based on the system health structured data block, determine the degradation processing strategy based on the abnormal results, and generate configuration instructions based on the degradation processing strategy.

[0160] Specifically, the scheduling module can parse the system health structured data blocks to obtain abnormal indicators. Then, the scheduling module can analyze these abnormal indicators based on preset anomaly analysis rules to determine the cause and scope of the anomaly, thereby obtaining the anomaly result. The anomaly analysis rules can be set according to actual needs and are not restricted here.

[0161] After receiving an abnormal result, the scheduling module can determine the current degradation handling strategy based on the pre-stored correspondence between different abnormal results and different degradation strategies. The different degradation strategies can be set according to actual needs and are not restricted here.

[0162] Subsequently, the scheduling module can generate configuration instructions based on the degradation processing strategy and send these instructions to the context management module via the MCP protocol. The configuration instructions include: instruction ID, target module (e.g., perception module), operation type (load model / disable function / adjust parameters), specific parameters (processing model ID / parameter value), and execution time limit (permanent / temporary, such as temporary until anomaly recovery).

[0163] In this embodiment, after receiving the configuration instruction sent by the scheduling module, the context management module can parse the configuration instruction to determine the target module, operation type and specific parameters, and perform the operation corresponding to the configuration instruction based on the target module, operation type and specific parameters.

[0164] In another embodiment of this application, after executing the operation corresponding to the configuration command, the context management module performs secondary verification of the exception to address the potential ineffectiveness issues (such as the exception being eliminated but not recovered) or security deficiencies (such as the exception still existing after the downgrade but not being further processed) of traditional one-time downgrades. Please refer to [link to relevant documentation]. Figure 7 , Figure 7 This is a flowchart illustrating the specific implementation of the context management module provided in one embodiment of this application. Figure 7 As shown in this embodiment, after executing the operation corresponding to the configuration command, the context management module can specifically perform the following steps, detailed below: In S501, after executing the operation corresponding to the configuration command, the degradation processing result of the vehicle control system is obtained.

[0165] In this embodiment, after executing the operation corresponding to the configuration command, the context management module can continue to obtain the system status data after the implementation of the degradation processing strategy, and detect whether the abnormal indicators in the system status data after the implementation of the degradation processing strategy still exist, thereby obtaining the degradation processing result of the vehicle control system.

[0166] The downgrade processing results include, but are not limited to, the first result and the second result. The first result is used to characterize the disappearance of the anomaly, i.e., the anomaly indicator no longer exists; the second result is used to characterize the persistence of the anomaly, i.e., the anomaly indicator still exists.

[0167] In one embodiment of this application, when the context management module detects that the degradation processing result is the first result, it may execute step S502.

[0168] In another embodiment of this application, when the context management module detects that the degradation processing result is the second result, it may execute step S503.

[0169] In S502, if the degradation process result is the first result, then the system recovery operation is performed; the first result is used to characterize the disappearance of the anomaly.

[0170] In this embodiment, when the context management module detects that the degradation processing result is the first result, it can send the first result to the scheduling module.

[0171] When the scheduling module receives the first result mentioned above, it indicates that the exception has disappeared. Therefore, the scheduling module can send a system recovery command to the context management module.

[0172] Once the context management module receives the aforementioned system recovery command, it can execute the system recovery operation.

[0173] It should be noted that the system recovery operation specifically refers to restoring all devices, modules, and models in the vehicle control system to their state before the degradation processing strategy was implemented.

[0174] In S503, if the degradation process results in the second result, the degradation operation continues; the second result is used to characterize the persistence of the anomaly.

[0175] In this embodiment, when the context management module detects that the degradation processing result is the second result, it can send the second result to the scheduling module.

[0176] When the scheduling module receives the second result mentioned above, it indicates that the exception continues. Therefore, in order to make exception handling more accurate and efficient, the scheduling module can obtain a higher-level degradation strategy than the previous degradation handling strategy, generate a degradation instruction based on the higher-level degradation strategy, and send the degradation instruction to the context management module.

[0177] In this embodiment, after receiving the aforementioned downgrade instruction, the context management module can continue to perform the downgrade operation based on the downgrade instruction.

[0178] As can be seen from the above, the vehicle control system provided in this embodiment, after executing the configuration command, allows the context management module to perform secondary verification of the abnormal state by obtaining the degradation processing result: if the abnormality disappears (first result), a system recovery operation is triggered, allowing the system to return to normal operation mode and avoiding functional limitations caused by prolonged degradation; if the abnormality persists (second result), degradation continues, ensuring that the system is always in a safe and controllable state. This closed-loop logic of execution-feedback-adjustment solves the problems of ineffectiveness (such as the abnormality being eliminated after degradation but not being restored) or insufficient security (such as the abnormality still existing after degradation but not being further processed) that may exist in traditional one-time degradation, making abnormality handling more accurate and efficient. At the same time, the automatic feedback and operation adjustment of the abnormality handling result can complete the entire process from degradation to verification, and then to recovery / continued degradation without manual intervention, improving the system's self-healing efficiency and reducing the need for manual intervention.

[0179] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0180] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0181] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle control system characterized by comprising: The application relates to a vehicle control system, comprising: a context management module configured to acquire environment data and construct an environment model based on the environment data; a scheduling module configured to determine a target processing model based on the environment model and send a model loading request to a model management module, wherein the model loading request carries the target processing model; the model management module configured to load the target processing model based on the model loading request; the scheduling module is further configured to receive a model processing result and generate a control instruction based on the model processing result, so that the vehicle drives based on the control instruction; and the model processing result is obtained by deploying the target processing model on a target computing node for processing by the scheduling module.

2. The vehicle control system of claim 1, wherein, The environment data comprises initial data collected by different sensors, and the environment model is constructed based on the environment data, comprising: determining a scene complexity based on each initial data; determining a target fusion strategy based on the scene complexity; fusing all the initial data based on the target fusion strategy to obtain fused data; constructing the environment model based on the fused data.

3. The vehicle control system of claim 1, wherein The target processing model is determined based on the environment model, comprising: analyzing the environment model to determine an environment complexity of the environment model; determining the target processing model based on the environment complexity.

4. The vehicle control system of claim 1, wherein Before determining the target processing model based on the environment model, the scheduling module is further configured to: generate a current task based on the environment model and determine a task priority of the current task; acquire a computing resource state of the vehicle control system; determine resource allocation information of the current task based on the task priority and the computing resource state, and send the resource allocation information to each computing node associated with the current task.

5. The vehicle control system of claim 1, wherein The vehicle control system further comprises a perception module and a planning and control module; the target processing model comprises a first processing model corresponding to the perception module and a second processing model corresponding to the planning and control module; and the model processing result comprises perception side data and decision side data. The perception module is configured to input the environment data into the first processing model for processing to obtain the perception side data. The planning and control module is configured to input the environment data and the perception side data into the second processing model for processing to obtain the decision side data.

6. The vehicle control system of claim 5, wherein The first processing model comprises a plurality of heterogeneous sub-models, and the environment data is input into each heterogeneous sub-model for processing to obtain a respective processing result of each heterogeneous sub-model. Each processing result is matched to obtain a matching result. The first processing model comprises a plurality of heterogeneous sub-models, and the environment data is input into each heterogeneous sub-model for processing to obtain a respective processing result of each heterogeneous sub-model. The environment data is input into a first heterogeneous sub-model for processing to obtain initial perception data.

7. The vehicle control system of claim 5, wherein ​ ​ If the initial perception data is abnormal data, the environment data is input to a second heterogeneous sub-model for processing to obtain the perception-side data.

8. The vehicle control system of claim 1, wherein The model processing result includes perception-side data and decision-side data, and the decision-side data includes at least one candidate driving trajectory; The control instruction is generated based on the model processing result, including: The decision-side data is evaluated based on the perception-side data to obtain evaluation results of the decision-side data in different dimensions; Based on the evaluation results of the decision-side data in different dimensions, at least one total score corresponding to each of the candidate driving trajectories is obtained; A target driving trajectory is determined based on the total scores; The control instruction is generated based on the target driving trajectory.

9. The vehicle control system of any one of claims 1-8, wherein, The context management module is further configured to receive system state data of the vehicle control system, and generate system health structured data blocks based on the system state data; The scheduling module is further configured to determine an abnormal result based on the system health structured data blocks, determine a degradation processing strategy based on the abnormal result, and generate a configuration instruction based on the degradation processing strategy; The context management module is further configured to perform an operation corresponding to the configuration instruction.

10. The vehicle control system of claim 9, wherein The context management module is further configured to: After performing the operation corresponding to the configuration instruction, obtain a degradation processing result of the vehicle control system; If the degradation processing result is a first result, perform a system recovery operation; the first result is used to represent that the abnormality disappears; If the degradation processing result is a second result, continue to perform a degradation operation; the second result is used to represent that the abnormality continues.

Images