A vehicle-end master distributed artificial intelligence automatic driving system and method

Abstract

The application relates to the technical field of intelligent driving and provides a vehicle-end-main distributed artificial intelligence automatic driving system and method. The system independently realizes eight automatic driving functions of perception, identification, positioning, fusion, prediction, planning, decision and control only by relying on the data, computing power, models and parameters of the vehicle end, and does not depend on the real-time operation support of a roadside unit, an edge system, a traffic control center and a cloud platform. The system comprises an AI distribution subsystem and an operation and maintenance subsystem. The AI distribution subsystem comprises a computing power, data, model and parameter distribution module, and the operation and maintenance subsystem comprises a coordination and optimization module and an execution module. Both the modules are deployed on the vehicle end and are autonomously controlled. The system supports the deployment of large, medium, small and micro AI models on the vehicle end, is configured with a distillation method, can generate small-scale variants suitable for computing power constraints from large models, and ensures sufficient computing resources under various working conditions through static computing power pre-planning and dynamic real-time scheduling.

Description

Technical Field

[0001] This application relates to the field of intelligent driving technology, and in particular to a vehicle-driven distributed artificial intelligence autonomous driving system and method. Background Technology

[0002] With the rapid development of autonomous driving technology, artificial intelligence (AI) is being applied more and more widely in vehicle perception, prediction, planning and decision-making, and control. To achieve high-level autonomous driving functions, the system needs to run complex AI models in multiple functional domains such as perception, recognition, localization, fusion, prediction, planning, decision-making, and control, which places extremely high demands on computing resources, data processing capabilities, and model management mechanisms.

[0003] Current mainstream autonomous driving system architectures can be divided into two categories: one is a centralized architecture centered on a cloud platform, where the training, inference, and updating of AI models are centrally deployed on cloud servers or edge computing nodes, with the vehicle only acting as an execution terminal to receive control commands; the other is a "vehicle-road-cloud" collaborative architecture, where roadside units (RSUs), edge servers, and the cloud platform jointly undertake perception fusion, computing power scheduling, and model distribution tasks. Both of these architectures rely on real-time communication links between the vehicle and external platforms to maintain the normal operation of core autonomous driving functions.

[0004] However, the above architecture faces the following technical bottlenecks in actual deployment: First, communication dependence leads to system vulnerability. In communication anomalies such as network outages, weak signal coverage, high latency, or high interference, vehicles cannot obtain computing results and control commands from the cloud or roadside in a timely manner, causing the autonomous driving function to be downgraded or even completely fail, directly threatening driving safety.

[0005] Second, data transmission raises privacy and security risks. Raw sensor data, location information, and driving behavior data from vehicles need to be uploaded to external platforms for processing. During transmission and storage, this data is at risk of being intercepted, tampered with, or used without authorization. Furthermore, cross-platform data flow increases the attack surface for information security.

[0006] Third, external platform failures can cause single points of failure. When the cloud platform server crashes, the RSU device fails, or the edge node is overloaded, all vehicles that rely on that external node will be affected simultaneously, and the system lacks the fault tolerance capability to operate independently.

[0007] Fourth, the vehicle personalization adaptation capability is insufficient. Different vehicles have significant differences in computing hardware configuration (CPU, GPU, memory), sensor type and number, driving route characteristics, and Operational Design Domain (ODD) conditions. However, centralized platforms use a uniform model and parameter configuration, making it difficult to perform fine-grained AI model customization, computing power adaptation, and parameter optimization for the specific hardware constraints and operating scenarios of each vehicle.

[0008] Fifth, the lack of a vehicle-side computing power management mechanism. Existing solutions lack the ability to systematically manage onboard computing resources and fail to address the dynamic changes in computing power requirements under different operating conditions. During vehicle operation, computing demands fluctuate significantly due to changes in road complexity, weather conditions, traffic density, sensor load, and other factors. However, the existing architecture lacks a computing power allocation mechanism that can independently perform static pre-planning and dynamic real-time scheduling on the vehicle side.

[0009] Therefore, there is an urgent need for a vehicle-centric distributed AI autonomous driving system that can deploy all AI model components, computing power components, and data components within the vehicle system. Relying solely on the vehicle's own data acquisition capabilities, computing resources, AI models, and parameters, it can independently complete the entire process of autonomous driving functions, including perception, recognition, localization, fusion, prediction, planning, decision-making, and control. This would achieve safe, efficient, and reliable autonomous driving without relying on any external platform support. Summary of the Invention

[0010] The purpose of this application is to provide a vehicle-driven distributed artificial intelligence autonomous driving system and method that can realize autonomous driving-related functions solely based on the vehicle's own data, computing power, models, and parameters, without relying on the support of external platforms.

[0011] To achieve the above objectives, this application adopts the following technical solution: A vehicle-driven distributed artificial intelligence (AI) autonomous driving system includes one or more of AI model components, computing power components, and data components. The system relies solely on the vehicle's own data, computing power, models, and parameters to achieve autonomous driving functions such as perception, recognition, localization, fusion, prediction, planning, decision-making, and control.

[0012] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the system is deployed and hosted on the vehicle system, without relying on real-time operational support provided by the roadside unit (RSU) system, edge system, traffic control center / traffic control unit (TCC / TCU) and cloud platform.

[0013] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the system includes an AI allocation subsystem and an operation and maintenance management subsystem, both of which are deployed on the vehicle and are autonomously controlled by the vehicle throughout the entire process.

[0014] Preferably, in the above-mentioned vehicle-driven distributed artificial intelligence autonomous driving system, the system includes communication components, computing components, power supply components, and perception components. All of these components are vehicle-specific components and are used only to support the implementation of vehicle-side autonomous driving functions.

[0015] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the system performs customized and / or personalized configurations based on the vehicle's own characteristics. The customized configuration process is carried out based on the vehicle's inherent characteristics and does not rely on data support from any external platform.

[0016] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the system achieves personalized adaptation for specific scenarios during vehicle operation, such as trip-specific, path-specific, road-specific, operation design domain (ODD)-specific, and / or vehicle-specific scenarios. The personalized adaptation is completed based on data autonomously collected by the vehicle.

[0017] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the system implements personalized configuration based on the priority of the user and / or the trip, and the priority is determined by the service level information recorded on the vehicle and the urgency instructions issued by the user.

[0018] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the system is equipped with a distillation method to optimize trip-related parameters, thereby optimizing autonomous driving decisions. The distillation method is executed independently by the vehicle's computing power and does not rely on external computing power.

[0019] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the distillation method is configured to generate medium-sized, small-sized, or micro-sized models from large-scale models deployed on the vehicle side, in order to adapt to the constraints of the vehicle's computing power.

[0020] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the AI ​​allocation subsystem includes one or more of a computing power allocation module, a data allocation module, a model allocation module, and / or a parameter allocation module. All of these modules are deployed on the vehicle side and serve only the vehicle-side AI allocation needs.

[0021] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the operation and maintenance management subsystem includes a coordination and optimization module and / or an execution module, used to realize the full-process operation management and maintenance of vehicle-side AI models, computing power and data.

[0022] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the AI ​​model component includes one or more of micro-models, small-scale models, medium-scale models, and large-scale models. All models are deployed and run within the vehicle system and do not rely on external models for support.

[0023] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the model allocation module is configured to allocate and manage micro-models, small models, medium-sized models, and / or large models deployed on the vehicle side, in order to adapt to the actual functional requirements of vehicle-driven autonomous driving.

[0024] Preferably, in the aforementioned vehicle-driven distributed artificial intelligence autonomous driving system, the AI ​​model component is trained and deployed autonomously by the vehicle to meet the vehicle's operational needs, without relying on any external platform for training support.

[0025] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the trained model and related data are updated using real-time or dynamic update methods supported by the vehicle, and the entire update process does not depend on the real-time operation support of external systems. Wherein: (1) A real-time update method is configured to update data and / or the trained model in a time range of 0.1 milliseconds to 1 second to ensure that the vehicle-side model can immediately combine the new data after receiving it, adjust its parameters in real time, and provide an adaptive response without delay. (2) Dynamic update method, configured to update data and / or trained model with an update time ranging from 1 second to several days, to enable the vehicle-side model to undergo periodic data-driven correction and optimize its performance over time through an adaptive learning mechanism.

[0026] Preferably, in the above-mentioned vehicle-driven distributed artificial intelligence autonomous driving system, the computing power allocation module includes a static computing power allocation submodule and / or a dynamic computing power allocation submodule, and the various submodules only allocate and schedule the computing power available on the vehicle side.

[0027] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the static computing power allocation submodule is configured to identify available computing resources on the vehicle side, estimate the computing power demand during vehicle operation, calculate the computing power gap, and allocate the vehicle's own computing power to compensate for the computing power gap. The static computing power allocation submodule includes one or more of the following: a static computing power identification unit, a computing power demand identification unit, a gap calculation unit, and a computing power allocation unit. It is hosted on the onboard computing platform and can utilize the vehicle's own computing resources and / or idle vehicle computing resources to compensate for the calculated gap.

[0028] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the dynamic computing power allocation submodule is configured to monitor the vehicle's operating status and external environmental changes in real time, and dynamically adjust the vehicle's computing power allocation scheme to adapt to the vehicle's real-time operating needs. The dynamic computing power allocation submodule includes an internal change identification unit and / or available computing power identification unit from the supply side, an external change identification unit and / or computing power demand identification unit from the demand side, an insufficient computing unit, a distillation unit, and multiple vehicle computing resource allocation units. Deployed on the onboard computing platform, it utilizes the vehicle's own computing resources and / or idle vehicle computing resources to compensate for the real-time resource gap between the supply and demand sides.

[0029] Preferably, in the aforementioned vehicle-driven distributed AI autonomous driving system, the data component includes vehicle data, ODD data, and system data. All data is autonomously collected, stored, and processed by the vehicle, without relying on any external data input. Wherein: (1) Vehicle data includes onboard sensor data and vehicle status data; (2) ODD data includes road conditions, weather conditions and traffic environment data related to the operational design domain; (3) System data includes system operation status data, computing resource usage data and model operation log data.

[0030] Secondly, this application also provides a vehicle-centric distributed artificial intelligence autonomous driving method, applying the vehicle-centric distributed artificial intelligence autonomous driving system described in the first aspect. This method achieves stable operation of the vehicle's autonomous driving function solely through the vehicle's own data collection, computing power allocation, model training, and operation and maintenance management. The method includes: (1) The data component autonomously collects vehicle data, ODD data, and system data; (2) The computing power allocation module allocates and schedules the available computing resources on the vehicle through the static computing power allocation sub-module and / or the dynamic computing power allocation sub-module; (3) The AI ​​model component independently completes the training, deployment, and updating of the model on the vehicle side; (4) The model allocation module allocates and manages AI models of different sizes according to the actual functional requirements of autonomous driving on the vehicle side; (5) The coordination and optimization module of the operation and maintenance management subsystem performs unified management and optimization of vehicle-side AI models, computing power and data.

[0031] The vehicle-driven distributed artificial intelligence autonomous driving system and method provided in this application have at least the following beneficial effects: (1) This application deploys and hosts all AI model components, computing power components and data components on the vehicle system without relying on any external support from roadside unit systems, edge systems, traffic control centers / traffic control units and cloud platforms. This enables the vehicle to independently complete the entire process of autonomous driving functions such as perception, identification, localization, fusion, prediction, planning, decision-making and control even in communication anomalies such as network interruption, weak signal coverage or high latency. This fundamentally eliminates the risk of autonomous driving function interruption caused by external communication failures, while avoiding the risk of privacy leakage during data transmission and the risk of single point of failure of external platforms.

[0032] (2) This application supports customized configuration for the inherent characteristics of the vehicle itself, and can achieve personalized adaptation for specific scenarios such as trip, route, road, operation design domain and vehicle. It can also prioritize scheduling based on user service level information and urgency, and can more accurately match the actual hardware constraints and operation requirements of each vehicle.

[0033] (3) The vehicle-side distillation method configured in this application can be executed independently by the vehicle-side computing power to generate medium-sized, small or micro models from large models. Under the constraints of vehicle power supply, cooling system, hardware resources and computing power, it can still run an AI model that matches the requirements of autonomous driving tasks, effectively solving the contradiction between the limited computing power on the vehicle and the requirements of high-performance AI models.

[0034] (4) The static computing power allocation submodule of this application identifies available computing resources on the vehicle before the start of the trip, estimates computing power requirements and calculates the gap. The dynamic computing power allocation submodule monitors the operating status and changes in the external environment in real time during the vehicle operation and dynamically adjusts the computing power allocation scheme. The dual-mode collaboration ensures that the vehicle always has sufficient computing resources to support the autonomous driving function under different operating conditions.

[0035] (5) This application supports multi-level vehicle-side deployment of micro-models, small models, medium-sized models and large models. The model allocation module allocates and manages the models according to actual functional requirements, covering eight major driving function domains. The training and deployment of the models are completed autonomously by the vehicle. The trained models and data are updated in real time (0.1 milliseconds to 1 second) or dynamically (1 second to several days) to ensure that the models always adapt to the latest environmental changes.

[0036] (6) The data components of this application cover vehicle data, ODD data and system data. All data are collected, stored and processed autonomously by the vehicle, forming a complete closed loop of vehicle data from data collection, preprocessing, fusion, distribution to model training and parameter updating, avoiding data delay or data loss caused by reliance on external data transmission.

[0037] (7) The operation and maintenance management subsystem of this application manages the vehicle-side AI model, computing resources and data in a unified manner through the coordination and optimization module. The coordination submodule is responsible for task management, resource matching, priority processing and load balancing. The optimization submodule realizes resource elastic scaling, energy consumption optimization and performance tuning to ensure efficient and stable operation of the vehicle-side autonomous driving system throughout its entire life cycle. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 A schematic diagram of key components in a vehicle-centric distributed AI autonomous driving system; Figure 2 A schematic diagram of an exemplary structure for a vehicle-driven distributed artificial intelligence autonomous driving system; Figure 3 A detailed structural diagram of the subsystems and modules of a vehicle-centric distributed artificial intelligence autonomous driving system; Figure 4 A schematic diagram of the structure of an AI-driven allocation system hosted by the vehicle system; Figure 5 A schematic diagram of module allocation for the vehicle-side model; Figure 6 A diagram illustrating the limitations of a vehicle's computing power; Figure 7 This is an exemplary structural diagram of the communication components of an in-vehicle AI system; Figure 8 A schematic diagram of the static computing power allocation submodule of a vehicle-centric system; Figure 9 A schematic diagram of the dynamic computing power allocation submodule of a vehicle-centric system; Figure 10 Workflow diagram for static computing resource allocation; Figure 11 Workflow diagram for allocating dynamic computing power; Figure 12 A schematic diagram of the structure of the vehicle data allocation submodule; Figure 13 This is a schematic diagram of the data acquisition unit. Figure 14 This is a schematic diagram of the data measurement unit. Figure 15 A schematic diagram of the data allocation unit; Figure 16 This is a schematic diagram of the structure of a big data preprocessing unit; Figure 17 A schematic diagram of the distillation preparation unit; Figure 18 A schematic diagram of the hardware structure for the data allocation module; Figure 19 A flowchart illustrating the data cleaning and fusion workflow for a big data reprocessing unit; Figure 20 Workflow diagram for allocating training data to the vehicle; Figure 21 This is a structural diagram of a large AI model; Figure 22 This is a schematic diagram of the structure of a small AI model; Figure 23 This is a schematic diagram of the structure of a miniature AI model; Figure 24 A schematic diagram of the model repository structure for AI model components; Figure 25 A schematic diagram of the mathematical framework for assigning modules to an AI model; Figure 26 Deployment flowchart for assigning modules to AI models; Figure 27 Configuration flowchart for assigning modules to AI models; Figure 28 This is a schematic diagram of a vehicle-centric primary architecture. Figure 29 A flowchart illustrating the vehicle operation process; Figure 30 A schematic diagram of the structure of the vehicle-centric model deployment allocation subsystem; Figure 31 This is a schematic diagram of the structure of a vehicle-centric model training allocation subsystem; Figure 32 A schematic diagram of the overall component structure of the parameter allocation module; Figure 33Flowchart for parameter allocation and update; Figure 34 This is a flowchart of the parameter acquisition submodule; Figure 35 Flowchart for parameter allocation; Figure 36 Flowchart for parameter update; Figure 37 A schematic diagram of the architecture for the coordination and optimization module; Figure 38 A schematic diagram of the architecture of the coordination submodule; Figure 39 A schematic diagram illustrating the architecture of the optimized submodules; Figure 40 Workflow diagram for coordinating and optimizing modules.

[0040] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0041] First, the reference numerals in the attached figures are explained as follows: 101. AI systems for autonomous driving; 102. Computing power components; 103. AI model components; 104. Data components; 201. AI system for autonomous driving; 202. AI allocation subsystem; 203. Operation and maintenance management subsystem; 301. AI system for autonomous driving; 302. AI allocation subsystem; 303. Operation and maintenance management subsystem; 304. Computing power allocation module; 305. Data allocation module; 306. Model allocation module; 307. Parameter allocation module; 308. Coordination and optimization module; 309. Execution module; 401. AI system for autonomous driving; 402. Computing power allocation module; 403. Data allocation module; 404. Model allocation module; 405. Parameter allocation module; 406. Deployment; 407. Vehicle system; 501. Model allocation module; 502. Large model; 503. Medium model; 504. Small model; 505. Micro model; 506. Deployed on; 507. Vehicle system; 601. Limitations of vehicle computing power; 602. Power supply; 603. Cooling system; 604. Hardware resource limits; 605. Computing processing power; 701. Communication components of AI systems (advanced cellular networks available); 702. Communication components of AI systems (advanced cellular networks not available); 703. 3G; 704. 4G; 705. 5G; 706. 6G; 707. Digital broadcasting; 708. Wi-Fi; 709. Bluetooth; 710. Satellite; 801. Static computing power allocation submodule; 802. Static computing power identification unit; 803. Computing power demand identification unit; 804. Gap calculation unit; 805. Computing power allocation unit; 806. Vehicle-centric computing platform; 807. Desired vehicle computing resources; 808. Computing resources of this vehicle; 809. Idle vehicle computing resources; 810. Mounted on; 811. Allocated; 901. Dynamic Computing Capacity Allocation Submodule; 902. Supply; 903. Internal Change Identification Unit; 904. Available Computing Capacity Identification Unit; 905. Demand; 906. External Change Identification Unit; 907. Computing Capacity Demand Identification Unit; 908. Insufficient Computing Unit; 909. Distillation Unit; 910. Vehicle Computing Resource Allocation Unit; 911. Vehicle Route Computing Resource Allocation Unit; 912. Vehicle Road Computing Resource Allocation Unit; 913. Onboard Computing Platform; 914. Required Vehicle Computing Resources; 915. Vehicle Computing Resources; 916. Idle Vehicle Computing Resources; 917. Deployment; 918. Allocation; 1201. Vehicle-mounted data distribution submodule; 1202. Data collection unit; 1203. Data measurement unit; 1204. Big data preprocessing unit; 1205. Data distribution unit; 1206. Distillation preparation unit; 1207. Vehicle; 1208. Vehicle; 1209. Distribution; 1210. Deployment; 1301. Data Acquisition Unit; 1302. Vehicle-mounted Data Acquisition Subunit; 1303. Workshop Data Acquisition Subunit; 1401. Data Measurement Unit; 1402. Detectable Data Recognition Component; 1403. Data Scale Component; 1404. Model Scale Component; 1405. Update Frequency Determination Component; 1501. Data allocation unit; 1502. Data management component; 1503. Data allocation strategy component; 1601. Data preprocessing unit; 1602. Data quality measurement component; 1603. Data preprocessing component; 1604. Data fusion component; 1701. Distillation preparation unit; 1702. Vehicle-specific data preparation component; 1703. Route-specific data preparation component; 1704. Road-specific data preparation component; 1705. ODD-specific data preparation component; 1706. Journey-specific data preparation component; 1801. Data distribution system hardware; 1802. Data storage; 1803. Memory; 1804. Central processing unit (CPU); 1805. Graphics processor (GPU); 2101. Large-scale AI model; 2102. Recognition; 2103. Perception; 2104. Localization; 2105. Fusion; 2106. Prediction; 2107. Decision-making; 2108. Planning; 2109. Control; 2110. Specific vehicle model allocation unit; 2111. Specific route model allocation unit; 2112. Distillation unit; 2201. Small AI model; 2202. Recognition; 2203. Perception; 2204. Localization; 2205. Fusion; 2206. Prediction; 2207. Decision-making; 2208. Planning; 2209. Control; 2210. Vehicle-specific model allocation unit; 2211. Route-specific model allocation unit; 2212. Distillation unit; 2301. Miniature AI Model; 2302. Recognition; 2303. Perception; 2304. Localization; 2305. Fusion; 2306. Prediction; 2307. Decision Making; 2308. Planning; 2309. Control; 2310. Specific Vehicle Model Allocation Unit; 2311. Specific Route Model Allocation Unit; 2312. Distillation Unit; 2401. AI Model Repository; 2402. Deep Learning Models; 2403. Artificial Intelligence Agent Models; 2404. Reinforcement Learning Model; 2405. Generative Model; 2406. Basic Model; 2407. Swarm Intelligence Model; 2501, V; 2502, OV; 2801. Vehicle-based driving model; 2802. Perception; 2803. Sensing; 2804. Localization; 2805. Fusion; 2806. Prediction; 2807. Decision-making; 2808. Planning; 2809. Control; 3001. Vehicle-centric model deployment and allocation subsystem; 3002. Input analysis module; 3003. Hardware capability verification module; 3004. Distillation unit; 3005. Resource coordination module; 3006. Allocation Execution Module; 3007. Vehicle-Specific Model Allocation Unit; 3008. Vehicle-Specific Route Model Allocation Unit; 3009. Vehicle Platform; 3010. Allocation; 3011. Hosting; 3012. Vehicle; 3101. Vehicle-centric model training and allocation subsystem; 3102. Input analysis module; 3103. Scene-aware model allocation module; 3104. Vehicle-specific model allocation unit; 3105. Hardware capability verifier module; 3106. Resource coordination module; 3107. Vehicle-specific route model allocation unit; 3108. Resource retrieval module; 3109. Allocation execution module; 3110. Distillation unit; 3111. Vehicle platform; 3112. Beyond-line-of-sight input; 3113. Allocation; 3114. Deployment; 3116. Vehicle-based training; 3201. Parameter Allocation Module; 3202. Parameter Acquisition Submodule; 3203. Parameter Allocation Submodule; 3204. Parameter Update Submodule; 3205. Parameter Acquisition Unit; 3206. Parameter Statistics Unit; 3207. Computing Resource Unit; 3208. Parameter Allocation Unit; 3209. Vehicle Parameter Update Unit; 3210. ODD Parameter Update Unit; 3211. AI Model Parameter Update Unit; 3212. Parameter Update Progress Unit; 3701. Coordination and Optimization Module; 3702. Coordination Submodule; 3703. Optimization Submodule; 3801. Coordination Submodule; 3802. Task Management Unit; 3803. Resource Matching Unit; 3804. Priority Processing Unit; 3805. Load Balancing Unit; 3806. Cluster Management Unit; 3901. Optimization Submodule; 3902. Resource Expansion Unit; 3903. Energy Consumption Optimization Unit; 3904. Resource Efficiency Optimization Unit; 3905. Performance Tuning Unit.

[0042] Example: Figure 1 A schematic diagram of key components of a vehicle-driven distributed artificial intelligence autonomous driving system is shown. The AI ​​system 101 for autonomous driving includes one or more of the following: computing power component 102, AI model component 103, and data component 104. The computing power component 102 is configured to independently execute the computing tasks required for autonomous driving functions such as perception, recognition, localization, fusion, prediction, planning, decision-making, and control, relying solely on the vehicle's own computing resources (including CPU, GPU, memory, etc.), without depending on any external computing power support provided by roadside units, edge systems, traffic control centers, or cloud platforms.

[0043] AI model component 103 includes one or more of micro-models, small-scale models, medium-scale models, and large-scale models. All models are deployed and run inside the vehicle system, and the training, deployment, and updating of models are completed autonomously by the vehicle, without relying on real-time invocation or support of external models.

[0044] Data component 104 is configured to collect, store and process only vehicle data (such as speed, acceleration and sensor data), operational design domain ODD data (such as road conditions and weather conditions) and system data (such as computing power utilization and model operation logs) generated by the vehicle itself. All data is managed autonomously by the vehicle and does not depend on external data input.

[0045] Through the collaborative work of the above components, the system can independently realize eight autonomous driving functions by relying only on the vehicle's own data, computing power, models and parameters during operation, fundamentally eliminating the dependence on external communication links and external platforms.

[0046] Figure 2 An exemplary structural diagram of a vehicle-driven distributed artificial intelligence autonomous driving system is shown. The AI ​​system 201 for autonomous driving includes one or more of an AI allocation subsystem 202 and an operation and maintenance management subsystem 203.

[0047] Figure 3 This paper presents a detailed structural diagram of the subsystems and modules of a vehicle-centric distributed artificial intelligence autonomous driving system. The AI ​​system 301 for autonomous driving includes one or more of the following: an AI allocation subsystem 302 and an operation and maintenance management subsystem 303. The AI ​​allocation subsystem 302 includes one or more of the following: a computing power allocation module 304, a data allocation module 305, a model allocation module 306, and a parameter allocation module 307. The operation and maintenance management subsystem 303 includes one or more of the following: a coordination and optimization module 308 and an execution module 309.

[0048] Figure 4 This paper illustrates the system architecture of a vehicle-centric distributed artificial intelligence autonomous driving system allocation system. The AI ​​allocation system 401 for autonomous driving includes one or more of the following: a computing power allocation module 402, a data allocation module 403, a model allocation module 404, and a parameter allocation module 405. The AI ​​allocation system 401 for autonomous driving is deployed 406 within the vehicle system 407.

[0049] Figure 5 This is a schematic diagram of the model allocation module. The model allocation module 501 includes one or more of the following: large model 502, medium model 503, small model 504, and micro model 505. The micro model 505, small model 504, medium model 503, and large model 502 are deployed 506 in the vehicle system 507.

[0050] Figure 6 This is a schematic diagram illustrating the limitations of a vehicle's computing power. The limitations 601 include one or more of the following: power supply 602, cooling system 603, hardware resource limits 604, and computing processing capacity 605.

[0051] Figure 7 An exemplary structure of the communication components of an AI system is shown. When an advanced cellular communication network is available, the communication component 701 of the AI ​​system includes one or more of 3G 703, 4G 704, 5G 705, 6G 706, digital broadcasting 707, Wi-Fi 708, Bluetooth 709, and satellite 710. When an advanced cellular communication network is unavailable, the communication component 702 of the AI ​​system includes one or more of 3G 703, 4G 704, and digital broadcasting 707.

[0052] Figure 8 The structure of a static computing power allocation submodule 801 for a vehicle-centric system is shown, including one or more of a static computing power identification unit 802, a computing power demand identification unit 803, a gap calculation unit 804, and a computing power allocation unit 805. The static computing power allocation submodule 801 for the vehicle-centric system is configured to be hosted 810 on a vehicle-centric computing platform 806, where desired computing resources 811 can be allocated, such as desired vehicle computing resources 807. This submodule 801 further utilizes local vehicle computing resources 808 and / or idle vehicle computing resources 809 to compensate for any calculated gaps, thereby ensuring that the vehicle-based platform has sufficient processing power to meet static computing power requirements.

[0053] Figure 9 The architecture of a dynamic computing power allocation submodule 901 in a vehicle-centric system is illustrated. This module includes an internal change identification unit 903 and / or an available computing power identification unit 904 from the supply side 902, an external change identification unit 906 and / or a computing power demand identification unit 907 from the demand side 905, a shortage computing unit 908, a distillation unit 909, a vehicle computing resource allocation unit 910, a vehicle route computing resource allocation unit 911, and / or a vehicle road computing resource allocation unit 912. This submodule 901 is deployed 917 on an onboard computing platform 913 and is capable of allocating 918 the required vehicle computing resources 914. This submodule 901 can also utilize its own vehicle computing resources 915 and / or idle vehicle computing resources 916 to compensate for real-time resource gaps between the supply side 902 and the demand side 905.

[0054] Figure 10This document demonstrates the static computing resource allocation workflow for planned purposes, illustrating the allocation schemes before real-time operation or under external conditions through a typical sequence of steps. The system first collects information on all available computing resources, including onboard processing hardware (such as CPU, GPU, and memory). This resource list is collected at a set time or before the start of the trip to ensure that known capacity is fully recorded. Subsequently, the system calculates the expected computing requirements for vehicle operation based on factors such as route complexity, anticipated traffic density, weather conditions, and the onboard AI model. During this planning phase, the system analyzes whether standard sensor data streams (such as LiDAR, radar, and cameras) need to be offloaded, or whether existing onboard hardware can independently complete the task. The workflow checks the difference between resource availability and predicted demand. If there is no shortage, the system executes the predetermined allocation scheme; if a resource shortage is detected (e.g., the onboard CPU / GPU or memory cannot meet the expected workload), the calculation step precisely determines the required additional capacity. The system then utilizes idle computing resources within the vehicle and / or available vehicle computing resources to compensate for the deficiency. During this phase, the static computing capacity allocation method employs a preset or rule-based allocation strategy, comprehensively considering resource overhead, bandwidth, or latency limitations set in the planning phase to determine the task allocation scheme. Finally, after resource reallocation or acquisition is complete, the system will conclude the workflow by confirming whether the revised static plan meets the expected needs of the upcoming trip or operating period. If the trip or operating plan changes (e.g., due to changes in road conditions or updated user needs), the system can rerun the process to re-verify whether all identified needs can still be met.

[0055] Figure 11This demonstrates the workflow of dynamic computing power allocation for real-time vehicle operation, showcasing how a vehicle copes with insufficient computing power under constantly changing conditions. In this process, the system first continuously monitors onboard parameters, including CPU / GPU utilization, battery status, and sensor health (such as LiDAR, radar, and camera streams), while simultaneously observing changes in the external environment, such as rapidly changing weather patterns, sudden traffic congestion, or unforeseen road hazards. When internal modules detect a potential increase in load (e.g., the addition of new sensors or advanced perception tasks triggered by adverse environmental factors), they automatically compare the total computing demand with current onboard resources. If the onboard CPU / GPU capacity is sufficient, the vehicle will continue operating without adjustment. However, when the system identifies insufficient computing power (e.g., real-time sensor fusion requires more GPUs and memory than currently available), it immediately assesses available idle onboard resources and resources from other vehicles to fill the gap. These resources may include idle GPUs from surrounding vehicles. When the vehicle determines that accessing idle vehicle computing resources is the optimal solution, the system will offload specific tasks such as intensive perception, map updates, or advanced path planning via wireless communication. This resource allocation is dynamic and has minimal impact on the overall autonomous driving function. The final step is shown in the diagram. Figure 11 This demonstrates how the system allocates customized idle vehicle computing resources to compensate for insufficient onboard computing power, ensuring that the vehicle maintains safe and responsive handling performance under constantly changing operating or environmental scenarios. After resource allocation, the system re-enters a continuous monitoring loop, ready to detect new deficiencies or release redundant computing resources. By coordinating the real-time collaboration between the vehicle's own hardware and idle computing resources from other vehicles, this dynamic workflow provides robust autonomous driving performance even when computing demands fluctuate.

[0056] Figure 12 The architecture of the vehicle-mounted data distribution submodule 1201 is shown, which includes one or more of the following: a data collection unit 1202, a data measurement unit 1203, a big data preprocessing unit 1204, a data distribution unit 1205, and a distillation preparation unit 1206. This vehicle-mounted distribution submodule 1201 is configured to be deployed on vehicle 1207 and is responsible for distributing and integrating data from one or more vehicles 1207 to vehicle 1208.

[0057] Figure 13 The architecture of the data acquisition unit 1301 is shown, which includes one or more external data acquisition subunits 1302 and on-board data acquisition subunits 1303. The on-board data acquisition subunit 1302 is responsible for acquiring on-board sensor data and vehicle status data, while the on-board data acquisition subunit 1303 is responsible for acquiring auxiliary data from surrounding vehicles.

[0058] Figure 14The architecture of the data measurement unit 1401 is illustrated. This unit includes one or more of the following: a detectable data identification component 1402, a data size component 1403, a model size component 1404, and an update frequency determination component 1405. Specifically, the detectable data identification component 1402 determines whether the data is detectable; the data size component 1403 determines the size of the data; the model size component 1404 determines the model size corresponding to the data during training or inference; and the update frequency determination component 1405 is specifically responsible for determining the data update frequency.

[0059] Figure 15 The architecture of the data allocation unit 1501 is illustrated, which includes one or more of a data management component 1502 and a data allocation strategy component 1503. The data management component 1502 is responsible for queuing all data to be transmitted, ensuring proper organization and prioritization of the data. The data allocation strategy component 1503 dynamically adjusts the allocation strategy based on the measurement data from the data measurement unit 1401 and the priority of the data sent by the data management component 1502, thereby ensuring the granularity of data allocation.

[0060] Figure 16 The architecture of a big data preprocessing unit 1601 is illustrated, which includes one or more of a data quality measurement component 1602, a data preprocessing component 1603, and a data fusion component 1604. The data quality measurement component 1602 is responsible for identifying data quality, including missing values, duplicate values, and validity checks. The data preprocessing component 1603 receives messages or notifications from the data quality measurement component 1602, performs missing value imputation and duplicate value removal, and reformats the dataset to a valid format. The data fusion component 1604, after completing data quality measurement and preprocessing, is responsible for fusing the data.

[0061] Figure 17The structure of the distillation preparation unit 1701 is shown, which includes one or more of the following components: a vehicle-specific data preparation component 1702, a route-specific data preparation component 1703, a road-specific data preparation component 1704, an ODD-specific data preparation component 1705, and a trip-specific data preparation component 1706. Specifically, the vehicle-specific data preparation component 1702 is configured to prepare training and validation data for a specific vehicle used in large-scale model distillation. The route-specific data preparation component 1703 is configured to prepare training and validation data for a specific route used in large-scale model distillation. The road-specific data preparation component 1704 is configured to prepare training and validation data for a specific road used in large-scale model distillation. The ODD-specific data preparation component 1705 is configured to prepare training and validation data for a specific operating design domain (ODD) used in large-scale model distillation. The trip-specific data preparation component 1706 is configured to prepare training and validation data for a specific trip used in large-scale model distillation.

[0062] Figure 18 The structure of the data allocation module hardware 1801 is shown, which includes one or more of the following components: data storage 1802, random access memory (RAM) 1803, central processing unit (CPU) 1804, and graphics processing unit (GPU) 1805. For example, in some embodiments, the data storage 1802 may be a Samsung 990 Pro solid-state drive (SSD); the RAM 1803 may be a Corsair Vengeance RGB DDR5 (6000MHz–8000MHz); the CPU 1804 may be an Intel Core i9-14900K; and the GPU 1805 may be an NVIDIA GeForce RTX 4090.

[0063] Figure 19 This demonstrates the workflow of a big data reprocessing unit used for data cleaning and fusion. The process first determines whether the data is clean or unclean. If the data is unclean, it is preprocessed and then returned for reassessment. If the data is clean, its quality is further evaluated. If the data quality is good, it proceeds directly to the fusion stage; if the data quality is poor, it is preprocessed to improve its integrity. After preprocessing, the data is again assessed for cleanliness and good quality. If it still does not meet the requirements, it returns to continue processing; if it meets the criteria, it enters the fusion stage, where different datasets are merged. Finally, the process ends, ensuring that only high-quality, fully processed data is used for subsequent analysis.

[0064] Figure 20The workflow of the data allocation unit for vehicle-side training data allocation is demonstrated. The data allocation unit receives notifications from the data measurement unit, which is configured to determine data detectability, data size, model size for training, and update frequency. The process first determines data detectability. If detectable, its data size is further determined. If the data size is less than 10 GB, the training model size is evaluated. If the training model size is less than 0.1 B parameters (i.e., 100 million parameters), the update frequency is further evaluated. If the update frequency is less than 10 ms, the data is allocated to the vehicle for training. This ensures that lightweight data with high timeliness requirements is processed directly on the vehicle. The process ends after data allocation is complete.

[0065] Figure 21 The structure of a large-scale AI model 2101 is shown, which includes an application layer comprising recognition 2102, perception 2103, localization 2104, fusion 2105, prediction 2106, decision-making 2107, planning 2108, and control 2109. The large-scale AI model 2101 also includes a vehicle-specific model allocation unit 2110 for customizing the model according to the hardware conditions or operational constraints of a specific vehicle; a route-specific model allocation unit 2111 for adapting AI functions based on route conditions; and a distillation unit 2112 for refining or compressing the model as needed to generate smaller-scale model variants.

[0066] Figure 22 The structure of a small-scale AI model 2201 is shown, which includes an application layer comprising recognition 2202, perception 2203, localization 2204, fusion 2205, prediction 2206, decision-making 2207, planning 2208, and control 2209. The small-scale AI model 2201 also includes a vehicle-specific model allocation unit 2210, a route-specific model allocation unit 2211, and a distillation unit 2212. Compared to medium-scale AI models, this model typically has stricter resource constraints or a more streamlined structure, making it suitable for vehicles with limited onboard computing power.

[0067] Figure 23The structure of the miniature AI model 2301 is shown, which includes an application layer comprising recognition 2302, perception 2303, localization 2304, fusion 2305, prediction 2306, decision-making 2307, planning 2308, and control 2309. The miniature AI model 2301 also includes a vehicle-specific model allocation unit 2310, a route-specific model allocation unit 2311, and a distillation unit 2312. This minimal-scale model prioritizes minimizing the use of onboard resources while still providing basic autonomous driving functions, and supports advanced functions through model distillation when needed.

[0068] Figure 24 The structure of an AI model repository 2401 for AI model components is shown. This repository contains various types of AI technologies and is organized into six categories: deep learning models 2402, AI agent models 2403, reinforcement learning models 2404, generative models 2405, basic models 2406, and swarm intelligence models 2407. This model repository structure, based on technology implementation paths, systematically organizes, classifies, and retrieves AI models to support the implementation of autonomous driving functions.

[0069] Figure 25 This paper presents the mathematical framework for the model allocation module in an autonomous driving system. As shown in the figure, the framework provides the core equation for controlling AI model allocation: M = F(V, OV), where M represents the combined output of AI models selected from the model repository; V2501 represents the set of AI models based on the vehicle; and OV2502 represents the set of AI models based on external components. The function F determines the coordination between V and OV to generate a model combination M that meets a predetermined level of automation while simultaneously satisfying safety and computational resource constraints. Furthermore, the figure also shows the dependent equation: V = f1(x1, x2, ..., x3). ) and OV = f2(x1, x2, …, x ), where f1 and f2 represent functions used to determine the vehicle-side AI model and the vehicle-side AI model, respectively, and the variables x1 to x It represents a single model from different functional domains, including functional modules such as perception, recognition, localization, fusion, prediction, planning, decision-making, and control.

[0070] Figure 26 The deployment process of the AI ​​model allocation module is demonstrated. The process first determines a function F as the criterion for model allocation. Based on function F, a set of AI models M is determined. After the set of AI models M is determined, the process ends, ensuring that the AI ​​models are allocated for subsequent use.

[0071] Figure 27The configuration process for the AI ​​model allocation module is demonstrated. This process begins by defining the model selection target, followed by input data type validation, driving scenario analysis, and hardware capability assessment. Next, based on the assessment results, the model size is determined, and finally, the optimized model is deployed for use.

[0072] Figure 28 The primary architecture was showcased: centered on the vehicle (2801), which includes an onboard driving model with multiple driving functions, covering perception (2802), sensing (2803), localization (2804), fusion (2805), prediction (2806), decision-making (2807), planning (2808), and control (2809). In this vehicle-centric configuration, all eight driving functions are deployed on the onboard platform, relying on local sensor data and computing power to achieve autonomous driving operation without depending on external data or computing resources.

[0073] Figure 29 The workflow for vehicle operation is demonstrated. The process begins with input analysis of the vehicle system. The workflow then assesses hardware capabilities. If the hardware capabilities meet the requirements, the process proceeds to deploy sensor and localization models on the vehicle system, followed by decision model processing, generation and execution of control commands, and the execution of vehicle control tasks. The process terminates once the vehicle control tasks are completed.

[0074] Figure 30 The structure of a vehicle-centric system model deployment and allocation subsystem 3001 is demonstrated, including an input analysis module 3002, a hardware capability verification module 3003, a distillation unit 3004, a resource coordination module 3005, an allocation execution module 3006, a vehicle-specific model allocation unit 3007, and a route-specific model allocation unit 3008. This subsystem 3001 is configured to be hosted 3011 on a vehicle 3012 and receives model allocation instructions from a vehicle platform 3009 via an allocation mechanism 3010. By verifying onboard capabilities and coordinating internal vehicle resources as needed, subsystem 3001 ensures that AI models and functions are correctly deployed on the vehicle in a vehicle-centric manner.

[0075] Figure 31A model training allocation subsystem 3101 for a vehicle-centric system is demonstrated, comprising an input analysis module 3102, a scene-aware model allocation module 3103, a vehicle-specific model allocation unit 3104, a hardware capability verification module 3105, a resource coordination module 3106, a route-specific model allocation unit 3107, a resource invocation module 3108, an allocation execution module 3109, and a distillation unit 3110. This subsystem 3101 is hosted 3114 on a vehicle-based training 3115 platform and receives model allocation instructions 3113 from the vehicle platform 3111 or out-of-range input 3112. In this vehicle-centric approach, onboard training tasks are primarily managed by the vehicle's local hardware and data resources.

[0076] Figure 32 The overall component structure of the parameter allocation module 3201 is shown. This module consists of three sub-modules: parameter acquisition sub-module 3202, parameter allocation sub-module 3203, and parameter update sub-module 3204. Specifically, parameter acquisition sub-module 3202 includes a parameter acquisition unit 3205 and a parameter statistics unit 3206; parameter allocation sub-module 3203 includes a computing resource unit 3207 and a parameter allocation unit 3208; and parameter update sub-module 3204 consists of a vehicle parameter update unit 3209, an ODD parameter update unit 3210, an AI model parameter update unit 3211, and a parameter update progress unit 3212.

[0077] Figure 33 This demonstrates the process of parameter allocation and updating during vehicle operation using a parameter allocation module. The parameter acquisition unit collects all parameters requiring updates during vehicle operation, while the parameter statistics unit identifies the parameter types and calculates their scale. The computing power resource unit calculates the available computing power of the vehicle-side system, and the parameter allocation unit allocates parameters to the vehicle-side system based on their type, scale, and computing power availability. Finally, the parameter update submodule employs a sequential update strategy to update various parameters.

[0078] Figure 34 This demonstrates the process of collecting and / or statistically evaluating parameters using the parameter acquisition submodule. The parameter acquisition unit collects all parameters that need to be updated during vehicle operation via a communication component. The parameter statistics unit identifies the parameter types, including vehicle parameters, driving environment parameters, and AI model parameters, and calculates the scale of each type of parameter.

[0079] Figure 35An exemplary parameter allocation process is demonstrated. First, the computing power resource unit calculates the available computing power of each host system during the parameter update process. Then, the parameter allocation unit obtains the parameter type and scale from the parameter statistics unit of the parameter acquisition submodule and allocates the parameters to the vehicle-side system group according to the availability of computing power resources. When the parameter scale is at different levels, it is allocated to different vehicle systems.

[0080] Figure 36 An exemplary parameter update flowchart is shown. The vehicle parameter update unit, ODD parameter update unit, and / or AI model parameter update unit first obtain parameter update requests from the parameter allocation submodule and determine whether an update request exists within the current time interval. If no update request exists, the parameter update process ends; if an update request exists but the vehicle is in an unsafe operating state, the parameter update progress unit records the vehicle parameter update status and executes the update after the vehicle stops. If an update request exists and the vehicle is in a safe operating state, the parameter update begins. During the parameter update process, if the computing power of the vehicle-side system can support the current parameter update, the vehicle parameter update unit, ODD parameter update unit, and / or AI model parameter update unit will execute a complete parameter update, and the parameter update progress unit will record the update status; if the computing power is insufficient, the vehicle parameter update unit, ODD parameter update unit, and / or AI model parameter update unit will execute a partial parameter update, and the parameter update progress unit will record the update status. In the next update cycle, these update units will repeat the same judgment and update process based on new update requests and computing power availability.

[0081] Figure 37 The architecture of the collaboration and optimization module is demonstrated. This module consists of a collaboration submodule and an optimization submodule, used for unified management of AI models, computing resources, and data.

[0082] Figure 38 The architecture of the collaboration submodule is shown. The collaboration submodule includes a task management unit, a resource matching unit, a priority processing unit, a load balancing unit, and a cluster management unit, which are used to organize, manage, and arrange the execution order of various tasks according to the allocated vehicle-side resources.

[0083] Figure 39 The architecture of the optimization submodule is shown. The optimization submodule consists of a resource elastic scaling unit, an energy consumption optimization unit, a resource efficiency optimization unit, and a performance tuning unit, aiming to ensure that the allocated vehicle-side resources are utilized most efficiently and that all tasks are executed under optimal performance.

[0084] Figure 40The flowchart illustrates the collaboration and optimization modules. The process begins with the collaboration submodule, which manages the order and timing of task execution. Next, the collaboration submodule matches tasks with allocated vehicle-side resources to ensure correct task-resource mapping. The next stage is the optimization submodule. This submodule monitors resource usage and system performance in real time and dynamically adjusts task execution methods based on workload fluctuations, maintaining overall operational efficiency within resource constraints. Finally, the optimization submodule generates and fine-tunes the optimization results and feeds them back to the collaboration submodule, thus initiating the next task execution cycle.

[0085] Finally, it should be noted that the above 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A vehicle-centric distributed artificial intelligence autonomous driving system, characterized in that, The system includes AI model components, computing power components, and data components. During operation, the system relies solely on the vehicle's own data, computing power, models, and parameters to achieve autonomous driving functions such as perception, recognition, localization, fusion, prediction, planning, decision-making, and control.

2. The system as described in claim 1, characterized in that, The system is deployed and hosted on the vehicle system and does not rely on the real-time operation support provided by the roadside unit (RSU) system, edge system, traffic control center (TCC) / traffic control unit (TCU) and cloud platform.

3. The system as described in claim 1, characterized in that, It includes an AI allocation subsystem and an operation and maintenance management subsystem, both of which are deployed on the vehicle and are autonomously controlled by the vehicle throughout the process.

4. The system as described in claim 1, characterized in that, It includes communication components, computing components, power supply components and sensing components. All of these components are vehicle-specific components and are used only to support the implementation of autonomous driving functions on the vehicle side.

5. The system as described in claim 1, characterized in that, Customized and / or personalized configurations are made based on the vehicle's inherent characteristics. The customization process is carried out based on the vehicle's inherent characteristics and does not rely on data support from any external platform.

6. The system as described in claim 1, characterized in that, Personalized adaptation is achieved for specific scenarios during vehicle operation, such as trip-specific, route-specific, road-specific, operation design domain (ODD)-specific, and / or vehicle-specific scenarios. This personalized adaptation is based on data autonomously collected by the vehicle.

7. The system as described in claim 5, characterized in that, Personalized configuration is achieved based on the priority of the user and / or the trip, and the priority is determined by the service level information recorded on the vehicle and the urgency instructions issued by the user.

8. The system as described in claim 5, characterized in that, The system is equipped with a distillation method to optimize trip-related parameters, thereby optimizing autonomous driving decisions. The distillation method is executed independently by the vehicle-side computing power and does not rely on external computing power.

9. The system as described in claim 1, characterized in that, The AI ​​model components include one or more of micro-models, small-scale models, medium-scale models, and large-scale models. All models are deployed and run within the vehicle system and do not rely on external models for support.

10. The system as described in claim 3, characterized in that, The AI ​​allocation subsystem includes one or more of the following modules: computing power allocation module, data allocation module, model allocation module, and / or parameter allocation module. All of these modules are deployed on the vehicle side and serve only the vehicle-side AI allocation needs.

11. The system as described in claim 3, characterized in that, The operation and maintenance management subsystem includes a coordination and optimization module and / or an execution module, which is used to realize the full-process operation management and maintenance of vehicle-side AI models, computing power and data.

12. The system as described in claim 8, characterized in that, The distillation method is configured to generate medium, small, or micro models from large models deployed on the vehicle side, to adapt to the constraints of the vehicle's computing power.

13. The system as described in claim 12, characterized in that, The model allocation module is configured to allocate and manage micro, small, medium and / or large models deployed on the vehicle to adapt to the actual functional requirements of autonomous driving on the vehicle.

14. The system as claimed in claim 1, characterized in that, The AI ​​model component is trained and deployed autonomously by the vehicle to meet the vehicle's operational needs, without relying on any external platform for training support.

15. The system as described in claim 14, characterized in that, After training, the model and related data are updated using real-time or dynamic update methods supported by the vehicle, and the entire update process does not depend on the real-time operation support of external systems.

16. The system as claimed in claim 10, characterized in that, The computing power allocation module includes a static computing power allocation submodule and / or a dynamic computing power allocation submodule. These submodules allocate and schedule computing power available on the vehicle side only.

17. The static computing power allocation submodule as described in claim 16, characterized in that, It is configured to identify available computing resources on the vehicle, estimate the computing power requirements during vehicle operation, calculate the computing power gap, and allocate the vehicle's own computing power to compensate for the computing power gap.

18. The dynamic computing power allocation submodule as described in claim 16, characterized in that, It is configured to monitor the vehicle's operating status and changes in the external environment in real time, and dynamically adjust the allocation scheme of vehicle computing power to adapt to the real-time operating needs of the vehicle.

19. The system as claimed in claim 1, characterized in that, The data components include vehicle data, ODD data, and system data. All data is collected, stored, and processed autonomously by the vehicle itself, without relying on any external data input.

20. A vehicle-centric distributed artificial intelligence autonomous driving method, characterized in that, Using the system described in any one of claims 1-19, the method achieves stable operation of the vehicle's autonomous driving function solely through the vehicle's own data collection, computing power allocation, model training, and operation and maintenance management. The method includes: (1) The data component autonomously collects vehicle data, ODD data, and system data; (2) The computing power allocation module allocates and schedules the available computing resources on the vehicle through the static computing power allocation sub-module and / or the dynamic computing power allocation sub-module; (3) The AI ​​model component independently completes the training, deployment, and updating of the model on the vehicle side; (4) The model allocation module allocates and manages AI models of different sizes according to the actual functional requirements of autonomous driving on the vehicle side; (5) The coordination and optimization module of the operation and maintenance management subsystem performs unified management and optimization of vehicle-side AI models, computing power and data.

Images