Software-defined unmanned vehicle system based on semantic understanding and weighted scoring

Abstract

The application provides a software-defined unmanned vehicle system based on semantic understanding and weighted scoring, and belongs to the technical field of software-defined unmanned vehicles. The system solves the problem of insufficient flexibility and generalization caused by the solidification of existing unmanned vehicle functions and the strong binding of scene tasks. The system comprises: an environment perception module that performs environment identification according to environment videos of unmanned vehicle operation to obtain an environment type; a task understanding module that generates technical requirements for executing task instructions according to semantic understanding results of the task instructions, the environment type and resource usage; a software-defined engine that performs feasibility filtering and multi-target weighted scoring on a service list according to the technical requirements, the environment type and the resource usage to determine an optimal activated service list; and a service running module that constructs a service calling link according to the dependency relationship between services in the optimal activated service list to realize the orderly switching of services.

Description

Technical Field

[0001] This invention relates to the field of software-defined autonomous vehicle technology, and in particular to a software-defined autonomous vehicle system based on semantic understanding and weighted scoring. Background Technology

[0002] Software-defined autonomous vehicles refer to autonomous vehicles whose functions can be altered by changing, switching, or upgrading the deployed software without modifying the hardware, thereby enhancing the vehicle's adaptability to different environments and tasks. One existing software-defined autonomous vehicle control system employs a three-layer architecture: a hardware execution layer, a controller layer, and an application layer. The controller layer utilizes a MAPE-K structure, comprising a monitor, an analyzer, a planner, an executer, and a knowledge base. The monitor component monitors user navigation needs, autonomous vehicle resources, and environmental changes. User navigation needs are primarily obtained through user interface interaction and VR device interaction. The analyzer, based on radar and navigation inputs, determines alignment between the radar and vehicle coordinate systems through coordinate transformation. The decisionner performs local path planning based on the analyzer's results. Finally, the executer publishes control commands via ROS topics to drive the lower-level machine. The software-defined implementation primarily relies on the ROS framework to abstract autonomous vehicle hardware (such as LiDAR and motors) into software-callable resources, acquiring resources and executing control through topic subscription and publishing.

[0003] The system currently suffers from the following main defects: (1) The solution only considers the navigation requirements of unmanned vehicles and does not take into account the constraints of complex autonomous task planning of unmanned vehicles (such as autonomous patrol and delivery); (2) User needs are mainly obtained from the interactive interface and VR devices, without considering convenient high-level and abstract command information such as natural language; (3) The analysis component only performs coordinate mapping and alignment of the target, obstacles, and vehicle position, without considering the impact of the unmanned vehicle's operating environment (such as parks, cities, and factories) on the unmanned vehicle's software algorithm and functional performance; (4) Although the overall solution has achieved hardware and software decoupling and software-based resource calling, it does not reflect the "software-defined unmanned vehicle function". That is, from the perspective of the implementation results, the unmanned vehicle platform function is not significantly different from the non-software-defined method.

[0004] It should also be noted that existing autonomous vehicles have their services and functions fixed at the factory. With the development of OTA technology, some software services can be upgraded and updated online, but they still follow the preset service call process during operation. This approach results in the fixed functions of autonomous vehicles being strongly bound to the scenario and task. When the usage environment and task functions change, redevelopment is required, which greatly limits the functional flexibility and scenario generalization of autonomous vehicles. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a software-defined autonomous vehicle system based on semantic understanding and weighted scoring, in order to solve the problems of insufficient flexibility and generalization caused by the factory-fixed functions and strong binding of scenarios and tasks in existing autonomous vehicles.

[0006] This invention provides a software-defined autonomous vehicle system based on semantic understanding and weighted scoring, the system comprising: The environmental perception module identifies the environment type based on video footage of the autonomous vehicle's operation. The task understanding module generates the technical requirements for executing the task instructions based on the semantic understanding results of the task instructions, the environment type, and resource usage. The software-defined engine performs feasibility filtering and multi-objective weighted scoring on the service list based on the technical requirements, environment type, and resource usage to determine the optimal list of activated services. The service operation module constructs service call chains based on the dependencies between services in the optimal active service list, thereby enabling orderly service switching.

[0007] Based on the above solution, the present invention makes the following improvements: Furthermore, within the software-defined engine, the following is executed: Based on the environmental type and resource usage, each service in the service list that meets the technical requirements is subjected to feasibility filtering. The services that pass the filtering are used as candidate services, and all candidate services constitute a candidate service set. Each candidate service in the candidate service set is scored using a multi-objective weighted method. Construct an optimal list of activated services based on the candidate service with the highest multi-objective weighted score in the candidate service set and all its dependent services.

[0008] Furthermore, the feasibility filtering criteria include runtime domain matching, dependency satisfaction, and resource sufficiency.

[0009] Furthermore, the runtime domain matching judgment is executed as follows: Determine whether the road surface type and weather type in the environment type are both within the range defined by the applicable environment of the current service. If so, the current service's operating domain matching judgment passes.

[0010] Furthermore, for services determined through runtime domain matching, the following dependency satisfaction checks are performed: Determine whether all dependent services declared by the current service are in the currently running service set or satisfy the runtime domain matching judgment. If so, the dependency satisfaction judgment of the current service passes.

[0011] Furthermore, for services that pass the dependency satisfaction judgment, the following resource sufficiency judgment is performed: Calculate the total resource consumption of the current service and all its dependent services for each resource type. If the total resource consumption for each resource type is less than the safe usage threshold of the corresponding total system resources, the resource sufficiency judgment is passed, and the current service is selected as a candidate service.

[0012] Furthermore, the j-th candidate service The multi-objective weighted score Total_Score(S_j) is represented as: Total_Score(S_ j) = W_perf * S_perf(S_ j) + W_res * S_res(S_ j) + W_sw * S_sw(S_ j) (1) Where W_perf, W_res, and W_sw represent the dynamic weighted values ​​of optimal performance preference, optimal resource preference, and overall task smoothness, respectively; S_perf(S_j), S_res(S_j), and S_sw(S_j) represent the j-th candidate service, respectively. Performance fit score, resource economy score, and switching cost score.

[0013] Furthermore, in the service runtime module, execute: The optimal list of activated services is compared with the currently running set of services to generate an operation sequence that includes services to be loaded, maintained, and unloaded; the operation order of each service in the optimal list of activated services is sorted according to the dependencies in the service description to form a service call chain. By leveraging a global communication proxy to load service call chains, orderly service switching can be achieved.

[0014] Furthermore, in the task understanding module, the following is executed: Perform semantic understanding on the task instructions to obtain the semantic understanding results of the task instructions; combine the semantic understanding results of the task instructions, environment type and resource usage to generate combined prompt words; The combined prompts are input into the task understanding model, which then predicts and outputs the technical requirements for executing the task instructions.

[0015] Furthermore, in the environmental perception module, the following is executed: The environmental video is preprocessed to obtain multiple frames of normalized environmental images; Each frame of normalized environment image is used for environment recognition, and the environment type is output based on the environment recognition results of multiple consecutive frames of normalized environment images.

[0016] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: This invention provides a software-defined autonomous vehicle system based on semantic understanding and weighted scoring. By introducing an environmental perception module and a task understanding module, it achieves deep parsing of natural language task instructions and accurate identification of operating environment types, enabling dynamic generation of technical requirements based on task needs and environmental characteristics. The software-defined engine, through multi-dimensional feasibility filtering based on operating domain matching, dependency satisfaction, and resource sufficiency, combined with a multi-objective weighted scoring mechanism considering performance fit, resource economy, and switching costs, accurately selects the optimal list of activated services, effectively solving the problem of fixed service call processes in traditional autonomous vehicles. The service operation module constructs call links based on inter-service dependencies, achieving orderly service switching and dynamic deployment through a global communication proxy. This allows for flexible adjustment of autonomous vehicle functions without hardware changes, significantly improving the adaptability of autonomous vehicles to complex tasks and changing environments, breaking the strong binding restrictions between functions and scenario tasks, and greatly enhancing the system's flexibility and scenario generalization capabilities. This autonomous vehicle system effectively solves the problems of insufficient flexibility and generalization caused by the factory-fixed functions and strong binding of scenario tasks in existing autonomous vehicles.

[0017] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0018] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 A schematic diagram of the structure of a software-defined autonomous vehicle system based on semantic understanding and weighted scoring, provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the processing flow of the environmental perception module provided in an embodiment of the present invention; Figure 3A schematic diagram of the processing flow of the task understanding module provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the processing flow of a software-defined engine provided in an embodiment of the present invention. Detailed Implementation

[0019] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0020] A specific embodiment of the present invention discloses a software-defined autonomous vehicle system based on semantic understanding and weighted scoring. A schematic diagram of the system structure is shown below. Figure 1 As shown. In this embodiment, the software-defined unmanned vehicle system refers to selecting and running services that match the current task and environment from a service list based on the task (such as patrol or delivery) and environment (such as a park or urban structured roads), thereby achieving the effect of dynamic switching of the software-defined unmanned vehicle according to the task and environment.

[0021] In this embodiment, the autonomous vehicle includes a central computing platform (CCU) and a high-definition camera. The software-defined autonomous vehicle system is deployed in the CCU and interacts with a portable remote control terminal and the high-definition camera. The portable remote control terminal is controlled by an operator to issue task commands to the autonomous vehicle system, while the high-definition camera is used to collect environmental video of the autonomous vehicle's operation. The portable remote control terminal interacts with the autonomous vehicle system at the autonomous vehicle end via a communication unit.

[0022] In this embodiment, the software-defined autonomous vehicle system includes an environmental perception module, a task understanding module, a status monitoring module, a software-defined engine, and a service operation module; in addition, the software-defined autonomous vehicle system also has a built-in service list and service description. Specific details are as follows.

[0023] (1) Environmental perception module The environmental perception module identifies the environment based on video footage of the autonomous vehicle's operation and determines the environment type.

[0024] In this embodiment, a high-definition camera captures environmental videos of the unmanned vehicle's operation and sends them to the environment perception module. The environment perception module performs the following: preprocessing of the environmental videos to obtain multiple frames of normalized environmental images; performing environment recognition on each frame of the normalized environmental images; and outputting the environment type based on the environment recognition results of multiple consecutive frames of normalized environmental images.

[0025] In practice, after receiving environmental video captured by a high-definition camera, the environmental perception module performs preprocessing operations such as video sampling, image scaling, and image pixel normalization to obtain multiple frames of normalized environmental images. For example, to balance real-time performance and computational load, the environmental perception module performs image preprocessing on the environmental video by sampling it at a fixed frequency of 5 frames per second. Each sampled frame is then scaled to 224×224 pixels, and the scaled image pixels are normalized to obtain the corresponding normalized environmental image.

[0026] Subsequently, the environment perception module performs environment recognition (covering road type recognition and weather type recognition) on each frame of normalized environment image, and outputs the environment type (road type and weather type) based on the environment recognition results of multiple consecutive frames of normalized environment images. For example, this embodiment uses MobileNetV3 as the backbone network, replacing the original model's classification layer with a dual-branch classification head, used for road type recognition and weather type recognition respectively, thereby constructing the environment perception model. Each preprocessed frame of normalized environment image is input into the environment perception model. The model uses the original prediction scores (logits) of the normalized environment image in the two branches, and converts the logits of each branch into a corresponding probability distribution using the softmax function. Finally, the category with the highest probability output by the road type recognition branch and the weather type recognition branch is selected as the road type recognition result and weather type recognition result for that frame of normalized environment image, respectively.

[0027] Subsequently, considering the integrity of the environmental video, the environmental perception module can employ a temporal fusion strategy to smoothly output the environmental type. Specifically, the road surface type recognition results and weather type recognition results of several consecutive frames (matching the video sampling frequency, e.g., 5 frames) of normalized environmental images are taken and fused using a majority voting method to obtain the final road surface type recognition result and weather type recognition result, which are used as the environmental type output by the environmental perception module, denoted as Env_t.

[0028] The processing flow of the environmental perception module is as follows: Figure 2 As shown.

[0029] (2) Task Understanding Module The task understanding module generates the technical requirements for executing the task instructions based on the semantic understanding results of the task instructions, the environment type, and resource usage.

[0030] In this embodiment, the operator sends natural language-based task instructions to the task understanding module in the unmanned vehicle via a communication unit on a portable remote control terminal. For example, the task instructions may include destination location information or route information (e.g., "deliver goods to point A" or "perform a patrol mission along the route"). In this embodiment, the task understanding module maps the operator's task instructions into constraints that the unmanned vehicle can understand and execute. The specific implementation process is described below.

[0031] In this embodiment, the task understanding module performs the following operations: semantic understanding of the task instructions to obtain the semantic understanding result of the task instructions; combining the semantic understanding result of the task instructions, the environment type, and the resource usage to generate combined prompt words; inputting the combined prompt words into the task understanding model, which then predicts and outputs the technical requirements for executing the task instructions.

[0032] In the specific implementation process, the task understanding module can perform semantic parsing on task instructions in natural language form. In this embodiment, the semantic understanding of task instructions can be achieved as follows: first, the task instructions are segmented into words, and the segmentation results are input into the RAG (Retrieval-Augmented Generation) system for retrieval to obtain the corresponding retrieval results; then, the segmentation results of the task instructions are combined with the retrieval results of the RAG to finally generate the semantic understanding result of the task instructions. The RAG, as an external knowledge base for the model, is used to store scenarios and professional knowledge. When a prompt input is received, it will first search the RAG knowledge base to see if there is any knowledge related to the current scenario.

[0033] In this embodiment, the task understanding model can be pre-trained as follows: Multiple combined prompt word samples and their corresponding technical requirements for executing task instructions are constructed. Using each combined prompt word sample and its corresponding technical requirements as input and output, the task understanding model is trained to obtain a successfully trained task understanding model. For example, in the specific implementation process, a dataset containing at least 1000 supervised fine-tuning data points is first constructed. Each data sample in the dataset includes a task instruction, environment type Env_t, resource usage Res_t, and output technical requirements Task_t. Combined prompt word samples are constructed based on the data samples in the dataset. Using the combined prompt word samples as input and the corresponding technical requirements as labels, the task understanding model is trained to obtain a successfully trained task understanding model. The task understanding model can be implemented based on the Qwen3-0.6B-Base model. In the specific implementation process, LoRA technology is also used for fine-tuning training on the basis of the pre-trained Qwen3-0.6B-Base model to obtain a successfully trained task understanding model.

[0034] In practice, the task understanding model outputs structured technical requirements (Task_t) in JSON format to drive the subsequent software-defined engine. In this embodiment, the technical requirements for executing task instructions are structured requirements, including: a list of mandatory service types (mandatory_service_types), i.e., services that must be started; dynamic weighting values ​​(optimization_weights), used to evaluate strategy preferences, including optimal performance preference (W_perf), optimal resource preference (W_res), and overall task smoothness (W_sw); and performance requirements (metric_baselines), used to constrain the performance requirements of the selected services. It should be noted that in this embodiment, the list of mandatory service names corresponds to service types, such as object detection services, while the specific service used needs to be selected later through software definition.

[0035] The processing flow of the task understanding module is as follows: Figure 3 As shown.

[0036] For example, taking the input task instruction "Battery is low, but please complete the area patrol smoothly, detect and report suspicious intrusion targets, and pay attention to security." as an example, the output Task_t is as follows: { "mandatory_service_types": ["intrusion_target_detection"], "optimization_weights": { "W_perf": 0.3, "W_res": 0.6, "W_sw": 0.1 }, "metric_baselines": { "planning_latency": {"optimal": 30, "acceptable": 100, "unit": "ms"}, "planning_accuracy": {"optimal": 1, "acceptable": 1.5, "unit": "m"} } } (3) Status monitoring module The status monitoring module is used to monitor the resource usage of the central computing platform (CCU) in real time, including real-time CPU, NPU, and memory usage, denoted as Res_t; and outputs the data to the task understanding module.

[0037] For example, the status monitoring module can call the system interfaces of the central computing platform (CCU) (such as files like / proc / stat and / proc / meminfo in Linux) or a dedicated system monitoring library (such as the psutil library) to collect real-time resource data. The status monitoring module periodically (e.g., every 100 milliseconds) reads the CPU's user mode, kernel mode, and idle time, calculates the proportion of non-idle time per unit time, and obtains the real-time CPU utilization. If the CCU integrates an NPU, it obtains metrics such as NPU computing core utilization and task queue length through its dedicated driver interface. It reads the system's total memory, used memory, and available memory values, and calculates the percentage of used memory to total memory as the real-time memory occupancy rate. The collected CPU, NPU, and memory usage data are packaged into a Res_t file according to a preset format (e.g., a dictionary containing "cpu_usage", "npu_usage", and "memory_usage" fields and their corresponding percentage values), and sent in real-time to the task understanding module through inter-process communication mechanisms (e.g., message queues, shared memory), providing the task understanding module with key information for generating combined prompts about the current system resource status. (4) Service list and service description The service list and service descriptions define the collection of all services deployed on the central computing platform (CCU), covering various basic and task-related functions required for autonomous vehicle operation. The service descriptions provide a detailed definition of each service, outlining its capabilities, and include at least the service category, service adaptation environment (ODD), service dependencies (Dep), performance metrics (Perf), and resource consumption (Cost). During implementation, the service list and service descriptions can be adaptively adjusted based on the specific circumstances of the autonomous vehicle system.

[0038] For example, the service list and service description are shown in Table 1.

[0039] Table 1 Service List and Service Description

[0040] The description is in JSON format. Taking "Unstructured Road Route Planning Service" as an example, the service description file is as follows: { "Service_id": "com.example.autonomous.unstructured_trajectory_planner", "Service_name": "Unstructured Road Route Planning Service", "Version": "V1 .0", "Functional_type": "planning", Description: Suitable for unstructured roads lacking clear lane markings (such as grasslands and industrial parks). Receives a raster map and location information to generate a smooth, passable trajectory. "Operation_Design_Domain": { "Environment": ["unstructured_road", "grassland", "field"], "Weather_condition": ["clear", "cloudy", "light_rain"], "Speed": [0, 30] }, "Performance": { "Max_Planning_Frequency": 20, "Typical_Computation_Latency": 40 }, "Resource_requirement": { "CPU_usage": "15%", "Memory_usage": 200000 }, "Inputs": [{ "Data_name": "local_occupancy_grid", "Data_type": "nav_msgs / OccupancyGrid", Description: Local raster map, resolution 0.1 m, value 0-100 represents the probability of occupancy. }, { "Data_name": "vehicle_state", "Data_type": "geometry_msgs / vehicleState", Description: Positioning, attitude, velocity, and angular velocity information. } ], "Output": [{ "Data_name": "trajectory", "Data_type": "nav_msgs / path", Description: "Locally optimal path, including discrete pose points for the next 3 seconds, at 0.5-second intervals." }], "Dependence": ["com.example.autonomous.offroad_perception_mapper", "com.example.autonomous.localization"] } (5) Software-defined engine The software-defined engine performs feasibility filtering and multi-objective weighted scoring on the service list based on the technical requirements, environment type, and resource usage to determine the optimal list of activated services.

[0041] In this embodiment, the software-defined engine matches the services in the service list with the environment type (Env_t), technical requirements (Task_t), and resource usage (Res_t) to determine the optimal list of services to activate, denoted as Activate_Set[best]. Preferably, this embodiment designs a matching algorithm that combines hard and soft constraints. The first stage performs feasibility filtering based on hard constraints, and the second stage performs multi-objective optimization scoring based on soft constraints and dynamic weights.

[0042] Initially, upon receiving an input task instruction, the algorithm is triggered to make a decision. During operation, the environment type Env_t and resource usage Res_t are updated periodically (e.g., every 10 minutes), triggering the algorithm's decision. For each decision t, the input to the matching algorithm is a triple context C_t = {Env_t, Task_t, Res_t}. In specific implementation, the service description of each service in the service list can also be converted into a service description vector. The service description vector Sd_i of the i-th service S_i in the service list is {ODD_i, Dep_i, Perf_i, Cost_i}, where ODD_i, Dep_i, Perf_i, and Cost_i represent the applicable environment, dependent service list, performance metrics, and resource consumption of the i-th service S_i, respectively.

[0043] a) Feasibility Filtering Based on the environmental type and resource usage, each service in the service list that meets the technical requirements is subjected to feasibility filtering. The services that pass the filtering are used as candidate services, and all candidate services constitute a candidate service set.

[0044] Preferably, in this embodiment, the judgment conditions for feasibility filtering include runtime domain matching judgment, dependency satisfaction judgment, and resource sufficiency judgment.

[0045] In the specific implementation process, for the i-th service S_i in the service list that meets the technical requirements, the following three Boolean judgments are executed in sequence.

[0046] Operation Domain (ODD) Matching Judgment: Determine whether the road surface type and weather type in the environment type Env_t are both within the scope defined by the applicable environment (i.e., the operation domain) of the current service. If so, the operation domain matching judgment of the current service passes, and the current service S_i is added to the activated service list Activate_Set[i]. If either the road surface type or the weather type does not meet the requirements, the operation domain (ODD) matching judgment fails, and the corresponding service is eliminated.

[0047] For services that are matched by the running domain (ODD), a dependency satisfaction check is performed: it is determined whether all dependent services declared by the current service S_i are in the currently running service set Running_Set (all services currently running), or whether the running domain (ODD) matching check is satisfied. If so, the dependency satisfaction check of the current service passes; otherwise, the corresponding service is discarded.

[0048] In the specific implementation process, it can first be determined whether the dependent service is in the currently running service set Running_Set (all services currently running). If so, the running domain (ODD) matching judgment is no longer performed; otherwise, the running domain (ODD) matching judgment is performed. If the running domain (ODD) matching judgment is performed, each preceding dependent service is recursively parsed, and the current service and all preceding dependent services are added to the activation service list Activate_Set[i] of the i-th service S_i.

[0049] For services that pass the dependency satisfaction test, a resource sufficiency test is performed: After the dependency resolution is completed, the total resource consumption of all services (the current service and all its dependent services) in the Activate_Set[i] list on each resource type is calculated, and compared with the total system resources of the central computing platform CCU on the corresponding resource type. If the total resource consumption on each resource type is less than the safe usage threshold of the corresponding total system resources, the resource sufficiency test is passed, and the service is included in the candidate service set; otherwise, the current service is eliminated.

[0050] For example, for Activate_Set[i], the first The total resource consumption of this resource can be expressed as , Represents the first element in Activate_Set[i]. This type of service is for the first Consumption of resources; Suppose the first The total system resources for this resource are Total_Res[ The safety threshold is Threshold (e.g., 0.8). That is, the first The system's total resource safety threshold for all types of resources, if for all All If the resource sufficiency of S_i is met, then the resource sufficiency judgment of S_i passes; otherwise, S_i is eliminated.

[0051] Services that pass the above three-step screening process will be considered as candidate services, and all candidate services will form a candidate service set (Candidate_Set). If this set is empty, the default fallback service will be used.

[0052] b) Multi-objective weighted scoring Each candidate service in the candidate service set is scored using a multi-objective weighted method. The score is obtained by weighted sum of the scores of the three sub-items, and the weights are determined by the optimization_weights in Task_t.

[0053] Performance fit score (S_perf): This score measures the degree to which the performance metrics (S_j.Perf) of the service commitment match the task requirements (technical requirements) Task_t.

[0054] Candidate service j Performance fit score Represented as: (1) (2) in, This represents the total number of performance metrics declared in the technical requirement Task_t, where k is the index of the k-th performance metric. Indicates candidate service In the The actual performance value of each performance indicator. Indicates the first The optimal value of each performance metric (i.e., Task_t.metric_baseline[k].optimal). It is the first The acceptable value for each performance metric (i.e., Task_t.metric_baseline[k].acceptable). The acceptable value can be understood as the minimum acceptable performance threshold for the task. When the service's performance value exceeds the acceptable value, the metric score is 0, indicating that the service cannot meet the task's basic performance requirements. It should be noted that task_t only specifies the service type, such as planning or awareness services, and specifies the relevant performance metrics. The actual service list may contain multiple services of a certain type (e.g., planning services a and b), and this section selects which specific planning service to use.

[0055] Resource economy score (S_res): This score encourages the use of high-performance services when resources are plentiful and lightweight services when resources are scarce.

[0056] Candidate service j Resource economy score Represented as: (3) Where M is the total number of resource types participating in the evaluation (for example, M=3 means evaluating CPU, NPU, and memory). Serving the j-th candidate For the The estimated consumption of this resource, i.e., the value of Resource_requirement in the service description. For the first in the system The total amount of resources available in real time, i.e. the usage status of each resource in Res_t.

[0057] Switching Cost Score (S_sw): This score aims to maintain system stability and avoid unnecessary and frequent service starts and stops.

[0058] Candidate service j The switching cost score S_sw(S_j) is expressed as: S_sw(S_ j) = - β * [1 - I(S_ j ∈ Running_Set)](4) Where I(·) represents the indicator function, which is 1 if S_j is currently running, and 0 otherwise. β is a positive penalty coefficient (e.g., 0.1).

[0059] Dynamic weight allocation and comprehensive scoring: The relative importance of the three sub-scores is dynamically adjusted by the task intent Task_t.optimization_weights.

[0060] Ultimately, the j-th candidate service The multi-objective weighted score Total_Score(S_j) is represented as: Total_Score(S_ j) = W_perf * S_perf(S_ j) + W_res * S_res(S_ j) + W_sw * S_sw(S_ j) (5) Where W_perf, W_res, and W_sw represent the dynamic weighted values ​​of performance-optimal preference, resource-optimal preference, and overall task smoothness, respectively.

[0061] c) Decision-making and output Based on the candidate service S_best with the highest multi-objective weighted score in the candidate service set Candidate_Set and all its dependent services, construct the optimal list of services to be activated. That is, the final list of services to be activated is the Activate_Set[best] corresponding to S_best.

[0062] A schematic diagram of the processing flow of a software-defined engine is shown below. Figure 4 As shown.

[0063] (6) Service operation module The service operation module constructs service call chains based on the dependencies between services in the optimal active service list, thereby enabling orderly service switching.

[0064] During the actual implementation process, the service operation module performs the following operations.

[0065] First, the system receives the optimal activated service list from the software-defined engine, compares the optimal activated service list with the currently running service set, generates an operation sequence containing services to be loaded (ToLoad), maintained (ToKeep), and unloaded (ToUnload), and sorts the operation order of each service in the optimal activated service list according to the dependency relationship in the service description to form a service call chain.

[0066] Next, a global communication proxy is used to load the service call chain, enabling orderly service startup and switching. Specifically, a global communication proxy takes over the data flow between all services. New services are loaded and connected to the proxy but not yet enabled. Once all new services have been loaded, the data flow of the proxy is switched from the old service instance to the new instance in one go. Finally, the old service is unloaded, thereby achieving a dynamic, smooth, and consistent switch of the entire service set while ensuring inter-service dependencies and data continuity.

[0067] In summary, the software-defined autonomous vehicle system based on semantic understanding and weighted scoring provided in this embodiment can achieve intelligent software definition based on environmental perception, task semantic understanding, and matching of operational status information with service capabilities. It can dynamically select appropriate service combinations according to the real-time operating environment, task execution, and computing resource usage of the autonomous vehicle, thereby improving the functional flexibility and scenario generalization of the autonomous vehicle in dynamic environments. While keeping the physical hardware composition of the autonomous vehicle unchanged, different functional capabilities and adaptation to different operating environments can be achieved by adjusting the running service software. The core technology of this invention lies in designing a matching algorithm that combines hardware and software constraints based on environmental perception, task understanding, and operational status information to dynamically match the service combinations of the running software.

[0068] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0069] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A software defined unmanned vehicle system based on semantic understanding and weighted scoring, characterized in that, The system includes: The environmental perception module identifies the environment type based on video footage of the autonomous vehicle's operation. The task understanding module generates the technical requirements for executing the task instructions based on the semantic understanding results of the task instructions, the environment type, and resource usage. The software-defined engine performs feasibility filtering and multi-objective weighted scoring on the service list based on the technical requirements, environment type, and resource usage to determine the optimal list of activated services. The service operation module constructs service call chains based on the dependencies between services in the optimal active service list, thereby enabling orderly service switching. In the software-defined engine, execute: Based on the environmental type and resource usage, each service in the service list that meets the technical requirements is subjected to feasibility filtering. The services that pass the filtering are used as candidate services, and all candidate services constitute a candidate service set. Each candidate service in the candidate service set is scored using a multi-objective weighted method. Construct an optimal list of activated services based on the candidate service with the highest multi-objective weighted score in the candidate service set and all its dependent services. the jth candidate service The multi-objective weighted score Total_Score(Sj) of the jth candidate service is expressed as: Total_Score(S_ j) = W_perf S_perf(S_ j) + W_res S_res(S_ j) + W_sw S_sw(S_ j)(1) Where W_perf, W_res, and W_sw represent the dynamic weighted values ​​of optimal performance preference, optimal resource preference, and overall task smoothness, respectively; S_perf(S_j), S_res(S_j), and S_sw(S_j) represent the j-th candidate service. Performance fit score, resource economy score, and switching cost score; Represented as: (2) (3) This represents the total number of performance metrics declared in the technical requirements. Indicates candidate service In the The actual performance value of each performance indicator. Indicates the first The optimal value of each performance metric It is the first Acceptable values ​​for each performance metric; Represented as: (4) in, M The total number of resource types participating in the assessment. Serving the j-th candidate For the first The estimated consumption of this resource. For the first in the system The total amount of resources available in real time; S_sw(S_j) is represented as: S_sw(S_ j) = - β [1 - I(S_ j ∈ Running_Set)](5) Where I(·) represents the indicator function, which is 1 if the candidate service S_j is currently running, and 0 otherwise; β is a positive penalty coefficient; Running_Set represents the set of currently running services.

2. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to claim 1, characterized in that, The feasibility filtering criteria include runtime domain matching, dependency satisfaction, and resource sufficiency.

3. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to claim 2, characterized in that, The runtime domain matching judgment is executed as follows: Determine whether the road surface type and weather type in the environment type are both within the range defined by the applicable environment of the current service. If so, the current service's operating domain matching judgment passes.

4. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to claim 3, characterized in that, For services determined by runtime domain matching, the following dependency satisfaction checks are performed: Determine whether all dependent services declared by the current service are in the currently running service set or satisfy the runtime domain matching condition. If so, the dependency satisfaction condition of the current service passes.

5. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to claim 4, characterized in that, For services that pass the dependency satisfaction check, perform the following resource sufficiency check: Calculate the total resource consumption of the current service and all its dependent services for each resource type. If the total resource consumption for each resource type is less than the safe usage threshold of the corresponding total system resources, the resource sufficiency judgment is passed, and the current service is selected as a candidate service.

6. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to claim 5, characterized in that, In the service runtime module, execute: The optimal list of activated services is compared with the currently running set of services to generate an operation sequence that includes services to be loaded, maintained, and unloaded; the operation order of each service in the optimal list of activated services is sorted according to the dependencies in the service description to form a service call chain. By leveraging a global communication proxy to load service call chains, orderly service switching can be achieved.

7. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to any one of claims 1-6, characterized in that, In the task understanding module, the following is executed: Perform semantic understanding on the task instructions to obtain the semantic understanding results of the task instructions; combine the semantic understanding results of the task instructions, environment type and resource usage to generate combined prompt words; The combined prompts are input into the task understanding model, which then predicts and outputs the technical requirements for executing the task instructions.

8. The software-defined autonomous vehicle system based on semantic understanding and weighted scoring according to claim 7, characterized in that, In the environmental perception module, the following is executed: The environmental video is preprocessed to obtain multiple frames of normalized environmental images; Each frame of normalized environment image is used for environment recognition, and the environment type is output based on the environment recognition results of multiple consecutive frames of normalized environment images.

Images