CN116233283B - A method for dynamic expansion and hot plugging of equipment communication protocol - Google Patents

Abstract

The present application provides a method for dynamic expansion and hot plugging of device communication protocols, which relates to the technical field of the Internet of Things and can realize flexible access and security control of edge devices. It includes the following steps: environment deployment: deploy real-time database, message server, Config microservice, and Handler microservice; device registration: determine whether there is a communication protocol for new devices in Config microservice; protocol extension: select the standard communication protocol framework predefined by Config microservice, and expand the communication protocol of new devices; device activation: Config microservice sends a device activation message to the system topic consumption start of the message server; Find the communication protocol corresponding to the new device and analyze the message.

Description

A method for dynamic expansion and hot plugging of equipment communication protocol

technical field

The present application relates to the technical field of the Internet of Things, in particular to a method for dynamic expansion and hot plugging of device communication protocols.

Background technique

With the rapid development of the Internet of Things technology, various devices are connected at a geometric rate. Every time a new type of equipment is connected to the business system, a set of communication protocols related to the equipment must be redefined, and then the business system needs to be redeployed and started before it can be put into use. Conversely, to uninstall the device, the services related to the device communication protocol must be stopped first, and the business system also needs to be restarted.

Moreover, from a security point of view, if you want to implement control based on a single device, you also need to write a communication protocol specific to the standby instance, which is extremely cumbersome and difficult to expand.

The above implementation methods have greatly increased the access burden of IoT devices, so it is urgent to propose an effective solution to achieve flexible access and security control of edge devices.

Contents of the invention

In order to solve at least one of the technical problems in the background technology, an embodiment of the present application provides a method for dynamic expansion and hot swapping of device communication protocols, which can realize flexible access and security control of edge devices.

The method for dynamic expansion and hot plugging of the device communication protocol provided by the embodiment of the present application includes the following steps:

Environment deployment: deploy real-time database, message server, Config microservice, Handler microservice;

Device registration: determine whether there is a communication protocol for edge devices in the Config microservice;

If there is no communication protocol for the edge device, then perform protocol extension steps;

If there is a communication protocol for the edge device, select the project and communication protocol for the edge device to register, enter the device information, complete the device registration, and perform the device activation steps;

Protocol extension: select the standard communication protocol framework predefined by Config microservices to expand the communication protocol of edge devices;

Device activation: The Config microservice sends a device activation message to the system topic consumption start of the message server, and at the same time dynamically creates tenants, namespaces, business topics, and certificate authorization in the message server;

Device monitoring: After receiving the device activation message, the consumption start listener of the Handler microservice dynamically creates a listener corresponding to the business topic of the edge device;

Data communication: the edge device sends data to the business topic of the message server;

Data processing: After receiving the message, the corresponding business listener of the Handler microservice searches for the communication protocol corresponding to the edge device, analyzes the message, and stores the remote data into the real-time database.

In one of the possible implementation manners, the embodiment of the present application provides a method for dynamic extension and hot plugging of the device communication protocol, and the protocol extension step includes:

Protocol development: Based on the standard communication protocol framework predefined by Config microservices, define the attributes, actions, events, and heartbeats of the edge devices to be added;

Model encapsulation: Compile and unit test the four types of codes for the properties, actions, events, and heartbeats of the edge devices that need to be added, and package them into independent model packages;

Model verification: upload the model package to the object repository or file server through the Config microservice, and then download it to the local to read the model, and perform normative inspection and verification on the model package;

If the verification fails, an error message is displayed and suggestions for improvement are displayed;

If the verification is passed, perform model preloading;

Model preloading: load the verified model package to the Config microservice to preheat object instantiation;

If the preheating fails, prompt and display the conflict resolution method;

If the warm-up is successful, execute the model deployment;

Model deployment: The Config microservice loads and sends messages to the system topic model of the message server. After receiving the message, the Handler microservice performs asynchronous operations, loads the model package, and completes the dynamic deployment of the edge device communication protocol.

In one of the possible implementation manners, the embodiment of the present application provides a dynamic expansion and hot plugging method of the device communication protocol, and the device activation step includes:

Create tenants: Config micro-services dynamically add tenants in units of projects in the message server;

Create a namespace: dynamically add a namespace in the message server based on the model library;

Create a theme: Create a corresponding theme according to the security control level when the device is registered;

Generating keys: Generate authorization keys according to the master station machine number, account key, and project key information;

Certificate authorization: generate a security certificate based on the key;

Activation message: The Config microservice sends an activation message to the consumer system topic of the message server.

In one of the possible implementation manners, the embodiment of the present application provides a method for dynamic expansion and hot plugging of the device communication protocol, and the device monitoring step includes:

After the Handler microservice receives the activation message, it queries the cache information to determine whether the current node has started monitoring the business topic of the edge device;

If it is started, the program prompts and returns;

If it is not started, query the protocol framework to which the edge device belongs, initialize the service processing interface, create a monitor for the business topic of the edge device, and save the activated information in the cache, and use polling to share the load for each node's monitoring of the same business topic.

In one of the possible implementation manners, the embodiment of the present application provides a dynamic expansion and hot plugging method of the device communication protocol, and the data processing step includes:

Device subscription: Edge devices send production data in real time according to the pre-agreed topic name in the extension agreement;

Topic consumption: The topic listener of the Handler microservice receives the message, and calls the business processing interface agreed in the protocol to process the message;

Data storage: business processing interface parses data, generates data instantiation objects, creates data table structure, and dynamically inserts data records;

Online analysis: data statistical analysis and related business systems query the real-time data of the device and perform streaming calculations.

In one of the possible implementations, the embodiment of the present application provides a dynamic expansion and hot-swapping method of the device communication protocol, and the security control level in the creation theme is divided into item-level control, device object model-level control and device instance-level control;

Project-level control means that all devices under a project belong to the same tenant and namespace, and share related topics;

The device object model level control is that the same class of devices belong to the same namespace and share related topics;

Device instance-level controls have separate topics for each device.

Beneficial effects of the present application: The embodiment of the present application provides a dynamic expansion and hot-swapping method of the device communication protocol. Relying on a set of self-expanding standard communication protocol framework, it greatly reduces the workload of definition and analysis of various device communication protocols, greatly facilitates the access of edge devices and the removal of old devices, reduces the dependence on the startup and deployment of business systems, and realizes arbitrary insertion and removal of devices under the standard communication protocol framework.

At the same time, relying on the message server, through the dynamic creation, subscription, and cancellation mechanism of the topic, the hot-swappable deployment of the device under the three-level control can be realized, and the real-time communication of the data of the device can be quickly realized, and the rapid blocking under abnormal conditions can avoid the spread of security problems, reduce the cost of manual intervention, and realize refined management and control.

1. The self-expanding standard communication protocol framework reduces the workload of definition and analysis of edge device protocols.

2. The flexible insertion and extraction mechanism of equipment reduces the dependence on the business system and improves work efficiency.

3. Relying on the refined three-level control, the safety control of the equipment is realized, the operation is simplified, and the labor cost is saved.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings that are required in the description of the embodiments or prior art. Obviously, the accompanying drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings without paying creative labor.

Fig. 1 is a schematic diagram of environment deployment in the dynamic expansion of the device communication protocol and the hot-swapping method of the embodiment of the present application;

Fig. 2 is the technical implementation flowchart of Config micro-service in the dynamic extension of the device communication protocol of the embodiment of the present application and the hot-swapping method;

Fig. 3 is a flow chart of the technical implementation of the Handler microservice in the method of dynamic expansion and hot plugging of the device communication protocol according to the embodiment of the present application.

Detailed ways

With the rapid development of the Internet of Things technology, various devices are connected at a geometric rate. Every time a type of edge device is connected to the business system, a set of communication protocols related to the device must be redefined, and then the business system needs to be re-deployed and started before it can be put into use. Conversely, to uninstall the device, the services related to the device communication protocol must be stopped first, and the business system also needs to be restarted.

At present, the device communication protocol is complicated and difficult to define uniformly: for the communication protocols commonly used in the Internet of Things, such as MQTT, XMPP, COAP, HTTP, and TCP, etc., a set of standard communication protocol frameworks are defined to correspond to them. For edge devices, it can be configured according to the standard framework according to its communication protocol, so as to achieve flexible customization and dynamic expansion.

It is difficult for devices to be dynamically connected, security control: For added edge devices, through the message publishing and subscription mechanism, business topics and corresponding business listeners can be established synchronously to realize dynamic access and uninstallation of devices, and achieve fine-grained management and control of devices.

From a security point of view, if you want to implement control based on a single device, you also need to write a communication protocol specific to the standby instance, which is extremely cumbersome and difficult to expand.

The above implementation methods have greatly increased the access burden of IoT devices, so it is urgent to propose an effective solution to achieve flexible access and security control of edge devices.

Based on this, the embodiment of the present application provides a method for dynamic expansion and hot plugging of device communication protocols, through which flexible access and security control of edge devices can be realized.

The implementation of the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

Referring to Figures 1-3, the embodiment of the present application provides a method for dynamic expansion and hot swapping of device communication protocols, including the following steps:

Environment deployment: deploy real-time database, message server, Config microservice, Handler microservice, among which:

Real-time database: Provide time-driven, reconcile resource allocation algorithm, adopt real-time data model, combine real-time system and database technology, and apply to data collection of Internet of Things. Its data and transactions have clear time limits, which can truthfully reflect the operation of on-site equipment, transaction execution time, deadlines, etc.; it can properly handle the contradiction between time and storage space, and efficiently process massive data. The database can choose TDengine, InfluxDB, OpenTSDB, etc.

Message server: Based on queuing and message passing technology, it provides synchronous or asynchronous and reliable message transmission middleware for applications in the network. At present, there are many products to choose from, such as RabbitM Q, EmqX, RocketMQ, Kafka, Pulsar, etc. When choosing, pay attention to the support for the Internet of Things, including: 1) support for commonly used MQTT, XMPP, COAP, HTTP, and TCP protocols; 2) support for creating multi-tenants by project, user, group and other dimensions, support for different protocols, and hierarchical security certification; 3) support for MQTT3.1 or above to avoid repeated consumption; 4) support for dynamic monitoring.

Config microservice and Handler microservice: they are the environment in which the business system runs. The development language can be Java, Python, C, etc. It is recommended to use an environment that supports JVM. The software architecture suggests a microservice system, which facilitates automatic registration and configuration of services.

Device registration: Determine whether there is a communication protocol for edge devices in the Config microservice.

If there is no communication protocol for the edge device, perform protocol extension steps.

If there is a communication protocol for the edge device, select the project and communication protocol to which the edge device is to be registered, enter the device information, complete the device registration, and perform the device activation steps.

Protocol extension: Select the standard communication protocol framework predefined by Config microservices to extend the communication protocol of edge devices, among which:

The protocol extension steps specifically include:

Protocol development: based on the predefined standard communication protocol framework of Config microservices, define the attributes, actions, events, and heartbeats of the edge devices to be added.

Model encapsulation: Compile and unit test the four types of codes for the properties, actions, events, and heartbeats of the edge devices that need to be added, and package them into independent model packages.

Model verification: upload the model package to the object repository or file server through the Config microservice, and then download it to the local to read the model, and perform normative inspection and verification on the model package.

If validation fails, an error message is displayed and suggestions for improvement are displayed.

If the validation passes, perform model preloading.

Model preloading: Load the verified model package to the Config microservice to preheat the object instantiation.

If the preheating fails, it will prompt and display the conflict resolution method.

If warmup is successful, perform model deployment.

Model deployment: The Config microservice loads and sends messages to the system topic model of the message server. After receiving the message, the Handler microservice performs asynchronous operations, loads the model package, and completes the dynamic deployment of the edge device communication protocol.

Device activation: The Config microservice sends a device activation message to the message server's system topic consumption startup, and at the same time dynamically creates tenants, namespaces, business topics, and certificate authorization in the message server, among which:

Referring to Figure 2, the device activation steps specifically include:

Create tenants: The Config microservice dynamically adds tenants in units of projects in the message server.

Create a namespace: Dynamically add a namespace in the message server based on the model library.

Create a topic: Create a corresponding topic according to the security control level when the device is registered, among which:

The security control level in creating a theme is divided into item-level control, device object model-level control and device instance-level control. Project-level control means that all devices under a project belong to the same tenant and namespace, and share related topics; device object model-level control means that the same type of devices belong to the same namespace, and share related topics; device instance-level control means that each device has an independent theme.

Generate key: Generate an authorization key based on the master machine number, account key, and project key information.

Certificate Authority: Generate security certificates based on keys.

Activation message: The Config microservice sends an activation message to the consumer system topic of the message server.

Device monitoring: After receiving the device activation message, the consumption start listener of the Handler microservice dynamically creates a listener corresponding to the business topic of the edge device, among which:

Referring to Figure 3, the device monitoring steps specifically include:

After the Handler microservice receives the activation message, it queries the cache information to determine whether the current node has started monitoring the business topic of the edge device.

If started, the program prompts and returns.

If it is not started, query the protocol framework to which the edge device belongs, initialize the service processing interface, create a monitor for the business topic of the edge device, and save the activated information in the cache, and use polling to share the load for each node's monitoring of the same business topic.

Data communication: The edge device sends data to the business topic of the message server.

Data processing: After receiving the message, the corresponding business listener of the Handler microservice searches for the communication protocol corresponding to the edge device, analyzes the message, and stores the remote data into the real-time database, among which:

The data processing steps specifically include:

Device subscription: edge devices send production data in real time according to the pre-agreed topic name in the extension agreement.

Topic consumption: The topic listener of the Handler microservice receives the message, and calls the business processing interface stipulated in the protocol to process the message.

Data storage: business processing interface parses data, generates data instantiation objects, creates data table structure, and dynamically inserts data records.

Online analysis: data statistical analysis and related business systems query the real-time data of the device and perform streaming calculations.

The dynamic expansion and hot-swapping method of the device communication protocol provided by the embodiment of the application relies on a set of self-expanding standard communication protocol framework, which greatly reduces the workload of definition and analysis of various device communication protocols, greatly facilitates the access of edge devices and the removal of old devices, reduces the dependence on the startup and deployment of business systems, and realizes arbitrary insertion and removal of devices under the framework of standard communication protocols.

At the same time, relying on the message server, through the dynamic creation, subscription, and cancellation mechanism of the topic, the hot-swappable deployment of the device under the three-level control can be realized, and the real-time communication of the data of the device can be quickly realized, and the rapid blocking under abnormal conditions can avoid the spread of security problems, reduce the cost of manual intervention, and realize refined management and control. The flexible insertion and extraction mechanism of equipment reduces the dependence on business systems and improves work efficiency. Relying on the refined three-level control, the safety control of the equipment is realized, the operation is simplified, and the labor cost is saved.

Taking dynamic access to an edge device as an example, describe the principles of dynamic expansion of communication protocols, dynamic activation of devices, and instant data communication:

As shown in Figure 1, the parties involved in the system mainly include four parts: message server, real-time database, Config microservice and Handler microservice, among which:

The dynamic expansion of the communication protocol is realized through the Config micro-service. For commonly used IoT protocols in the system, such as HTTP, TCP, MQTT, XMPP, COAP, etc., a set of corresponding standard communication protocol frameworks are pre-defined for edge devices to choose when accessing. The quasi-communication protocol framework does not limit the data format of communication, and supports Json, message, XML, binary string, etc. The protocol framework uses objectification to describe the object model and business algorithm of the device, and fully defines the attributes, actions, events, and heartbeats of the object model.

Realize device hot-swapping and instant communication through the Handler microservice. When the microservice starts, it will perform initialization work, create system tenants, system namespaces, and six system themes by default in the message server, and start six system listeners corresponding to the six system themes, which are used for model deployment, business theme consumption activation, business theme production activation, business theme consumption stop, business theme production stop, and business theme sending for function correction.

The following is a short description of the implementation process.

1. Protocol extension: When there is a request to add an edge device, select the standard communication protocol framework predefined by the Config microservice to expand the communication protocol of the device, including data format, analysis method, processing result, reverse control, etc.;

2. Protocol encapsulation: encapsulate each part of the protocol into a complete functional package;

3. Protocol check: upload the function package to the Config microservice, check the protocol, and send a protocol loading message to the system topic "Model Loading" of the message server after the check is passed;

4. Protocol loading: Handler microservice "model loading listener" receives the protocol loading message, starts to download the function package, and dynamically loads the new device protocol into the protocol library;

5. Device activation: The Config microservice sends a device activation message to the system topic "Consumption Start" of the message server, and at the same time dynamically creates tenants, namespaces, and business topics (such as topic_a topic, not the six pre-defined system topics in the Handler microservice) in the message server, and performs certificate authorization.

6. Device monitoring: After receiving the device activation message, the Handler microservice "consumption start listener" dynamically creates a listener corresponding to the business topic of the device (here dynamically creates a business listener for the topic_a topic, such as listener_a, which is not a pre-defined six major system listeners in the Handler microservice).

7. Data communication: the edge device sends data to the business topic "topic_a" of the message server.

8. Data processing: After receiving the message, the corresponding business listener "listener_a" of the Handler microservice searches for the protocol corresponding to the device, analyzes the message, and stores the remote data into the real-time database.

System platform architecture:

The first layer: real-time database, which stores the real-time data collected by the equipment;

The second layer: message server, which supports dynamic creation, consumption and production of topics, and realizes asynchronous communication;

The third layer: micro-service clusters, including Config micro-service clusters to realize dynamic expansion of communication protocols; Handler micro-service clusters to realize hot-swappable devices and instant messaging.

specific embodiment

Taking the MQTT protocol as an example, the specific implementation process of edge device protocol extension and data collection is described.

Step 1: Environment deployment, including real-time database, message server, Config microservice, Handler microservice, optional business components include cache server, object storage server;

The second step: protocol expansion, when a new type of equipment is connected, first expand the protocol;

Step 2.1: Protocol development. In this example, the MQTT communication protocol framework is selected to describe the attributes, actions, events, and heartbeats of the device. For example, to define the properties of a video recorder device, the class name is "Tv Prop", where "Tv" means ${custom class name}, and "Prop" means ${object model classification}. This class must implement the IMqttR interface, which represents topic subscription and is used to receive messages. The @Dev annotation indicates that the type of the topic is "Prop". The example is as follows:

Two methods of IMqttR interface:

The fields of the Recorder subclass are the properties of the device, which are defined by the developer. Each field must be annotated with @Prop. The attributes of the video recorder device defined in this example are:

SDevice is used to define the public attributes of the device. There are 4 attribute fields by default, which are timestamp, device number, message number, and device name.

The @Dev annotation identifies the type of topic, the name of the supertable, and the name of the topic.

The @Prop annotation is used to define device property fields, including name, data type, tags, subtable tags, and description. The source code is as follows:

Step 2.2: Model encapsulation. After the development is completed, compile and unit test the four types of codes of device attributes, actions, events, and heartbeats, and finally package them into independent jar packages.

Step 2.3: Model verification, upload the model package to the object repository or file server through the Config microservice. Then download it locally to read the model, check the normativeness of each part model, and verify it. If there is an error, it will prompt that the model verification failed, and display specific improvement suggestions.

Step 2.4: Preload the model. After the verification is passed, load it into the Config microservice to warm up the object instantiation. If it fails, it will prompt the conflict handling method. The example is as follows:

Step 2.5: Model deployment. After the warm-up is successful, the Config microservice sends a message to the "Model Loading" system topic of the message server. After the Handler microservice receives the message, it performs asynchronous operations, loads the model, and completes the dynamic deployment of the edge device protocol.

Step 3: Device registration. If you want to add an edge device, add it in the Config microservice, select the project to which the device is to be registered, and select three levels of security control for the device. Then select the model deployed in the previous step to complete the registration of the device.

Step 3.1: Add the edge device in the Config microservice, first determine whether there is a communication protocol for the device.

Step 3.2: If there is an agreement, select the project to which the device will be registered. The security control level of the device can be selected from three levels, then select the protocol model deployed in the previous step, and enter the key information such as the number and name of the device to complete the registration of the device;

Step 3.3: No agreement, enter the second step;

Step 4: Device activation, select the device to be activated in the Config microservice, the message server performs initialization related operations, and notifies the instant messaging module to asynchronously activate the monitoring of the topic.

Step 4.1: Create tenants, and the Config microservice dynamically adds tenants in units of projects in the message server.

Step 4.2: Create a namespace, dynamically add a namespace in the message server based on the model library, and the default namespace is default.

Step 4.3: Create a theme, and establish a corresponding theme according to the security control level when the device is registered. Project-level control means that all devices under a project belong to the same tenant and default namespace, and share related topics; device object model-level control means that the same type of devices belong to the same namespace, and share related topics; device instance level means that each device has an independent theme.

Step 4.4: Generate a key, and generate an authorization key based on the master station machine number, account key, and project key information.

Step 4.5: Certificate authorization, generate a security certificate based on the key, including certificate type (management terminal/client), subject, algorithm (NONE, HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512, the default is RS256), validity period (one year is 1y, 1 hour is 1h, 3 days is 3d), expiration Date, scope of authorization (consume, produce, functions, sources, sinks, packages).

Step 4.5: Activate the message, the Config microservice sends a message to the message server "consumption start" system topic, the message includes information such as the tenant, topic, certificate, and the protocol framework to which the device belongs.

Step 4.6: Dynamic monitoring. After the Handler microservice receives the message, it queries the cache information to determine whether the current node has started monitoring the topic. If yes, the program prompts and returns; otherwise, it queries the protocol framework to which the device belongs, initializes the business processing interface, creates a monitoring of the business topic, and saves the activated information in the cache. For the monitoring of the same business topic by each node, the polling method will be used to share the load. The example is as follows:

final String topic = topicDto.getFullTopic();

StringsubscriptName=topicDto.getSubscriptionPrefix()+tenantId+namespaceId+topicId;

new OnMsgConsumerBusinessListener(topicDto. getModelDto(), dataHandler);

Step 5: Data processing, the business topic receives the real-time data sent by the edge end and saves it in the real-time database.

Step 5.1: Device subscription, the edge device sends production data in real time according to the pre-agreed topic name in the extension agreement.

Step 5.2: topic consumption, the topic listener of the Handler microservice receives the message, and calls the business processing interface agreed in the protocol to process the message.

Step 5.3: Data storage, business processing interface parses data, generates data instantiation objects, creates data table structure, and dynamically inserts data records. Examples are as follows:

Tuple2<String,List<Object>>t2=ReflectUtils.getInsSql(mqttObj.getClass(),device);

jdbcTemplate. update(t2);

Step 5.4: Online analysis, data statistical analysis and related business systems query the real-time data of the device and perform stream calculation.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: it can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements to some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims (6)

1. a dynamic expansion and hot plug method of equipment communication protocol, is characterized in that, comprises the steps: Environment deployment: deploy real-time database, message server, Config microservice, Handler microservice; Device registration: determine whether there is a communication protocol for edge devices in the Config microservice; If there is no communication protocol for the edge device, then perform protocol extension steps; If there is a communication protocol for the edge device, select the project and communication protocol for the edge device to register, enter the device information, complete the device registration, and perform the device activation steps; Protocol extension: select the standard communication protocol framework predefined by Config microservices to expand the communication protocol of edge devices; Device activation: The Config microservice sends a device activation message to the system topic consumption start of the message server, and at the same time dynamically creates tenants, namespaces, business topics, and certificate authorization in the message server; Device monitoring: After receiving the device activation message, the consumption start listener of the Handler microservice dynamically creates a listener corresponding to the business topic of the edge device; Data communication: the edge device sends data to the business topic of the message server; Data processing: After receiving the message, the corresponding business listener of the Handler microservice searches for the communication protocol corresponding to the edge device, analyzes the message, and stores the remote data into the real-time database. 2. The dynamic extension and hot plug method of equipment communication protocol according to claim 1, is characterized in that, described protocol expansion step comprises: Protocol development: Based on the standard communication protocol framework predefined by Config microservices, define the attributes, actions, events, and heartbeats of the edge devices to be added; Model encapsulation: Compile and unit test the four types of codes for the properties, actions, events, and heartbeats of the edge devices that need to be added, and package them into independent model packages; Model verification: upload the model package to the object repository or file server through the Config microservice, and then download it to the local to read the model, and perform normative inspection and verification on the model package; If the verification fails, an error message is displayed and suggestions for improvement are displayed; If the verification is passed, perform model preloading; Model preloading: load the verified model package to the Config microservice to preheat object instantiation; If the preheating fails, prompt and display the conflict resolution method; If the warm-up is successful, execute the model deployment; Model deployment: The Config microservice loads and sends messages to the system topic model of the message server. After receiving the message, the Handler microservice performs asynchronous operations, loads the model package, and completes the dynamic deployment of the edge device communication protocol. 3. The dynamic expansion and hot plug method of equipment communication protocol according to claim 2, is characterized in that, described equipment activation step comprises: Create tenants: Config micro-services dynamically add tenants in units of projects in the message server; Create a namespace: dynamically add a namespace in the message server based on the model library; Create a theme: Create a corresponding theme according to the security control level when the device is registered; Generating keys: Generate authorization keys according to the master station machine number, account key, and project key information; Certificate authorization: generate a security certificate based on the key; Activation message: The Config microservice sends an activation message to the consumer system topic of the message server. 4. The dynamic extension and hot plug method of equipment communication protocol according to claim 3, is characterized in that, described equipment monitoring step comprises: After the Handler microservice receives the activation message, it queries the cache information to determine whether the current node has started monitoring the business topic of the edge device; If it is started, the program prompts and returns; If it is not started, query the protocol framework to which the edge device belongs, initialize the business processing interface, create a monitor for the business topic of the edge device, and save the activated information in the cache, and use polling to share the load for each node's monitoring of the same business topic. 5. The dynamic expansion and hot plug method of equipment communication protocol according to claim 4, is characterized in that, described data processing step comprises: Device subscription: Edge devices send production data in real time according to the pre-agreed topic name in the extension agreement; Topic consumption: The topic listener of the Handler microservice receives the message, and calls the business processing interface agreed in the protocol to process the message; Data storage: business processing interface parses data, generates data instantiation objects, creates data table structure, and dynamically inserts data records; Online analysis: data statistical analysis and related business systems query the real-time data of the device and perform streaming calculations. 6. The dynamic expansion and hot-swapping method of the device communication protocol according to claim 3, wherein the security control level in the creation theme is divided into project-level control, device object model-level control and device instance-level control; Project-level control means that all devices under a project belong to the same tenant and namespace, and share related topics; The device object model level control is that the same class of devices belong to the same namespace and share related topics; Device instance-level controls have separate topics for each device.