A modbus device access method and system based on microservice architecture

Abstract

The present invention proposes a modbus device access method and system based on a microservice architecture. The modbus device access method based on the microservice architecture includes: splitting the overall system to be set up with microservices to obtain multiple microservice projects; setting up microservice architectures for multiple microservice projects to obtain microservice architectures corresponding to each microservice project; testing and deploying the microservice architectures corresponding to each microservice project, and regularly maintaining and updating the microservice architectures corresponding to each microservice project that has completed testing and deployment. The system includes modules corresponding to the steps of the method.

Description

Technical Field

[0001] The invention proposes a modbus device access method and system based on a microservice architecture, belonging to the technical field of device access. Background Art

[0002] The traditional monolithic architecture concentrates the business logic in a single application, which may seem a simple and effective approach at first. However, this architecture approach may bring a series of problems when facing a large number of Modbus devices:

[0003] Performance bottleneck: When a large number of Modbus devices are connected at the same time, a single Modbus driver service may not be able to effectively handle all requests, resulting in performance degradation. This may cause delays and long response times.

[0004] Scalability issues: Traditional monolithic architectures are difficult to achieve good scalability. As the number of devices increases, the expansion of a single application will become complicated and may require more hardware resources and manpower investment.

[0005] Single point of failure: Since all business logic is concentrated in one application, if there is a problem with that application, the entire system may be affected. This leads to the fragility of the system, which is susceptible to single point of failure.

[0006] Difficult to maintain: Monolithic architectures often result in large and complex code bases that are difficult to maintain and understand. This makes it difficult to update and fix the application, which can lead to the introduction of bugs.

[0007] Lack of flexibility: Traditional monolithic architectures are often not flexible enough to cope with changing requirements. When adding new features or responding to new Modbus device types, the entire application may need to be modified. Summary of the invention

[0008] The present invention provides a modbus device access method and system based on a microservice architecture, which is used to solve the problem in the prior art that when there are many access devices, the modbus driver service is prone to problems and may affect the entire program. The technical solutions adopted are as follows:

[0009] A modbus device access method based on a microservice architecture, the modbus device access method based on a microservice architecture comprising:

[0010] Split the overall system to be set up for microservices and obtain multiple microservice projects;

[0011] Set up microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project;

[0012] The microservice architecture corresponding to each microservice project is tested and deployed, and the microservice architecture corresponding to each microservice project that has completed testing and deployment is regularly maintained and updated.

[0013] Furthermore, the overall system to be set up for microservices is split to obtain multiple microservice projects, including:

[0014] Extract the system structure of the overall system to be set up by the microservice and obtain the subsystems of the overall system;

[0015] Classifying the functions performed by each subsystem to obtain a subsystem library corresponding to each function type; wherein the subsystem library includes a device unit corresponding to each subsystem;

[0016] Extract each device in the device unit corresponding to each subsystem;

[0017] A microservice project is set for each device in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice and a data flow microservice.

[0018] Furthermore, a microservice architecture is set for multiple microservice projects to obtain a microservice architecture corresponding to each microservice project, including:

[0019] Retrieve each device setting microservice project in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice, and a data flow microservice;

[0020] Set up the device driver microservice structure for the device driver microservice;

[0021] The message proxy microservice structure is set for the message proxy microservice; specifically, the message proxy microservice is used to handle the transmission of device data and message routing. It can be implemented using a message queue or event bus. The device driver microservice sends data to the message proxy, which is responsible for routing the data to appropriate services, such as the rule engine, data statistical analysis, etc.

[0022] The rule engine microservice structure is set for the rule engine microservice; specifically, the rule engine microservice is used to define and execute data processing rules, such as data filtering, data conversion, alert generation, etc. The rules can be triggered based on the received data.

[0023] The data statistical analysis microservice structure is set for the data statistical analysis microservice; specifically, the data statistical analysis microservice is responsible for real-time or offline analysis of data, generating reports or performing advanced data processing. It can be integrated with an analysis library or a machine learning model.

[0024] Set up the data flow microservice structure for the data flow microservice. Specifically, when a new device is connected to the device, there should be an automated deployment process. This can be an automated script or use a container orchestration tool (such as Docker Compose, Kubernetes) to start a new device driver microservice instance.

[0025] Furthermore, the device driver microservice structure is set for the device driver microservice, including:

[0026] Use the Modbus communication library to set the communication protocol and communication method between the device to be driven and the Modbus device;

[0027] The communication data format between the device to be driven and the Modbus device is set according to the communication protocol and communication mode between the device to be driven and the Modbus device.

[0028] Further, the communication data format between the device to be driven and the Modbus device is set according to the communication protocol and communication mode between the device to be driven and the Modbus device, including:

[0029] extracting a data format conforming to the communication protocol as a candidate data format;

[0030] Extracting the data format contained in the data generated by the device to be driven;

[0031] Extracting data corresponding to each data format of the target data volume; wherein the value range of the target data volume is 10MB-50MB;

[0032] Converting the data corresponding to each data format into the candidate data format in sequence, and obtaining an average time duration for converting the data corresponding to each data format into the candidate data format;

[0033] Extracting a data format corresponding to a maximum value of an average time duration for data conversion from each data format to the candidate data format as a tentative data format;

[0034] Extract the average data conversion time corresponding to the conversion of the tentative data format into the candidate data format in sequence;

[0035] According to the average data conversion time, the conversion parameters corresponding to the conversion of the tentative data format to the candidate data format are obtained in sequence; wherein the conversion parameters are obtained by the following formula:

[0036]

[0037] Where X represents the conversion parameter; T max Indicates the time length corresponding to the maximum value of the average duration; T min Indicates the time length corresponding to the minimum value of the average duration; X 0 represents the preset benchmark parameter value; C represents the average amount of data generated per unit time in the provisional data format corresponding to the maximum value of the average duration; C z Indicates the total amount of data generated per unit time by the device to be driven;

[0038] The candidate data format corresponding to the minimum value of the conversion parameter is used as the communication data format between the device to be driven and the Modbus device.

[0039] A modbus device access system based on a microservice architecture, the modbus device access system based on a microservice architecture comprising:

[0040] The microservice project acquisition module is used to split the overall system to be set up for microservices and obtain multiple microservice projects;

[0041] The microservice architecture acquisition module is used to set the microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project;

[0042] The testing and deployment module is used to test and deploy the microservice architecture corresponding to each microservice project, and to regularly maintain and update the microservice architecture corresponding to each microservice project that has completed testing and deployment.

[0043] Furthermore, the microservice project acquisition module includes:

[0044] The subsystem extraction module is used to extract the system structure of the overall system to be set up by the microservice and obtain the subsystems of the overall system;

[0045] A subsystem library acquisition module, used to classify the functions performed by each subsystem and obtain a subsystem library corresponding to each function type; wherein the subsystem library includes a device unit corresponding to each subsystem;

[0046] A subsystem corresponding device extraction module is used to extract each device in the device unit corresponding to each subsystem;

[0047] The microservice project setting module is used to set up microservice projects for each device in the device unit corresponding to each subsystem; wherein the microservice projects include device driver microservice, message proxy microservice, rule engine microservice, data statistical analysis microservice and data flow microservice.

[0048] Furthermore, the microservice architecture acquisition module includes:

[0049] A microservice project calling module is used to call each device setting microservice project in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice, and a data flow microservice;

[0050] A device driver microservice structure setting module is used to set the device driver microservice structure for the device driver microservice;

[0051] The message proxy microservice structure setting module is used to set the message proxy microservice structure for the message proxy microservice; specifically, the message proxy microservice is used to handle the transmission of device data and message routing. It can be implemented using a message queue or an event bus. The device driver microservice sends data to the message proxy, which is responsible for routing the data to appropriate services, such as the rule engine, data statistical analysis, etc.

[0052] The rule engine microservice structure setting module is used to set the rule engine microservice structure for the rule engine microservice; specifically, the rule engine microservice is used to define and execute data processing rules, such as data screening, data conversion, alarm generation, etc. The rules can be triggered based on the received data.

[0053] The data statistics analysis microservice structure setting module is used to set the data statistics analysis microservice structure for the data statistics analysis microservice; specifically, the data statistics analysis microservice is responsible for real-time or offline analysis of data, generating reports or performing advanced data processing. It can be integrated with an analysis library or a machine learning model.

[0054] The data flow microservice structure setting module is used to set the data flow microservice structure for the data flow microservice. Specifically, when a new device is connected to the device, there should be an automated deployment process. This can be an automated script or use a container orchestration tool (such as Docker Compose, Kubernetes) to start a new device driver microservice instance.

[0055] Furthermore, the device driver microservice structure setting module includes:

[0056] The communication parameter setting module is used to set the communication protocol and communication mode between the device to be driven and the Modbus device using the Modbus communication library;

[0057] The communication data format setting module is used to set the communication data format between the device to be driven and the Modbus device according to the communication protocol and communication mode between the device to be driven and the Modbus device.

[0058] Furthermore, the communication data format setting module includes:

[0059] A candidate data format extraction module, used to extract data formats that conform to the communication protocol as candidate data formats;

[0060] A device-generated data format extraction module, used to extract the data format contained in the data generated by the device to be driven;

[0061] A data information volume extraction module is used to extract data corresponding to each data format of the target data volume; wherein the value range of the target data volume is 10MB-50MB;

[0062] A data format conversion module, used to convert the data corresponding to each data format into the candidate data format in sequence, and obtain an average time duration for converting the data corresponding to each data format into the candidate data format;

[0063] A provisional data format extraction module, used to extract a data format corresponding to a maximum value of an average time length for data conversion from each data format to the candidate data format as a provisional data format;

[0064] A data conversion average duration extraction module, used for extracting the corresponding average duration of data conversions of the provisional data format to the candidate data format in sequence;

[0065] The conversion parameter acquisition module is used to acquire the conversion parameters corresponding to the conversion of the tentative data format to the candidate data format in sequence according to the average duration of the data conversion; wherein the conversion parameters are acquired by the following formula:

[0066]

[0067] Where X represents the conversion parameter; T max Indicates the time length corresponding to the maximum value of the average duration; T min Indicates the time length corresponding to the minimum value of the average duration; X 0represents the preset benchmark parameter value; C represents the average amount of data generated per unit time in the provisional data format corresponding to the maximum value of the average duration; C z Indicates the total amount of data generated per unit time by the device to be driven;

[0068] The data format determination module is used to use the candidate data format corresponding to the minimum value of the conversion parameter as the communication data format between the device to be driven and the Modbus device.

[0069] Beneficial effects of the present invention:

[0070] The present invention proposes a modbus device access method and system based on microservice architecture, which adopts microservice architecture to split services such as device driver, message proxy, rule engine, data statistical analysis, and data flow. Each device provides additional redundant modbus driver services to increase device access reliability, and automatically starts new driver services when new devices are connected. Flexible deployment can be achieved, while improving the reliability of platform access devices and the scalability of computing performance. At the same time, it allows business logic to be split into small, independently deployable and scalable services, providing better performance, scalability, and fault tolerance. This approach can effectively cope with the challenges of accessing a large number of Modbus devices and provide a more flexible, maintainable, and scalable solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 is a flow chart of the method of the present invention;

[0072] Figure 2 The system block diagram of the system of the present invention. DETAILED DESCRIPTION

[0073] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0074] The embodiment of the present invention proposes a modbus device access method based on a microservice architecture, such as Figure 1 As shown, the modbus device access method based on microservice architecture includes:

[0075] S1. Split the overall system to be set up for microservices and obtain multiple microservice projects;

[0076] S2. Set up microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project;

[0077] S3. Test and deploy the microservice architecture corresponding to each microservice project, and regularly maintain and update the microservice architecture corresponding to each microservice project that has completed testing and deployment.

[0078] The working principle of the above technical solution is as follows: Split the overall system (S1): First, split the overall system to be microserviced. This step is about dividing the original single application or system into multiple microservice projects, each of which focuses on a specific function or service.

[0079] Microservice architecture setup (S2): Set up the corresponding microservice architecture for each microservice project. Microservice architecture is a distributed architecture in which the system consists of multiple small, autonomous services that can be deployed and scaled independently. In this step, the service boundaries, API interfaces, data storage, communication methods, etc. of each microservice project are defined.

[0080] Test, deploy, maintain, and update (S3): Perform a series of operations on the microservice architecture corresponding to each microservice project, including:

[0081] Testing: Ensure that each microservice project runs properly as defined by the microservice architecture, can perform its specific functions, and can work with other microservices.

[0082] Deployment: Deploy each microservice project to the corresponding operating environment as needed, such as a container, cloud service, or physical server.

[0083] Regular maintenance: Monitor and maintain each microservice project to ensure its performance, availability, and security. This may include tasks such as troubleshooting, updates, and patch management.

[0084] Update: Each microservice project is updated regularly to adapt to new requirements, fix vulnerabilities, or introduce new features.

[0085] The effects of the above technical solutions are: Modularity and elasticity: After adopting the microservice architecture, the system becomes more modular, each microservice runs independently and is easy to expand or reduce, thereby increasing the elasticity of the system.

[0086] Rapid development and deployment: Each microservice project can be independently developed, tested, and deployed by different development teams, thus accelerating the development cycle.

[0087] Flexibility in maintenance and updates: The independence of microservice projects means that maintenance and updates can be more flexible without affecting the entire system.

[0088] Fault tolerance and availability: The independence of microservice projects also improves the fault tolerance of the system. The failure of one microservice will not affect the availability of the entire system.

[0089] Better resource management: Microservice architecture allows for better management of system resources, allocating and releasing resources based on demand, and improving resource utilization.

[0090] In general, this technical solution makes the system more flexible, maintainable, and scalable through the adoption of microservice architecture, which helps to meet the needs of modern applications, especially in large-scale, complex, and distributed systems.

[0091] In one embodiment of the present invention, the overall system to be set up for microservices is split to obtain multiple microservice projects, including:

[0092] S101, extracting the system structure of the overall system to be set up by the microservice, and obtaining each subsystem of the overall system;

[0093] S102, classifying the functions performed by each subsystem to obtain a subsystem library corresponding to each function type; wherein the subsystem library includes a device unit corresponding to each subsystem;

[0094] S103, extracting each device in the device unit corresponding to each subsystem;

[0095] S104. Set up a microservice project for each device in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice, and a data flow microservice.

[0096] The working principle of the above technical solution is: extract the system structure of the overall system (S101): first, analyze the overall system to be microserviced, and extract its system structure, including the composition and mutual relationship of each subsystem.

[0097] Function classification and subsystem library (S102): Classify the functions performed by each subsystem in the overall system. This step helps to organize subsystems with similar functions together and build a subsystem library. Each subsystem library includes a group of subsystems that belong to the same functional type and may include different equipment units.

[0098] Device unit extraction (S103): extracting each device from the device unit corresponding to each subsystem. A device unit usually includes a group of devices that work together in the overall system to provide specific functions.

[0099] Microservice project setting (S104): Set up microservice projects for each device in the device unit corresponding to each subsystem. These microservice projects include different types of microservices, such as device driver microservices, message proxy microservices, rule engine microservices, data statistics analysis microservices, and data flow microservices. Each microservice type has its specific responsibilities to support the functions and data processing of the device.

[0100] The effects of the above technical solution are: Modular system: split the overall system to make it more modular, and each subsystem and equipment unit can be independently developed, deployed and maintained.

[0101] Granularity control of microservices: By setting up different types of microservices for devices in each subsystem, the granularity of microservices can be finely controlled to ensure that each microservice has specific responsibilities.

[0102] Flexibility: The functional classification and microservice settings of the overall system improve the flexibility of the system. Microservices can be easily added, replaced or upgraded to meet changing requirements.

[0103] Performance optimization: Different types of microservices can focus on their specific tasks, thereby optimizing performance and improving the responsiveness and efficiency of the system.

[0104] Facilitates teamwork: Each microservice project can be managed by a different development team, which helps parallel development, reduces conflicts, and improves development efficiency.

[0105] In general, the above technical solution of this embodiment helps to prepare for the microservice transformation of the overall system, making the system more flexible, maintainable and scalable.

[0106] In one embodiment of the present invention, a microservice architecture is set for multiple microservice projects to obtain a microservice architecture corresponding to each microservice project, including:

[0107] S201, calling each device setting microservice project in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice and a data flow microservice;

[0108] S202, setting a device driver microservice structure for the device driver microservice;

[0109] S203, setting the message proxy microservice structure for the message proxy microservice; specifically, the message proxy microservice is used to handle the transmission of device data and message routing. It can be implemented using a message queue or an event bus. The device driver microservice sends data to the message proxy, which is responsible for routing the data to appropriate services, such as a rule engine, data statistical analysis, etc.

[0110] S204. Setting the rule engine microservice structure for the rule engine microservice; specifically, the rule engine microservice is used to define and execute data processing rules, such as data screening, data conversion, alarm generation, etc. The rules can be triggered based on the received data.

[0111] S205. Set up a data statistics analysis microservice structure for the data statistics analysis microservice. Specifically, the data statistics analysis microservice is responsible for real-time or offline analysis of data, generating reports or performing advanced data processing. It can be integrated with an analysis library or a machine learning model.

[0112] S206. Set up the data flow microservice structure for the data flow microservice. Specifically, when a new device is connected to the device, there should be an automated deployment process. This can be an automated script or use a container orchestration tool (such as DockerCompose, Kubernetes) to start a new device driver microservice instance.

[0113] The working principle of the above technical solution is as follows: Device driver microservice structure setting (S202): This step specifically involves the structure setting of the device driver microservice. The device driver microservice is responsible for communication with the physical device, data collection and transmission. Its structure will include settings in terms of interface definition, communication protocol, data parsing, error handling, etc. to ensure the correct connection of the device and data collection.

[0114] Message broker microservice structure setting (S203): The message broker microservice is used to handle the transmission of device data and message routing. It ensures the reliable delivery and routing of data to appropriate services. The structure of the message broker may include message queues, topic subscriptions, routing rules, etc. to meet the needs of message delivery and distribution.

[0115] Rule engine microservice structure setting (S204): The rule engine microservice is responsible for defining and executing data processing rules, such as data filtering, data conversion, alert generation, etc. The structure of the rule engine will include settings in terms of rule definition, condition checking, data processing, action triggering, etc., so as to process data in real time.

[0116] Data statistics analysis microservice structure setting (S205): The data statistics analysis microservice is responsible for real-time or offline analysis of data, generating reports or performing advanced data processing. Its structure may involve data stream processing, storage, analysis algorithms, etc. to meet the needs of data analysis.

[0117] Data flow microservice structure setting (S206): The data flow microservice is responsible for the automated deployment process when a new device is connected to the device. This may involve the use of automated scripts and container orchestration tools (such as Docker Compose and Kubernetes) to start a new device driver microservice instance.

[0118] The effects of the above technical solutions are: Microservice hierarchical structure: Each microservice type has specific responsibilities and structures to achieve a hierarchical microservice architecture. This improves maintainability and scalability.

[0119] Clear functionality: Each microservice type focuses on its specific task, increasing code clarity and manageability.

[0120] Integration: Clear interface definitions and collaboration between different microservice types enable smooth data transmission and processing.

[0121] Automation: Automated deployment processes ensure rapid access to new devices, reduce the need for manual configuration, and improve efficiency.

[0122] In general, the above technical solution of this embodiment helps to create a structure for each microservice project and ensures that each type of microservice can effectively complete its tasks while ensuring the collaboration between them. This helps to build an efficient, flexible and easy-to-maintain microservice architecture.

[0123] In one embodiment of the present invention, a device driver microservice structure is set for a device driver microservice, including:

[0124] S2021. Use the Modbus communication library to set the communication protocol and communication method between the device to be driven and the Modbus device;

[0125] S2022. Setting a communication data format between the device to be driven and the Modbus device according to the communication protocol and communication mode between the device to be driven and the Modbus device.

[0126] The working principle of the above technical solution is: using the Modbus communication library to set the communication protocol and mode (S2021): In this step, the Modbus communication library is used to configure the communication protocol and communication mode between the device to be driven and the Modbus device. Modbus is a common communication protocol widely used in the field of industrial automation. Through the Modbus communication library, the parameters of the communication protocol can be defined, such as communication speed, data bit, stop bit, check mode, etc. This step ensures that the communication between the device to be driven and the Modbus device can be correctly established.

[0127] Set the communication data format (S2022): In order to ensure effective communication, the communication data format between the device to be driven and the Modbus device needs to be set according to the defined communication protocol. This includes the encoding and decoding methods of the data, the format of the data packet (such as register address, function code, etc.) and the method of interpreting the data. The correct setting of the communication data format ensures that the data exchange between devices is accurate and reliable.

[0128] The effects of the above technical solution are: Modbus communication support: By utilizing the Modbus communication library, communication between the device to be driven and the Modbus device can be easily achieved, ensuring the interoperability between the devices.

[0129] Communication protocol consistency: Defining the communication protocol and data format ensures that the communication parameters between the device to be driven and the Modbus device are consistent, thereby reducing the possibility of communication errors.

[0130] Data accuracy: Properly formatting communications data helps ensure accurate transmission and interpretation of data, thereby improving data reliability and consistency.

[0131] In general, the above technical solution of this embodiment ensures that the device driver microservice can effectively communicate with the Modbus device, accurately transmit and interpret data, thereby realizing the collection and transmission function of device data. This is very important for fields such as industrial automation and equipment monitoring.

[0132] In one embodiment of the present invention, the communication data format between the device to be driven and the Modbus device is set according to the communication protocol and communication mode between the device to be driven and the Modbus device, including:

[0133] Step 1, extracting a data format that complies with the communication protocol as a candidate data format;

[0134] Step 2, extracting the data format contained in the data generated by the device to be driven;

[0135] Step 3, extracting data corresponding to each data format of the target data volume; wherein the value range of the target data volume is 10MB-50MB;

[0136] Step 4: Convert the data corresponding to each data format into the candidate data format in sequence, and obtain an average time for converting the data corresponding to each data format into the candidate data format;

[0137] Step 5, extracting the data format corresponding to the maximum value of the average time for converting the data corresponding to each data format to the candidate data format as a tentative data format;

[0138] Step 6: extracting the average data conversion time corresponding to the conversion from the tentative data format to the candidate data format in sequence;

[0139] Step 7: Obtain the conversion parameters corresponding to the conversion of the tentative data format to the candidate data format in sequence according to the average data conversion time; wherein the conversion parameters are obtained by the following formula:

[0140]

[0141] Where X represents the conversion parameter; T max Indicates the time length corresponding to the maximum value of the average duration; T min Indicates the time length corresponding to the minimum value of the average duration; X 0 represents the preset benchmark parameter value; C represents the average amount of data generated per unit time in the provisional data format corresponding to the maximum value of the average duration; C z Indicates the total amount of data generated per unit time by the device to be driven;

[0142] Step 8: Use the candidate data format corresponding to the minimum value of the conversion parameter as the communication data format between the device to be driven and the Modbus device.

[0143] The working principle of the above technical solution is as follows: Extract candidate data formats (step 1): First, extract candidate data formats from the defined communication protocol, and these data formats meet the requirements of the communication protocol.

[0144] Extract the data format of the device to be driven (step 2): Detect the data generated by the device to be driven, including the data format it contains.

[0145] Extract the target data volume (step 3): Determine the range of the target data volume, which is usually between 10MB and 50MB.

[0146] Data format conversion (step 4): convert the data in each data format into the candidate data format in turn, and record the average time for converting the data corresponding to each data format into the candidate data format.

[0147] Determine a provisional data format (step 5): According to the maximum value of the above average duration, select a data format corresponding to the maximum value of the average duration as the provisional data format.

[0148] Obtaining conversion parameters (steps 6 and 7): extract the average data conversion time corresponding to the conversion from the tentative data format to the candidate data format, and calculate the conversion parameters based on these average data conversion times. The conversion parameter is a parameter that measures the efficiency of data format conversion, which takes into account the speed and amount of data converted.

[0149] Select the communication data format (step 8): The candidate data format with the minimum conversion parameters is selected as the communication data format between the device to be driven and the Modbus device. This ensures that the selected data format can achieve fast and efficient data transmission and interpretation.

[0150] The effects of the above technical solution are: Data transmission efficiency: by selecting a data format with minimum conversion parameters, efficient conversion between data formats is ensured, thereby improving the efficiency of data transmission.

[0151] Communication data consistency: Selecting the appropriate communication data format helps ensure communication consistency between the device to be driven and the Modbus device, reducing the possibility of communication errors.

[0152] Meeting communication requirements: This method allows the selection of an appropriate communication data format based on the target data volume requirements to meet specific communication requirements.

[0153] In general, the above technical solution of this embodiment ensures that the communication between the device driver microservice and the Modbus device can be carried out efficiently and reliably, while meeting the requirements of the communication protocol and data format.

[0154] The embodiment of the present invention proposes a modbus device access system based on a microservice architecture, such as Figure 2 As shown, the modbus device access system based on microservice architecture includes:

[0155] The microservice project acquisition module is used to split the overall system to be set up for microservices and obtain multiple microservice projects;

[0156] The microservice architecture acquisition module is used to set the microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project;

[0157] The testing and deployment module is used to test and deploy the microservice architecture corresponding to each microservice project, and to regularly maintain and update the microservice architecture corresponding to each microservice project that has completed testing and deployment.

[0158] The working principle of the above technical solution is as follows: Split the overall system: First, split the overall system to be microserviced. This step is about dividing the original single application or system into multiple microservice projects, each of which focuses on a specific function or service.

[0159] Microservice architecture setup: Set up the corresponding microservice architecture for each microservice project. Microservice architecture is a distributed architecture in which the system consists of multiple small, autonomous services that can be deployed and scaled independently. In this step, the service boundaries, API interfaces, data storage, communication methods, etc. of each microservice project are defined.

[0160] Testing, deployment, maintenance, and updating: Perform a series of operations on the microservice architecture corresponding to each microservice project, including:

[0161] Testing: Ensure that each microservice project runs properly as defined by the microservice architecture, can perform its specific functions, and can work with other microservices.

[0162] Deployment: Deploy each microservice project to the corresponding operating environment as needed, such as a container, cloud service, or physical server.

[0163] Regular maintenance: Monitor and maintain each microservice project to ensure its performance, availability, and security. This may include tasks such as troubleshooting, updates, and patch management.

[0164] Update: Each microservice project is updated regularly to adapt to new requirements, fix vulnerabilities, or introduce new features.

[0165] The effects of the above technical solutions are: Modularity and elasticity: After adopting the microservice architecture, the system becomes more modular, each microservice runs independently and is easy to expand or reduce, thereby increasing the elasticity of the system.

[0166] Rapid development and deployment: Each microservice project can be independently developed, tested, and deployed by different development teams, thus accelerating the development cycle.

[0167] Flexibility in maintenance and updates: The independence of microservice projects means that maintenance and updates can be more flexible without affecting the entire system.

[0168] Fault tolerance and availability: The independence of microservice projects also improves the fault tolerance of the system. The failure of one microservice will not affect the availability of the entire system.

[0169] Better resource management: Microservice architecture allows for better management of system resources, allocating and releasing resources based on demand, and improving resource utilization.

[0170] In general, this technical solution makes the system more flexible, maintainable, and scalable through the adoption of microservice architecture, which helps to meet the needs of modern applications, especially in large-scale, complex, and distributed systems.

[0171] The microservice project acquisition module in one embodiment of the present invention includes:

[0172] The subsystem extraction module is used to extract the system structure of the overall system to be set up by the microservice and obtain the subsystems of the overall system;

[0173] A subsystem library acquisition module, used to classify the functions performed by each subsystem and obtain a subsystem library corresponding to each function type; wherein the subsystem library includes a device unit corresponding to each subsystem;

[0174] A subsystem corresponding device extraction module is used to extract each device in the device unit corresponding to each subsystem;

[0175] The microservice project setting module is used to set up microservice projects for each device in the device unit corresponding to each subsystem; wherein the microservice projects include device driver microservice, message proxy microservice, rule engine microservice, data statistical analysis microservice and data flow microservice.

[0176] The working principle of the above technical solution is: Extract the system structure of the overall system: First, analyze the overall system to be microserviced and extract its system structure, including the composition and relationship of each subsystem.

[0177] Functional classification and subsystem library: Classify the functions performed by each subsystem in the overall system. This step helps to organize subsystems with similar functions together and build subsystem libraries. Each subsystem library includes a group of subsystems that belong to the same functional type and may include different equipment units.

[0178] Device unit extraction: Extract each device from the device unit corresponding to each subsystem. A device unit usually contains a group of devices that work together in the overall system to provide specific functions.

[0179] Microservice project settings: Set up microservice projects for each device in the device unit corresponding to each subsystem. These microservice projects include different types of microservices, such as device driver microservices, message broker microservices, rule engine microservices, data statistics analysis microservices, and data flow microservices. Each microservice type has its specific responsibilities to support the functions and data processing of the device.

[0180] The effects of the above technical solution are: Modular system: split the overall system to make it more modular, and each subsystem and equipment unit can be independently developed, deployed and maintained.

[0181] Granularity control of microservices: By setting up different types of microservices for devices in each subsystem, the granularity of microservices can be finely controlled to ensure that each microservice has specific responsibilities.

[0182] Flexibility: The functional classification and microservice settings of the overall system improve the flexibility of the system. Microservices can be easily added, replaced or upgraded to meet changing requirements.

[0183] Performance optimization: Different types of microservices can focus on their specific tasks, thereby optimizing performance and improving the responsiveness and efficiency of the system.

[0184] Facilitates teamwork: Each microservice project can be managed by a different development team, which helps parallel development, reduces conflicts, and improves development efficiency.

[0185] In general, the above technical solution of this embodiment helps to prepare for the microservice transformation of the overall system, making the system more flexible, maintainable and scalable.

[0186] The microservice architecture acquisition module according to an embodiment of the present invention includes:

[0187] A microservice project calling module is used to call each device setting microservice project in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice, and a data flow microservice;

[0188] A device driver microservice structure setting module is used to set the device driver microservice structure for the device driver microservice;

[0189] The message proxy microservice structure setting module is used to set the message proxy microservice structure for the message proxy microservice; specifically, the message proxy microservice is used to handle the transmission of device data and message routing. It can be implemented using a message queue or an event bus. The device driver microservice sends data to the message proxy, which is responsible for routing the data to appropriate services, such as the rule engine, data statistical analysis, etc.

[0190] The rule engine microservice structure setting module is used to set the rule engine microservice structure for the rule engine microservice; specifically, the rule engine microservice is used to define and execute data processing rules, such as data screening, data conversion, alarm generation, etc. The rules can be triggered based on the received data.

[0191] The data statistics analysis microservice structure setting module is used to set the data statistics analysis microservice structure for the data statistics analysis microservice; specifically, the data statistics analysis microservice is responsible for real-time or offline analysis of data, generating reports or performing advanced data processing. It can be integrated with an analysis library or a machine learning model.

[0192] The data flow microservice structure setting module is used to set the data flow microservice structure for the data flow microservice. Specifically, when a new device is connected to the device, there should be an automated deployment process. This can be an automated script or use a container orchestration tool (such as Docker Compose, Kubernetes) to start a new device driver microservice instance.

[0193] The working principle of the above technical solution is as follows: Device driver microservice structure setting: This step specifically involves the structure setting of the device driver microservice. The device driver microservice is responsible for communication with physical devices, data collection and transmission. Its structure will include settings in terms of interface definition, communication protocol, data parsing, error handling, etc. to ensure the correct connection of the device and data collection.

[0194] Message broker microservice structure settings: The message broker microservice is used to handle the transmission of device data and message routing. It ensures reliable delivery of data and routing to appropriate services. The structure of the message broker may include message queues, topic subscriptions, routing rules, etc. to meet the needs of message delivery and distribution.

[0195] Rule engine microservice structure settings: The rule engine microservice is responsible for defining and executing data processing rules, such as data filtering, data transformation, alert generation, etc. The structure of the rule engine will include settings for rule definition, condition checking, data processing, action triggering, etc., so as to process data in real time.

[0196] Data statistics and analysis microservice structure setting: Data statistics and analysis microservice is responsible for real-time or offline analysis of data, generating reports or performing advanced data processing. Its structure may involve data stream processing, storage, analysis algorithms, etc. to meet the needs of data analysis.

[0197] Data flow microservice structure setup: The data flow microservice is responsible for the automated deployment process when a new device is connected to the device. This may involve the use of automated scripts and container orchestration tools (such as Docker Compose and Kubernetes) to start new device driver microservice instances.

[0198] The effects of the above technical solutions are: Microservice hierarchical structure: Each microservice type has specific responsibilities and structures to achieve a hierarchical microservice architecture. This improves maintainability and scalability.

[0199] Clear functionality: Each microservice type focuses on its specific task, increasing code clarity and manageability.

[0200] Integration: Clear interface definitions and collaboration between different microservice types enable smooth data transmission and processing.

[0201] Automation: Automated deployment processes ensure rapid access to new devices, reduce the need for manual configuration, and improve efficiency.

[0202] In general, the above technical solution of this embodiment helps to create a structure for each microservice project and ensures that each type of microservice can effectively complete its tasks while ensuring the collaboration between them. This helps to build an efficient, flexible and easy-to-maintain microservice architecture.

[0203] The device driver microservice structure setting module of one embodiment of the present invention includes:

[0204] The communication parameter setting module is used to set the communication protocol and communication mode between the device to be driven and the Modbus device using the Modbus communication library;

[0205] The communication data format setting module is used to set the communication data format between the device to be driven and the Modbus device according to the communication protocol and communication mode between the device to be driven and the Modbus device.

[0206] The working principle of the above technical solution is: Use the Modbus communication library to set the communication protocol and mode: In this step, the Modbus communication library is used to configure the communication protocol and communication mode between the device to be driven and the Modbus device. Modbus is a common communication protocol widely used in the field of industrial automation. Through the Modbus communication library, the parameters of the communication protocol can be defined, such as communication speed, data bit, stop bit, check mode, etc. This step ensures that the communication between the device to be driven and the Modbus device can be established correctly.

[0207] Set the communication data format: In order to ensure effective communication, the communication data format between the device to be driven and the Modbus device needs to be set according to the defined communication protocol. This includes the encoding and decoding methods of the data, the format of the data packet (such as register address, function code, etc.) and the method of interpreting the data. The correct setting of the communication data format ensures that the data exchange between devices is accurate and reliable.

[0208] The effects of the above technical solution are: Modbus communication support: By utilizing the Modbus communication library, communication between the device to be driven and the Modbus device can be easily achieved, ensuring the interoperability between the devices.

[0209] Communication protocol consistency: Defining the communication protocol and data format ensures that the communication parameters between the device to be driven and the Modbus device are consistent, thereby reducing the possibility of communication errors.

[0210] Data accuracy: Properly formatting communications data helps ensure accurate transmission and interpretation of data, thereby improving data reliability and consistency.

[0211] In general, the above technical solution of this embodiment ensures that the device driver microservice can effectively communicate with the Modbus device, accurately transmit and interpret data, thereby realizing the collection and transmission function of device data. This is very important for fields such as industrial automation and equipment monitoring.

[0212] The communication data format setting module according to an embodiment of the present invention includes:

[0213] A candidate data format extraction module, used to extract data formats that conform to the communication protocol as candidate data formats;

[0214] A device-generated data format extraction module, used to extract the data format contained in the data generated by the device to be driven;

[0215] A data information volume extraction module is used to extract data corresponding to each data format of the target data volume; wherein the value range of the target data volume is 10MB-50MB;

[0216] A data format conversion module, used to convert the data corresponding to each data format into the candidate data format in sequence, and obtain an average time duration for converting the data corresponding to each data format into the candidate data format;

[0217] A provisional data format extraction module, used to extract a data format corresponding to a maximum value of an average time length for data conversion from each data format to the candidate data format as a provisional data format;

[0218] A data conversion average duration extraction module, used for extracting the corresponding average duration of data conversions of the provisional data format to the candidate data format in sequence;

[0219] The conversion parameter acquisition module is used to acquire the conversion parameters corresponding to the conversion of the tentative data format to the candidate data format in sequence according to the average duration of the data conversion; wherein the conversion parameters are acquired by the following formula:

[0220]

[0221] Where X represents the conversion parameter; Tmax Indicates the time length corresponding to the maximum value of the average duration; T min Indicates the time length corresponding to the minimum value of the average duration; X 0 represents the preset benchmark parameter value; C represents the average amount of data generated per unit time in the provisional data format corresponding to the maximum value of the average duration; C z Indicates the total amount of data generated per unit time by the device to be driven;

[0222] The data format determination module is used to use the candidate data format corresponding to the minimum value of the conversion parameter as the communication data format between the device to be driven and the Modbus device.

[0223] The working principle of the above technical solution is as follows: Extract candidate data formats: First, extract candidate data formats from the defined communication protocol, and these data formats meet the requirements of the communication protocol.

[0224] Extract the data format of the device to be driven: Detect the data generated by the device to be driven, including the data format it contains.

[0225] Extract target data volume: Determine the value range of the target data volume, which is usually between 10MB and 50MB.

[0226] Data format conversion: convert the data in each data format into the candidate data format in turn, and record the average time for converting the data corresponding to each data format into the candidate data format.

[0227] Determine a provisional data format: According to the maximum value of the above average duration, select a data format corresponding to the maximum value of the average duration as the provisional data format.

[0228] Obtaining conversion parameters: extracting the average data conversion time corresponding to the conversion from the tentative data format to the candidate data format in sequence, and calculating the conversion parameters based on these average data conversion times. The conversion parameter is a parameter that measures the efficiency of data format conversion, which takes into account the speed and amount of data converted.

[0229] Select the communication data format: The candidate data format with the smallest conversion parameters is used as the communication data format between the device to be driven and the Modbus device. This ensures that the selected data format can achieve fast and efficient data transmission and interpretation.

[0230] The effects of the above technical solution are: Data transmission efficiency: by selecting a data format with minimum conversion parameters, efficient conversion between data formats is ensured, thereby improving the efficiency of data transmission.

[0231] Communication data consistency: Selecting the appropriate communication data format helps ensure communication consistency between the device to be driven and the Modbus device, reducing the possibility of communication errors.

[0232] Meeting communication requirements: This method allows the selection of an appropriate communication data format based on the target data volume requirements to meet specific communication requirements.

[0233] In general, the above technical solution of this embodiment ensures that the communication between the device driver microservice and the Modbus device can be carried out efficiently and reliably, while meeting the requirements of the communication protocol and data format.

[0234] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A modbus device access method based on microservice architecture, characterized in that: The modbus device access method based on microservice architecture includes: Split the overall system to be set up for microservices and obtain multiple microservice projects; Set up microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project; Test and deploy the microservice architecture corresponding to each microservice project, and regularly maintain and update the microservice architecture corresponding to each microservice project that has completed testing and deployment; Among them, the device driver microservice structure is set for the device driver microservice, including: Use the Modbus communication library to set the communication protocol and communication method between the device to be driven and the Modbus device; Setting a communication data format between the device to be driven and the Modbus device according to the communication protocol and communication mode between the device to be driven and the Modbus device; Wherein, the communication data format between the device to be driven and the Modbus device is set according to the communication protocol and communication mode between the device to be driven and the Modbus device, including: extracting a data format that complies with the communication protocol as a candidate data format; Extracting the data format contained in the data generated by the device to be driven; Extracting data corresponding to each data format of the target data volume; wherein the value range of the target data volume is 10MB-50MB; Converting the data corresponding to each data format into the candidate data format in sequence, and obtaining an average time duration for converting the data corresponding to each data format into the candidate data format; Extracting a data format corresponding to a maximum value of an average time duration for data conversion from each data format to the candidate data format as a tentative data format; Extract the average data conversion time corresponding to the conversion of the tentative data format into the candidate data format in sequence; According to the average data conversion time, the conversion parameters corresponding to the conversion of the tentative data format to the candidate data format are obtained in sequence; wherein the conversion parameters are obtained by the following formula: in, X Represents conversion parameters; T max Indicates the time length corresponding to the maximum value of the average duration; T min Indicates the time length corresponding to the minimum value of the average duration; X 0 indicates the preset baseline parameter value; C The average amount of data generated per unit time in the provisional data format corresponding to the maximum value of the average duration; C z Indicates the total amount of data generated per unit time by the device to be driven; The candidate data format corresponding to the minimum value of the conversion parameter is used as the communication data format between the device to be driven and the Modbus device.

2. According to the modbus device access method based on microservice architecture according to claim 1, it is characterized in that: Split the overall system to be set up for microservices and obtain multiple microservice projects, including: Extract the system structure of the overall system to be set up by the microservice and obtain the subsystems of the overall system; Classifying the functions performed by each subsystem to obtain a subsystem library corresponding to each function type; wherein the subsystem library includes a device unit corresponding to each subsystem; Extract each device in the device unit corresponding to each subsystem; A microservice project is set for each device in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice and a data flow microservice.

3. The modbus device access method based on microservice architecture according to claim 1 is characterized in that: Set up microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project, including: Retrieve each device setting microservice project in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice, and a data flow microservice; Set up the device driver microservice structure for the device driver microservice; Set up the message proxy microservice structure for the message proxy microservice; Set up the rule engine microservice structure for the rule engine microservice; Set up the data statistics analysis microservice structure for the data statistics analysis microservice; Set up the data flow microservice structure for the data flow microservice.

4. A modbus device access system based on microservice architecture, characterized in that: The modbus device access system based on microservice architecture includes: The microservice project acquisition module is used to split the overall system to be set up for microservices and obtain multiple microservice projects; The microservice architecture acquisition module is used to set the microservice architecture for multiple microservice projects and obtain the microservice architecture corresponding to each microservice project; A testing and deployment module, used to test and deploy the microservice architecture corresponding to each microservice project, and to regularly maintain and update the microservice architecture corresponding to each microservice project that has completed testing and deployment; Device driver microservice structure setting module, including: The communication parameter setting module is used to set the communication protocol and communication mode between the device to be driven and the Modbus device using the Modbus communication library; A communication data format setting module, used to set the communication data format between the device to be driven and the Modbus device according to the communication protocol and communication mode between the device to be driven and the Modbus device; Wherein, the communication data format setting module includes: A candidate data format extraction module, used to extract data formats that conform to the communication protocol as candidate data formats; A device-generated data format extraction module, used to extract the data format contained in the data generated by the device to be driven; A data information volume extraction module is used to extract data corresponding to each data format of the target data volume; wherein the value range of the target data volume is 10MB-50MB; A data format conversion module, used to convert the data corresponding to each data format into the candidate data format in sequence, and obtain an average time duration for converting the data corresponding to each data format into the candidate data format; A provisional data format extraction module, used to extract a data format corresponding to a maximum value of an average time length for data conversion from each data format to the candidate data format as a provisional data format; A data conversion average duration extraction module, used for extracting the corresponding average duration of data conversions of the provisional data format to the candidate data format in sequence; The conversion parameter acquisition module is used to acquire the conversion parameters corresponding to the conversion of the tentative data format to the candidate data format in sequence according to the average duration of the data conversion; wherein the conversion parameters are acquired by the following formula: in, X Represents conversion parameters; T max Indicates the time length corresponding to the maximum value of the average duration; T min Indicates the time length corresponding to the minimum value of the average duration; X 0 indicates the preset baseline parameter value; C The average amount of data generated per unit time in the provisional data format corresponding to the maximum value of the average duration; C z Indicates the total amount of data generated per unit time by the device to be driven; The data format determination module is used to use the candidate data format corresponding to the minimum value of the conversion parameter as the communication data format between the device to be driven and the Modbus device.

5. The modbus device access system based on microservice architecture according to claim 4 is characterized in that: The microservice project acquisition module includes: The subsystem extraction module is used to extract the system structure of the overall system to be set up by the microservice and obtain the subsystems of the overall system; A subsystem library acquisition module, used to classify the functions performed by each subsystem and obtain a subsystem library corresponding to each function type; wherein the subsystem library includes a device unit corresponding to each subsystem; The subsystem corresponding device extraction module is used to extract each device in the device unit corresponding to each subsystem; The microservice project setting module is used to set up microservice projects for each device in the device unit corresponding to each subsystem; wherein the microservice projects include device driver microservice, message proxy microservice, rule engine microservice, data statistical analysis microservice and data flow microservice.

6. According to the modbus device access system based on microservice architecture as claimed in claim 4, it is characterized in that: The microservice architecture acquisition module includes: A microservice project calling module is used to call each device setting microservice project in the device unit corresponding to each subsystem; wherein the microservice project includes a device driver microservice, a message proxy microservice, a rule engine microservice, a data statistics analysis microservice, and a data flow microservice; A device driver microservice structure setting module is used to set the device driver microservice structure for the device driver microservice; A message proxy microservice structure setting module is used to set the message proxy microservice structure for the message proxy microservice; A rule engine microservice structure setting module is used to set the rule engine microservice structure for the rule engine microservice; A data statistics analysis microservice structure setting module is used to set the data statistics analysis microservice structure for the data statistics analysis microservice; The data flow microservice structure setting module is used to set the data flow microservice structure for the data flow microservice.

Images