Federal vehicle AI management system and method based on trusted data space

Abstract

The invention discloses a federated vehicle AI management system and method based on trusted data space, and the system comprises a trusted data space infrastructure layer, a cloud AI manager and a vehicle end AI manager, and the trusted data space infrastructure layer comprises an identity authentication service module, a strategy execution engine, a data routing controller and a metadata agent module. The cloud AI manager comprises a multi-agent cooperation engine, a cloud digital twinborn body and a model context protocol interface module, and the vehicle end AI manager comprises a real-time control execution module, a vehicle end digital twinborn body and a data sovereignty gateway. The system can reduce the vehicle cloud data transmission quantity, thereby improving the data transmission efficiency. The minimum necessity principle of data access is realized, and the sovereignty and privacy of user data can be guaranteed; a standardized service integration interface is provided, so that a new service provider can complete access within several weeks, and the energy consumption and the cost are reduced; the integrated realization of various vehicle management scenes is supported, the delay is reduced, and the real-time performance is good.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, specifically to a federated vehicle AI management system and method based on a trusted data space. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity, vehicles have evolved from traditional means of transportation into mobile intelligent terminals integrating a large number of sensors, computing units, and communication modules. Modern intelligent connected vehicles generate terabytes of data every day, covering multiple dimensions such as vehicle powertrain status, environmental perception information, location trajectory, and driving behavior.

[0003] Existing vehicle-to-everything (V2X) systems generally adopt a centralized cloud architecture, with vehicles acting as data collection terminals, periodically reporting full-scale status data to the cloud platform via mobile communication networks. This architecture has the following technical drawbacks:

[0004] 1. The inability to achieve context-aware on-demand data synchronization results in data transmission redundancy of 85-92%.

[0005] 2. The lack of a technically enforceable minimum necessity principle enforcement mechanism means that raw data is directly uploaded to the cloud, posing privacy and compliance risks.

[0006] 3. Third-party service integration uses point-to-point customized interfaces, resulting in long integration cycles (3-6 months) and high maintenance costs;

[0007] 4. Large latency (1-5 seconds) in vehicle-to-cloud data synchronization affects the quality of real-time decision-making services. Existing vehicle-to-everything (V2X) systems generally employ a time-triggered periodic data reporting mechanism when periodically reporting data. The onboard terminal packages and uploads vehicle status data to the cloud at preset time intervals (usually five to thirty seconds). The size of a single reported data packet is typically between two and ten kilobytes, containing hundreds of parameters such as vehicle identification number (VIN), GPS coordinates, vehicle speed, engine speed, battery level, and various sensor readings. The implementation principle of this mode is as follows: the onboard terminal periodically reads the status parameters of each electronic control unit of the vehicle through the controller area network (CAN) bus, encodes them according to the data dictionary defined by the manufacturer, and uploads them to the cloud's message queue service via a fourth-generation or fifth-generation mobile communication network. The cloud application subscribes to the message queue and persists the data to a time-series database.

[0008] To provide intelligent mobility services to users, automakers need to interface with numerous third-party service providers, such as parking lot operators, charging network providers, traffic management departments, and map service providers. Currently, this integration typically employs customized application programming interfaces (APIs): the manufacturer's cloud platform development team negotiates data interface formats with each service provider, develops dedicated adaptation code, and establishes point-to-point virtual private networks or leased lines for data exchange. This tightly coupled architecture leads to: long integration cycles (requiring three to six months of development and testing for each new service platform); high maintenance costs (both parties need to upgrade simultaneously when interface versions change); poor scalability (multiple sets of adaptation code need to be developed for multiple service providers); and severe data silos (different brands of vehicles cannot share a unified service infrastructure).

[0009] Furthermore, existing connected vehicle systems lack the traditional architecture for protecting data sovereignty: in traditional connected vehicle architectures, raw vehicle data is directly uploaded to the manufacturer's cloud platform, leaving users with little control over the data's flow, use, and retention period. Although some systems declare the scope of data use in their user agreements, there is a lack of technical means to enforce these policies. When manufacturers need to share vehicle data with third parties, the data transfer process lacks transparency and auditability, posing a risk of privacy breaches.

[0010] Existing standards for vehicle-to-everything (V2X) architecture include: the Vehicle-to-Everything (V2X) communication standards developed by the 3rd Generation Partnership Project (GPP) (e.g., Technical Specifications 23.285 and 23.286), which define the communication architecture between vehicles and infrastructure, other vehicles, and pedestrians, but primarily focus on the communication layer and do not address cloud data management and service integration. The International Organization for Standardization (ISO) standard 20078, "Intelligent Transportation Systems - Extended Global Open Data Exchange for Vehicles," defines a general framework for vehicle data exchange, but its data model is relatively basic and does not consider the technical implementation of data sovereignty and privacy protection.

[0011] The standard for digital twin technology in the Internet of Vehicles (IoV) is defined by the International Organization for Standardization (ISO) standard 23247, "Manufacturing Framework for Digital Twins of Automated Systems and Integration," which defines the conceptual framework of a digital twin, including four elements: physical entity, virtual entity, data connectivity, and services. Existing research primarily applies digital twins to scenarios such as manufacturing process simulation and predictive maintenance of equipment, employing high-frequency full-data synchronization to maintain high fidelity of the twin. However, it does not address vehicle operation management scenarios or discuss low-fidelity twin design in communication-constrained environments.

[0012] The standards for multi-agent systems in the Internet of Vehicles (IoV) are as follows: The Intelligent Physical Agents Foundation has developed a series of multi-agent system standards, defining specifications such as agent communication languages ​​and interaction protocols. However, these standards are mainly geared towards general computing environments and are not optimized for the real-time, reliability, and security requirements of IoV, nor do they address specific application scenarios for vehicle management.

[0013] The International Data Spaces (IDS) standard in the Internet of Vehicles (IoV) is defined by the International Data Spaces Association, led by the Fraunhofer Institute in the European Union, which published the "International Data Spaces Reference Architecture Model." This model defines an architecture framework based on sovereign data sharing, including core components such as identity management, policy enforcement, and data connectors. While this architecture has been applied in the Industrial Internet sector in Europe, its application in the IoV field is less studied, and the unique characteristics of vehicle data (e.g., high-frequency generation, real-time requirements, and mobility) have not been discussed in depth.

[0014] Therefore, existing vehicle networking systems have the following drawbacks:

[0015] 1. Low data transmission efficiency

[0016] Based on actual testing and analysis of automakers' connected vehicle systems: the periodic reporting frequency is once every ten seconds, the average size of a single data packet is 5.2 kilobytes (after compression), the average daily driving time is two hours, and the average daily data transmission volume per vehicle is approximately 3.65 megabytes. However, auditing the use of cloud data revealed that only about 8% to 15% of the data is actually read by the application, with a data redundancy rate of 85% to 92%. The main reason is that the application only needs specific parameters for specific scenarios (e.g., navigation services only need location, diagnostic services only need fault codes), but the system cannot obtain them on demand and can only report the full amount.

[0017] 2. High energy consumption and cost

[0018] For connected vehicle systems using a data-based billing model: mobile data traffic costs approximately 0.5 to 2 yuan per megabyte (vehicle IoT card), resulting in an annual data cost of approximately 1,332 yuan per vehicle. For an automaker with one million connected vehicles, the annual data cost is approximately 1.332 billion yuan. As for cloud storage costs: time-series database storage costs approximately 0.1 yuan per gigabyte per month, with each vehicle generating approximately 1.33 gigabytes of data annually, resulting in an annual storage cost of approximately 159.6 million yuan for one million vehicles.

[0019] 3. High latency and poor real-time performance

[0020] In the existing architecture, vehicle status data needs to go through a chain of collection at the vehicle end, uploading, cloud storage, and application retrieval, with end-to-end latency typically between one and five seconds. For scenarios requiring real-time decision-making (e.g., dynamic route planning, emergency rescue dispatch), this latency leads to decisions based on outdated information, impacting service quality. More seriously, when a large number of vehicles report data simultaneously, cloud access systems and databases can become congested, resulting in the loss of some data packets or a sharp increase in latency, with the worst-case latency reaching over thirty seconds.

[0021] 4. Privacy and compliance risks

[0022] According to the "Personal Information Protection Law of the People's Republic of China" and the "Several Provisions on the Management of Automobile Data Security (Trial Implementation)," precise location trajectories, in-vehicle audio and video, and biometric information generated by vehicles are considered sensitive personal information and must be collected and used in accordance with the "minimum necessity" principle. However, the traditional full-reporting model cannot guarantee "minimum necessity" at the technical level: raw trajectory data is uploaded directly, even if the application only needs the start and end points; camera video streams are uploaded to the cloud for processing, even if local computing power is sufficient; and there is a lack of fine-grained access control, allowing cloud applications to read all uploaded data. This exposes automakers to compliance risks. Summary of the Invention

[0023] To address these issues, this application provides a federated vehicle AI management system and method based on a trusted data space, thereby resolving the problems of low data transmission efficiency, high energy consumption and cost, high latency and poor real-time performance, as well as privacy and compliance risks in existing technologies.

[0024] To achieve the above objectives, this application provides the following technical solution:

[0025] Firstly, a federated vehicle AI management system based on a trusted data space includes a trusted data space infrastructure layer, a cloud AI manager, and a vehicle-side AI manager.

[0026] The trusted data space infrastructure layer includes an identity authentication service module, a policy execution engine, a data routing controller, and a metadata broker module.

[0027] The identity authentication service module is used to assign unique digital identities to the vehicle-side AI manager, the cloud-based AI manager, and external service providers based on distributed identity identification technology, and to perform identity authentication using digital certificates;

[0028] The policy execution engine is used to build a policy management architecture for vehicle-cloud collaboration using a policy definition language and a rule engine: the main policy copy is stored on the vehicle and backed up in the cloud trusted data space; the policy execution point intercepts all data access requests and the policy decision point performs authorization evaluation; and finally, fine-grained attribute access control is achieved by issuing JWT tokens.

[0029] The data routing controller is used to implement the data connector of the international data space standard protocol and provides support for multiple transmission protocols.

[0030] The metadata broker module is used to provide a centralized or federated service catalog, and uses the International Data Spatial Information Model to semantically describe resources, supporting structured query language queries and expressive state transition application programming interfaces.

[0031] The cloud-based AI manager includes a multi-agent collaboration engine, a cloud-based digital twin, and a model context protocol interface module.

[0032] The multi-agent collaboration engine is used to configure multiple functionally dedicated agents, each responsible for a specific vehicle management task. The agents collaborate using an asynchronous message passing mechanism and listen for changes in specific state attributes in the cloud-based digital twin through a publish-subscribe pattern.

[0033] The cloud-based digital twin is used to store a virtual mapping of the vehicle's physical state; the virtual mapping is a dynamic projection subset of the complete state of the vehicle, and the projection dimension is adaptively adjusted according to the currently activated intelligent agent task.

[0034] The model context protocol interface module is used to provide standardized external service integration interfaces and encapsulate general logic;

[0035] The vehicle-side AI manager includes a real-time control execution module, a vehicle-side digital twin, and a data sovereignty gateway.

[0036] The real-time control execution module is used to execute vehicle behavior decisions and control commands, receive the target state issued by the cloud AI manager, and convert it into controller area network or Ethernet commands that can be executed by the vehicle's underlying controller.

[0037] The vehicle-side digital twin is used to collect status data of each electronic control unit in real time through the vehicle bus and to maintain the high-fidelity digital twin of the vehicle.

[0038] The data sovereignty gateway is used to execute the data sharing policy preset on the vehicle, intercept all data requests from the cloud AI manager, perform policy matching based on the data request attributes, and is responsible for data desensitization and aggregation processing.

[0039] Optionally, the policy execution point in the policy execution engine is deployed at a key node in the data flow path. When the policy decision point performs authorization evaluation, it generates a decision result of permission, denial, or inapplicability. If the decision result is permission, a JWT access token containing the authorization scope and validity period is generated.

[0040] Optionally, the data routing controller provides transmission protocols including Hypertext Transfer Security Protocol, Message Queuing Telemetry Transport Protocol, and Advanced Message Queuing Protocol, and the transmission protocols employ end-to-end encryption mechanisms when transmitting data.

[0041] Optionally, each agent configured in the multi-agent collaborative engine runs as an independent service process in a containerized environment. Each agent includes a perception module, a decision-making module, an execution module, and a learning module.

[0042] The sensing module is used to subscribe to specific state attribute change events of the cloud-based digital twin;

[0043] The decision-making module is used to generate action plans based on the current state and historical experience;

[0044] The execution module is used to convert the decision results into digital twin state updates or external service calls;

[0045] The learning module is used to optimize decision-making strategies using reinforcement learning or supervised learning algorithms.

[0046] Optionally, the cloud-based digital twin includes: a set of state attributes, historical time-series data of state, a state prediction model, and state constraint rules; the state attributes in the set of state attributes are organized in a three-layer hierarchical manner, and each state attribute includes: current value, timestamp, data quality index, and freshness tag.

[0047] Optionally, the model context protocol interface module includes: a service registry, a protocol adapter, a request router, and a response converter.

[0048] The service registry is used to store metadata of registered external services, including: service name, service type, service endpoint URL, authentication method, request format, response format, rate limit, and service level agreement.

[0049] The protocol adapter is used to support multiple third-party service protocols and convert the unified format requests issued by the intelligent agent into the native protocol format of the target service;

[0050] The request router is used to select the optimal service provider instance based on the service type and load conditions, and supports load balancing strategies and failure retry mechanisms.

[0051] The response converter is used to uniformly convert heterogeneous response formats from third-party services into Model Context Protocol (MCP) standard responses.

[0052] Optionally, the real-time control execution module adopts a priority scheduling mechanism, where higher priority instructions can preempt lower priority instructions.

[0053] Optionally, the vehicle-side digital twin includes state vectors with 100 to 500 dimensions, including powertrain, chassis and body, positioning and motion, environmental perception, cabin state, and communication network subsystems.

[0054] Optionally, it also includes a federated learning module for collaboratively training AI models while protecting user privacy.

[0055] Secondly, a federated vehicle AI management method based on a trusted data space, the method being applied to the federated vehicle AI management system based on a trusted data space, comprising:

[0056] Step 1: Task Triggering Stage: The cloud-based AI manager triggers the corresponding task based on the user's pre-defined scenario and sends it to the corresponding intelligent agent;

[0057] Step 2: Task Requirement Analysis Phase: The agent analyzes the input information required for the task and checks the cloud digital twin to determine the availability of each required information item: if the information item exists and its timeliness meets the requirements, it is used directly; if the information item does not exist or has expired, it is marked as pending request; if the information item can be obtained through external services, it is marked as a model context protocol interface module call.

[0058] Step 3: On-demand data request generation stage: For information items marked as pending requests, the agent calls the data request generator to fill in all fields of the request message and generate a complete structured format request message. The request message is sent to the data routing controller of the trusted data space through the transport layer security protocol encrypted channel.

[0059] Step 4: Policy Verification and Data Authorization Phase: The data routing controller forwards the request to the policy execution point of the policy execution engine. The policy execution point extracts the request attributes to construct an Extensible Access Control Markup Language request context. The policy decision point evaluates the policy and returns the decision result. If the decision result allows, a JWT token is generated and routed to the vehicle-side AI manager along with the request message through an encrypted channel.

[0060] Step 5: Vehicle-side data extraction and response stage: The vehicle-side data sovereignty gateway receives the request message and verifies the signature validity, expiration time, and whether the audience of the JWT token is the vehicle itself; if the verification is successful, the data sovereignty gateway generates a database query based on the allowed data list, executes the query to obtain the latest status record, obtains the response message, and sends the response message back to the cloud AI manager through an encrypted channel;

[0061] Step 6: Cloud Decision and Planning Stage: After receiving the response message, the cloud AI manager verifies the checksum and checks the matching of the request identifier, and calls the cloud digital twin update interface to perform differential update. The agent executes the decision algorithm based on the updated cloud digital twin, and calls the external service system through the model context protocol interface module to obtain environmental information or execute service reservations. It generates a task execution plan by combining internal status and external information.

[0062] Step 7: Target State Synchronization and Execution Phase: The intelligent agent transforms the execution plan into the target state of the cloud-based digital twin. Changes in the digital twin trigger state synchronization events, which are then pushed to the vehicle-side AI manager via a publish-subscribe mechanism. The vehicle-side AI manager subscribes to target state update type events.

[0063] Step 8: Vehicle-side Execution and Feedback Phase: The vehicle-side real-time control execution module receives events, parses the planned path, extracts the navigation path point sequence, and pushes a notification to the driver before the expected execution time. After the driver confirms, the real-time control execution module sends the path points to the in-vehicle navigation system and starts navigation guidance. During the journey, it continuously monitors key states. If the deviation from the planned route exceeds a threshold, or if real-time traffic conditions show congestion ahead or the battery level is below a safe threshold, the corresponding processing procedure is triggered. When a key milestone is reached, an execution feedback message is generated. The feedback message is transmitted back to the cloud AI manager through the data space. The cloud digital twin updates the corresponding data, the intelligent agent receives the completion notification, updates the task status, and records the execution effect data for strategy learning.

[0064] Compared with the prior art, this application has at least the following beneficial effects:

[0065] Based on further analysis and research into existing technical problems, this application provides a federated vehicle AI management system based on a trusted data space. This system includes a trusted data space infrastructure layer, a cloud-based AI manager, and a vehicle-side AI manager. The trusted data space infrastructure layer comprises an identity authentication service module, a policy execution engine, a data routing controller, and a metadata broker module. The cloud-based AI manager includes a multi-agent collaboration engine, a cloud-based digital twin, and a model context protocol interface module. The vehicle-side AI manager includes a real-time control execution module, a vehicle-side digital twin, and a data sovereignty gateway. This system reduces the amount of vehicle-to-cloud data transmission, thereby improving data transmission efficiency; it implements the "minimum necessity" principle for data access, ensuring user data sovereignty and privacy; it provides standardized service integration interfaces, enabling new service providers to complete integration within weeks, reducing energy consumption and costs; and it supports the integrated implementation of various vehicle management scenarios, reducing latency and providing good real-time performance. Attached Figure Description

[0066] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0067] Figure 1 A schematic diagram of a federated vehicle AI management system architecture based on a trusted data space, provided in Embodiment 1 of this application;

[0068] Figure 2 This is a schematic diagram of the network topology of multiple participants in the trusted data space provided in Embodiment 1 of this application;

[0069] Figure 3 This is a schematic diagram of the cloud-based AI manager and vehicle-side AI manager architecture provided in Embodiment 1 of this application;

[0070] Figure 4 This is a schematic diagram of the state space projection relationship between the cloud and vehicle-side digital twins provided in Embodiment 1 of this application;

[0071] Figure 5 This is a schematic diagram of the integrated architecture of the model context protocol interface module provided in Embodiment 1 of this application;

[0072] Figure 6 This is a schematic diagram of multi-agent collaborative work provided in Embodiment 1 of this application;

[0073] Figure 7This is a schematic diagram of the communication efficiency comparison experiment data provided in Embodiment 1 of this application;

[0074] Figure 8 This is a flowchart of a federated vehicle AI management method based on a trusted data space, provided in Embodiment 2 of this application.

[0075] Figure 9 A detailed sequence diagram of data request and policy verification provided for Embodiment 2 of this application;

[0076] Figure 10 This is a data flow diagram of the entire lifecycle of a vehicle's journey, provided in Embodiment 2 of this application. Detailed Implementation

[0077] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0078] In the description of this application: unless otherwise stated, "a plurality of" means two or more. The terms "first," "second," "third," etc., in this application are intended to distinguish the objects referred to and do not have any special meaning in terms of technical connotation (e.g., they should not be construed as an emphasis on importance or order). Expressions such as "including," "comprising," and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).

[0079] The terms used in this application, such as "upper," "lower," "left," "right," and "middle," are generally used to indicate the general relative positional relationship for the purpose of intuitive understanding by referring to the accompanying drawings, and are not absolute limitations on the positional relationship in the actual product.

[0080] Example 1

[0081] Please see Figure 1 This embodiment provides a federated vehicle AI management system based on a trusted data space, including an external service ecosystem layer, a trusted data space infrastructure layer, a cloud AI manager, a vehicle AI manager, and a vehicle system layer. The trusted data space infrastructure layer is used to provide distributed data sharing and access control capabilities. The cloud AI manager and the vehicle AI manager form a federated AI manager that is logically bound to a single vehicle. The cloud AI manager is deployed on a cloud server, and the vehicle AI manager is deployed on the vehicle's onboard computing platform. The two communicate through the data space infrastructure layer.

[0082] The trusted data space infrastructure layer includes an identity authentication service module, a policy execution engine, a data routing controller, and a metadata broker module.

[0083] The identity authentication service module is used to assign unique digital identities to the vehicle-side AI manager, cloud-based AI manager, and external service providers based on distributed identity identification technology, and uses X.509 digital certificates for identity authentication.

[0084] Specifically, the identity authentication service module uses W3C Distributed Identity (DID) technology to assign decentralized identifiers to the vehicle-side AI manager, cloud-based AI manager, and external service providers, and issues X.509 v3 digital certificates, supporting TLS 1.3 two-way authentication.

[0085] The policy execution engine is used to build a vehicle-cloud collaborative policy management architecture using a policy definition language and rule engine based on the Open Digital Rights Language (ODRL). The master policy copy is stored on the vehicle and backed up in a trusted data space in the cloud. Policy execution points intercept all data access requests, and policy decision points perform authorization evaluation. Finally, fine-grained attribute access control is achieved by issuing JWT tokens. In other words, the policy execution engine includes a policy repository, policy execution points, and policy decision points. The vehicle stores the master policy copy, the trusted data space maintains backup copies, data usage policies are defined using the ODRL 2.2 format, attribute access control is implemented based on XACML 3.0, and JWT access tokens are generated.

[0086] Specifically, the Policy Enforcement Point (PEP) in the policy enforcement engine (a component responsible for intercepting requests and enforcing decisions) is deployed at key nodes in the data flow path. The Policy Decision Point (PDP), a component in the policy enforcement engine responsible for evaluating requests and generating decisions, generates a permission, denial, or inapplicable decision during authorization evaluation. If the decision is permission, a JWT access token containing the authorization scope and validity period is generated. In other words, the policy enforcement engine uses a policy definition language based on the Open Digital Rights Language (ODL). The vehicle-side stores a set of data sharing policies. The policy enforcement point intercepts all data access requests, and the policy decision point performs policy matching based on a rule engine using the Extensible Access Control Markup Language (XACML) rule engine (a standard policy evaluation language for implementing fine-grained attribute access control).

[0087] More specifically, the policy repository of the policy execution engine adopts a distributed storage architecture, with the main policy copy stored locally on the vehicle and a backup policy copy maintained in the trusted data space.

[0088] The policy definition adopts the Open Digital Rights Language (ODRL) version 2.2 format, and each policy contains three core tags:

[0089] Permission tag: Defines the allowed operation types (read, write, update, delete, transfer), operation objects (specific data categories such as location data, driving behavior data), and authorized entities (cloud AI manager, third-party service providers, vehicle owners).

[0090] Duty: Defines the obligations that data users must fulfill, such as encrypting data transmission, deleting the original data after use, using it only for a specific purpose (such as route planning), and not reselling or sharing it with third parties.

[0091] Constraint labels: Define the restrictions on data usage, such as time constraints (data is only accessible during a specific time period), geographical constraints (data is only available in a specific geographical area), and usage constraints (data is only used for a specific application scenario).

[0092] The policy execution point is deployed at key nodes in the data flow path (vehicle gateway, cloud API gateway, data routing controller), intercepts all data access requests and extracts request attributes (requester identity, requested data type, request purpose, request time, request location) to construct a policy evaluation request in XACML 3.0 format.

[0093] The policy decision point loads relevant policy rules and performs an attribute-based access control (ABAC) model evaluation, returning a decision result of Permit, Deny, or Not Applicable. If the decision is Permit, a JSON Web Token (JWT) access token is generated, containing the authorization scope (a list of accessible data fields) and the expiration time (token expiration time).

[0094] The data routing controller is used to implement data connectors for international data space standard protocols and provides support for multiple transport protocols.

[0095] Specifically, the data routing controller provides multiple transport protocols, including Hypertext Transfer Protocol Secure (HTTP), Message Queuing Telemetry Transport Protocol (MQTT), and Advanced Message Queuing Protocol (ALQP). These protocols employ end-to-end encryption during data transmission, using Transport Layer Security (TLS) version 1.3 and Application Layer Advanced Encryption Standard (ALS) 256-bit encryption. The data routing controller implements the IDS-RAM 4.0 connector function, supporting HTTPS, MQTT over TLS, and AMQP over TLS protocols. The transport layer uses TLS 1.3, the application layer uses AES-256-GCM encryption, and key management uses HKDF-derived session keys. The metadata and service discovery module uses the IDS information model for semantic description, supports SPARQL queries and RESTful APIs, and has a service discovery response time of no more than 500 milliseconds.

[0096] More specifically, the data routing controller implements connector functionality conforming to the International Data Space Reference Architecture Model (IDS-RAM) version 4.0. The data routing controller provides multi-protocol support: HTTPS for synchronous request-response communication, MQTT over TLS for asynchronous messaging in a publish-subscribe pattern, and AMQP over TLS for reliable message queue communication.

[0097] Data transmission employs an end-to-end encryption mechanism: the transport layer uses the TLS 1.3 protocol, supports forward secrecy, and adopts the ECDHE key exchange algorithm; the application layer uses AES-256-GCM mode to encrypt sensitive data, providing Authenticated Encryption to ensure data confidentiality and integrity.

[0098] Key management uses the HMAC-based Key Derivation Function (HKDF) to derive session keys from the master key. The master key is established through a secure key negotiation protocol (such as a TLS handshake), and the session key is rotated periodically (by default every 24 hours or after every 100MB of data transfer) to reduce the risk of key leakage.

[0099] The data routing controller maintains a routing table, recording the network address (IP address and port) and reachability status (online, offline, unstable) of each participating node (vehicle-side AI manager, cloud-based AI manager, and external service provider). The routing table is dynamically updated via a heartbeat mechanism (sending a heartbeat packet every 30 seconds).

[0100] The data routing controller implements request routing, load balancing, and failure retry functions: request routing selects the optimal path by looking up the routing table based on the target node identifier; load balancing distributes requests among multiple cloud server instances using a weighted round-robin algorithm; failure retry automatically retryes requests when they fail, and the retry strategy uses an exponential backoff algorithm (the first retry is delayed by 1 second, the second by 2 seconds, the third by 4 seconds, and a maximum of 5 retries).

[0101] The metadata broker module provides a centralized or federated service catalog and uses the International Data Spatial Information Model to semantically describe resources, supporting Structured Query Language queries and a Representational State Transition application programming interface.

[0102] Please see Figure 2 In this embodiment, when the trusted data space infrastructure is deployed:

[0103] The International Data Space Connector (i.e., the data routing controller) is deployed on the vehicle end and integrated into the vehicle AI Manager as a data exit gateway; it is deployed in the cloud at the boundary of the cloud AI Manager as a data entry gateway; and each third-party service provider deploys its own International Data Space Connector.

[0104] The metadata broker module is deployed as a federated service catalog operated by an automotive industry alliance or a neutral third-party organization; it is configured as a five-node distributed deployment to support geographical disaster recovery; and it uses a graph database to store relational graphs.

[0105] Certificate authorities adopt industry public key infrastructure systems, such as vehicle-to-everything communication public key infrastructure; the root certificate authority is operated by an industry association, and car manufacturers and service providers each operate their own sub-certificate authorities; the certificate validity period is three years for vehicle certificates, one year for intelligent agent certificates, and two years for service provider certificates.

[0106] Please see Figure 3 The cloud-based AI manager includes a multi-agent collaboration engine, a cloud-based digital twin, and a Model Context Protocol (MCP) interface module.

[0107] The multi-agent collaborative engine is used to configure multiple functionally dedicated agents. Each agent is responsible for specific vehicle management tasks, including at least commuting planning agents, parking arrangement agents, health diagnosis agents, charging scheduling agents, and maintenance appointment agents. The agents collaborate using an asynchronous message passing mechanism and listen for changes in specific state attributes in the cloud-based digital twin through a publish-subscribe pattern.

[0108] Specifically, each agent configured in the multi-agent collaborative engine runs as an independent service process in a containerized environment. Each agent includes a perception module, a decision-making module, an execution module, and a learning module.

[0109] The perception module is used to subscribe to specific state attribute change events of the digital twin in the cloud.

[0110] The decision-making module is used to generate action plans based on the current state and historical experience.

[0111] The execution module is used to transform decision results into digital twin state updates or external service calls.

[0112] The learning module is used to optimize decision-making strategies using reinforcement learning or supervised learning algorithms.

[0113] More specifically, the types of intelligent agents include at least: commuting planning agents, parking scheduling agents, health diagnosis agents, charging dispatch agents, maintenance appointment agents, insurance advisor agents, and energy consumption optimization agents. Each intelligent agent has a perception module, a decision-making module, an execution module, and a learning module.

[0114] Agents collaborate via an asynchronous message passing mechanism. The message queue adopts a publish-subscribe pattern, and the message format is JSON or Protocol Buffers. Message types include: status notification (an agent broadcasts its current status or completed tasks), task request (an agent requests assistance from other agents to complete a task), collaboration invitation (an agent invites other agents to participate in joint decision-making), and execution feedback (an agent reports the results of task execution).

[0115] The collaborative mechanism supports task decomposition, task allocation, and conflict resolution. Task decomposition breaks down complex tasks into subtasks and assigns them to different agents; task allocation uses algorithms based on capability matching and load balancing; conflict resolution employs priority mechanisms or negotiation mechanisms. For example, when the charging scheduling agent and the commuting planning agent have different suggestions on departure time, a compromise solution is reached based on the user-defined priority or through negotiation.

[0116] A cloud-based digital twin is used to store a virtual mapping of the vehicle's physical state. The virtual mapping is a dynamic projection subset of the complete vehicle state (i.e., a subset of the vehicle state stored in the cloud-based digital twin, which dynamically adjusts the included state dimensions according to the currently activated task). The projection dimension is adaptively adjusted according to the currently activated agent task, satisfying the following relationship: the cloud-based state vector is a subset of the vehicle-based state vector, and the dimension of the cloud-based state vector is no more than 30% of the dimension of the vehicle-based state vector.

[0117] Specifically, the cloud-based digital twin stores a dynamic projection subset S_cloud of the vehicle's state. Given a vehicle system S_vehicle and |S_cloud| ≤ 0.3 × |S_vehicle|, a hierarchical organization (vehicle system - subsystem - parameters) is adopted. The latest state is stored in Redis, and historical data is stored in InfluxDB. The vehicle-side digital twin synchronization module collects 100 to 500-dimensional state vectors and adaptively selects a synchronization strategy based on data sensitivity, change frequency, and task relevance, such as... Figure 4 As shown.

[0118] More specifically, the cloud-based digital twin includes: a set of state attributes, historical time-series data of states, a state prediction model, and state constraint rules. The state attributes are organized in a three-tiered hierarchy: the first tier is the vehicle system category (powertrain system, chassis system, body system, infotainment system); the second tier is the subsystem category (engine subsystem, battery subsystem, motor subsystem under the powertrain system); and the third tier is the specific parameters (state of charge, voltage, current, and temperature under the battery subsystem). Each state attribute includes: current value, timestamp, data quality metrics (accuracy, completeness, consistency score), and freshness marker (the difference between the last update time and the current time).

[0119] The projection dimension of the cloud-based digital twin adaptively adjusts according to the currently active agent's task. The projection selection algorithm is based on a task-data dependency graph, which defines the mapping relationship between each task type and the required data attributes. When agent A_i is activated, the cloud-based digital twin loads a subset of data attributes associated with A_i; when agent A_i completes its task, the relevant data attributes can be unloaded to release storage resources.

[0120] The storage adopts a hybrid architecture: the latest state snapshot is stored in the in-memory database Redis, which supports microsecond-level read latency; historical time-series data is stored in the time-series database InfluxDB or TimescaleDB, which supports write throughput of millions of state attributes per second and millisecond-level query response.

[0121] The Model Context Protocol Interface module provides a standardized interface for integrating external services. Through this interface, agents can call third-party services such as traffic information services, parking management systems, charging pile networks, and maintenance platforms. It also encapsulates common logic such as service discovery, authentication, data exchange, and error handling.

[0122] Please see Figure 5 Specifically, the Model Context Protocol Interface module includes: a service registry, a protocol adapter, a request router, and a response converter.

[0123] The service registry stores metadata for registered external services, including: service name, service type, service endpoint URL, authentication method (API key, OAuth 2.0, JWT), request format (JSON, XML), response format, rate limit (maximum number of requests per minute), and service level agreement (availability guarantee, response time guarantee).

[0124] Protocol adapters are used to support various third-party service protocols: RESTful API, SOAP, gRPC, and GraphQL. The protocol adapter converts uniformly formatted requests (including service type, operation name, and parameter list) issued by the agent into the native protocol format of the target service.

[0125] The request router is used to select the optimal service provider instance based on service type and load conditions, supporting load balancing strategies (round-robin, least connections, weighted round-robin) and failure retry mechanisms.

[0126] The response converter is used to uniformly convert heterogeneous response formats from third-party services into standard responses of the Model Context Protocol (JSON format, including status codes, data payloads, and error messages).

[0127] The Model Context Protocol Interface module supports the following service types: traffic information services (real-time traffic conditions, route planning), parking management system (parking space query, reservation, payment), charging pile network (charging station query, status monitoring, scheduled charging), maintenance platform (service provider query, reservation, work order management), insurance services (claims, premium calculation), weather services, and map services.

[0128] In this embodiment, the cloud AI manager may further include: a decision execution and feedback module, which is used to convert the decision result of the intelligent agent into the target state update of the cloud digital twin, trigger synchronous execution on the vehicle side, and receive execution feedback from the vehicle side.

[0129] Specifically, the target state represents the desired state or action of the vehicle. Target state attributes include: planned route (a list of waypoints, each waypoint containing latitude and longitude, estimated arrival time, and road segment attributes such as speed limit and road conditions), target parking lot (location coordinates, parking lot name, and reservation information including parking space number and reservation time period), recommended departure time (the optimal departure time considering traffic conditions and user schedule), charging plan (charging station location, estimated charging duration, and charging cost), and maintenance appointment (service provider name, address, appointment time, and maintenance item list).

[0130] Target status updates trigger status synchronization events. These events include: event type (navigation update, charging plan update, maintenance appointment, etc.), priority (urgent, high, medium, low), payload (specific data of the target status), and expected execution time. Events are pushed to subscribers on the vehicle via a message queue (MQTT or AMQP).

[0131] The decision execution and feedback module also receives execution feedback from the vehicle. Feedback types include: execution start confirmation, progress update (completion percentage, current location), milestone arrival (reaching waypoint, reaching charging station), execution completion, and execution failure (failure reason, error code). Feedback data is used to update the actual execution status of the cloud-based digital twin and serves as training samples for the agent learning module to improve future decision-making quality.

[0132] In this embodiment, the cloud-based AI manager is deployed in a public or private cloud environment and adopts a microservice architecture, including a containerized intelligent agent service, a digital twin storage cluster, a message queue middleware, a model context protocol gateway service, and a policy decision point service.

[0133] Containerized Agent Service: Each functional agent (commuting planning, parking arrangement, health diagnosis, charging scheduling, maintenance appointment, etc.) is deployed as an independent container, running in a container orchestration platform cluster, supporting automatic scaling. Typical configuration: Each agent container is allocated a dual-core CPU, four gigabytes of memory, and ten gigabytes of solid-state drive storage.

[0134] Digital twin storage cluster: It uses a distributed time-series database to store historical time-series data of the digital twin's state and an in-memory database cluster to store the latest snapshot.

[0135] Message Queue Middleware: Implements asynchronous message passing and event publish-subscribe between agents using a distributed stream processing platform. Model Context Protocol Gateway Service: Deploys an application programming interface (API) gateway to implement routing, authentication, rate limiting, and monitoring of the Model Context Protocol. Configuration: Two-node primary / backup configuration, each node with an eight-core CPU and 16 gigabytes of memory.

[0136] Policy Decision Point Service: Deploys an extensible access control markup language policy engine, loads Open Digital Rights Language policies, and executes decisions. (Continue reading...) Figure 2 The vehicle-side AI manager includes a real-time control execution module, a vehicle-side digital twin, and a data sovereignty gateway.

[0137] The real-time control execution module is used to execute the vehicle's millisecond- to second-level behavioral decisions and control commands. It receives the target state issued by the cloud AI manager and converts it into controller area network or Ethernet commands that can be executed by the vehicle's underlying controller.

[0138] Specifically, the real-time control execution module receives the target status from the cloud, parses the planning information and control instructions in the target status, and converts them into CAN bus messages or vehicle Ethernet data packets that can be executed by the vehicle's underlying controller.

[0139] Control commands include: navigation route setting (sending a sequence of waypoints to the navigation system to trigger route planning and navigation guidance), vehicle unlocking / locking (sending control commands to the body control module (BCM)), air conditioning preset (starting the air conditioning system to the target temperature before the user's scheduled departure time), and charging start / stop control (starting or stopping the charging process and setting the target state of charge (SOC)).

[0140] The real-time control execution module employs a priority scheduling mechanism, where high-priority commands (such as emergency braking and collision warning response) can preempt low-priority commands (such as air conditioning adjustment and music playback). Command execution includes precondition checks, such as verifying user identity (via digital key or biometrics) and ensuring the vehicle is parked (gear in P and handbrake engaged) before unlocking.

[0141] The real-time control execution module monitors the command execution process, sampling key states (vehicle speed, gear, battery SOC, motor speed) every 100 milliseconds to 1 second to detect execution deviations. If the actual execution result deviates from the target state by more than a preset threshold (e.g., the actual path deviates from the planned path by more than 50 meters, or the actual charging SOC deviates from the target SOC by more than 5%), an abnormal event is generated and reported to the cloud via the vehicle network, triggering replanning or manual intervention.

[0142] The vehicle-side digital twin is used to collect status data of each electronic control unit in real time through the vehicle bus and to maintain a high-fidelity digital twin of the vehicle.

[0143] Specifically, the vehicle-side digital twin contains state vectors with 100 to 500 dimensions, the exact number depending on the vehicle configuration (approximately 100 dimensions for entry-level vehicles, and up to 500 dimensions for high-end intelligent vehicles). State data is collected via CAN bus, LIN bus, FlexRay bus, or in-vehicle Ethernet, with collection frequencies varying depending on the data type: safety-critical data (brake pressure, steering angle) is collected at 100Hz, powertrain data (engine speed, battery voltage) at 10Hz, and vehicle comfort data (window status, seat position) at 1Hz.

[0144] The vehicle-side digital twin synchronization module adaptively selects a synchronization strategy based on data sensitivity, change frequency, and task relevance.

[0145] High-priority data (security critical, high real-time requirements): uploaded to the cloud in real time, using MQTT QoS 2 to ensure message delivery, with a transmission delay of no more than 100 milliseconds.

[0146] Medium-priority data (diagnostic data, performance data): Batch compressed upload, packaged every minute or every 10 minutes, using gzip or LZ4 compression algorithms, with a compression rate of 50-70%.

[0147] Low-priority data (historical statistics, user preferences): Uploaded on demand, only when requested by the cloud-based intelligent agent or when the vehicle is charging / connected to WiFi.

[0148] The synchronization strategy supports dynamic adjustment: when a new intelligent agent task is activated in the cloud, the vehicle-side synchronization module receives the task-data dependency list and automatically increases the synchronization priority of relevant data.

[0149] The data sovereignty gateway is used to execute the vehicle's preset data sharing policy, intercept all data requests from the cloud AI manager, and perform policy matching based on attributes such as purpose identifier, parameter specifications, and requester identity in the data request. Data is only extracted from the vehicle's digital twin when the policy allows it. The data sovereignty gateway is also responsible for data anonymization and aggregation processing to ensure that the transmitted data complies with the minimum necessary principle.

[0150] In this embodiment, the vehicle-side AI manager is deployed on the in-vehicle computing platform and is divided into three deployment modes according to the vehicle's level of intelligence: Mode A, Mode B, and Mode C.

[0151] Model A - Basic Connected Vehicle (On-board Terminal Box): The hardware consists of a quad-core 1.5 GHz RISC processor, 2 gigabytes of random access memory, and 16 gigabytes of embedded multimedia card storage; the operating system is an embedded Linux system; the deployment components are a lightweight vehicle AI manager, which only includes a data sovereignty gateway, a digital twin synchronization module, and a real-time control module, without deploying a vehicle intelligent agent; applicable models are traditional fuel vehicles and entry-level electric vehicles.

[0152] Mode B - Intelligent Connected Vehicles (Intelligent Cockpit Domain Controller): The hardware is an automotive-grade system-on-a-chip, 8 gigabytes of random access memory, and 128 gigabytes of general-purpose flash memory; the operating system is an in-vehicle Android system or an automotive-grade Linux system; the deployment components are a complete vehicle-side AI manager plus a lightweight intelligent agent (parking assistance, intelligent voice); applicable models are mid-to-high-end intelligent electric vehicles and intelligent cockpit vehicles.

[0153] Mode C - Autonomous Vehicle (Central Computing Platform): The hardware consists of a dedicated autonomous driving chip, 64 gigabytes of random access memory, and 1 terabyte of solid-state drive; the operating system is a real-time Linux system or a real-time operating system; the deployment components are a complete vehicle-side AI manager plus an advanced vehicle-side intelligent agent (path planning, decision control); applicable vehicle types are Level 3 and above autonomous vehicles.

[0154] This embodiment provides a federated vehicle AI management system based on a trusted data space, which also includes a federated learning module for collaboratively training AI models while protecting user privacy.

[0155] Specifically, the federated learning module supports two deployment modes: cross-vehicle federated learning (multiple vehicles collaboratively train and share models) and vehicle-cloud federated learning (vehicle and cloud collaboratively train models).

[0156] Cross-vehicle federated learning process: The cloud server initializes the global model and distributes it to participating vehicles; each vehicle trains the model using local data for several epochs, calculating model parameter updates (gradients or weight differences); vehicles upload their local model updates to the cloud server, with data transmission employing differential privacy technology (adding calibration noise to the gradient) or a secure aggregation protocol (encrypting gradients to ensure the server cannot see the gradients of individual vehicles); the cloud server aggregates the model updates from all vehicles (using FedAvg, FedProx, or FedNova algorithms) to generate a new global model; the cloud distributes the updated global model to participating vehicles to begin the next round of training.

[0157] Vehicle-to-Cloud Federated Learning Process: For a single vehicle, the vehicle-side AI manager and the cloud-side AI manager collaboratively train a personalized model; the vehicle-side is responsible for training the low-level feature extraction part of the model (using vehicle sensor data), while the cloud-side is responsible for training the high-level decision-making part of the model (using historical behavior data and external environment data); the vehicle-side and the cloud-side exchange intermediate layer feature representations (instead of raw data) through an encrypted channel to achieve vertical federated learning.

[0158] The federated learning module supports applications including driving behavior prediction, energy consumption optimization, fault diagnosis, and route planning optimization. The federated learning cycle is configurable, with a typical configuration of performing a global model update once a week.

[0159] This embodiment provides a federated vehicle AI management system based on a trusted data space, which employs an on-demand data synchronization and coordination mechanism to achieve selective, bidirectional synchronization between the cloud and the vehicle's digital twin, including:

[0160] Data request generation process: The functional intelligent agent in the cloud AI manager analyzes the vehicle status information required to complete the task based on the currently executed task, checks the timeliness and completeness of the relevant status in the cloud digital twin, and if the existing data does not meet the decision requirements, it generates a structured data request message. This message includes: request identifier, requester identity and digital certificate, data purpose semantic tag, parameter specification description (including data type, time range, sampling rate, aggregation method, numerical precision), and usage constraints (including data retention period, allowed processing operations, and storage location requirements).

[0161] Policy verification and routing process: Data request messages are transmitted through the data routing controller of the trusted data space. The policy execution engine intercepts the request, extracts key attributes, and retrieves matching rules from the vehicle-side preset Open Digital Rights Language policy library. Policy matching adopts an attribute-based access control model. The matching dimensions include: requester identity category, data usage type, data sensitivity level, and spatiotemporal constraints. If all dimensions match, the policy decision point generates a temporary access token, which includes the authorization scope and validity period. If any dimension does not match, the request is rejected and a rejection reason code is returned.

[0162] Minimum Data Subset (MDS, which is the minimum necessary data set to meet the current task requirements, and whose size is significantly smaller than the full vehicle status data) extraction process: After receiving a data request carrying a valid access token, the vehicle-side data sovereignty gateway parses the parameter specification description, generates a query instruction for the vehicle-side digital twin storage, extracts the raw data that meets the requirements of type, time range, and sampling rate, preprocesses it according to the aggregation method, and quantizes it according to the numerical precision to form the minimum data subset, whose size is much smaller than the full status. In typical scenarios, the size of the minimum data subset is less than 1% of the size of the full status.

[0163] The cloud-based digital twin differential update process: After receiving a data subset, the cloud AI manager verifies the data integrity and updates the cloud-based digital twin using a state differential algorithm. It only modifies the state vector components corresponding to the data subset. For state indices included in the data subset, the received data is used directly for updating. For state indices not included in the data subset but with a prediction model, the update is performed based on the prediction model and the time interval since the last update. For state indices not included in the data subset and without a prediction model, the value from the previous moment remains unchanged.

[0164] Vehicle-side status synchronization execution process: After the cloud-based intelligent agent completes the decision, it writes the decision result as the target state of the cloud-based digital twin. Change events of the cloud-based digital twin are pushed to the vehicle-side AI manager through a subscription-publishing mechanism. The vehicle-side real-time control module parses the target state, converts it into a sequence of vehicle control commands, and sends them to the corresponding domain controllers through the vehicle bus. It monitors the execution process and feeds back the key milestone states to the cloud-based AI manager.

[0165] System operation monitoring and optimization mechanism: The monitoring and optimization mechanism is implemented through a communication efficiency quantification module, a decision quality assessment module, and a strategy learning and evolution module. The communication efficiency quantification module statistically analyzes the amount of vehicle-to-cloud data transmitted per unit time, recording the total size of data request messages and the total size of data response messages under on-demand synchronization mode, calculating the total transmission volume, and comparing it with the theoretical transmission volume assuming a traditional periodic reporting mode. The decision quality assessment module tracks the execution effect of the agent's decisions, recording indicators such as decision success rate and user satisfaction. When the success rate of a certain type of decision is found to be below a threshold, it analyzes whether this is due to insufficient information from the cloud-based digital twin, triggering an adjustment to the data request strategy. The strategy learning and evolution module optimizes the data request strategy based on historical data request records and vehicle state change patterns using reinforcement learning algorithms. The learning objective is to minimize data transmission volume while maximizing decision quality. Strategy parameters include request triggering conditions, data timeliness thresholds, and sampling rate selection.

[0166] The detailed mechanism of multi-agent collaboration in a federated vehicle AI management system based on a trusted data space provided in this embodiment is as follows:

[0167] This embodiment details how cloud-based multi-agent systems can collaborate through shared digital twins, such as... Figure 6 As shown.

[0168] The roles and responsibilities of intelligent agents:

[0169] The multiple intelligent agents in the cloud-based AI manager each perform their respective functions:

[0170] The commuting planning agent is responsible for route planning and time scheduling for daily commutes. It listens for commuting tasks in the task queue and navigation requests initiated by users. The required data includes the vehicle's current location, battery level or fuel level, destination address, and expected arrival time. The output includes recommended routes, recommended departure times, estimated arrival times, and energy consumption estimates. The coordination relationship is as follows: if insufficient range is detected, the charging scheduling agent is triggered; if the destination is reached, the parking arrangement agent is triggered.

[0171] The parking arrangement agent is responsible for searching and reserving parking spaces at the destination, listening for parking needs from the commuting planning agent and user-initiated parking requests. The required data includes destination location, estimated arrival time, estimated parking duration, vehicle size information, and whether a charging station is needed. The output includes a list of recommended parking lots, reservation confirmation information, estimated parking fees, and walking distance. The collaboration is as follows: if a parking lot provides a charging station, notify the charging dispatch agent; if the reservation fails, notify the commuting planning agent to find alternative destinations.

[0172] The charging scheduling agent is responsible for planning the charging time and location for electric vehicles, monitoring events where the battery level is below a threshold and warnings of insufficient range in commuting plans. The required data includes the current battery state of charge, remaining range, current location or planned route, charging preference (fast charging or slow charging), and electricity price information. The outputs include recommended charging station locations, recommended charging duration, estimated charging costs, and estimated range after charging. The collaborative relationship is with the commuting planning agent to insert charging station stops in the route and with the parking arrangement agent to prioritize parking lots with charging stations.

[0173] The health diagnostic agent is responsible for predictive health assessments of vehicle components, monitoring periodic diagnostic task triggers and abnormal condition detection events. The required data includes historical battery temperature, voltage, and current data, powertrain operating parameters, chassis component wear data, and cumulative mileage. The outputs include health score reports, abnormal alarms, maintenance recommendations, and remaining life predictions. The collaborative relationship is as follows: if maintenance is required, a maintenance appointment will be triggered; if a potential fault is detected, the agent will notify the owner and may restrict certain functions.

[0174] The maintenance appointment agent is responsible for scheduling maintenance services based on the diagnostic results, listening to maintenance suggestions issued by the health diagnostic agent and proactive maintenance requests from the vehicle owner. The required data includes diagnostic reports, vehicle model and configuration, vehicle owner location preferences, and historical maintenance records. The outputs include a list of recommended service providers, appointment time confirmation, estimated costs, and a list of required replacement parts. The collaborative relationship involves working with the commuting planning agent to arrange suitable arrival times to avoid affecting daily commutes.

[0175] Collaboration mechanism based on digital twins:

[0176] Each intelligent agent achieves loosely coupled collaboration by subscribing to state change events of the cloud-based digital twin:

[0177] The first step is state publication. After a smart agent completes a decision, it writes the result to a specific field of the digital twin in the cloud. For example, a commuting planning agent writes the planned route to the planned route field of the digital twin and the estimated arrival time to the estimated arrival time field. The digital twin triggers a state change event. The event includes the changed field name, the new value, the timestamp, and the triggering smart agent identifier.

[0178] The second step is event subscription. Other agents pre-subscribe to the state fields they are interested in. For example, the parking scheduling agent subscribes to change events for the planned route and estimated arrival time fields. When these fields are updated, the parking scheduling agent will be notified.

[0179] The third step is collaborative triggering. The agent that receives the event notification checks the event content to determine whether action needs to be taken. For example, after receiving the estimated arrival time update event, the parking arrangement agent checks whether the destination needs parking. If the destination is in a parking demand area (such as a commercial area or office area), the parking search process is automatically triggered. If the destination is in an area where parking is not required (such as a short stop at a highway service area), the event is ignored.

[0180] The fourth step is state synchronization. The triggered agent reads the complete context information required to make decisions from the digital twin. For example, the parking arrangement agent reads the coordinates of the destination of the planned route, the estimated arrival time, and the current battery charge status of the vehicle (to determine whether a charging station is needed). Based on this information, it calls the external parking service.

[0181] In the fifth step, the parking arrangement agent writes the result back to the digital twin after completing the parking space reservation, updates the target parking lot field, parking space number field, and parking fee field, and triggers the status change event again. The commuting planning agent, which has subscribed to these fields, can update the navigation destination to the parking lot entrance coordinates instead of the original destination coordinates after receiving the notification.

[0182] Real-world examples of agent collaboration:

[0183] Let's take a complex weekend outing scenario as an example to illustrate multi-agent collaboration:

[0184] In the initial scenario, the car owner plans to drive to a suburban scenic spot 120 kilometers from the city center on Saturday morning. He initiates a request through the voice assistant to "plan the route to a certain scenic spot". The system creates a suburban trip task and assigns it to the commuting planning agent.

[0185] The commuting planning agent workflow analyzes the task to extract destination coordinates, current time (8:00 AM), and defaults to arriving as soon as possible if no specific arrival time is required. Checking the cloud-based digital twin reveals that the current location is known, but the battery status data is outdated (last night's data). A request is made to the vehicle to update the battery status. A response indicating 75% battery status and 180km remaining range is received. The one-way distance of 120km and the round-trip distance of 240km are calculated, exceeding the current range of 180km, indicating a need for charging. External transportation services are invoked to obtain route planning, including three alternative routes. The distribution of charging stations along each route is evaluated, and route two is selected because it has a fast-charging station 20km from the attraction. A complete route including the charging plan is generated and written into the digital twin, including the planned route, charging stations along the way, estimated arrival time at the attraction, and a low range warning flag. A status change event is then published.

[0186] The charging dispatch agent responds. Having subscribed to the insufficient range warning flag field, the agent receives the event notification, reads the planned route and information on passing charging stations from the digital twin, checks that the passing charging station is a certain fast charging station with a power of 120 kW, calls the external charging service to query the real-time status of the charging station, including three out of five available charging piles, zero currently waiting vehicles, estimated waiting time of zero minutes, and peak electricity price of 1.2 yuan per kilowatt-hour. The agent calculates the charging demand: from the current 75% minus the round-trip consumption of approximately 60%, the remaining 15% needs to be replenished to 80% to ensure a safety margin, requiring approximately 30 kilowatt-hours. The estimated charging time is 30 kilowatt-hours divided by 120 kilowatts, approximately 15 minutes. The estimated charging cost is 30 kilowatt-hours multiplied by 1.2 yuan, equaling 36 yuan. A charging plan is generated and written into the digital twin, including the charging station identifier, suggested charging time, and estimated cost. A charging plan confirmation event is then published.

[0187] The parking arrangement agent responds. Having subscribed to the estimated arrival time at the attraction field, the agent receives an event notification, reads the destination coordinates from the digital twin (identifying the attraction), determines that the attraction is a popular tourist area requiring parking, and calls external parking services to query nearby parking lots. These include the official parking lot (200 meters from the attraction entrance, 500 capacity, 120 currently available, 20 yuan / day fee) and private parking lots (200 meters from the attraction entrance, 80 currently available, 15 yuan / day fee). Considering both distance and price, the official parking lot is recommended. The agent checks if reservations are necessary due to weekend crowding and suggests making reservations. The parking service's reservation interface is called, and a parking space is successfully reserved. This information is written to the digital twin, including the target parking lot, parking space reservation number, and parking fee. A parking arrangement completion event is then published.

[0188] The commuting planning agent updates the route, receives notifications when parking arrangements are completed, reads parking lot coordinates from the digital twin, updates the navigation destination from the attraction entrance to the parking lot entrance, recalculates the route and fine-tunes the navigation guidance for the last kilometer, updates the planned route field of the digital twin, and generates the final complete travel plan, including a suggested departure time of 8:10 am, approximately one hour for the first leg of the journey to the charging station, a 15-minute charging stop, approximately 20 minutes for the second leg of the journey to the attraction, an estimated arrival time of 9:45 am, parking information, and an estimated total cost of 36 yuan for charging plus 20 yuan for parking.

[0189] For plan push and execution, the cloud AI manager pushes the complete plan to the vehicle. The driver sees a visualized plan on the vehicle screen, including route map, charging station location, parking lot location, time nodes, and cost details. The driver clicks the confirm and start navigation button, and the vehicle starts navigation. When the vehicle arrives at the charging station, it reminds the driver to charge. When the vehicle arrives at the parking lot, it displays the reservation code. Throughout the trip, each intelligent agent continuously monitors the status. If there is a queue at the charging station, the charging dispatch agent automatically searches for alternative charging stations. If the parking lot is full, the parking arrangement agent automatically searches for alternative parking lots.

[0190] Learning and optimization of intelligent agents:

[0191] Each agent accumulates experience and optimizes its decisions over a long period of operation.

[0192] The commuting planning agent learns and records the driver's historical commuting patterns, including frequent destinations, preferred routes, and departure time habits. It also learns traffic congestion patterns, such as the high probability of congestion on certain road sections during Monday morning rush hour and the longer duration of Friday evening rush hour. The algorithm optimizes the departure time recommendation by adjusting the lead time based on historical on-time arrival rates. Personalized route selection adjusts the recommendation weights based on the driver's past route selection preferences (such as preference for highways or scenic routes).

[0193] The charging dispatch agent learns and records car owners' charging habits, including preferred charging stations, preferred state of charge ranges (e.g., habitually charging between 20% and 80%), and tolerance for charging time. It also learns the service quality of different charging stations, including actual charging rate, queuing time, and equipment failure rate. To optimize charging timing, it recommends considering electricity price fluctuations to take advantage of off-peak electricity prices to save costs and combining it with travel arrangements to charge during parking waiting periods rather than making a special trip to charge.

[0194] The parking arrangement agent learns and records car owners' parking preferences, including acceptable walking distance, price sensitivity, and preference for parking lot type (above ground or underground). It also learns the actual experience of different parking lots, including whether the parking space size is suitable for the car model, ease of entry and exit, and payment method friendliness. The recommendation algorithm is then optimized to provide recommendations that best match the car owner's habits by integrating multiple dimensions of factors.

[0195] The health diagnostic agent learns and accumulates historical health data of the vehicle to establish a personalized health baseline. It learns the impact of different usage patterns on component lifespan, such as the accelerated degradation of battery life caused by frequent fast charging. It optimizes the prediction model to improve the accuracy of remaining lifespan prediction. The proactive health suggestion actively reminds the owner to adjust usage habits based on early abnormal signals detected.

[0196] While technologies such as digital twins, multi-agent systems, and trusted data spaces have already been applied in their respective fields, combining them for vehicle-cloud collaborative management is not a simple matter of piling up technologies and faces the following technical obstacles:

[0197] 1. Paradigm Conflict in the Application of Digital Twins

[0198] Traditional digital twin theory emphasizes "high-fidelity synchronization," arguing that virtual entities should replicate all states of physical entities as accurately as possible. However, in vehicle-cloud collaborative scenarios, complete synchronization leads to the aforementioned data transmission and cost issues. A technical bias faced by those skilled in the art is that "reducing synchronization fidelity inevitably leads to a decline in decision-making quality." How to achieve high-quality decision-making even with a low-fidelity digital twin remains a challenge, lacking current technological guidance.

[0199] 2. Resource Constraints in Multi-Agent Systems

[0200] Traditional multi-agent systems assume that each agent operates in a resource-rich computing environment and can frequently exchange messages to achieve collaboration. However, in vehicle-cloud architectures, communication between vehicles and the cloud suffers from bandwidth limitations, uncertain latency, and intermittent connections. Designing an efficient multi-agent collaboration mechanism that enables agents to cooperate effectively even with limited vehicle-cloud data exchange remains an unsolved technical problem in this field.

[0201] 3. The challenges of dynamic adaptation to trusted data spaces

[0202] The existing international data space architecture primarily caters to data trading scenarios between enterprises, where data providers and consumers are relatively stable, and data sharing strategies are determined at the time of contract signing and rarely change during operation. However, in vehicle operation scenarios, data access needs are dynamically changing: commuting planning agents require real-time location data during rush hour but not at night; health diagnostic agents only require detailed battery data under specific fault scenarios. The existing international data space architecture lacks technical solutions to support such dynamic strategies.

[0203] Therefore, the federated vehicle AI management system based on trusted data space provided in this embodiment has the following advantages:

[0204] 1. Data transmission efficiency has been greatly improved.

[0205] Through actual deployment testing (100 test vehicles, over a period of 3 months): the average daily data transmission volume per vehicle decreased from 3.65 MB in the traditional periodic reporting mode to 0.18 MB in the on-demand synchronization mode of this embodiment, a reduction of 95.1%; the average monthly traffic cost decreased from 109.5 RMB per vehicle in the traditional mode to 5.4 RMB in the mode of this embodiment, a reduction of 95.1%. Figure 7 As shown ( Figure 7 In the diagram, the X-axis represents time (days), and the Y-axis represents the cumulative data transmission volume (megabytes). Two curves are plotted: the traditional periodic reporting mode (exponential growth) and the on-demand synchronization mode of this invention (slow linear growth), with key scenario nodes marked. The cloud storage cost is reduced from RMB 159.6 million per year for 1 million vehicles in the traditional mode to RMB 7.8 million in the mode of this embodiment, a reduction of 95.1%.

[0206] Specific scenario analysis: In the commuting planning scenario, the traditional model requires continuous reporting for 40 minutes, generating 1.25 megabytes of data. This embodiment only requires three data request-response interactions, totaling 6,000 bytes, with a compression ratio of 99.5%. In the health diagnosis scenario, the traditional model requires uploading three days' worth of full historical data, approximately 157 megabytes. This embodiment only extracts time-series data of diagnosis-related parameters, approximately 8.2 megabytes, with a compression ratio of 94.8%. In the parking arrangement scenario, the traditional model reports approximately 150 kilobytes every 5 minutes. This embodiment requests the current location in a single instance, resulting in a compression ratio of 98.7%.

[0207] 2. Privacy protection technology safeguards

[0208] It complies with the "minimum necessity principle" requirement of Article 6 of the Personal Information Protection Law: cloud applications cannot obtain data that is not explicitly requested, thus achieving technical enforcement; all data access has a clear purpose statement and audit log; sensitive data (such as precise trajectory) is only transmitted briefly when necessary and deleted after use.

[0209] Through third-party privacy compliance audits, we have obtained the International Organization for Standardization (ISO) International Electrotechnical Commission (IEC) Standard 27701 Privacy Information Management System Certification, the European Union General Data Protection Regulation (GDPR) Compliance Certification (applicable to the EU market), and the China Cybersecurity Classified Protection Level 3 Certification.

[0210] 3. Service integration efficiency has been significantly improved.

[0211] The new service access cycle is shortened from three to six months for traditional customized application programming interfaces (APIs) to one to two weeks for the MPC interface module in this embodiment, a reduction of 92%; the integration development cost is reduced from 500,000 to 1 million yuan in the traditional way to 50,000 to 80,000 yuan in this embodiment, a reduction of 90%; and the application programming interface maintenance cost is reduced from 150,000 to 250,000 yuan per year in the traditional way to 20,000 to 30,000 yuan in this embodiment, a reduction of 88%.

[0212] 4. System scalability and flexibility

[0213] Pluggable agents: Adding new intelligent agents requires no modification to the core system; only the deployment of a new agent container and configuration of a subscription theme are needed. Multi-vehicle adaptation: The same cloud-based AI manager can serve different vehicle models, adapting to differences through version management of digital twin models. Progressive upgrades: Vehicles can upgrade the capabilities of the vehicle-side AI manager via over-the-air download technology without hardware modifications.

[0214] 5. Balancing decision quality and real-time performance

[0215] Although the cloud-based digital twin is a "low-fidelity projection" of the vehicle's status, the decision-making quality has not significantly decreased thanks to an intelligent on-demand request mechanism: the route planning accuracy reaches 98.7%, a negligible difference compared to the 99.1% of traditional real-time reporting; the relevance of charging station recommendations reaches 96.3%, actually improving compared to the 92.1% of recommendations based on historical data; and the health diagnosis accuracy reaches 97.5%, on par with traditional methods. Meanwhile, through predictive requests and asynchronous processing, the average decision latency has been reduced from the traditional 3-5 seconds to 1-2 seconds.

[0216] 6. Improved energy efficiency

[0217] Regarding vehicle-side energy consumption: the energy consumption of fourth- or fifth-generation mobile communication modules has decreased from 15% to 2% (comparing on-demand communication with continuous reporting), saving approximately 8.5 kWh of communication energy per vehicle per year (equivalent to an increase of 50 km in range per year for electric vehicles). Regarding infrastructure energy consumption: cloud server computing resource usage has decreased by 60% (reduced data volume leads to lower computing demands for storage, retrieval, and analysis), mobile network base station load has decreased, and the probability of network congestion has declined.

[0218] 7. Improved user experience

[0219] Service response time improved from an average of 5 seconds to 2 seconds (predictive planning); service personalization increased, with the agent learning user preferences and proactively providing customized suggestions; transparency and controllability were enhanced, with users able to view data access audit logs and adjust privacy policies through the application. User satisfaction survey (Net Promoter Score) improved from 42 points for traditional connected car services to 71 points.

[0220] 8. Commercial Value and Ecological Effects

[0221] Reduced operating costs for automakers: Traffic fees, storage fees, and computing fees have decreased by approximately 85%; Reduced access costs for third-party service providers: From the level of 1 million to the level of 100,000, promoting ecosystem prosperity; New business models: Enhanced user trust through data sovereignty protection, enabling data authorization transactions (users can selectively authorize data to insurance companies in exchange for insurance premium discounts based on usage).

[0222] In summary, the federated vehicle AI management system based on a trusted data space provided in this embodiment achieves efficient, secure, and scalable vehicle operation and management through an innovative on-demand data synchronization mechanism, a federated AI architecture between the cloud and the vehicle, and policy-based data access control. This embodiment reduces vehicle-to-cloud data transmission volume by more than 90% while maintaining the accuracy and timeliness of vehicle management decisions; it implements the "minimum necessity" principle for data access, technically protecting user data sovereignty and privacy; it provides standardized service integration interfaces, enabling new service providers to complete integration within weeks; it supports the integrated implementation of various vehicle management scenarios (intelligent mobility planning, predictive maintenance, ecosystem service integration, etc.); and it is applicable to both manned and autonomous vehicles, possessing broad application prospects.

[0223] Example 2

[0224] Please see Figure 8 This embodiment provides a federated vehicle AI management method based on a trusted data space. This method is applied to the federated vehicle AI management system based on a trusted data space provided in Embodiment 1, and includes:

[0225] Step 0: Initialization Phase: When the vehicle leaves the factory or connects to the network for the first time, the vehicle-side AI manager and cloud-side AI manager nodes are registered in the trusted data space, and distributed identity identifiers are assigned. X.509 digital certificates are issued to establish identity trust relationships. The vehicle owner configures data sharing policies through the vehicle's interactive interface or mobile application, selecting predefined policy templates or custom policy rules. The policies are stored in the policy repository of the vehicle and the trusted data space in Open Digital Rights Language format. The vehicle-side digital twin synchronization module starts and begins to periodically collect vehicle status, establishing the initial value of the vehicle-side state vector. The cloud-side digital twin is initialized to an empty set or contains vehicle static attributes. The cloud-side multi-agent collaborative engine activates the corresponding functional agents according to the vehicle owner's subscribed services, and the agents enter a standby state.

[0226] Step 1: Task Triggering Stage: The cloud-based AI manager triggers the corresponding task based on the user's pre-defined scenario and sends it to the corresponding intelligent agent;

[0227] Specifically, task triggering is achieved through methods such as the car owner initiating a task request, automatic triggering of scheduled tasks, or event-driven triggering.

[0228] Step 2: Task Requirement Analysis Phase: The agent analyzes the input information required for the task and checks the cloud digital twin to determine the availability of each required information item: if the information item exists and its timeliness meets the requirements, it is used directly; if the information item does not exist or has expired, it is marked as pending request; if the information item can be obtained through external services, it is marked as a model context protocol interface module call.

[0229] Specifically, the cloud-based AI manager assigns tasks to the corresponding functional agents, which analyze the input information required for the task. The agents check the cloud-based digital twin to determine the availability of each required information item: if the information item exists and its timeliness meets the requirements, it is used directly; if the information item does not exist or has expired, it is marked as pending request; if the information item can be obtained through external services, it is marked as a model context protocol interface module call.

[0230] Step 3: On-demand data request generation stage: For information items marked as pending requests, the agent calls the data request generator to fill in all fields of the request message and generate a complete structured format request message. The request message is sent to the data routing controller of the trusted data space through the transport layer security protocol encrypted channel.

[0231] Please see Figure 9 Specifically, for information items marked as pending requests, the agent invokes the data request generator to specify the data purpose, required parameters, timeliness requirements, and accuracy requirements; the data request generator fills in all fields of the request message, including the requester's identity certificate, timestamp, and digital signature, to generate a complete structured format message; the request message is sent to the data routing controller of the trusted data space through a transport layer security protocol encrypted channel.

[0232] Step 4: Policy Verification and Data Authorization Phase: The data routing controller forwards the request to the policy execution point of the policy execution engine. The policy execution point extracts the request attributes to construct an Extensible Access Control Markup Language request context. The policy decision point evaluates the policy and returns the decision result. If the decision result allows, a JWT token is generated and routed to the vehicle-side AI manager along with the request message through an encrypted channel.

[0233] Continue reading Figure 9 Specifically, the data routing controller forwards the request to the policy execution point component of the policy execution engine. The policy execution point extracts the request attributes to construct an Extensible Access Control Markup Language (EXCUL) request context. The policy execution point calls the policy decision point to perform policy evaluation. The policy decision point loads Open Digital Rights Language (ODL) rules from the vehicle-side policy repository and performs multi-dimensional matching, including identity matching, purpose matching, data type matching, and spatiotemporal constraint matching. The policy decision point returns the decision result. If allowed, it generates a JSON Web Token (JWT, a compact token format used to securely transmit claims between parties; in this embodiment, it is used to transmit data access authorization information). Its payload includes the request subject, audience, purpose, list of allowed data, expiration timestamp, and constraints. The token and the request are routed together to the vehicle-side AI manager through an encrypted channel.

[0234] Step 5: Vehicle-side data extraction and response stage: The vehicle-side data sovereignty gateway receives the request message and verifies the signature validity, expiration time, and whether the audience of the JWT token is the vehicle itself; if the verification is successful, the data sovereignty gateway generates a database query based on the allowed data list, executes the query to obtain the latest status record, obtains the response message, and sends the response message back to the cloud AI manager through an encrypted channel;

[0235] Specifically, the vehicle-side data sovereignty gateway receives the request and verifies the validity of the network token's signature, expiration time, and whether the audience is the vehicle itself. The data sovereignty gateway generates a database query based on the allowed data list, executes the query to obtain the latest status record, and quantifies it according to accuracy requirements. It checks spatial and temporal constraints, and verifies them if the policy has specific requirements. Then, it encapsulates a data response message, which includes a data subset, metadata, request identifier, and verification, and sends the response back to the cloud through an encrypted channel.

[0236] Step 6: Cloud Decision and Planning Stage: After receiving the response message, the cloud AI manager verifies the checksum and checks the matching of the request identifier, and calls the cloud digital twin update interface to perform differential update. The agent executes the decision algorithm based on the updated cloud digital twin, and calls the external service system through the model context protocol interface module to obtain environmental information or execute service reservations. It generates a task execution plan by combining internal status and external information.

[0237] Specifically, the cloud-based AI manager receives the response, verifies the checksum, and checks if the request identifier matches; it calls the cloud-based digital twin update interface to perform differential updates, writing a subset of data into the corresponding state attributes of the cloud-based digital twin, while other state components remain unchanged or are updated according to the prediction model; the agent executes the decision-making algorithm based on the updated cloud-based digital twin; it calls external service systems through the model context protocol to obtain environmental information or execute service reservations; and it generates a task execution plan by integrating internal state and external information.

[0238] Step 7: Target State Synchronization and Execution Phase: The intelligent agent transforms the execution plan into the target state of the cloud-based digital twin. Changes in the digital twin trigger state synchronization events, which are then pushed to the vehicle-side AI manager via a publish-subscribe mechanism. The vehicle-side AI manager subscribes to target state update type events.

[0239] Specifically, the intelligent agent transforms the solution into the target state of a cloud-based digital twin, including information such as the planned route, target parking lot, and recommended departure time. Changes to the digital twin trigger state synchronization events, which include the change type, change fields, change value, priority, and expected execution time. These events are pushed to the vehicle via a publish-subscribe mechanism, and the vehicle's AI manager subscribes to target state update type events.

[0240] Step 8: Vehicle-side Execution and Feedback Phase: The vehicle-side real-time control execution module receives events, parses the planned path, extracts the navigation path point sequence, and pushes a notification to the driver before the expected execution time. After the driver confirms, the real-time control execution module sends the path points to the in-vehicle navigation system and starts navigation guidance. During the journey, it continuously monitors key states. If the deviation from the planned route exceeds a threshold, or if real-time traffic conditions show congestion ahead or the battery level is below a safe threshold, the corresponding processing procedure is triggered. When a key milestone is reached, an execution feedback message is generated. The feedback message is transmitted back to the cloud AI manager through the data space. The cloud digital twin updates the corresponding data, the intelligent agent receives the completion notification, updates the task status, and records the execution effect data for strategy learning.

[0241] Specifically, the vehicle-side real-time control module receives events, parses the planned route, and extracts the navigation path point sequence. Before the expected execution time arrives, it pushes a notification to the driver. After the driver confirms, the control module sends the path points to the in-vehicle navigation system and starts navigation guidance. During driving, it continuously monitors key states. If the deviation from the planned route exceeds a threshold, or if real-time traffic conditions show congestion ahead or the battery level is below a safe threshold, it triggers the corresponding processing procedure. When a key milestone is reached, it generates an execution feedback message, including the event type, milestone name, timestamp, location, and parking space information. The feedback message is transmitted back to the cloud through the data space, and the cloud digital twin updates information such as route status, actual arrival time, and parking location. The intelligent agent receives the completion notification, updates the task status, and records the execution effect data for strategy learning.

[0242] This embodiment also provides a federated vehicle AI management method based on a trusted data space, which further includes:

[0243] Continuous monitoring and optimization phase: The communication efficiency quantification module counts the total data transmission volume of this task, including the total number of bytes for data request messages, data response messages, target status synchronization, and execution feedback; it calculates the data transmission compression ratio by comparing it with the traditional mode; the decision quality assessment module evaluates indicators such as task success rate, arrival time deviation, and user satisfaction; the strategy learning module records the experience of this task, including scenario characteristics, data requirements, and optimization directions, and retrains the prediction model after accumulating sufficient experience.

[0244] Example 1: The complete process of commuting planning

[0245] Please see Figure 10 Taking a typical weekday morning commute as an example, the system operation process is explained in detail.

[0246] Scenario: Mr. Zhang, the car owner, lives in Chaoyang District, Beijing, and works in Zhongguancun, Haidian District. His vehicle is an electric SUV of a certain brand, vehicle identification number ABCD1234567890123, currently parked in his home's underground garage. The time is 7:00 AM on Thursday, December 5, 2025. His goal is to arrive at his company by 8:30 AM and he needs to reserve a parking space.

[0247] Step 1: Trigger the scheduled task;

[0248] The car owner set up a "Weekday Commute Assistant" via the car's infotainment system the night before. The system automatically activates the commuting planning agent at 7:00 AM every weekday. The task scheduler in the cloud-based AI manager checks the current date and time, and if the trigger conditions are met, generates a task instance containing a task identifier, task type, trigger time, destination information, and constraints. The task is then assigned to the commuting planning agent.

[0249] Step 2: Agent requirements analysis;

[0250] After receiving the task, the agent analyzes the information needed to complete the planning: current location, destination, expected arrival time, vehicle range, and real-time traffic conditions. The agent checks the cloud-based digital twin to determine the availability of each required information item: if the information item exists and its timeliness meets the requirements (timestamp less than a threshold, such as five minutes from the current time), it is used directly; if the information item does not exist or has expired, it is marked as pending; if the information item can be obtained through external services (such as real-time traffic), it is marked as a model context protocol call.

[0251] The agent decides: vehicle location is outdated and needs to be re-requested; battery state of charge and remaining range are missing and need to be requested; traffic conditions are obtained by calling external services through the model context protocol.

[0252] Step 3: Generate a data request message;

[0253] The agent invokes the data request generator, specifying the agent identifier as the commuting planning agent instance number, the data purpose as navigation planning, the target vehicle as the vehicle identification number, and the required parameters including the global navigation satellite system location, the power system battery state of charge, and the power system battery remaining range. Each parameter specifies the time range as the latest snapshot and the required accuracy. The generated complete structured message is approximately 0.8 kilobytes and is sent to the data routing controller in the trusted data space via a secure hypertext transfer protocol.

[0254] Step 4: Strategy Verification;

[0255] The data routing controller receives the request and forwards it to the policy execution point of the policy execution engine. The policy execution point extracts the request attributes, including the requesting agent identifier, agent type, data purpose semantic label, target vehicle identifier, data type list, and current time. The policy execution point calls the policy decision point, which loads the Open Digital Rights Language policy for the vehicle from the vehicle-side policy repository and performs an Extensible Access Control Markup Language evaluation.

[0256] The evaluation process is as follows: Rule 1: Target matching is successful (agent type is in the allowed list), purpose matching is successful (purpose is navigation planning in the policy), data type matching is partial (location GNS and battery data are allowed), time constraint check (constraints are only required during active trips; if the current trip status is inactive, this rule does not apply); Rule 2: Matches the default commuting planning rule, all conditions are met (target matching, purpose matching, data type matching, time constraint meets weekday morning 7-9 am commuting planning is allowed), the evaluation result is allowed.

[0257] The policy decision point generates a network token access token. Its payload includes: the request subject is the commuting planning agent identifier, the audience is the target vehicle identifier, the purpose is navigation planning, the allowed data list includes the GPS location, powertrain battery state of charge, and remaining powertrain battery range, and an expiration timestamp of ten minutes. The token, along with the original request, is routed to the vehicle.

[0258] Step 5: Extract vehicle-side data;

[0259] The vehicle is currently parked, and the vehicle-side AI manager is operating in low-power mode while continuously monitoring network connections. The data sovereignty gateway receives the request and token, verifies the network token signature and validity period, and parses the list of allowed data. The gateway queries the vehicle-side digital twin storage and retrieves the latest status record (collected at 10:05 PM last night when the vehicle was turned off).

[0260] The query results include: timestamp of 22:05 last night, latitude 39.9142, longitude 116.4074, state of charge 0.68, and remaining range of 245 kilometers. The gateway processes the data according to accuracy requirements: location is retained to four decimal places with approximately ten-meter precision, state of charge is retained to two decimal places with approximately one-hundredth precision, and remaining range is rounded to the nearest integer.

[0261] The gateway encapsulates a data response message of approximately 1.2 kilobytes, containing a subset of data, metadata (collection timestamp, data quality metrics including location accuracy of 3.5 meters and state of charge estimation confidence level of 0.95), a request identifier, and a checksum. The response is then transmitted back to the cloud via an encrypted channel.

[0262] Step 6: Update the digital twin in the cloud;

[0263] The cloud-based AI manager receives the response, verifies the checksum, and checks for matching request identifiers. It then calls the cloud-based digital twin update interface to perform a differential update: updating the latest snapshot in the in-memory database, including the latitude, longitude, and timestamp of the GPS system, the battery state of charge, remaining range, and timestamp; writing historical records to the time-series database; and updating the cloud-based state vector, including location coordinates, location freshness marked as nine hours old, battery state of charge, and remaining range.

[0264] The agent receives the update notification and continues the decision-making process.

[0265] Step 7: Path planning and external service invocation;

[0266] The agent invokes the Model Context Protocol (MGP) client to request real-time traffic information. The MGP gateway performs the following steps: Service discovery queries the Beijing Municipal Transportation Administration's service endpoint from the metadata broker; authentication uses the vehicle manufacturer's service account credentials to authenticate with the Transportation Administration's application programming interface (API); protocol conversion transforms the MGP request into the Transportation Administration's Representational State Transition API call; invocation and response retrieval; response conversion transforms the Transportation Administration's Extensible Markup Language (EXPLAIN) response into the MGP standard structured format; and the result is returned to the agent.

[0267] The traffic service response includes information on multiple routes, each with route identifier, name, distance, estimated travel time, congestion level, and road segment details. The agent analyzes traffic data and, based on the vehicle's remaining range (245 kilometers), determines that charging is unnecessary and selects a recommended route. The optimal departure time is calculated: with an arrival deadline of 8:30 AM and an estimated travel time of 32 minutes, the recommended departure time is 7:55 AM (allowing a 3-minute buffer).

[0268] Step 8: Parking space reservation;

[0269] The agent invokes the Model Context Protocol parking service with the following parameters: location (address: No. 27 Zhongguancun Street, Haidian District, Beijing; coordinates: within a radius of 300 meters); arrival time: 8:27 AM; parking duration: 9 hours; vehicle information (type: sedan; length: 4.7 meters; no charging required); payment method (linked account); preferences (indoor preference, maximum walking distance: 200 meters).

[0270] The parking service provider's response includes: successful booking, booking confirmation, parking lot information (name: Zhongguancun Software Park Underground Parking Lot, address, coordinates, 150-meter walking distance to destination), parking space number B2-045, booking time range from 8:27 AM to 5:30 PM, price: 45 yuan, entry code: 237865, and cancellation policy: free cancellation before 8:00 AM.

[0271] Step 9: Generate a complete commuting plan;

[0272] The intelligent agent integrates all information to generate a final commuting plan that includes a plan identifier, generation time, departure information (location, recommended time, preparation reminder), route information (route identifier, name, distance, estimated time, waypoint list, traffic conditions, estimated arrival time), parking information (reservation identifier, parking lot name, parking space number, entry code, price, walking distance), energy analysis (trip energy consumption estimate, arrival state of charge estimate, whether charging is required), and alternative plans.

[0273] Step 10: Update the cloud-based digital twin and trigger synchronization;

[0274] The intelligent agent writes the solution into a cloud-based digital twin: updating the planned route, target parking lot, recommended departure time, route status (planned), solution version, last updater, and last update timestamp. Digital twin updates trigger event publishing, including event types such as target status update, vehicle identification, a list of changed fields, a normal priority, and a payload containing the planned route, target parking lot, and recommended departure time. The event is pushed to subscribers on the vehicle via a message queue.

[0275] Step 11: The vehicle receives and prepares to execute the command;

[0276] The vehicle-side AI manager's real-time control module subscribes to target status update events and receives commuting plans. The control module parses the plan, extracting the departure time, waypoint sequence, parking lot coordinates, and access code. The control module schedules tasks: sending a notification to the driver five minutes before departure (7:50 AM), including a title, message content, and optional operation buttons; and starting navigation at the departure time (7:55 AM, if the driver confirms), including waypoints and destination coordinates.

[0277] Step 12: Owner interaction and navigation activation;

[0278] At 7:50 AM, the in-vehicle system pushes a notification to the vehicle's infotainment screen and the driver's mobile application, including suggested departure time, route information, parking information, estimated arrival time, and current battery level. The driver clicks the "Start Navigation" button, triggering a user confirmation event on the vehicle's system, which includes an event type of user action, an action of confirming navigation, a route identifier, and a timestamp.

[0279] Immediately launch the navigation system, load route waypoints, and begin navigation guidance. Update the vehicle's digital twin: navigation active route indicator, navigation destination, and navigation status "guiding".

[0280] Step 13: Monitoring the driving process;

[0281] During vehicle operation, the vehicle-side AI manager continuously monitors key states: updating the position, speed, and heading in the vehicle's state vector every 30 seconds; detecting yaw and triggering replanning if the current position is more than 500 meters away from the planned route; monitoring battery level and triggering the charging scheduling agent if the state of charge is below 30%; and monitoring congestion and proactively notifying the cloud-based agent to assess whether to switch to an alternative route if severe congestion is detected ahead.

[0282] The trip went smoothly without any incidents. The vehicle sent a brief status update to the cloud every five minutes, containing only the current location, estimated arrival time, and battery level, for a total of six updates. Each data packet was approximately 0.3 kilobytes, for a total of 1.8 kilobytes.

[0283] Step 14: Arrival and Parking;

[0284] The vehicle arrived at the parking lot entrance at 8:25 AM. The vehicle's AI manager detected that the current location was less than 50 meters from the target parking lot and triggered the following: a message was displayed on the human-machine interface with the title "Arrived at Parking Lot" and the content including the entry code and parking space number; an arrival milestone event was generated, including the event type "Milestone Arrival", the milestone name "Arrived at Parking Lot", the timestamp, the location, and the parking lot information.

[0285] The driver enters the parking lot using the entry code, finds a parking space, parks, and turns off the vehicle. The vehicle system detects the engine shutdown event (monitoring the power mode via the controller area network bus) and performs the following actions: collecting a final state snapshot including final location, mileage, and battery level; updating the vehicle's state vector including GPS location, power system battery state of charge, metadata (total mileage increased), navigation status (completed), and vehicle power mode (off).

[0286] Generate trip completion feedback, including trip identifier, status "completed," actual departure time, actual arrival time, actual travel time, actual distance, actual energy consumption, parking confirmation, parking space availability, and user rating pending. Send the feedback to the cloud; the data packet is approximately 0.5 kilobytes.

[0287] Step 15: Cloud status update and learning.

[0288] The cloud-based AI manager receives trip feedback and updates the cloud-based state vector: route status as completed, actual arrival time, parking location information, and final trip summary. The commuting planning agent's strategy learning module records this experience, including scenario features (date, day of the week, departure time, weather, traffic level), decision content (route selection, departure time recommendation), and result evaluation (arrival time error, energy consumption error, user satisfaction).

[0289] The strategy learning module accumulates experience records, and when the number of experiences reaches a threshold (e.g., every 100 experiences), the trip time prediction model and energy consumption prediction model are retrained. If car owners give ratings through the application (e.g., a five-star review), these ratings will be incorporated into the reinforcement learning reward signal to further optimize future decision-making strategies.

[0290] Total data transmission volume statistics:

[0291] Data request from the cloud to the vehicle: 0.8 kilobytes; data response from the vehicle to the cloud: 1.2 kilobytes; Model Context Protocol (MCP) traffic service call between the cloud and external systems: 2.5 kilobytes; Model Context Protocol (MCP) parking service call between the cloud and external systems: 1.8 kilobytes; target state synchronization from the cloud to the vehicle: 3.5 kilobytes; driving state updates (6 times) from the vehicle to the cloud: 1.8 kilobytes; trip completion feedback from the vehicle to the cloud: 0.5 kilobytes; total: 12.1 kilobytes.

[0292] Compared to the traditional method, assuming a reporting frequency of 10 seconds and a processing time of 32 minutes: the traditional method generates 5.2 kilobytes of data multiplied by a reporting rate of 6 times per minute, totaling 998.4 kilobytes over 32 minutes. This invention generates 12.1 kilobytes of data, achieving a compression ratio of 98.8%.

[0293] Example 2: In-depth analysis of health diagnosis scenarios

[0294] Scenario Setup: The vehicle is the same electric SUV, vehicle identification number ABCD1234567890123. The trigger condition is a scheduled health check, automatically performed on the 1st of each month. The time is 23:00 on December 1, 2025 (off-peak hours). The diagnostic objective is battery health assessment and prediction of remaining battery life.

[0295] Step 1: Diagnostic task triggered;

[0296] The health diagnosis intelligent agent is activated as planned, generating diagnostic tasks that include a task identifier, a task type of battery health assessment, a vehicle identifier, a diagnostic scope (battery capacity, cell consistency, thermal performance, aging prediction), and a data window of the last thirty days.

[0297] Step 2: Diagnostic data requirements analysis;

[0298] The built-in diagnostic algorithm of the intelligent agent requires the following data: individual cell temperature (data path is the power system battery cell temperature array, time range is the last 30 days, only data during charge and discharge is required, sampling rate is once per minute, because temperature consistency is a key indicator for assessing battery health); battery pack voltage (data path is the power system battery pack voltage, time range is the last 30 days, aggregation method is the minimum and maximum average value per charging cycle, because voltage changes reflect capacity decay); battery pack current (data path is the power system battery pack current, time range is the last 30 days, aggregation method is the same as voltage); state of charge curve (data path is the power system battery state of charge, time range is the last 30 days, event is charge and discharge cycle, because the shape of the charge and discharge curve reflects battery state); ambient temperature (data path is ambient temperature, time range is the last 30 days, aggregation method is daily average); total mileage (data path is metadata total mileage, time range is a snapshot from 30 days ago to the present, because it is the cumulative mileage during the calculation period); number of charging cycles (data path is the number of power system battery charging cycles, time range is the latest snapshot).

[0299] Upon examining the cloud-based digital twin, it was discovered that this data had never been synchronized (this was the first time the health diagnostic agent had run).

[0300] Step 3: Generate large-scale data requests;

[0301] The agent generates data requests with detailed parameter specifications, including request identifier, version, timestamp, requester information (agent identifier, type, version, credentials including distributed identity, certificate, signature), target information (vehicle identifier, vehicle owner distributed identity), purpose information (semantic tag: battery health assessment, ontology: vehicle data purpose ontology, description, business context), data specifications (containing seven parameter objects, each defining path, data type, time range, sampling or aggregation method, precision, and filtering conditions), constraints (maximum response size of 10 megabytes, response timeout of 30 seconds, acceptable data loss rate of 0.05%, high data quality requirements), usage policies (retention period of 30 days, allowed operations including statistical analysis and machine learning training and diagnostic report generation, prohibited operations including third-party sharing and re-identification attempts, data residency requirement: same region as the vehicle, anonymization not required, audit trail required: access time, processing operations, and visitor identity), and notification settings (response delivery method: push, endpoint, authentication method, progress update enabled, including completion milestones).

[0302] The request message is approximately 1.5 kilobytes in size.

[0303] Step 4: Strategy verification;

[0304] The vehicle-side policy includes specific rules for health diagnosis, which include permission tags. The target is all data of the power system battery, the action is reading, the assignee is the health diagnosis intelligent agent, and the constraints include: the purpose tag is battery health assessment, the data age is no more than three days (access to the most recent three days of historical data is allowed), the request frequency is no more than once a month (a maximum of one request per month); the obligation is that if the data needs to be shared with a third party, it must be anonymized first.

[0305] Policy verification passed, access token generated.

[0306] Step 5: Extract large-scale data from the vehicle;

[0307] The vehicle-side data sovereignty gateway receives a request, which is a complex multi-dimensional time-series data query. The gateway first checks the request frequency limit: it queries the audit log for historical requests within the last thirty days used for battery health assessment. If such requests exist, they are rejected, and a policy violation error message is thrown indicating that the monthly diagnostic limit has been exceeded. After the check passes, data extraction is performed.

[0308] Since the vehicle-side digital twin stores high-frequency raw data, a large amount of aggregation calculation is required: The first step is to identify charging periods by identifying charging sessions from November 1st to December 1st from the vehicle status time series data source and returning 15 charging sessions; the second step is to identify discharging periods by identifying discharging sessions with a discharging current less than the negative 5 ampere threshold from the same data source and returning 42 discharging sessions corresponding to 42 trips.

[0309] The second step is to extract the individual cell temperature during charging and discharging. For each charging and discharging session, the time-series data measurement item is cyclically queried. The time range is the start and end time of the session, and the sampling interval is every minute. The data containing the session identifier, session type, start time, duration, and temperature array (ninety-six cells multiplied by multiple sampling points) is added to the individual cell temperature list during the activity.

[0310] The third step is to aggregate voltage and current data by charging cycle. For each charging cycle, the battery pack voltage curve and battery pack current curve are identified and queried. The minimum, maximum, average, and complete curves of the voltage and the minimum, maximum, average, and complete curves of the current are calculated. The data containing the cycle identifier, start time, voltage object, and current object are added to the cycle-based voltage and current list.

[0311] The fourth step is to extract the state of charge (SOC) during charge / discharge cycles. For each charging cycle, the SOC curve is queried to extract the initial SOC, final SOC, SOC change, and complete curve. The fifth step is to aggregate the daily average ambient temperature. The time-series data measurement item is ambient temperature, ranging from November 1st to December 1st, and the aggregation method is the daily average. The sixth step is to extract mileage data. The snapshot at 00:00:00 on November 1st is retrieved, and the snapshot at 23:59:59 on December 1st is retrieved, with the mileage increment calculated as the difference between the ending and starting values. The seventh step is to obtain the latest charging cycle count from the battery charging cycle count.

[0312] After extraction, the estimated size of the gateway assessment data subset is as follows: Individual temperature data during the activity period is approximately 420 kilobytes, voltage and current curves are approximately 28 kilobytes, state of charge curves are approximately 14 kilobytes, ambient temperature is approximately 0.1 kilobytes, and mileage and cycle count are approximately 16 bytes, totaling approximately 462 kilobytes. Although the data volume is large, it is still far smaller than the full report (approximately 157 megabytes of full data over 30 days).

[0313] The gateway checks the maximum response size constraint (10 megabytes) in the request, and the data meets the requirements. Anonymization is performed: the exact timestamp of the session is removed, retaining only the relative time; November 5, 2025, 2:30 PM is anonymized to the afternoon of the fifth day. Formatting: converted to a compressed structured format, including data period, number of charging sessions, number of discharging sessions, individual cell temperature during the activity period, voltage and current per cycle, state of charge cycle, daily ambient temperature, mileage increment, and total number of charging cycles. The compressed data is approximately 120 kilobytes.

[0314] Encapsulate the response message and send it back.

[0315] Step 6: Cloud-based diagnostic algorithm execution;

[0316] The cloud-based health diagnostic agent receives data, updates the historical data cache in the cloud-based digital twin, and then executes the diagnostic algorithm.

[0317] Algorithm 1 performs individual consistency analysis, analyzing individual temperature data during the activity period and outputting a consistency score of 0.92 (out of 1.0, indicating good consistency).

[0318] Algorithm 2 capacity decay assessment uses voltage and current curves and state-of-charge cycles as inputs to estimate capacity decay. The outputs include an estimated current capacity of 73.5 kWh, an initial capacity of 75 kWh, a capacity retention rate of 0.98%, and a decay rate per cycle of 0.00015.

[0319] Algorithm 3 evaluates thermal management performance. It uses the unit temperature and ambient temperature during the activity as inputs to evaluate thermal management. The outputs include the highest temperature of 42.3 degrees Celsius during fast charging, temperature uniformity of 0.88, and cooling efficiency of 0.75.

[0320] Algorithm 4 uses a machine learning model to predict remaining lifetime. The inputs include capacity retention rate of 0.98, number of charging cycles, total mileage, cell consistency of 0.92, and thermal stress index. The outputs include predicted remaining cycle count of 1,850, predicted remaining lifespan of 6.2 years, confidence interval from 5.8 to 6.6 years, and health grade A.

[0321] The generated diagnostic report includes: report identifier, vehicle identifier, generation time, diagnostic period, overall health score of 95 points (out of 100), health level A, battery health details (capacity retention rate of 98%, cell consistency score of 0.92, thermal performance score of 0.75, predicted remaining life of 6.2 years, health level A), key findings (overall battery condition is excellent, good cell temperature consistency indicates that the battery management system is working normally, capacity decay rate is below average, and there is room for improvement in temperature control of the thermal management system during fast charging), recommended measures (maintain current charging habits and avoid frequent fast charging to 100%, try to park in a shady place during hot summer periods, it is recommended to perform a deep battery inspection when the mileage reaches 150,000 kilometers, no immediate maintenance is required and normal use can continue), and the next diagnostic plan is scheduled for January 1, 2026.

[0322] Step 7: Report push and user interaction;

[0323] The cloud-based AI manager pushes diagnostic reports to car owners through multiple channels: the vehicle's infotainment system displays a health report summary on the dashboard the next time the vehicle is started, including a health score of 95 (Grade A) and approximately six years of remaining lifespan, and provides a button to view the detailed report; the mobile application pushes a notification with the title "Your vehicle health report is ready" and the content "Battery health is excellent, please see details," and provides a detailed report with charts and graphs, including historical trend comparisons; and emails send a portable document attachment containing the complete report.

[0324] After the car owner clicks to view the detailed report, the application displays multi-dimensional visualization charts: the capacity retention rate trend chart shows the capacity change curve from the time of purchase to the present, comparing the current value of 98 with the new car's 100; the individual cell temperature heat map shows the temperature distribution of 96 cells during the most recent fast charge, with varying shades of color indicating good temperature consistency; the charging habit analysis pie chart shows the charging type distribution over the past 30 days, with slow charging accounting for 70% and fast charging accounting for 30%; and the lifespan prediction chart shows the confidence interval for the predicted remaining mileage and lifespan based on the current usage pattern.

[0325] Car owners can provide feedback on the report by clicking the "Helpful" or "Need More Information" buttons; if they find that some data in the report does not match their actual experience, they can submit corrective suggestions; if they have any questions about the suggested measures, they can directly communicate with customer service or technical support.

[0326] Step 8: Data usage audit and policy update;

[0327] After the diagnosis is completed, the system automatically records the data usage audit log, which includes: audit identifier, vehicle identifier, data request identifier, visitor is a health diagnosis agent, access time, access purpose is battery health assessment, list of accessed data types, data size is 120 kilobytes, data usage operations include statistical analysis and machine learning model inference and report generation, data retention status is that it will be deleted after 30 days, and compliance checks have passed all policy constraints.

[0328] Vehicle owners can view this audit log through the application to understand how their vehicle data is being used. If a vehicle owner believes the data has been misused, they can file a complaint to trigger a manual review process.

[0329] Based on diagnostic results and user feedback, the strategy learning module may adjust future data request strategies: if it finds that thermal management assessment requires higher precision temperature data, it will request a higher sampling rate in the next diagnostic; if it finds that capacity assessment is insensitive to certain parameters, it will reduce these parameters and reduce data transmission volume in future requests; if users report a desire for more frequent diagnostics, the strategy can be adjusted to allow diagnostics every two weeks after obtaining user consent.

[0330] End-to-end data transmission and efficiency analysis:

[0331] The data transmission in this health diagnosis scenario includes: 1.5 kilobytes of data request messages from the cloud to the vehicle; 120 kilobytes of data response messages from the vehicle to the cloud (compressed); and approximately 50 kilobytes of diagnostic reports from the cloud to the vehicle owner's devices (vehicle infotainment system and mobile phone) (including charts); totaling approximately 171.5 kilobytes.

[0332] Compared to the traditional method of reporting 30 days of historical data in full: the traditional method requires uploading 30 days of complete vehicle status time-series data. Assuming that a data packet of 5.2 kilobytes is collected every 10 seconds, the total data volume for 30 days is equal to 5.2 kilobytes multiplied by 6 times per minute, 60 minutes per hour, 24 hours per day, and 30 days, which equals approximately 134 megabytes (if only the driving time of 2 hours per day is considered, it is approximately 8.9 megabytes).

[0333] Even considering only travel time, the data transmission volume of the present invention is 0.17 megabytes, while that of the traditional method is 8.9 megabytes, achieving a compression ratio of 98.1%.

[0334] More importantly, in traditional methods, a large amount of irrelevant data (such as cabin temperature, entertainment system status, etc.) will also be uploaded, while this invention only extracts the battery-related parameters required for diagnosis, truly realizing the "minimum necessary" principle.

[0335] For details on the specific implementation of a federated vehicle AI management method based on a trusted data space, please refer to the above description of the limitations of a federated vehicle AI management system based on a trusted data space, which will not be repeated here.

[0336] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. These embodiments not explicitly written should also be considered to be within the scope of this specification.

Claims

1. A federated vehicle AI management system based on trusted data space, characterized in that, This includes a trusted data space infrastructure layer, a cloud-based AI manager, and a vehicle-side AI manager; The trusted data space infrastructure layer includes an identity authentication service module, a policy execution engine, a data routing controller, and a metadata broker module. The identity authentication service module is used to assign unique digital identities to the vehicle-side AI manager, the cloud-based AI manager, and external service providers based on distributed identity identification technology, and to perform identity authentication using digital certificates; The policy execution engine is used to build a policy management architecture for vehicle-cloud collaboration using a policy definition language and a rule engine: the main policy copy is stored on the vehicle and backed up in the cloud trusted data space; the policy execution point intercepts all data access requests and the policy decision point performs authorization evaluation; and finally, fine-grained attribute access control is achieved by issuing JWT tokens. The data routing controller is used to implement the data connector of the international data space standard protocol and provides support for multiple transmission protocols. The metadata broker module is used to provide a centralized or federated service catalog, and uses the International Data Spatial Information Model to semantically describe resources, supporting structured query language queries and expressive state transition application programming interfaces. The cloud-based AI manager includes a multi-agent collaboration engine, a cloud-based digital twin, and a model context protocol interface module. The multi-agent collaboration engine is used to configure multiple functionally dedicated agents, each responsible for a specific vehicle management task. The agents collaborate using an asynchronous message passing mechanism and listen for changes in specific state attributes in the cloud-based digital twin through a publish-subscribe pattern. The cloud-based digital twin is used to store a virtual mapping of the vehicle's physical state; the virtual mapping is a dynamic projection subset of the complete state of the vehicle, and the projection dimension is adaptively adjusted according to the currently activated intelligent agent task. The model context protocol interface module is used to provide standardized external service integration interfaces and encapsulate general logic; The vehicle-side AI manager includes a real-time control execution module, a vehicle-side digital twin, and a data sovereignty gateway. The real-time control execution module is used to execute vehicle behavior decisions and control commands, receive the target state issued by the cloud AI manager, and convert it into controller area network or Ethernet commands that can be executed by the vehicle's underlying controller. The vehicle-side digital twin is used to collect status data of each electronic control unit in real time through the vehicle bus and to maintain the high-fidelity digital twin of the vehicle. The data sovereignty gateway is used to execute the data sharing policy preset on the vehicle, intercept all data requests from the cloud AI manager, perform policy matching based on the data request attributes, and is responsible for data desensitization and aggregation processing.

2. The federated vehicle AI management system based on trusted data space according to claim 1, wherein, The policy execution point in the policy execution engine is deployed at key nodes in the data flow path. When the policy decision point performs authorization evaluation, it generates a decision result of permission, denial, or inapplicability. If the decision result is permission, a JWT access token containing the authorization scope and validity period is generated.

3. The federated vehicle AI management system based on trusted data space according to claim 1, wherein, The data routing controller provides transmission protocols including Hypertext Transfer Security Protocol, Message Queuing Telemetry Transport Protocol, and Advanced Message Queuing Protocol, and the transmission protocols employ end-to-end encryption mechanisms when transmitting data.

4. The federated vehicle AI management system based on trusted data space according to claim 1, characterized in that, Each agent configured in the multi-agent collaborative engine runs as an independent service process in a containerized environment. Each agent includes a perception module, a decision-making module, an execution module, and a learning module. The sensing module is used to subscribe to specific state attribute change events of the cloud-based digital twin; The decision-making module is used to generate action plans based on the current state and historical experience; The execution module is used to convert the decision results into digital twin state updates or external service calls; The learning module is used to optimize decision-making strategies using reinforcement learning or supervised learning algorithms.

5. The federated vehicle AI management system based on trusted data space according to claim 1, characterized in that, The cloud-based digital twin includes: a set of state attributes, historical time-series data of state, a state prediction model, and state constraint rules; the state attributes in the set of state attributes are organized in a three-layer hierarchical manner, and each state attribute includes: current value, timestamp, data quality index, and freshness tag.

6. The federated vehicle AI management system based on trusted data space according to claim 1, characterized in that, The model context protocol interface module includes: a service registry, a protocol adapter, a request router, and a response converter. The service registry is used to store metadata of registered external services, including: service name, service type, service endpoint URL, authentication method, request format, response format, rate limit, and service level agreement. The protocol adapter is used to support multiple third-party service protocols and convert the unified format requests issued by the intelligent agent into the native protocol format of the target service; The request router is used to select the optimal service provider instance based on the service type and load conditions, and supports load balancing strategies and failure retry mechanisms. The response converter is used to uniformly convert heterogeneous response formats from third-party services into Model Context Protocol (MCP) standard responses.

7. The federated vehicle AI management system based on trusted data space according to claim 1, characterized in that, The real-time control execution module adopts a priority scheduling mechanism, where higher priority instructions can preempt lower priority instructions.

8. The federated vehicle AI management system based on trusted data space according to claim 1, characterized in that, The vehicle-side digital twin contains 100 to 500-dimensional state vectors, which include powertrain, chassis and body, positioning and motion, environmental perception, cabin state, and communication network subsystems.

9. The federated vehicle AI management system based on trusted data space according to claim 1, characterized in that, It also includes a federated learning module, which is used to collaboratively train AI models while protecting user privacy.

10. A federated vehicle AI management method based on a trusted data space, characterized in that, The method is applied to the federated vehicle AI management system based on trusted data space as described in any one of claims 1-9, comprising: Step 1: Task Triggering Stage: The cloud-based AI manager triggers the corresponding task based on the user's pre-defined scenario and sends it to the corresponding intelligent agent; Step 2: Task Requirement Analysis Phase: The agent analyzes the input information required for the task and checks the cloud digital twin to determine the availability of each required information item: if the information item exists and its timeliness meets the requirements, it is used directly; if the information item does not exist or has expired, it is marked as pending request; if the information item can be obtained through external services, it is marked as a model context protocol interface module call. Step 3: On-demand data request generation stage: For information items marked as pending requests, the agent calls the data request generator to fill in all fields of the request message and generate a complete structured format request message. The request message is sent to the data routing controller of the trusted data space through the transport layer security protocol encrypted channel. Step 4: Policy Verification and Data Authorization Phase: The data routing controller forwards the request to the policy execution point of the policy execution engine. The policy execution point extracts the request attributes to construct an Extensible Access Control Markup Language request context. The policy decision point evaluates the policy and returns the decision result. If the decision result allows, a JWT token is generated and routed to the vehicle-side AI manager along with the request message through an encrypted channel. Step 5: Vehicle-side data extraction and response stage: The vehicle-side data sovereignty gateway receives the request message and verifies the signature validity, expiration time, and whether the audience of the JWT token is the vehicle itself; if the verification is successful, the data sovereignty gateway generates a database query based on the allowed data list, executes the query to obtain the latest status record, obtains the response message, and sends the response message back to the cloud AI manager through an encrypted channel; Step 6: Cloud Decision and Planning Stage: After receiving the response message, the cloud AI manager verifies the checksum and checks the matching of the request identifier, and calls the cloud digital twin update interface to perform differential update. The agent executes the decision algorithm based on the updated cloud digital twin, and calls the external service system through the model context protocol interface module to obtain environmental information or execute service reservations. It generates a task execution plan by combining internal status and external information. Step 7: Target State Synchronization and Execution Phase: The intelligent agent transforms the execution plan into the target state of the cloud-based digital twin. Changes in the digital twin trigger state synchronization events, which are then pushed to the vehicle-side AI manager via a publish-subscribe mechanism. The vehicle-side AI manager subscribes to target state update type events. Step 8: Vehicle-side Execution and Feedback Phase: The vehicle-side real-time control execution module receives events, parses the planned path, extracts the navigation path point sequence, and pushes a notification to the driver before the expected execution time. After the driver confirms, the real-time control execution module sends the path points to the in-vehicle navigation system and starts navigation guidance. During the journey, it continuously monitors key states. If the deviation from the planned route exceeds a threshold, or if real-time traffic conditions show congestion ahead or the battery level is below a safe threshold, the corresponding processing procedure is triggered. When a key milestone is reached, an execution feedback message is generated. The feedback message is transmitted back to the cloud AI manager through the data space. The cloud digital twin updates the corresponding data, the intelligent agent receives the completion notification, updates the task status, and records the execution effect data for strategy learning.

Images