Gateway dynamic self-coding system and method based on model context protocol

Abstract

The invention discloses a gateway dynamic self-coding system and method based on a model context protocol, and the system comprises an inspection module which is used for monitoring the states of all equipment nodes in a gateway system, and recording the corresponding node element information if the states of the equipment nodes change; the model context protocol management module is used for constructing a context request based on a model context protocol when the state of the equipment node changes; the AI engine is used for acquiring node element information based on the context request and generating a tool calling instruction based on a model context protocol according to the node element information; the mapping relation generation engine is used for generating a mapping module according to the tool calling instruction; and the self-encoding module is used for generating a service configuration script corresponding to the equipment node according to the tool calling instruction and the mapping module. According to the invention, the remote operation and maintenance cost can be reduced, the whole process from equipment discovery to business online is intelligent and automatic, and the method can be widely applied to the technical field of mobile internet.

Description

Technical Field

[0001] This application relates to the field of mobile Internet technology, and in particular to a gateway dynamic self-encoding system and method based on Model Context Protocol. Background Technology

[0002] In current Internet of Things (IoT) and Industrial Internet scenarios, gateways, as core nodes connecting edge devices and upper-layer applications, undertake key functions such as protocol conversion, data aggregation, and device management. With the increasing variety of devices, heterogeneous interface protocols, and frequent functional iterations, traditional gateways face problems such as high maintenance costs and long upgrade cycles due to reliance on manual configuration or firmware upgrades, making it difficult to meet the needs of various intelligent applications in the current network. Summary of the Invention

[0003] The main objective of this application is to propose a gateway dynamic self-encoding system and method based on the Model Context Protocol, which can reduce remote operation and maintenance costs and meet the needs of various intelligent applications in the current network.

[0004] To achieve the above objectives, one aspect of this application proposes a gateway dynamic autoencoder system based on the Model Context Protocol, comprising: The inspection module is used to monitor the status of all device nodes in the gateway system. If the status of a device node changes, the corresponding node metadata is recorded. The model context protocol management module is used to construct a context request based on the model context protocol when the state of the device node changes. The AI ​​engine is used to obtain the node meta information based on the context request, and then generate tool invocation instructions based on the model context protocol according to the node meta information. A mapping relationship generation engine is used to generate mapping modules according to the tool's invocation instructions; The self-encoding module is used to generate the service configuration script corresponding to the device node according to the tool call instructions and the mapping module.

[0005] In some embodiments, the system further includes: A configuration window generator is used to generate configuration interface metadata based on the tool invocation instructions and the mapping module; An encryption / decryption communication module is used to synchronously send the configuration interface metadata to the cloud management platform; The cloud management platform is used to render the configuration interface based on the configuration interface metadata, and then receive user configuration parameters through the configuration interface.

[0006] In some embodiments, the system further includes: The upper-layer application library and plugin management module is used to store and publish the mapping module.

[0007] To achieve the above objectives, another aspect of this application proposes a gateway dynamic self-encoding method based on the Model Context Protocol, comprising the following steps: The inspection module monitors the status of all device nodes in the gateway system. If the status of a device node changes, the corresponding node metadata is recorded. When the state of the device node changes, the model context protocol management module constructs a context request based on the model context protocol. The AI ​​engine obtains the node meta information based on the context request, and then generates tool invocation instructions based on the model context protocol according to the node meta information. The mapping relationship generation engine generates mapping modules according to the tool's call instructions; The self-encoding module generates the service configuration script corresponding to the device node based on the tool call instructions and the mapping module.

[0008] In some embodiments, the method further includes: By configuring the window generator, configuration interface metadata is generated according to the tool invocation instructions and the mapping module; The configuration interface metadata is synchronously sent to the cloud management platform via the encryption / decryption communication module. The cloud management platform renders the configuration interface based on the configuration interface metadata, and then receives user configuration parameters through the configuration interface.

[0009] In some embodiments, the method further includes: The mapping module is stored and published through the upper-layer application library and plugin management module.

[0010] In some embodiments, the step of constructing a context request based on the model context protocol when the state of the device node changes via the model context protocol management module specifically includes: The device nodes are encapsulated as resources, and the mapping relationship generation engine, the self-encoding module, and the configuration window generator are encapsulated as tools for the AI ​​engine to call. Construct a context request based on the model context protocol; When the state of the device node changes, the AI ​​engine is notified through the context request.

[0011] In some embodiments, the tool invocation instruction includes a first invocation instruction, a second invocation instruction, and a third invocation instruction. The step of obtaining the node metadata based on the context request through the AI ​​engine, and then generating the tool invocation instruction based on the model context protocol according to the node metadata, specifically includes: The model context protocol management module initiates the context request to the inspection module to obtain the node metadata. Semantic understanding is performed on the node metadata to obtain the target device instance; Based on the target device instance, a first invocation instruction is generated, which is used to invoke the mapping relationship generation engine; Based on the target device instance, a second invocation instruction is generated, which is used to invoke the configuration window generator; Based on the node metadata, the mapping module, and the user configuration parameters, a third invocation instruction is generated, which is used to invoke the self-encoding module.

[0012] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0013] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0014] The embodiments of this application include at least the following beneficial effects: The gateway dynamic self-encoding system and method based on the Model Context Protocol (MGP) of this application includes an inspection module, a MGP management module, an AI engine, a mapping relationship generation engine, and a self-encoding module. The inspection module is used to monitor the status of all device nodes in the gateway system. If the status of a device node changes, it records the corresponding node metadata. The MGP management module is used to construct a context request based on the MGP when the status of a device node changes. The AI ​​engine is used to obtain node metadata based on the context request, and then generate tool call instructions based on the MGP according to the node metadata. The mapping relationship generation engine is used to generate a mapping module according to the tool call instructions. The self-encoding module is used to generate the business configuration script corresponding to the device node according to the tool call instructions and the mapping module. This application securely exposes the underlying device nodes of the gateway to the AI ​​engine through the MGP, enabling the AI ​​model to dynamically call gateway capabilities like using a "tool," and drive the self-encoding module to complete the automatic generation and deployment of business configuration scripts. This eliminates the need for remote operation and maintenance iteration upgrades, reduces remote operation and maintenance costs, and realizes full-process intelligence and automation from device discovery to business launch, which can meet the needs of various intelligent applications in the current network. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments of this application are described below. It should be understood that the drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions in this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the basic system architecture provided in one embodiment of the present application; Figure 2 A schematic diagram of the architecture of a gateway dynamic self-encoding system based on the Model Context Protocol provided in one embodiment of this application; Figure 3 A schematic diagram of the architecture of a gateway dynamic self-encoding system based on the Model Context Protocol provided in another embodiment of this application; Figure 4 A flowchart illustrating the steps of a gateway dynamic self-encoding method based on the Model Context Protocol provided in one embodiment of this application; Figure 5 A system timing diagram provided for one embodiment of this application; Figure 6 A flowchart illustrating the steps of a gateway dynamic self-encoding method based on a model context protocol, as provided in another embodiment of this application; Figure 7 A flowchart illustrating the steps of a gateway dynamic self-encoding method based on a model context protocol, as provided in another embodiment of this application; Figure 8 A flowchart illustrating step S102 provided in one embodiment of this application; Figure 9 A flowchart illustrating step S103 provided in one embodiment of this application; Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0019] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0020] MCP (Model Context Protocol) is a protocol for managing model context information, primarily used in the fields of artificial intelligence and machine learning. It ensures that models can be correctly understood and used across different systems by standardizing context information such as model input / output formats, dependencies, and runtime environments.

[0021] DBUS (Desktop Bus): A cross-process communication mechanism widely used in Linux and embedded systems. It enables message passing between different processes through a message bus (such as the system bus and session bus), supporting functions such as service discovery, API calls, and event notifications. DBUS provides standardized message formats and interface definitions, simplifying the complexity of inter-process communication, and is commonly used in desktop environments, system services, and embedded device communication scenarios.

[0022] In current Internet of Things (IoT) and Industrial Internet scenarios, gateways, as core nodes connecting edge devices and upper-layer applications, undertake key functions such as protocol conversion, data aggregation, and device management. With the increasing variety of devices, heterogeneous interface protocols, and frequent functional iterations, traditional gateways face challenges such as high maintenance costs and long upgrade cycles due to reliance on manual configuration or firmware upgrades, making it difficult to meet the needs of various intelligent applications in the current network. Although AI technology has been introduced into edge device management in recent years, the following problems still exist: 1) AI model silos: The AI ​​engine lacks a standardized interaction mechanism with other modules of the gateway (such as configuration and protocol conversion), making it difficult to work together; 2) Incomplete context transmission: Device change information cannot be transmitted to the AI ​​model in a structured "context" form, resulting in inaccurate semantic understanding; 3) Limited automation: Existing solutions mostly remain at the "discovery → notification" level, and cannot achieve end-to-end automatic generation from device identification to business configuration; 4) Lack of unified protocol support: There is no universal protocol specification for the request, response, and context data formats between AI models and system components; 5) The AI ​​logic is pre-written and static, making it unable to dynamically adapt to unknown new device types. The various modules of the system communicate through customized interfaces, resulting in poor scalability.

[0023] The Model Context Protocol (MCP) provides a standardized framework for AI models to interact with external systems, but its current applications are mostly concentrated in software development support. There are still no mature solutions for its innovative application in device management, dynamic mapping, and self-coded updates for IoT gateways.

[0024] In view of this, this application proposes a gateway dynamic self-encoding system based on the Model Context Protocol (MGP), including an inspection module, a MGP management module, an AI engine, a mapping relationship generation engine, and a self-encoding module. The inspection module monitors the status of all device nodes in the gateway system and records the corresponding node metadata if the status of a device node changes. The MGP management module constructs a context request based on the MGP when the status of a device node changes. The AI ​​engine obtains node metadata based on the context request and then generates tool invocation instructions based on the MGP. The mapping relationship generation engine generates a mapping module based on the tool invocation instructions. The self-encoding module generates the corresponding business configuration script for the device node based on the tool invocation instructions and the mapping module. This application securely exposes the underlying device nodes of the gateway to the AI ​​engine through the MGP, enabling the AI ​​model to dynamically invoke gateway capabilities like using a "tool" and drive the self-encoding module to automatically generate and deploy business configuration scripts. This eliminates the need for remote operation and maintenance iteration upgrades, reducing remote operation and maintenance costs and achieving full-process intelligence and automation from device discovery to service deployment, meeting the needs of various intelligent applications in the current network. The gateway dynamic self-encoding system of this application embodiment can be applied to scalable IoT devices, smart manufacturing and vehicle networking scenarios, but is not limited thereto.

[0025] First, the basic system architecture of this application is introduced. (Refer to...) Figure 1 , Figure 1 This is a schematic diagram of the basic system architecture provided in one embodiment of the present application. The basic system mainly includes four layers: cloud platform, system layer, firmware layer and hardware layer.

[0026] The cloud platform is located at the top layer of the basic system architecture and includes a cloud management platform for overall data management and remote control functions.

[0027] The system layer is the core control layer of the entire gateway dynamic self-encoding system. It is built on the gateway DBUS capability foundation and is used to implement flexible service configuration based on the Model Context Protocol (MCP protocol).

[0028] The firmware layer provides basic communication support for the system, mainly including BSP (Board Support Package), Kernel, and DBUS communication-related content; it is used for hardware driver initialization, basic function implementation of the operating system kernel, and communication between various components within the system through DBUS, providing a stable operating environment and communication foundation for the upper-layer system.

[0029] The hardware layer is the physical foundation of the system, including hardware devices such as Wi-Fi, Bluetooth, and USB; it provides wireless and wired connectivity, enabling the system to interact with external devices, collect and transmit information, and serves as a bridge connecting the entire system to the external physical world.

[0030] based on Figure 1 The basic system architecture, refer to Figure 2 , Figure 2 This is a schematic diagram of the architecture of a gateway dynamic autoencoder system based on the Model Context Protocol (MGP) according to one embodiment of this application. This application proposes a gateway dynamic autoencoder system based on the MGP, comprising: The inspection module is used to monitor the status of all device nodes in the gateway system. If the status of a device node changes, the corresponding node metadata is recorded. The Model Context Protocol Management module is used to construct a context request based on the Model Context Protocol when the state of a device node changes. The AI ​​engine is used to obtain node meta information based on context requests, and then generate tool call instructions based on the model context protocol based on the node meta information. The mapping relationship generation engine is used to generate mapping modules based on tool call instructions; The self-encoding module is used to generate the business configuration scripts corresponding to the device nodes based on the tool's call instructions and mapping module.

[0031] Specifically, all device nodes in the gateway system are DBUS nodes, communicating via DBUS. The inspection module, model context protocol management module, AI engine, mapping relationship generation engine, and autoencoder module are all deployed at the system layer (gateway).

[0032] The inspection module, acting as an MCP server, is used to manage the device node resources. It continuously scans, listens to, and records the status and changes of all device nodes in the gateway system. If a device node is added, deleted, or its attributes are modified, the module captures the node metadata corresponding to the device node. The captured node metadata includes interfaces, data types, permissions, etc.

[0033] The Model Context Protocol (MCP) management module serves as the core communication hub of the system, implementing the MCP server interface, managing MCP sessions, and controlling permissions and security. The MCP server interface function collaborates with the inspection module, encapsulating device nodes and mapping rules into standard MCP "Resources," and encapsulating configuration window generators, mapping relationship generation engines, and other components into standard MCP "Tools." These encapsulated resources and tools can be called by the AI ​​engine in a standardized manner, providing strong support for subsequent intelligent processing and analysis. The MCP session management function establishes communication sessions with the AI ​​engine that conform to the MCP standard, handling its context requests and responses. The permission and security control function, based on the permission model built into the Model Context Protocol (MCP protocol), controls which resources and tools the AI ​​engine can access and use, ensuring operational security.

[0034] The AI ​​engine runs as an MCP client. When the DBUS inspection module detects a new device node or a change in the attributes of a device node, it notifies the engine. The engine then initiates a session through the Model Context Protocol Management module, dynamically acquiring node metadata and analyzing node functions by calling MCP methods such as `list_resources` and `read_resource`, and invoking appropriate tools (such as mapping generation tools and configuration window generators) to resolve the issue. It should be noted that the AI ​​engine's decision-making process is based on its understanding of the real-time gateway context, rather than pre-defined static logic.

[0035] The mapping relationship generation engine, acting as an MCP server, has its functionality encapsulated as an MCP "tool" by the Model Context Protocol Management module. When the AI ​​engine calls this tool through the Model Context Protocol (MCP protocol), it generates standardized mapping modules (including API interfaces and data structure definitions) that can be recognized by upper-layer applications based on a preset rule base (including function classification and data format conversion templates).

[0036] The self-encoding module is used to receive tool call instructions, generate executable business configuration scripts, complete the business configuration of the target device instance, and realize the system's dynamic self-encoding function.

[0037] Reference Figure 3 , Figure 3 The schematic diagram of the architecture of a gateway dynamic autoencoder system based on the Model Context Protocol provided in another embodiment of this application, further includes, as an optional implementation: A configuration window generator is used to generate configuration interface metadata based on tool call instructions and mapping modules; The encryption / decryption communication module is used to synchronously send configuration interface metadata to the cloud management platform; The cloud management platform is used to render the configuration interface based on the configuration interface metadata, and then receive user configuration parameters through the configuration interface.

[0038] Specifically, the encryption / decryption communication module is deployed at the system layer (gateway), and the configuration window generator is deployed in the cloud management platform.

[0039] The configuration window generator, acting as an MCP server, is also encapsulated as an MCP "tool" by the Model Context Protocol (MCP) management module. It is invoked by the AI ​​engine or other components via tool call instructions based on the MCP protocol, and generates structured configuration interface metadata according to the mapping module. This metadata includes information such as parameter ranges, default values, and interaction logic.

[0040] The encryption / decryption communication module is used to encrypt and decrypt data transmitted between the gateway and the cloud management platform to prevent data leakage and tampering, thereby ensuring the security of data transmission between the gateway and the cloud.

[0041] The cloud management platform receives configuration interface metadata and automatically renders the configuration interface, which is operated by the administrator. The administrator can issue corresponding configuration parameters in the configuration interface to provide the input basis for the self-encoding module to execute scripts.

[0042] As an optional implementation, the system further includes: The upper-layer application library and plugin management module is used to store and publish mapping modules.

[0043] Specifically, the upper-layer application library and plugin management module are used to store and publish the mapping module; business plugins dynamically discover and call new node capabilities by querying the upper-layer application library, thus achieving hot-swapping.

[0044] It should be noted that this application embodiment introduces the Model Context Protocol (MCP protocol), which abstracts the inspection module, mapping relationship generation engine, configuration window generator and self-encoding module into a standard MCP server, and uses the AI ​​engine as an MCP client, so that the AI ​​engine can be decoupled from the gateway underlying layer, so that the AI ​​engine can discover and call the various tools and resources of the gateway.

[0045] The foregoing has described the gateway dynamic autoencoder system based on the Model Context Protocol (MTP) of this application. It can be recognized that, compared with traditional gateways, the embodiments of this application have the following advantages: 1. When device nodes change, the underlying device nodes of the gateway are securely exposed to the AI ​​engine through the model context protocol, enabling the AI ​​model to dynamically call the gateway capabilities like using a "tool". This breaks down the integration barriers between the AI ​​model and the gateway functional modules. It also drives the self-coding module to automatically generate and deploy business configuration scripts, eliminating the need for remote operation and maintenance iteration upgrades of the program, reducing remote operation and maintenance costs. From device discovery to cloud interface rendering, the entire process requires no manual coding.

[0046] Second, the node metadata of the changed device nodes is transmitted in a structured context, which can improve the accuracy of AI semantic understanding.

[0047] Third, whether it is a small local model or a large cloud model, they can all be called uniformly through the model context protocol, which is highly adaptable and scalable.

[0048] Reference Figure 4 , Figure 4 This is a flowchart illustrating the steps of a gateway dynamic self-encoding method based on the Model Context Protocol (MGP) according to one embodiment of this application. This application also provides a gateway dynamic self-encoding method based on the MGP, including the following steps S101 to S105: Step S101: Monitor the status of all device nodes in the gateway system through the inspection module. If the status of a device node changes, record the corresponding node metadata. Step S102: When the state of a device node changes, a context request based on the model context protocol is constructed through the model context protocol management module. Step S103: Obtain node meta information based on context request through AI engine, and then generate tool call instructions based on model context protocol according to node meta information; Step S104: Generate the mapping module by generating the engine through the mapping relationship and according to the tool call instructions; Step S105: Using the self-encoding module, generate the business configuration script corresponding to the device node according to the tool call instructions and mapping module.

[0049] Specifically, such as Figure 5 The diagram shows the system timing. First, the inspection module, acting as the MCP server, continuously monitors device node change events on the DBUS bus. When a new device node is detected or a device node's configuration is changed, the module automatically abstracts the physical node into a standardized resource object, extracting its node identifier, interface type, data type, permissions, and dependencies, forming a logical resource pool that can be called by the AI ​​engine.

[0050] Next, based on the real-time status of the resource pool, the Model Context Protocol (MCP) management module constructs a context request containing a timestamp, change type, and resource identifier. When a new device node is detected to be connected or a device node's configuration is changed, an asynchronous notification is immediately pushed to the AI ​​engine through the event channel of the Model Context Protocol (MCP), triggering subsequent processing.

[0051] Then, the AI ​​engine, acting as an MCP client, initiates a session through the Model Context Protocol management module upon receiving the notification. It dynamically requests access to the new device node resources, obtains node metadata, and generates tool invocation instructions based on the Model Context Protocol (MCP protocol). This invocation invokes the corresponding tools to resolve the issue. This includes a tool invocation instruction mapping relationship generation engine based on the MCP protocol, generating a standardized mapping module. This mapping module, according to a preset rule base (including function classification and data format conversion templates), generates API interfaces and data structure definitions recognizable by upper-layer applications from the node metadata, enabling conversion between different structures or semantics.

[0052] Finally, the self-encoding module tool automatically outputs an executable business configuration script based on the AI ​​engine's call instructions, completing the business configuration for the target device instance.

[0053] It is understood that the embodiments of this application securely expose the underlying device nodes of the gateway to the AI ​​engine through the Model Context Protocol (MCP protocol), enabling the AI ​​model to dynamically call the gateway capabilities like using a "tool" and drive the self-encoding module to complete the automatic generation and deployment of business configurations, realizing the intelligent and automated process from device discovery to business launch.

[0054] Reference Figure 6 , Figure 6 The flowchart of a gateway dynamic self-encoding method based on the Model Context Protocol (MGP) provided in another embodiment of this application is further illustrated as an optional implementation, the gateway dynamic self-encoding method based on the MGP also includes the following steps S106 to S108: Step S106: Generate configuration interface metadata by using the configuration window generator according to the tool call instructions and mapping module; Step S107: Synchronously send the configuration interface metadata to the cloud management platform through the encryption / decryption communication module; Step S108: Through the cloud management platform, the configuration interface is rendered based on the configuration interface metadata, and then the user configuration parameters are received through the configuration interface.

[0055] Specifically, such as Figure 5The system sequence diagram shown illustrates how the AI ​​engine invokes a configuration window generation tool via a tool call command based on the Model Context Protocol (MCP). This tool generates configuration interface metadata, including parameter ranges, default values, and interaction logic, based on field types, value ranges, and dependencies. This metadata is then encrypted and decrypted by the communication module before being synchronously sent to the cloud management platform. The cloud management platform renders the configuration interface, allowing administrators to issue corresponding user configuration parameters.

[0056] Reference Figure 7 , Figure 7 The flowchart illustrates the steps of a gateway dynamic self-encoding method based on the Model Context Protocol (MCP) according to another embodiment of this application. Further, as an optional implementation, the gateway dynamic self-encoding method based on the MCP protocol further includes the following step S109: Step S109: Store and publish the mapping module through the upper-layer application library and plugin management module.

[0057] Specifically, such as Figure 5 The system sequence diagram shown illustrates that after the mapping relationship generation engine generates a standardized mapping module, it immediately pushes the mapping module, containing API interfaces, data structure definitions, and capability verbs, to the upper-layer application library in a versioned compressed package via a synchronization channel established between the upper-layer application library and the plugin management module. The plugin management module parses dependencies, verifies signatures, hot-updates the plugin index, and notifies each running plugin instance to refresh its local cache. Subsequently, plugins can dynamically discover, load, and invoke the monitoring, configuration, and alarm capabilities provided by new device nodes through the unified capability bus without requiring a restart, achieving plug-and-play functionality, significantly shortening the business launch cycle, and reducing operational costs.

[0058] Reference Figure 8 , Figure 8 The flowchart of step S102 provided in one embodiment of this application is further, as an optional implementation, step S102 can be further divided into the following steps S1021 to S1023: Step S1021: Encapsulate the device node as a resource, and encapsulate the mapping relationship generation engine, the self-encoding module, and the configuration window generator as tools for the AI ​​engine to call. Step S1022: Construct a context request based on the model context protocol; Step S1023: When the state of a device node changes, notify the AI ​​engine via a context request.

[0059] It should be noted that the Model Context Protocol Management module is the core communication hub of this application embodiment. The MCP server interface, MCP session management, and permission and security control functions are implemented through the Model Context Protocol Management module.

[0060] Specifically, when implementing the MCP server interface, the Model Context Protocol Management module encapsulates device nodes into standard MCP "Resources" and configuration window generators, mapping relationship generation engines, etc., into standard MCP "Tools." These encapsulated resources and tools can be called by the AI ​​engine in a standardized form, providing strong support for subsequent intelligent processing and analysis. In the communication phase, the Model Context Protocol Management module and the AI ​​engine, acting as an MCP client, establish a standard-compliant communication session to accurately handle various requests from the AI ​​engine and provide timely and appropriate responses. Regarding permissions and security control, the Model Context Protocol Management module leverages the built-in permission model of the Model Context Protocol (MCP protocol) to strictly control the AI ​​engine's access permissions. It clearly defines the resources that the AI ​​engine can access and the tools it can use, preventing unauthorized access and operations, ensuring system operational security from the source, and preventing data leaks, system failures, and other problems caused by improper operations.

[0061] Reference Figure 9 , Figure 9 The flowchart of step S103 provided in one embodiment of this application is further illustrated as an optional implementation. The tool invocation instruction includes a first invocation instruction, a second invocation instruction, and a third invocation instruction. Step S103 can be further divided into the following steps S1031 to S1035: Step S1031: Through the model context protocol management module, initiate a context request to the inspection module to obtain node metadata; Step S1032: Perform semantic understanding on the node metadata to obtain the target device instance; Step S1033: Generate a first invocation instruction based on the target device instance. The first invocation instruction is used to invoke the mapping relationship generation engine. Step S1034: Generate a second invocation instruction based on the target device instance. The second invocation instruction is used to invoke the configuration window generator. Step S1035: Generate a third call instruction based on node metadata, mapping module and user configuration parameters. The third call instruction is used to call the self-encoding module.

[0062] Specifically, the AI ​​engine initiates a context request containing intent to the inspection module through the Model Context Protocol (MCP) management module, dynamically requesting access to changed device node resources. After obtaining node metadata, it performs semantic understanding analysis of node functions to accurately locate the target device instance. Subsequently, the AI ​​engine invokes a mapping relationship generation tool via a first call instruction based on the MCP, passing in the target device instance information. This tool generates a standardized mapping module based on a preset rule base, providing a basis for data transformation and association for subsequent business processing. Next, the AI ​​engine invokes a configuration window generator via a second call instruction based on the MCP, generating configuration interface metadata. After receiving user configuration parameters from the administrator through the configuration interface, the AI ​​engine integrates all information, including node metadata, mapping modules, and user configuration parameters, and invokes a self-encoding tool via a third call instruction based on the MCP, accurately passing this relevant information as parameters. After receiving the parameters, the self-encoding module tool processes the input data according to its internal encoding logic and algorithms. After a series of calculations and transformations, it finally outputs an executable business configuration script. This script contains specific business configuration instructions for the target device instance, which can be executed directly on the target device to complete the business configuration of the target device instance, realizing the intelligent and automated process from device discovery to business launch.

[0063] In some optional embodiments, for the semantic understanding process, the AI ​​engine first performs structured parsing on the acquired node metadata, extracting information such as node identifier, interface type, data type, permissions, and dependencies. Then, it enhances the metadata by supplementing missing fields and resolving conflicts, and converts the enhanced metadata into data features for subsequent semantic analysis. Next, it performs syntax-level parsing and semantic-level annotation on the format-converted metadata, and combines it with contextual information such as the current gateway load and the number of connected devices to obtain the node functions of the device nodes.

[0064] It is understood that the content of the above system embodiments is applicable to this method embodiment. The specific functions implemented in this method embodiment are the same as those in the above system embodiments, and the beneficial effects achieved are also the same as those achieved in the above system embodiments.

[0065] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0066] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0067] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1002 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 using the methods described in the embodiments of this application. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

[0068] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0069] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0070] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0071] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0072] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0073] The gateway dynamic self-encoding system and method based on the Model Context Protocol (MCP) provided in this application abstracts the inspection module, mapping relationship generation engine, configuration window generator, and self-encoding module into a standard MCP server by introducing the MCP protocol, and uses the AI ​​engine as an MCP client. When device nodes change, the underlying device nodes of the gateway are securely exposed to the AI ​​engine through the MCP protocol, enabling the AI ​​model to dynamically call gateway capabilities like using a "tool," breaking down the integration barriers between the AI ​​model and gateway functional modules; and driving the self-encoding module to automatically generate and deploy business configuration scripts, eliminating the need for remote operation and maintenance iteration upgrades, reducing remote operation and maintenance costs, and shortening the gateway upgrade iteration cycle. From device discovery to cloud interface rendering, the entire process requires no manual coding.

[0074] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0075] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0076] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0077] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0078] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0079] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0080] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0081] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0083] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0084] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A gateway dynamic auto-encoder system based on Model Context Protocol, characterized in that, include: The inspection module is used to monitor the status of all device nodes in the gateway system. If the status of a device node changes, the corresponding node metadata is recorded. The model context protocol management module is used to construct a context request based on the model context protocol when the state of the device node changes. The AI ​​engine is used to obtain the node meta information based on the context request, and then generate tool invocation instructions based on the model context protocol according to the node meta information. A mapping relationship generation engine is used to generate mapping modules according to the tool's invocation instructions; The self-encoding module is used to generate the service configuration script corresponding to the device node according to the tool call instructions and the mapping module.

2. The system according to claim 1, characterized in that, The system also includes: A configuration window generator is used to generate configuration interface metadata based on the tool invocation instructions and the mapping module; An encryption / decryption communication module is used to synchronously send the configuration interface metadata to the cloud management platform; The cloud management platform is used to render the configuration interface based on the configuration interface metadata, and then receive user configuration parameters through the configuration interface.

3. The system according to claim 1, characterized in that, The system also includes: The upper-layer application library and plugin management module is used to store and publish the mapping module.

4. A gateway dynamic self-encoding method based on Model Context Protocol, characterized in that, Includes the following steps: The inspection module monitors the status of all device nodes in the gateway system. If the status of a device node changes, the corresponding node metadata is recorded. When the state of the device node changes, the model context protocol management module constructs a context request based on the model context protocol. The AI ​​engine obtains the node meta information based on the context request, and then generates tool invocation instructions based on the model context protocol according to the node meta information. The mapping relationship generation engine generates mapping modules according to the tool's call instructions; The self-encoding module generates the service configuration script corresponding to the device node based on the tool call instructions and the mapping module.

5. The method according to claim 4, characterized in that, The method further includes: By configuring the window generator, configuration interface metadata is generated according to the tool invocation instructions and the mapping module; The configuration interface metadata is synchronously sent to the cloud management platform via the encryption / decryption communication module. The cloud management platform renders the configuration interface based on the configuration interface metadata, and then receives user configuration parameters through the configuration interface.

6. The method according to claim 4, characterized in that, The method further includes: The mapping module is stored and published through the upper-layer application library and plugin management module.

7. The method according to claim 5, characterized in that, The step of constructing a context request based on the model context protocol when the state of the device node changes through the model context protocol management module specifically includes: The device nodes are encapsulated as resources, and the mapping relationship generation engine, the self-encoding module, and the configuration window generator are encapsulated as tools for the AI ​​engine to call. Construct a context request based on the model context protocol; When the state of the device node changes, the AI ​​engine is notified through the context request.

8. The method according to claim 7, characterized in that, The tool invocation instructions include a first invocation instruction, a second invocation instruction, and a third invocation instruction. The step of obtaining the node metadata based on the context request through the AI ​​engine, and then generating tool invocation instructions based on the model context protocol according to the node metadata, specifically includes: The model context protocol management module initiates the context request to the inspection module to obtain the node metadata. Semantic understanding is performed on the node metadata to obtain the target device instance; Based on the target device instance, a first invocation instruction is generated, which is used to invoke the mapping relationship generation engine; Based on the target device instance, a second invocation instruction is generated, which is used to invoke the configuration window generator; Based on the node metadata, the mapping module, and the user configuration parameters, a third invocation instruction is generated, which is used to invoke the self-encoding module.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 4 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 4 to 8.

Images