Vehicle service calling method and device and electronic equipment

Abstract

The invention discloses a vehicle service calling method and device and electronic equipment, and relates to the technical field of communication, an equipment end system of the method comprises a model context protocol MCP routing component, and the MCP routing component manages a plurality of registered MCP service ends which provide different vehicle services. According to the method, an MCP service calling request is generated under the condition that a device end system or a cloud end system receives a user instruction. An MCP service calling request generated by the device end system is sent to an MCP routing component of the device end system through an MCP client of the device end system, or an MCP service calling request generated by the cloud end system is sent to an MCP routing component of the device end system through a cloud end MCP relay gateway; and the MCP service calling request is sent to an MCP server side corresponding to the equipment side system through the MCP service routing component. And finally, calling a service interface corresponding to the MCP service calling request through the MCP server to execute a corresponding service so as to realize calling of the vehicle service. Therefore, the embodiment of the invention realizes unified calling of the vehicle service.

Description

Technical Field

[0001] This application belongs to the fields of intelligent vehicle technology and edge artificial intelligence, and particularly relates to methods, devices and electronic devices for invoking vehicle services. Background Technology

[0002] Calling vehicle atomic services from the device side is the core link to realize intelligent interaction on the vehicle side. As users' demands for real-time response speed, personalized service adaptation capabilities and usage scenarios on the vehicle side continue to increase, the requirements for efficiency, compatibility and scenario adaptability of service calls are also increasing.

[0003] Existing methods for invoking vehicle services often rely on the Model Context Protocol (MCP) to enable AI agents to call atomic vehicle services. However, due to limitations in the protocol communication layer's support for certain protocols, the client-side can typically only deploy an MCP client to initiate service call requests, rather than deploying the corresponding MCP server. Consequently, the vehicle's native services will maintain their own heterogeneous server-side interfaces, making it impossible to achieve unified invocation of vehicle services through a deployed MCP client. Summary of the Invention

[0004] This application provides a method, apparatus, and electronic device for invoking vehicle services, in order to solve the problem that existing methods for invoking vehicle services cannot achieve unified invoking of vehicle services.

[0005] In a first aspect, embodiments of this application provide a method for invoking vehicle services, applied to a device-side system. The device-side system includes a Model Context Protocol (MCP) client, an MCP routing component, and an MCP server providing different vehicle services. The method includes: Upon receiving a user command from the in-vehicle intelligent terminal, an MCP service call request is generated; When the device-side system generates an MCP service call request or receives an MCP service call request from the cloud system, the MCP client sends the MCP service call request to the MCP routing component. Send an MCP service call request to the MCP server through the MCP service routing component; The service corresponding to the MCP service call request is executed by calling the service interface through the MCP server.

[0006] Secondly, embodiments of this application provide a method for invoking vehicle services, applied to a cloud system, the method comprising: Upon receiving a user instruction from an in-vehicle intelligent terminal or a cloud-based intelligent agent, an MCP service call request is generated; The cloud-based MCP relay gateway sends an MCP service call request to the MCP routing component, which then sends the MCP service call request to the MCP server. The MCP server then calls the service interface to execute the service corresponding to the MCP service call request.

[0007] Thirdly, embodiments of this application provide a vehicle service invocation apparatus, applied to a device-side system. The device-side system includes a Model Context Protocol (MCP) client, an MCP routing component, and an MCP server providing different vehicle services. The apparatus includes: The generation module is used to generate an MCP service call request upon receiving a user command from the in-vehicle intelligent terminal. The sending module is used to send an MCP service call request to the MCP routing component through the MCP client when the device-side system generates an MCP service call request or receives an MCP service call request sent by the cloud system. The sending module is also used to send MCP service call requests to the MCP server through the MCP service routing component; The execution module is used to execute the service corresponding to the MCP service call request by calling the service interface through the MCP server.

[0008] Fourthly, embodiments of this application provide a vehicle service invocation device applied to a cloud system, the device comprising: The generation module is used to generate an MCP service call request upon receiving a user instruction from an in-vehicle intelligent terminal or a cloud-based intelligent agent. The sending module is used to send MCP service call requests to the MCP routing component through the cloud MCP relay gateway. This allows the MCP routing component to send MCP service call requests to the MCP server and execute the service corresponding to the MCP service call request through the service interface called by the MCP server.

[0009] Fifthly, embodiments of this application provide an electronic device, the device comprising: a processor and a memory storing computer program instructions; the processor executing the computer program instructions to implement a method for invoking vehicle services as described in the first or second aspect.

[0010] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the method for invoking vehicle services in the first or second aspect.

[0011] In a seventh aspect, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a method for invoking vehicle services in the first or second aspect.

[0012] This application provides a method, apparatus, and electronic device for invoking vehicle services. The device-side system includes a Model Context Protocol (MCP) routing component, which manages multiple registered MCP servers providing different vehicle services. The MCP routing component enables centralized registration and management of vehicle services, and registering MCP servers with it ensures a unified interface specification for all services. Upon receiving a user instruction, the device-side system or cloud system generates an MCP service invocation request, ensuring that different types of vehicle services have the same invocation format. The device-side system's MCP client sends the generated MCP service invocation request, or the cloud-side MCP relay gateway sends it to the device-side system's MCP routing component. The MCP service invocation request is then sent to the corresponding MCP server on the device-side system via the routing component. Using the MCP client as a unified entry point eliminates the need for the edge AI agent to directly interface with the underlying interfaces of various vehicle services. Furthermore, the MCP routing component optimizes the edge service invocation process and improves efficiency. Finally, the MCP server invokes the service interface corresponding to the MCP service invocation request to execute the corresponding service, thus realizing the vehicle service invocation. Therefore, the embodiments of this application realize the unified invocation of vehicle services. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a schematic diagram of the vehicle service invocation system provided in an embodiment of this application; Figure 2 This is an MCP architecture diagram of the device-side system provided in the embodiments of this application; Figure 3 This is a routing and relay architecture diagram of the cloud system provided in the embodiments of this application. Figure 4 This is a schematic diagram illustrating the interaction between the MCP routing component and the cloud-based MCP relay gateway provided in this application embodiment; Figure 5 This is a flowchart illustrating a method for invoking vehicle services provided in an embodiment of this application; Figure 6 This is a schematic diagram of an MCP server registration process provided in an embodiment of this application; Figure 7 This is a schematic diagram of the device for invoking vehicle services in a device-side system provided in an embodiment of this application; Figure 8 This is a schematic diagram of the device for invoking vehicle services in a cloud system provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0016] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0017] In related technologies, vehicle service invocation methods often rely on the Model Context Protocol (MCP) to enable AI agents to call vehicle atomic services. However, due to limitations in the protocol communication layer's support for certain protocols, the edge device can typically only deploy an MCP client to initiate service call requests, rather than deploying the corresponding MCP server. Specifically, the edge device lacks an access interface: it lacks a unified interface for accessing vehicle atomic services through an MCP client, resulting in a cumbersome and inefficient invocation process, making it difficult to achieve convenient invocation of vehicle atomic services by the edge device. Secondly, the existing protocol of the MCP server does not meet the deployment requirements of edge mobile intelligence, preventing the cloud system's AI agent from accessing vehicle atomic services through a standard MCP client, thus limiting the cloud system's intelligent control over the vehicle. Furthermore, the MCP protocol lacks definition regarding cloud systems' access to mobile atomic capabilities. Finally, the traditional service-oriented architecture (SOA) solution for cloud systems to access vehicle-side atomic capabilities suffers from inconsistent interfaces due to varying implementations across different vendors. This leads to difficulties in accessing cloud systems across platforms and brands, and the solution cannot provide access to existing large-scale models, thus hindering the expansion of intelligent applications. Therefore, the vehicle's native services will maintain their own heterogeneous server-side interfaces, making it impossible to achieve unified invocation of vehicle services through the deployed MCP client.

[0018] To address the problems of existing technologies, this application discloses a method, apparatus, and electronic device for invoking vehicle services. The device-side system of this method includes a Model Context Protocol (MCP) routing component, which manages multiple registered MCP servers providing different vehicle services. The MCP routing component enables centralized registration and management of vehicle services, and the registration of MCP servers with the MCP routing component ensures that vehicle services have a unified interface specification. When the device-side system or cloud system receives a user instruction, the method generates an MCP service invocation request, ensuring that the invocation format is the same for different types of vehicle services. The MCP service invocation request generated by the device-side system is sent to the MCP routing component of the device-side system via the MCP client, or via the cloud-based MCP relay gateway. The MCP service invocation request is then sent to the corresponding MCP server in the device-side system through the MCP service routing component. Using the MCP client as a unified sending entry point eliminates the need for the edge-side AI agent to directly interface with the underlying interfaces of various vehicle services. Furthermore, the distribution of invocation requests through the MCP routing component optimizes the edge-side service invocation process and improves invocation efficiency. Finally, the corresponding service is executed by calling the service interface corresponding to the MCP service call request through the MCP server, thus realizing the invocation of vehicle services. Therefore, this embodiment of the application realizes the unified invocation of vehicle services.

[0019] The embodiments of this application can be applied to various application scenarios such as edge AI Agent control, cloud AI control, cross-platform calling, large model docking, intelligent driving assistance, car sharing operation, and vehicle status detection.

[0020] The following section first introduces a system for invoking vehicle services provided in an embodiment of this application.

[0021] Figure 1 A schematic diagram of the structure of a vehicle service invocation system 100 according to an embodiment of this application is shown. Figure 1 As shown, the system may include a device-side system 101 and a cloud system 102. The device-side system 101 may include an MCP client 1011, an MCP routing component 1012, and an MCP server 1013. The cloud system 102 includes a cloud MCP relay gateway 1021 and an MCP client 1022.

[0022] The MCP client 1011 initiates MCP service call requests internally on the device side, receives service requests from end-side applications, generates service call requests conforming to the MCP protocol specification, and serves as the interface carrier for end-side applications to call vehicle services. The MCP routing component 1012 receives MCP service call requests from the MCP client 1011 or the cloud-based MCP relay gateway 1021. The MCP server 1013 receives the MCP service call requests forwarded by the MCP routing component 1012, parses the service name and parameters in the request, and calls the vehicle's hardware interface or software service to execute the corresponding atomic service. The cloud-based MCP relay gateway 1021 receives cloud-based MCP service call requests from the MCP client 1022, converts them into a device-compatible communication protocol, and forwards the converted MCP service call requests to the vehicle's MCP routing component 1012. The MCP client 1022 receives service requests from cloud applications, generates remote service call requests conforming to the MCP protocol specification, and sends the generated MCP request to the cloud-based MCP relay gateway 1021, triggering the remote service call process.

[0023] Specifically, the MCP architecture diagram of device-side system 101 is as follows: Figure 2As shown, the system comprises an intelligent agent service layer (AgentService) 201, an AI SDK interface layer (AI SDK Interface) 202, an intelligent agent basic service layer (Agent Basic Service) 203, an AI basic service layer (AI Basic Service) 204, and a model service layer (ModelService) 205. The intelligent agent service layer 201 receives user instructions, generates intelligent decisions, and initiates service calls; it may include a system intelligent agent (SystemAgent) 2011 and a business agent 2012. The AI ​​SDK interface layer 202 provides standardized interfaces for agents to call underlying capabilities; it may include a data perception interface 2021, an MCP routing interface (MCProuter) 2022, a large model call interface 2023, a memory management interface 2024, and an MCP extbuilder interface (MCP extbuilder) 2025. The intelligent agent basic service layer 203 is responsible for the actual execution of environmental perception and vehicle services; it may include a perception service (PerceptionService) 2031 and an action service (ActionService) 2032. The AI ​​infrastructure service layer 204 provides memory data, model management, and multimodal interaction capabilities to the upper layers, and may include Long Short-Term Memory service 2041, AI Play service 2042, and ModelCoreService 2043. The model service layer 205 provides inference capabilities for small models and large language models, and may include Small Model Inference Service 2051 and Large Language Model Inference Service 2052.

[0024] Specifically, the routing and relay architecture diagram of cloud system 102 is as follows: Figure 3As shown, it may include an end-side runtime manager 301, a cloud-based MCP relay gateway 302, and a cloud-based MCP client 303. The end-side runtime manager (AI Runtime) 301 may include an intelligent agent 3011, an MCP client 3012, an executor SDK 3013, a memory SDK 3014, an MCP ext builder SDK 3015, an MCP router service 3016, an MCP router 3017, an MCP protocol dispatcher 3018, an executor MCP server 3019, and a memory MCP server 3020. The cloud-based MCP relay gateway 302 includes an HTTP-based MCP routing component (MCProuter over HTTP) 3021, an MCP protocol converter 3022, and an MCP protocol dispatcher 3023. The cloud-based MCP client 303 includes an HTTP-based MCP client 3031.

[0025] In some embodiments, the interaction diagram between the MCP routing component 1012 of the device-side system and the cloud-based MCP relay gateway 1021 is as follows: Figure 4 As shown, each end-side device 401 can run multiple MCP servers 402. The multiple MCP servers 402 of the multiple end-side devices 401 can be connected to the cloud MCP relay gateway 404 through the MCP routing component 403, and can interact with the cloud clients 405 of multiple cloud devices through the cloud MCP relay gateway 404.

[0026] The method for invoking vehicle services provided in the embodiments of this application is described below.

[0027] Figure 5 A flowchart illustrating a method for invoking vehicle services according to an embodiment of this application is shown. Figure 5 As shown, the method may include the following steps: S501 to S504.

[0028] S501 generates an MCP service call request when the device-side system receives a user command sent by the vehicle-mounted intelligent terminal.

[0029] Among them, the device-side system is the core operating system on the terminal side, mainly Android devices; the in-vehicle intelligent terminal is the in-vehicle device used to receive user interaction commands; and the MCP service call request is a service call request that follows the MCP protocol specification.

[0030] In some embodiments, user instructions can be classified into various types such as voice instructions, text instructions, and touch instructions. After receiving the user instructions transmitted by the in-vehicle smart terminal, the device system will convert the user instructions into service call requests that conform to the MCP protocol specification.

[0031] This application's embodiments convert diverse user commands into standardized MCP requests, providing a unified format for subsequent interactions between the MCP routing component and the MCP server, avoiding adaptation errors caused by heterogeneous command formats. Furthermore, it directly provides a compliant format for subsequent processes, thereby ensuring the integrity of the vehicle service call process.

[0032] In some embodiments, after receiving a user command from the in-vehicle smart terminal, the device system determines whether the vehicle service corresponding to the user command exists. If the corresponding vehicle service does not exist, an error message is generated and returned to the in-vehicle smart terminal.

[0033] This application embodiment determines the validity of the user command by judging whether the vehicle service corresponding to the user command exists, thus avoiding invalid MCP service call requests from entering subsequent processes and wasting resources, thereby improving the overall efficiency of service calls.

[0034] S502, the device-side system sends an MCP service call request to the MCP routing component through the MCP client.

[0035] Among them, the MCP client is a client component that follows the MCP protocol and is deployed on the device system. It is used to pass standardized MCP service call requests to the MCP routing component. The MCP routing component is the core component of the MCP protocol deployed on the device system. It is responsible for collecting and managing all MCP server information on the device side, receiving requests from the MCP client or the relay gateway in the cloud system, and forwarding them.

[0036] In some embodiments, after generating an MCP service call request, the device-side system sends the standardized MCP service call request to the MCP routing component through its integrated MCP client, so that the MCP service call request can be sent to the MCP server.

[0037] This embodiment of the application sends MCP service call requests through an MCP client, ensuring that requests entering the MCP routing component conform to the MCP protocol specifications and avoiding the MCP routing component's inability to recognize non-standard requests. Furthermore, by using the MCP client as an intermediary and establishing a fixed transmission path from the MCP client to the MCP routing component, it avoids link chaos caused by directly sending service call requests.

[0038] S503: When the cloud system receives a user command from the vehicle-mounted intelligent terminal or the cloud-based intelligent agent, it generates an MCP service call request.

[0039] The cloud system is a remote service system that includes an MCP relay gateway. It is responsible for receiving user commands from the in-vehicle intelligent terminal or the cloud intelligent agent in the cloud system and generating MCP service call requests. The in-vehicle intelligent agent is an instruction processing device deployed on the vehicle. It can receive user commands or generate user commands based on vehicle data. The cloud intelligent agent is an intelligent agent in the cloud. It can remotely receive user commands or automatically generate user commands based on vehicle data.

[0040] In some embodiments, in addition to receiving user commands sent by in-vehicle intelligent terminals and cloud intelligent agents, the cloud system can also receive commands from other intelligent agents such as third-party ecosystem intelligent agents and vehicle network intelligent agents.

[0041] In some embodiments, when a user sends a remote control user command to the cloud system via an in-vehicle smart terminal or a cloud-based smart agent, the cloud system, upon receiving the user command, generates a corresponding MCP service call request according to the MCP protocol specification through the cloud system's MCP client, and sends the generated MCP service call request to the cloud system's cloud MCP relay gateway through the MCP relay gateway, so that the cloud system can send the MCP service call request to the MCP route through the cloud MCP relay gateway.

[0042] This application's embodiments support remote control of vehicle services by a cloud system, overcoming the limitations of local calls from the client side. Furthermore, the cloud system generates MCP service call requests in the same format as the client side, avoiding call failures caused by differences in client-cloud protocols.

[0043] In some embodiments, after receiving a remote control user command sent by the in-vehicle intelligent terminal, the cloud system determines whether the vehicle service corresponding to the user command exists and the user's and vehicle's permission status. If the vehicle service corresponding to the user command exists and the user has the corresponding vehicle's operating permissions, the system generates an MCP service call request.

[0044] This application embodiment determines the validity of the user command by checking if the corresponding vehicle service exists, thus preventing invalid MCP service call requests from entering subsequent processes and wasting resources. Furthermore, it checks the user's operating permissions for the vehicle to prevent unauthorized remote operation, improving the security of remote control.

[0045] S504, the cloud system sends an MCP service call request to the MCP routing component through the cloud MCP relay gateway.

[0046] The cloud-based MCP relay gateway serves as the communication device between the cloud system and the end-side MCP routing components. It supports the MCP protocol (MCP over WebSocket) based on a bidirectional communication protocol. This allows it to convert MCP service call requests generated by the cloud system, such as those in the MCP protocol (MCP over HTTP) format, into the end-side compatible MCP over WebSocket format, handling remote request forwarding and protocol adaptation. The WebSocket-based MCP communication method supports long-lived connections, ensuring the real-time performance and stability of command and data interaction between the cloud system and the end-side.

[0047] In some embodiments, the cloud system sends the generated MCP service call request to the cloud MCP relay gateway. The cloud system relay gateway completes the protocol conversion and sends the MCP service call request to the MCP routing component on the end side through a long connection.

[0048] This application embodiment uses the protocol conversion of the cloud system's protocol format to convert it into the protocol format required by the end side through the cloud MCP relay gateway, thus solving the compatibility problem between the cloud system and the end side protocol. Furthermore, it establishes a long WebSocket connection through the cloud MCP relay gateway, avoiding frequent connection establishment and ensuring that remote requests can be sent to the end side quickly.

[0049] In some embodiments, after the cloud-based MCP relay gateway sends a request to the end-side MCP routing component, if it does not receive a request acceptance confirmation from the end-side within a preset time, it automatically caches the request and triggers a retransmission; if the retransmission fails after a preset number of times, it reports the end-side offline information to the cloud system.

[0050] This application embodiment avoids the loss of remote requests due to network fluctuations, ensuring the stability of cross-platform calls.

[0051] S505, the device-side system sends an MCP service call request to the MCP server through the MCP service routing component.

[0052] Among them, the MCP server is the service provider that follows the MCP protocol.

[0053] In some embodiments, after receiving an MCP service call request from an MCP client on the receiving end or an MCP relay gateway in the cloud, the MCP routing component parses the service information in the MCP service call request, queries the locally stored MCP server registration information, finds a matching target MCP server, and forwards the MCP service call request to that server.

[0054] This application embodiment matches the target MCP server based on the service information in the service call request, avoiding the problem of incorrect request sending. Furthermore, by using the MCP routing component as a unified distribution hub, multiple MCP servers do not need to be directly connected to by the MCP client or cloud system, reducing the links of direct interaction between components and reducing the complexity of the end-side system.

[0055] In some embodiments, when the MCP routing component receives multiple requests, it prioritizes them according to the service type corresponding to the requests. For example, safety-related requests such as "emergency unlocking of car doors" and "opening windows after a collision" are marked as "high priority," while non-critical requests such as "adjusting music volume" and "playing navigation voice" are marked as "normal priority." The routing component prioritizes forwarding high-priority requests and then processes normal-priority requests.

[0056] In scenarios with multiple concurrent requests, this application embodiment prioritizes responding to high-priority requests to ensure the response speed of critical services.

[0057] S506, the device-side system executes the service corresponding to the MCP service call request by calling the service interface through the MCP server.

[0058] Among them, the service interface is the interface connecting the MCP server and the vehicle hardware system, which is used to convert MCP service call requests into hardware operation instructions; the service corresponding to the MCP service call request is the vehicle atomic service, that is, the basic and independent functional service that the vehicle has.

[0059] In some embodiments, after receiving a request forwarded by the MCP routing component, the MCP server calls its own encapsulated service interface to convert the MCP service call request into an operation instruction that can be recognized by the vehicle hardware system, thereby triggering the execution of the corresponding vehicle atomic service.

[0060] In this embodiment, the MCP server encapsulates hardware operations through a service interface, thereby achieving interface adaptation for vehicle services.

[0061] The MCP routing component in this embodiment enables centralized registration and management of vehicle services. Simultaneously, the registration of MCP servers with the MCP routing component ensures that vehicle services share a unified interface specification. When the device-side system or cloud system receives a user instruction, it generates an MCP service call request, ensuring that different types of vehicle services have the same call format. The device-side system's MCP client sends the MCP service call request generated by the device-side system, or the cloud-side MCP relay gateway sends the MCP service call request generated by the cloud system to the device-side system's MCP routing component. The MCP service routing component then sends the MCP service call request to the corresponding MCP server on the device-side system. Using the MCP client as a unified sending entry point eliminates the need for the edge-side AI agent to directly interface with the underlying interfaces of various vehicle services. Furthermore, the distribution of call requests through the MCP routing component optimizes the edge-side service call process and improves call efficiency. Finally, the MCP server calls the service interface corresponding to the MCP service call request to execute the corresponding service, thus realizing the vehicle service call. Therefore, this embodiment achieves unified vehicle service invocation.

[0062] In some embodiments, such as Figure 6 As shown, the device-side system also includes an MCP builder interface. Before generating an MCP service call request upon receiving a user instruction, the method may also include S601 and S602.

[0063] S601 encapsulates the vehicle's services into MCP services through the MCP builder interface to obtain the MCP server.

[0064] The MCP Builder interface is an interface component deployed on the device-side system. It can be used as an extension builder interface for MCP, encapsulating vehicle native services according to the MCP protocol specification to generate services that conform to the MCP protocol and their corresponding MCP servers. MCP services are standardized services that conform to the MCP protocol specification after being encapsulated by the MCP Builder interface.

[0065] In some embodiments, the device-side system first reads the functional logic of the vehicle's native service through its integrated MCP builder interface, and then encapsulates it in a standardized manner according to the MCP protocol specification, defining a unified service name, service description, parameter format and interface call rules, and finally generating an MCP service with MCP protocol compatibility, as well as an MCP server that carries the service.

[0066] This application encapsulates the native vehicle services of different brands and types with varying interface formats into a unified MCP protocol service, avoiding the difficulties in call adaptation caused by inconsistent native service interfaces. Furthermore, by adapting only the MCP protocol, vehicle functions can be called through the MCP server, eliminating the need to individually adapt the interfaces of each vehicle's native service, thus reducing development and maintenance costs.

[0067] S602, register the MCP server with the MCP routing component so that the MCP routing component can call the MCP server based on the registration information of the MCP server.

[0068] The registration process involves the MCP server transmitting its key information to the MCP routing component, which then stores and maintains this information. Registration information is the core data passed to the routing component during MCP server registration, and may include service name, service version, parameter list, service description, service status, and call address.

[0069] In some embodiments, after obtaining the MCP server through the MCP builder interface, the MCP server initiates a registration request to the MCP routing component of the device system, passing its registration information to the MCP routing component. The MCP routing component receives and verifies the legality of the registration information. If the verification is successful, it stores the information in the local MCP server registry, completing the registration. When the MCP routing component receives an MCP service call request, it can find a matching MCP server by querying the registration information in the registry and initiate the call.

[0070] In this embodiment, the MCP routing component uses registration information to detect all available MCP servers on the client side, preventing requests from being undeliverable due to the routing component being unaware of the server's existence. Matching MCP servers through registration information ensures that requests are not misdelivered or missed, improving call accuracy. Furthermore, when an MCP server is added or removed, only the routing component's registry needs to be updated; the core logic of the routing component does not need to be modified, improving system scalability.

[0071] In some embodiments, when the device-side system receives a user instruction, it generates an MCP service call request, which may include: User commands are input into a pre-trained function call model. The model then extracts features from the command information to obtain sub-command information. This pre-trained model, based on a vehicle service scenario, possesses capabilities for command intent recognition, feature extraction, and structured decomposition. It can be used to break down natural language or non-standardized command information into explicit sub-command information that matches vehicle services. The sub-command information consists of command units obtained after feature extraction, which are matched with the vehicle's atomic services.

[0072] The corresponding vehicle service is determined based on the sub-instruction information, and the corresponding MCP service call request is generated.

[0073] This application's embodiments address the ambiguity or unstructured form of natural language user commands. The model clarifies core requirements through feature extraction, avoiding subsequent service matching errors caused by ambiguous commands. Furthermore, the command information is decomposed into sub-command information corresponding to the vehicle's atomic services, facilitating subsequent matching with vehicle services.

[0074] In some embodiments, after the device-side system obtains the generated sub-instruction information, it first finds the vehicle service corresponding to the sub-instruction through the service type matching table; then it reads the predefined MCP protocol format of the vehicle service and generates a complete MCP service call request that conforms to the MCP specification based on the sub-instruction information.

[0075] In some embodiments, the device-side system encapsulates the vehicle's vehicle services into MCP services through the MCP builder interface to obtain an MCP server, including: The vehicle's services are encapsulated into an MCP service based on the bidirectional communication protocol WebSocket through the MCP builder interface, resulting in a WebSocket-based MCP server.

[0076] In some embodiments, the method further includes: The MCP routing component, based on the bidirectional communication protocol WebSocket, establishes a connection with the cloud-based MCP relay gateway and sends the registration information of the MCP server to the cloud-based MCP relay gateway, so that the cloud-based MCP relay gateway can generate an MCP service call request based on the registration information.

[0077] Among them, the bidirectional communication protocol WebSocket is a long-connection communication protocol that supports bidirectional simultaneous communication. It is the core transport layer of MCPover WebSocket, which can ensure the real-time performance and stability of command and data interaction between the cloud system and the client side, and avoid the delay of frequent connection establishment.

[0078] In some embodiments, before deploying the MCP server, the device-side system first calls its integrated MCP builder interface. This interface reads the functional logic of the vehicle's native services and forms a basic MCP service framework according to the MCP protocol specification. Furthermore, the interface embeds a WebSocket protocol module within the basic MCP service framework, configuring long-connection parameters to ensure that both MCP service request reception and result feedback can be transmitted via the WebSocket protocol. Finally, it encapsulates a WebSocket-based MCP service that possesses both MCP protocol standardization capabilities and WebSocket bidirectional communication capabilities, along with a WebSocket-based MCP server that carries this service.

[0079] This application's embodiments address the shortcomings of the MCP protocol's communication layer by encapsulating and integrating WebSocket, enabling the client-side MCP server to communicate with external components. Furthermore, WebSocket's persistent connection and bidirectional communication features avoid the latency associated with frequent connection establishment in traditional short-connection systems. All vehicle services, after encapsulation, use WebSocket as the communication layer, preventing interaction confusion caused by different services using different communication protocols.

[0080] In some embodiments, the device-side system sends an MCP service call request to the corresponding MCP server through the MCP service routing component, which may include: The MCP routing component performs security authentication on MCP service call requests; the security authentication process is the process of determining whether an MCP service call request is allowed to enter the subsequent forwarding process.

[0081] Once security authentication is successful, the MCP service call request is sent to the corresponding MCP server on the device system via the MCP service routing component.

[0082] This application embodiment improves the security of vehicle service calls by performing security authentication on MCP service call requests, filtering illegal requests in advance, and preventing unauthorized entities from calling critical vehicle services.

[0083] In some embodiments, security authentication may include verifying the legitimacy of the request source, the matching of invocation permissions, and the compliance of request parameters. Specifically, request source legitimacy authentication can extract the source identifier from the request and query a locally preset list of trusted sources to determine whether the request comes from a legitimate entity. Invocation permission matching authentication can verify whether the legitimate source entity has the permissions corresponding to the service name in the request. Request parameter compliance authentication can check whether the request parameters comply with the constraint rules of the vehicle service. If all three types of security authentication pass, the security authentication is deemed successful; otherwise, the authentication is deemed to have failed and an authentication failure message is returned.

[0084] In some embodiments, vehicle services include execution services and long short-term memory services.

[0085] The execution service is a functional service that directly interfaces with vehicle hardware and performs physical operations. It is responsible for converting MCP service call requests into actual hardware operations for vehicle atomic services, such as window control and air conditioning adjustment. The long short-term memory service is a data carrier responsible for storing and retrieving user behavior data and contextual information, such as air conditioning temperature preferences and frequently used navigation destinations.

[0086] The vehicle service in this application includes an execution service and a long short-term memory service. The execution service directly interfaces with the hardware to ensure that MCP service call requests can be transformed into actual physical operations. The long short-term memory service, after being encapsulated by MCP, can provide user habit data, enabling the generation of service call instructions that fit user needs, thus solving the problem of rigid vehicle call services.

[0087] In some embodiments, when the cloud system receives a user command sent by the in-vehicle smart terminal, it generates an MCP service call request, which may include: The user's instruction information is input into a pre-trained function call model. The function call model extracts features from the instruction information to obtain sub-instruction information. The corresponding vehicle service is determined based on the sub-instruction information, and the corresponding MCP service call request is generated.

[0088] In some embodiments, after receiving user instructions from the in-vehicle intelligent terminal, the cloud system first performs instruction structuring processing to convert non-standardized user instructions into structured instruction information. Then, this instruction information is input into a pre-trained function call model. Based on pre-trained vehicle service scenario logic, the model extracts key features from the instruction information, identifies and separates sub-instruction information that is formatted correctly and clearly defined. After generating the sub-instruction information, the cloud system uses the vehicle service registration information pre-set by the cloud system to find the matching end-side vehicle service and its corresponding MCP server. Then, it reads the MCP protocol specification corresponding to the vehicle service and generates an MCP service call request from the sub-instruction.

[0089] When generating an MCP service call request, the cloud system in this application generates the MCP service call request through the same structure and process as the client side. After the protocol conversion by the cloud MCP relay gateway, it can be directly received and forwarded by the client-side MCP routing component, avoiding call failure due to protocol compatibility issues.

[0090] In some embodiments, the present application can be applied to intelligent cockpit middleware. This solution can solve the problems of high cost and low efficiency caused by the need for traditional cockpit-side intelligent agents to adapt to different hardware vendors' service interface APIs and software development kits (SDKs) one by one when calling cockpit atomic capabilities such as air conditioning control, seat adjustment, and ambient lighting switching, as well as the difficulty of achieving end-to-cloud collaboration in cloud-based intelligent agents. Specifically, the present application can enhance the cloud-based agent's understanding of and invocation of cockpit atomic capabilities, thereby enhancing the AI's end-to-cloud integration capabilities in the cockpit; it can support end-side agents to call on-vehicle atomic capabilities using the MCP protocol, eliminating the need for individual API and SDK adaptations and enabling rapid access to the cockpit system. Embodiments of the vehicle control method in specific scenarios are shown below.

[0091] In one example, taking the edge AI Agent control scenario as an example, consider opening a car window. The user, inside the car, issues a voice command to the edge intelligent agent (such as the in-vehicle intelligent assistant): "Open the driver's side window." The edge intelligent agent parses the command using Automatic Speech Recognition (ASR), understands the user's need to control the driver's side window to open, determines the target service as the window control service, and generates a service call command. The edge AI Agent calls the MCP client, encapsulating the command to open the driver's side window into a service call request conforming to the MCP protocol. The edge MCP routing component receives the MCP service call request sent by the MCP client and performs security authentication. If authentication is successful, the MCP routing component queries the local server registration list, finds the corresponding window control MCP server, and forwards the service call request to that window control MCP server. Upon receiving the request forwarded by the MCP routing component, the window control MCP server extracts the service name and parameters to confirm the need to open the driver's side window, and sends an opening command to the driver's side window motor via the vehicle hardware communication protocol.

[0092] In one example, taking a cloud-based AI control scenario, automatic vehicle temperature regulation is achieved through cloud-based AI. Vehicle sensors transmit real-time interior temperature data to the cloud AI via a long-lived connection between the end-side MCP routing component and the cloud MCP relay gateway using the MCPover WebSocket protocol. The cloud AI analyzes the received temperature data and, when it determines that the interior temperature is higher than a user-preset suitable threshold, generates a control command to "lower the air conditioning temperature." Subsequently, the cloud AI, through its integrated standard MCP client, encapsulates this control command into an MCP service call request according to the MCP protocol and sends it to the cloud MCP relay gateway. Upon receiving the request, the cloud MCP relay gateway, based on the unique vehicle identifier (such as device ID) carried in the request, locates the corresponding target vehicle in the list of registered vehicle devices and then converts the original HTTP-based MCP request into an MCPover request supported by the end-side MCP over protocol. The request is then converted using the WebSocket protocol and forwarded to the vehicle's on-device MCP routing component. Upon receiving the request, the on-device MCP routing component queries the local MCP server registry to find the on-device MCP server responsible for air conditioning control and forwards the request to that MCP server. The on-device MCP server parses the temperature adjustment parameters in the request, calls the vehicle's air conditioning control hardware interface to perform the temperature adjustment operation, and then feeds back the execution result to the cloud AI after the operation is completed, thus realizing remote control of the air conditioning temperature.

[0093] In one example, taking a cross-platform call scenario, the vehicle is unlocked via an application. After the user initiates a request to "unlock the vehicle" in the application (APP), the platform's cloud system first verifies the user information and vehicle binding relationship. Once confirmed, it encapsulates the "unlock vehicle" request into a standardized MCP service call request using its integrated standard MCP client, according to the MCP protocol. This request is then sent to the cloud-based MCP relay gateway of this invention. Because the cloud-based MCP relay gateway provides a unified MCP interface, it is compatible with the protocol differences of vehicles from different brands and platforms. Therefore, upon receiving the request, the gateway does not need additional adaptation for a specific vehicle brand. It directly locates the corresponding end-side MCP routing component based on the target vehicle device ID carried in the request and converts the MCP service call request into an MCP service call. The request is forwarded to the on-device MCP routing component after being formatted using the overWebSocket protocol. Upon receiving the request, the on-device MCP routing component performs security authentication (such as verifying whether the third-party platform has the authorization to unlock the vehicle). After successful authentication, it queries the local MCP server list, finds the MCP server responsible for unlocking the vehicle, and forwards the request. The on-device MCP server calls the vehicle door lock control interface to perform the unlocking operation. After the operation is completed, the result is fed back to the cloud system of the third-party travel platform through the relay gateway. The system then pushes the "vehicle unlocked" information to the user's APP, realizing unified access across vehicle brands.

[0094] In one example, taking a large-scale model integration scenario, a user sends a command containing a travel plan (e.g., "Leave home for work at 8:00 AM tomorrow, prepare the car interior environment in advance") to the large-scale model (such as an intelligent mobility large-scale model) of the integration system via a terminal device. The large-scale model first parses the travel plan, extracting key information such as "departure time 8:00 AM" and "destination company," and combines it with the user's historical preferences (e.g., the usual car interior temperature is 25°C) to generate a vehicle control request to "start the air conditioning in advance and adjust it to 25°C." Subsequently, the large-scale model, through its integrated MCP client, encapsulates this request into an MCP service call request according to the MCP protocol and sends it to the cloud-based MCP relay gateway of this invention. After receiving the request, the cloud-based MCP relay gateway finds the corresponding vehicle-side MCP routing component based on the user vehicle device information associated in the request and converts the request into an MCP. After being forwarded in the overWebSocket protocol format, the request is received by the on-side MCP routing component. The component first verifies the validity of the request time (e.g., confirming that the current time is close to 8 o'clock) and its legality. If the verification is successful, the component queries the local MCP server responsible for air conditioning control and forwards the request to that MCP server. The on-side MCP server parses the request and calls the vehicle air conditioning system interface to start the air conditioning and adjust the temperature to 25°C. At the same time, the execution result of "air conditioning has been started and adjusted to the target temperature" is fed back to the big model along the original link. The big model then informs the user that the vehicle is ready through the terminal device.

[0095] In one example, taking the intelligent assisted driving scenario as an example, the solution of this application achieves driving safety assurance under complex road conditions through an end-cloud collaborative architecture of cloud-based global decision-making, standardized communication using the MCP protocol, and real-time execution by the end-side hardware. Specifically, the vehicle's sensors continuously collect and upload real-time driving data and surrounding environment perception data to the cloud system via the cloud-based MCP relay gateway through the end-side MCP routing component. Based on this multi-dimensional data and combined with real-time road condition information from a high-precision map, the cloud system automatically generates intelligent driving assistance decisions and encapsulates these decisions into service call requests conforming to the MCP protocol specification through an MCP client deployed in the cloud. This request is first sent to the cloud-based MCP relay gateway, which performs protocol conversion on the request, converting the commonly used cloud-based MCP over HTTP format to the end-side supported MCP over WebSocket format to ensure real-time bidirectional communication. Based on the unique vehicle identifier carried in the request, the gateway locates the end-side MCP routing component of the target vehicle in a preset routing data mapping table and forwards the converted request to that end-side MCP routing component. Upon receiving a request, the edge-side MCP routing component immediately performs security authentication. Once authentication is successful, it queries the locally registered server information based on the service name in the request and forwards the request to the edge-side MCP server responsible for executing the intelligent driving assistance atomic services. This edge-side MCP server parses the request parameters, performs the corresponding adjustments, and transmits the execution result back to the cloud system via the cloud-based MCP relay gateway through the edge-side MCP routing component, forming a complete closed loop. This enables real-time adjustments to the vehicle's driving status under complex road conditions, ensuring driving safety.

[0096] In one example, consider a car-sharing operation scenario. After a user completes a vehicle reservation on the car-sharing platform's app, the platform's cloud system obtains information such as the reserved vehicle's identifier and the reserved time slot. When the user arrives near the vehicle and clicks "Unlock Vehicle" on the app, the platform's cloud system, through its integrated MCP client, encapsulates the "remote vehicle unlocking" request into an MCP service call request according to the MCP protocol and sends it to the cloud-based MCP relay gateway of this invention. Upon receiving the request, the cloud-based MCP relay gateway queries the list of registered vehicles based on the vehicle identifier in the request. After confirming that the target vehicle is online, it converts the MCP request into an MCP overlay. The request is forwarded to the vehicle's on-device MCP routing component using the WebSocket protocol. Upon receiving the request, the on-device MCP routing component first verifies the operating platform's calling permissions (e.g., confirming that the platform has remote control authorization for the vehicle) and the timeliness of the request (e.g., confirming that it is within the scheduled time period). After successful verification, it queries the local MCP server responsible for unlocking the vehicle and forwards the request. The on-device MCP server then calls the vehicle's door lock control interface to perform the unlocking operation. After the operation is completed, the execution result of "vehicle unlocked" is fed back to the operating platform's cloud system through the cloud MCP relay gateway. The system then pushes the unlocking success information to the user's APP, and also synchronizes basic information such as the vehicle's current location and battery level to the user, facilitating a smooth ride for the user.

[0097] In one example, consider a vehicle status detection scenario. Vehicle sensors collect real-time data on battery level, engine status, fuel level (or remaining range), etc. This data is continuously uploaded to the cloud AI via the cloud MCP relay gateway through the on-device MCP routing component according to the MCPover WebSocket protocol. The cloud AI monitors and analyzes the uploaded vehicle status data in real time. When it detects that the vehicle's battery level is below a preset low-battery threshold (e.g., less than 20% remaining), it calls the map service to query available charging stations near the vehicle's current location. After confirming the presence of a nearby charging station, the cloud AI generates a command to "remotely control the vehicle to navigate to the XX charging station." It then encapsulates this command into an MCP service call request through its own MCP client and sends it to the cloud MCP relay gateway. Upon receiving the request, the cloud MCP relay gateway locates the corresponding on-device MCP routing component based on the vehicle's device ID and converts the request into an MCP overlay. After being forwarded in WebSocket protocol format, the request is received by the on-device MCP routing component. The component verifies the validity of the instruction (e.g., confirming the accuracy of the charging pile information and that the vehicle is currently parked). If the verification is successful, the component queries the local MCP server responsible for navigation services and forwards the request. The on-device MCP server parses the charging pile location information in the request, calls the vehicle navigation system interface, sets the charging pile as the destination, and starts the navigation function. At the same time, the execution result "Navigation started, destination is XX charging pile" is fed back to the cloud AI along the original link. The cloud AI then pushes this information to the user's mobile APP to remind the user that the vehicle has started charging pile navigation.

[0098] Figure 7 This application illustrates a vehicle service invocation apparatus 700 provided in an embodiment of the present application. The apparatus is applied to a device-side system, which includes a Model Context Protocol (MCP) client, an MCP routing component, and an MCP server providing different vehicle services. The apparatus may include: The generation module 701 is used to generate an MCP service call request upon receiving a user instruction sent by the vehicle-mounted intelligent terminal. The sending module 702 is used to send an MCP service call request to the MCP routing component through the MCP client when the device-side system generates an MCP service call request or receives an MCP service call request sent by the cloud system. The sending module 702 is also used to send an MCP service call request to the MCP server through the MCP service routing component; Execution module 703 is used to execute the service corresponding to the MCP service call request through the service interface called by the MCP server.

[0099] In some embodiments, the vehicle service invocation device 700 may further include: The encapsulation module is used to encapsulate the vehicle's vehicle services into MCP services through the MCP builder interface, thus obtaining the MCP server. The registration module is used to register the MCP server with the MCP routing component, so that the MCP routing component can call the MCP server based on the registration information of the MCP server.

[0100] In some embodiments, the vehicle service invocation device 700 may further include: The extraction module is used to input the instruction information of the user command into the pre-trained function call model, and extract the features of the instruction information through the function call model to obtain the sub-instruction information; The generation module 701 is also used to determine the corresponding vehicle service based on the sub-instruction information and generate the corresponding MCP service call request.

[0101] In some embodiments, the encapsulation module is further configured to encapsulate the vehicle's vehicle services into an MCP service based on the bidirectional communication protocol WebSocket through the MCP builder interface, thereby obtaining a WebSocket-based MCP server.

[0102] In some embodiments, the vehicle service invocation apparatus 700, including the registration module, is further configured to establish a connection with the cloud-based MCP relay gateway via the MCP routing component, using the MCP protocol implemented based on the bidirectional communication protocol WebSocket, and send the registration information of the MCP server to the cloud-based MCP relay gateway, so that the cloud-based MCP relay gateway can generate an MCP service invocation request based on the registration information.

[0103] In some embodiments, the sending module 702 is further configured to send an MCP service call request to the corresponding MCP server on the device side when the MCP routing component receives an MCP service call request sent by the cloud MCP relay gateway. The execution module 703 is also used by the MCP server to execute the corresponding service based on the MCP service call request sent by the cloud MCP relay gateway.

[0104] In some embodiments, the vehicle service invocation device 700 may further include: The authentication module is used to perform security authentication on MCP service call requests through the MCP routing component; The sending module 702 is also used to send an MCP service call request to the corresponding MCP server of the device system through the MCP service routing component when the security authentication is passed.

[0105] In some embodiments, the execution module is further configured to execute the execution service and long short-term memory service corresponding to the MCP service call request by calling the service interface through the MCP server.

[0106] Figure 7 The various modules in the device shown can achieve Figure 5 The various steps involved, and the corresponding technical effects achieved, will not be elaborated upon here for the sake of brevity.

[0107] Figure 8 This application illustrates a vehicle service invocation apparatus 800, applied to a cloud system, which may include: The generation module 801 is used to generate an MCP service call request upon receiving a user instruction sent by the in-vehicle intelligent terminal. The sending module 802 is used to send an MCP service call request to the MCP routing component through the cloud MCP relay gateway, so that the MCP routing component can send the MCP service call request to the MCP server and execute the service corresponding to the MCP service call request through the service interface called by the MCP server.

[0108] In some embodiments, the vehicle service invocation device 800 may further include: The extraction module is used to input the instruction information of the user command into the pre-trained function call model, and extract the features of the instruction information through the function call model to obtain the sub-instruction information; The generation module 801 is also used to determine the corresponding vehicle service based on the sub-instruction information and generate the corresponding MCP service call request.

[0109] Figure 8 The various modules in the device shown can achieve Figure 5 The various steps involved, and the corresponding technical effects achieved, will not be elaborated upon here for the sake of brevity.

[0110] Figure 9 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0111] The electronic device may include a processor 901 and a memory 902 storing computer program instructions.

[0112] Specifically, the processor 901 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0113] Memory 902 may include mass storage for data or instructions. For example, and not limitingly, memory 902 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 902 may include removable or non-removable (or fixed) media, or memory 902 may be non-volatile solid-state memory. Memory 902 may be internal or external to the integrated gateway disaster recovery device.

[0114] In one example, memory 902 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the vehicle control method according to this disclosure.

[0115] The processor 901 reads and executes computer program instructions stored in the memory 902 to achieve... Figure 1 The vehicle control method in the illustrated embodiment.

[0116] In one example, the electronic device may also include a communication interface 903 and a bus 904. For example, Figure 9 As shown, the processor 901, memory 902, and communication interface 903 are connected through bus 904 and complete communication with each other.

[0117] The communication interface 903 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0118] Bus 904 includes hardware, software, or both, that couples components of an electronic device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 904 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0119] Furthermore, in conjunction with the vehicle control methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle control methods in the above embodiments.

[0120] This application also provides a computer program product, including a computer program that, when executed, implements any of the vehicle control methods described in the above embodiments.

[0121] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0122] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or text segments used to perform the required tasks. Programs or text segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Text segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0123] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0124] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0125] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method of vehicle service invocation, the method comprising: The method is applied to a device-side system, the device-side system comprising a model context protocol (MCP) client, an MCP routing component, and MCP service sides providing different vehicle services, and the method comprises: generating an MCP service invocation request in response to receiving a user instruction sent by an in-vehicle intelligent terminal; sending the MCP service invocation request to the MCP routing component via the MCP client in response to generating the MCP service invocation request by the device-side system or receiving an MCP service invocation request sent by a cloud-side system; sending the MCP service invocation request to an MCP service side via the MCP service routing component; invoking a service interface via the MCP service side to execute a service corresponding to the MCP service invocation request.

2. The method of vehicle service invocation of claim 1, wherein, The device-side system further comprises an MCP builder interface, and before generating the MCP service invocation request in response to receiving the user instruction, the method further comprises: encapsulating a vehicle service of a vehicle as an MCP service via the MCP builder interface to obtain an MCP service side; registering the MCP service side in the MCP routing component, so that the MCP routing component invokes the MCP service side according to registration information of the MCP service side.

3. The method of vehicle service invocation of claim 2, wherein, Generating the MCP service invocation request in response to receiving the user instruction comprises: inputting instruction information of the user instruction into a pre-trained function invocation model, performing feature extraction on the instruction information via the function invocation model to obtain sub-instruction information; determining a corresponding vehicle service according to the sub-instruction information and generating a corresponding MCP service invocation request.

4. The method of vehicle service invocation of claim 3, wherein, The encapsulating the vehicle service of the vehicle as the MCP service via the MCP builder interface to obtain the MCP service side comprises: encapsulating the vehicle service of the vehicle as an MCP service based on a websocket protocol via the MCP builder interface to obtain a websocket-based MCP service side.

5. The method of vehicle service invocation of claim 4, wherein, The method further comprises: establishing a connection with a cloud-side MCP relay gateway based on an MCP protocol implemented based on a websocket protocol via the MCP routing component, and sending registration information of the MCP service side to the cloud-side MCP relay gateway, so that the cloud-side MCP relay gateway generates an MCP service invocation request based on the registration information.

6. The method of vehicle service invocation of claim 5, wherein, The method further comprises: sending the MCP service invocation request to a corresponding MCP service side of the device-side system in response to the MCP routing component receiving an MCP service invocation request sent by the cloud-side MCP relay gateway; The MCP service side executes a corresponding service according to the MCP service invocation request sent by the cloud-side MCP relay gateway.

7. The method of vehicle service invocation of claim 1, wherein, The sending the MCP service invocation request to the corresponding MCP service side of the device-side system via the MCP service routing component comprises: performing security authentication on the MCP service invocation request via the MCP routing component; In a case where the security authentication passes, the MCP service routing component sends the MCP service call request to a corresponding MCP server of a device-side system.

8. The method of vehicle service invocation of claim 1, wherein, The vehicle services include execution services and long short-term memory services.

9. A method of vehicle service invocation, the method comprising: The method is applied to a cloud system, and the method comprises: In a case where a user instruction sent by the vehicle-mounted intelligent terminal or the cloud intelligent agent is received, generating an MCP service call request; The cloud MCP relay gateway sends the MCP service call request to the MCP routing component, so that the MCP routing component sends the MCP service call request to the MCP server, and the MCP server calls a service interface to execute a service corresponding to the MCP service call request.

10. The method of vehicle service invocation of claim 9, wherein, In a case where a user instruction sent by the vehicle-mounted intelligent terminal is received, generating an MCP service call request, comprising: Inputting instruction information of the user instruction into a pre-trained function call model, performing feature extraction on the instruction information by using the function call model, and obtaining sub-instruction information; According to the sub-instruction information, determining a corresponding vehicle service, and generating a corresponding MCP service call request.

11. An apparatus for vehicle service invocation, the apparatus comprising: The device-side system comprises a model context protocol (MCP) client, an MCP routing component, and MCP servers providing different vehicle services, and the apparatus comprises: A generating module configured to, in a case where a user instruction sent by the vehicle-mounted intelligent terminal is received, generate an MCP service call request; A sending module configured to, in a case where the device-side system generates an MCP service call request or receives an MCP service call request sent by the cloud system, send the MCP service call request to the MCP routing component by using the MCP client; The sending module is further configured to send the MCP service call request to the MCP server by using the MCP service routing component; An execution module configured to call a service interface by using the MCP server to execute a service corresponding to the MCP service call request.

12. An apparatus for vehicle service invocation, the apparatus comprising: The apparatus is applied to a cloud system, and the apparatus comprises: A generating module configured to, in a case where a user instruction sent by the vehicle-mounted intelligent terminal or a cloud intelligent agent is received, generate an MCP service call request; A sending module configured to send the MCP service call request to the MCP routing component by using a cloud MCP relay gateway, so that the MCP routing component sends the MCP service call request to the MCP server, and the MCP server calls a service interface to execute a service corresponding to the MCP service call request.

13. An electronic device, comprising: The device comprises a processor and a memory storing computer program instructions; and the processor executes the computer program instructions to implement the method for calling a vehicle service according to any one of claims 1-10.

Images