Test method, device, equipment and medium for simulating large-scale modbus equipment

Abstract

The embodiment of the application discloses a test method, device, equipment and medium for simulating large-scale Modbus equipment. The method belongs to the technical field of Internet of Things, and comprises the following steps: if a simulation online request sent by a front end is received through any service instance, a Modbus equipment is simulated to perform online test according to the simulation online request, a device list and a unit identifier resource list; and if a simulation data interaction request / simulation offline request sent by the front end is received through any service instance, the Modbus equipment is simulated to perform data interaction test / offline test according to the simulation data interaction request / the simulation offline request and a device online record stored in a cache middleware. The embodiment of the application can simulate large-scale Modbus equipment to perform data online test, data interaction test and offline test, does not need to deploy a device simulator, reduces resource consumption, saves device deployment time and shortens a test period.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a testing method, apparatus, device, and medium for simulating large-scale Modbus devices. Background Technology

[0002] The Modbus protocol is widely used in industrial automation, covering multiple industries such as manufacturing, energy, and environment. The cloud's ability to access Modbus devices is one of the standards for measuring its southbound access capability. In practical applications, various reasons often prevent the availability of a sufficient number of real devices in a timely manner. To perform stress testing on large-scale Modbus devices in the cloud, simulation devices are typically used. Existing methods for simulating large-scale Modbus devices mainly fall into two categories: cloud-based Modbus device simulation software and single-instance device simulation services (with Modbus device simulation capabilities) deployed on the Modbus device itself. However, both are limited by the characteristics of the Modbus protocol and cannot simulate Modbus devices on a large scale for testing. Furthermore, because the Modbus protocol differs from protocols such as MQTT, LwM2M, and CoAP, it requires the cloud to actively initiate connection requests, and each Modbus device requires an IP address. Therefore, using cloud-based device simulation services to simulate large-scale Modbus devices not only suffers from resource shortages but also requires large-scale device deployment, resulting in a long testing cycle. Summary of the Invention

[0003] This invention provides a testing method, apparatus, equipment, and medium for simulating large-scale Modbus devices, aiming to reduce resource consumption, save equipment deployment time, and shorten the testing cycle by simulating large-scale Modbus devices.

[0004] In a first aspect, embodiments of the present invention provide a testing method for simulating large-scale Modbus devices, applied to a device simulation service in the cloud, comprising:

[0005] If a simulated online request is received from the front end through any service instance, the Modbus device is simulated for online testing based on the simulated online request, the device list, and the unit identifier resource list.

[0006] If a simulated data interaction request / simulated offline request is received from the front end through any of the service instances, then the Modbus device is simulated for data interaction testing / offline testing based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware.

[0007] Secondly, embodiments of the present invention also provide a testing apparatus for simulating large-scale Modbus devices, applied to device simulation services in the cloud, comprising:

[0008] The first simulation test unit is used to simulate a Modbus device for online testing based on the simulated online request, the device list, and the unit identifier resource list if a simulated online request sent by the front end is received through any service instance.

[0009] The second simulation test unit is used to simulate the Modbus device to perform data interaction test / offline test based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware if a simulated data interaction request / simulated offline request is received from the front end through any of the service instances.

[0010] Thirdly, embodiments of the present invention also provide a computer device, the computer device having an Internet of Things platform, which includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the above-described method.

[0011] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0012] This invention provides a testing method, apparatus, device, and medium for simulating large-scale Modbus devices. The method includes: if a simulated online request is received from a frontend through any service instance, then a Modbus device is simulated for online testing based on the simulated online request, a device list, and a unit identifier resource list; if a simulated data interaction request / simulated offline request is received from the frontend through any service instance, then the Modbus device is simulated for data interaction testing / offline testing based on the simulated data interaction request / simulated offline request and device online records stored in a cache middleware. The technical solution of this invention, based on the simulated online request, simulated data interaction request, and simulated offline request received by any service instance, and using the device list, unit identifier resource list, and device online records stored in the cache middleware, simulates large-scale Modbus devices for data online testing, data interaction testing, and offline testing. This eliminates the need to deploy device simulators, reduces resource consumption, saves device deployment time, and shortens the testing cycle. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A test architecture diagram for simulating a large-scale Modbus device is provided in this embodiment of the invention;

[0015] Figure 2 A timing diagram for simulating the online testing method of a large-scale Modbus device, provided in an embodiment of the present invention;

[0016] Figure 3 This is a flowchart illustrating a testing method for simulating a large-scale Modbus device provided in an embodiment of the present invention;

[0017] Figure 4 for Figure 3 A simplified flowchart of the online testing process for a simulated Modbus device;

[0018] Figure 5 for Figure 3 A simplified flowchart of the data interaction test for a simulated Modbus device;

[0019] Figure 6 for Figure 3 A simplified flowchart of the process for simulating the offline testing of Modbus devices;

[0020] Figure 7 for Figure 3 A simplified flowchart of the automatic expansion process for the equipment simulation service;

[0021] Figure 8 A schematic block diagram of a test apparatus for simulating a large-scale Modbus device provided in an embodiment of the present invention;

[0022] Figure 9 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0025] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0026] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0027] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0028] Please see Figure 1 , Figure 1 This is a test architecture diagram for simulating a large-scale Modbus device provided by an embodiment of the present invention. Figure 1 In this architecture diagram, the front-end, cloud, and real devices are included. The cloud includes a device simulation service, a device access service, and a caching middleware. Communication is possible between the device simulation service and the device access service, between the device simulation service and the caching middleware, between the device access service and the caching middleware, between the front-end and the device simulation service, and between real devices and the device access service. It should be noted that in this embodiment, the device access service is the southbound entry point of the IoT platform, directly facing various devices and responsible for access management and data interaction. The device simulation service is responsible for simulating devices using various protocols accessed by the IoT platform. Modbus is the most commonly used device data standard communication protocol in the industrial automation field. It should also be noted that because Modbus devices operate in a passive connection mode, after starting up, they wait for the IoT platform to actively initiate a connection. Therefore, unlike other protocols that actively initiate connection requests to the IoT platform, there is no active online operation. When simulating Modbus devices, to ensure consistency with the simulation operation logic of other protocol devices, such as... Figure 2As shown, the following device simulation deployment process is defined:

[0029] (1) The device simulation service and the device access service agree on a Modbus device online notification interface. The interface parameters include device ID, device unit identifier (slave address, SlaveId), online / offline identifier, IP address of the current service instance, and port number (502 by default in the Modbus protocol). When the device simulation service receives a device simulation online request initiated by the front end, the device simulation service first verifies the legality of the device. After it is legal, it calls the online notification interface to notify the device access service that the current device has started, that is, to notify the device online with the device information. (2) After receiving the online request, the device access service requests the device simulation service to establish a communication channel. (3) After receiving the connection channel establishment request, the device simulation service responds. The device access service responds to the device online request, formally establishes a communication channel, and stores the mapping relationship between the device ID and the unit identifier (the device ID information will not be carried in the subsequent Modbus message; the device simulation service identifies the device through the unit identifier). The device simulation online operation is completed.

[0030] Based on the aforementioned device simulation deployment process and considering the characteristics of the Modbus protocol, this embodiment designs a Modbus unit identifier resource recycling method to enable a single microservice (corresponding to a single IP address) to simulate up to 256 devices. In the Modbus protocol header, the 7th byte is the unit identifier (slave address, SlaveId), with a length of 1 byte, which can represent a maximum of 256 unit identifiers, thus representing 256 devices. The device simulation service needs to store the mapping relationship between unit identifiers and device IDs. This resource is released after a device goes offline, achieving recycling. The specific strategy is as follows: When the device simulation service starts, the mapping relationship between Modbus unit identifier resources and device IDs is stored and initialized in key-value format, i.e., the value (device ID) of the identifier (key) is set to empty. When a Modbus device starts and requests resources, the unit identifier resources are traversed to obtain available identifiers for the device to use, and their value is set to the device ID. After the device goes offline, the device ID corresponding to the unit identifier is reset to empty, i.e., set to an available state, so that it can be used by other devices when they come online.

[0031] Understandably, by deploying multiple devices in the cloud to simulate service instances, and designing the device online, data interaction, and offline processes based on caching middleware under multiple service instance states, it is possible to simulate up to "instance number * 256" devices.

[0032] Please see Figure 3 , Figure 3This is a flowchart illustrating a testing method for simulating large-scale Modbus devices according to an embodiment of the present invention. The testing method for simulating large-scale Modbus devices according to this embodiment of the present invention can be applied to device simulation services in the cloud of an IoT platform. For example, the testing method for simulating large-scale Modbus devices can be implemented through software programs configured on the device simulation service. Figure 3 As shown, the method includes the following steps S100-S110.

[0033] S110. If a simulated online request is received from the front end through any service instance, then the Modbus device is simulated for online testing based on the simulated online request, the device list, and the unit identifier resource list.

[0034] In this embodiment of the invention, after the simulated online request sent by the front end reaches any service instance in the back end, it is determined whether the online notification conditions are met based on the simulated online request, the device list, and the unit identifier resource list. If the online notification conditions are met, a device online notification is sent to the device access service, wherein the device online notification carries the device ID and the unit identifier. If an online success notification is received from the device access service, a communication link is established with the device access service, and the mapping relationship between the unit identifier and the device ID is stored in the unit identifier resource list. The obtained IP address and port number of the current service instance are stored in the cache middleware, wherein the cache middleware is Redis. An online success notification is returned to the front end to complete the simulated online test of the Modbus device. Understandably, if an online failure notification is received from the device access service, an online failure message is returned. It should be noted that both the device list and the unit identifier resource list are stored in memory.

[0035] The step of determining whether the online notification conditions are met based on the simulated online request, the device list, and the unit identifier resource list specifically includes: obtaining the device ID carried in the simulated online request; querying whether the device ID exists in the device list; if the device ID exists in the device list, then querying whether a usable unit identifier exists in the unit identifier resource list; if a usable unit identifier exists in the unit identifier resource list, then it is determined that the online notification conditions are met. Understandably, if the device ID does not exist in the device list, it indicates that the online device is invalid, and an online failure message is returned. Understandably, if a usable unit identifier does not exist in the unit identifier resource list, an online failure message is also returned. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 for Figure 3The flowchart for the online testing of the simulated Modbus device is simplified and will not be described in detail here for the sake of simplicity.

[0036] S120. If a simulated data interaction request / simulated offline request is received from the front end through any of the service instances, then the Modbus device is simulated for data interaction testing / offline testing based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware.

[0037] In embodiments of the present invention, such as Figure 5 As shown, Figure 5 for Figure 3 The flowchart for simulating Modbus device data interaction testing is as follows: After a simulated data interaction request initiated by the front end reaches any service instance in the device simulation service, it first queries Redis to see if there is a record of the device going online. If not, a query / modification failure message is returned. If it exists, the device going online record found in Redis is parsed to obtain the IP information, which is compared with the address of the current service instance. If they are the same, the data interaction operation corresponding to the simulated data interaction request is executed, and a success message is returned to complete the simulated Modbus device data interaction test / offline test. The data interaction operation is either a query operation or a modification operation. If they are different, the simulated data interaction request is forwarded to the corresponding service instance according to the online IP address and the corresponding port and service interface. If the forwarding is successful, a success message is returned to complete the simulated Modbus device data interaction test; otherwise, a query / modification failure message is returned. Understandably, after the forwarded simulated offline request enters a new service instance, the above steps are repeated to complete the query / modification operation.

[0038] Furthermore, such as Figure 6 As shown, Figure 6 for Figure 3The flowchart for simulating Modbus device offline testing is as follows: After a simulated offline request initiated by the front end reaches any service instance in the device simulation service, it first queries Redis to see if there is a device online record. If not, it returns a offline failure message. If it exists, it parses the device online record found in Redis to obtain the IP information and compares it with the current service instance address. If they are the same, it clears the device online data in the cache middleware, notifies the device access service to disconnect, completes the offline operation, and returns a offline success message. If they are different, it forwards the simulated offline request to the corresponding service instance based on the online IP address and the corresponding port and service interface. If the forwarding is successful, it returns a forwarding success message; otherwise, it returns a offline failure message. After the forwarded request enters the new service instance, the above steps are repeated to complete the device offline operation.

[0039] Furthermore, such as Figure 7 As shown, Figure 7 for Figure 3 The flowchart illustrates the automatic scaling process of the device simulation service. A device online statistics module is added to the device simulation service. This module periodically writes the number of available unit identifiers in the current service instance to Redis. When the unit identifier resources in any service instance are exhausted, it first checks if there is an idle service instance in Redis. If so, the simulated online request is forwarded to that idle service instance. If no idle service instance is found in the cache middleware, it indicates that the unit identifier resources in all deployed service instances are exhausted. The service instance that found the resource exhaustion checks if the scaling lock in Redis is occupied. If the scaling lock is not occupied, it is set to occupied to prevent other service instances from performing scaling operations, and the scaling interface is called to add a new service instance. After the scaling operation is completed, if the cache middleware shows information about the newly added service instance (i.e., the newly added service instance updates the unit identifier resource usage in Redis), the service instance that initiated the scaling resets the scaling lock to available status when it finds the newly added service instance information in Redis. Understandably, subsequent online requests can be forwarded to the newly added instance for processing.

[0040] It should be noted that in this embodiment, a maximum of "service instance number * 256" devices can be simulated. If there is a need to simulate N Modbus devices in the cloud, then only at least N / 256 service instances need to be deployed in the cloud. If the number of simulated Modbus devices increases subsequently, the service instances can be horizontally scaled up using an automatic scaling strategy to meet performance stress testing requirements. This embodiment of the invention is easy to implement and promote. The Modbus protocol is widely used in the field of industrial automation. Any platform that needs to access Modbus devices must perform stress testing on its device access performance to achieve production-level capabilities. It can also be extended to systems in other fields and industries, including but not limited to the Internet of Things, industry, energy, and environmental sectors.

[0041] It should also be noted that in this implementation, by integrating the large-scale Modbus device simulation capability into the cloud, the resource consumption of deploying a large number of device simulators on the client side is reduced, and the time spent on client deployment and configuration is saved, shortening the platform stress test cycle. By using the default Modbus protocol port 502, the operation of other services is avoided by occupying non-default port resources, and problems such as increased complexity and poor versatility in protocol message parsing caused by modifying the default port are also avoided. Deploying multiple service instances solves the problem of large-scale device simulation and avoids single points of failure, improving service high availability. An automatic horizontal scaling strategy ensures that when the number of connected devices exceeds the current service instance's capacity, service instances are automatically added, automatically improving the performance of the simulated devices upon launch.

[0042] Figure 8 This is a schematic block diagram of a test apparatus 200 for simulating a large-scale Modbus device, provided in an embodiment of the present invention. Figure 8 As shown, corresponding to the above-described test method for simulating large-scale Modbus devices, the present invention also provides a test apparatus 200 for simulating large-scale Modbus devices. This test apparatus 200 includes a unit for performing the above-described test method for simulating large-scale Modbus devices. Specifically, please refer to... Figure 8 The test apparatus 200 for simulating large-scale Modbus devices includes a first simulation test unit 201 and a second simulation test unit 202.

[0043] The first simulation test unit 201 is configured to simulate a Modbus device for online testing if a simulated online request is received from the front end through any service instance, based on the simulated online request, the device list, and the unit identifier resource list. The second simulation test unit 202 is configured to simulate a Modbus device for data interaction testing / offline testing if a simulated data interaction request / simulated offline request is received from the front end through any service instance, based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware.

[0044] In some embodiments, such as this one, the first simulation test unit 201 includes a judgment unit, a sending unit, a storage unit, and a first return unit.

[0045] The determination unit is used to determine whether the online notification conditions are met based on the simulated online request, the device list, and the unit identifier resource list. The sending unit is used to send a device online notification to the device access service if the online notification conditions are met, wherein the device online notification carries the device ID and the unit identifier. The storage unit is used to establish a communication link with the device access service if it receives an online success notification returned by the device access service, and store the mapping relationship between the unit identifier and the device ID in the unit identifier resource list, and store the obtained IP address and port number of the current service instance in the cache middleware. The first return unit is used to return an online success notification to the front end to complete the simulated online test of the Modbus device.

[0046] In some embodiments, such as this embodiment, the determination unit includes an acquisition unit, a first query unit, a second query unit, and a determination unit.

[0047] The acquisition unit is used to acquire the device ID carried in the simulated online request; the first query unit is used to query whether the device ID exists in the device list; the second query unit is used to query whether there is a usable unit identifier in the unit identifier resource list if the device ID exists in the device list; and the determination unit is used to determine whether the online notification conditions are met if there is a usable unit identifier in the unit identifier resource list.

[0048] In some embodiments, such as this one, the second simulation test unit 202 includes a third query unit, a parsing comparison unit, a first execution unit, a clearing unit, a second return unit, a first forwarding unit, and a second execution unit.

[0049] The third query unit is used to query whether there is a device online record in the cache middleware; if the online record exists in the cache middleware, the parsing and comparison unit parses the online record to obtain the online IP address and compares whether the online IP address is the same as the obtained IP address of the current service instance; the first execution unit is used to execute the data interaction operation corresponding to the simulated data interaction request if the online IP address is the same as the IP address of the current service instance and a simulated data interaction request is received from the front end through any of the service instances, wherein the data interaction operation is a query operation or a modification operation; the clearing unit is used to clear if the online IP address is the same as the IP address of the current service instance and a simulated data interaction request is received from the front end through any of the service instances. If the frontend sends a simulated offline request, the device online data in the cache middleware is cleared, and the device is notified to disconnect from the access service. The second return unit is used to return a data interaction / offline success notification to the frontend to complete the simulated data interaction test / offline test of the Modbus device. If the online IP address is different from the IP address of the current service instance, the first forwarding unit is used to forward the simulated data interaction request / simulated offline request according to the online IP address and the corresponding Port and service interface. If the forwarding is successful, the second execution unit is used to return to the step of returning a data interaction / offline success notification to the frontend to complete the simulated data interaction test / offline test of the Modbus device.

[0050] In some embodiments, such as this one, the test apparatus 200 simulating a large-scale Modbus device further includes a writing unit, a fourth query unit, a second forwarding unit, a fifth query unit, a setting unit, and a reset unit.

[0051] The writing unit is used to periodically write available unit identifiers from the current service instance into the cache middleware; the fourth query unit is used to query whether there is an idle service instance in the cache middleware if the unit identifier resources in any of the service instances are exhausted; the second forwarding unit forwards the simulated online request to the idle server instance if there is an idle service instance in the cache middleware; the fifth query unit is used to query whether the expansion lock in the cache middleware is occupied if there is no idle service instance in the cache middleware; the setting unit is used to set the expansion lock to an occupied state if the expansion lock is not occupied, and call the expansion interface to add a new service instance; the reset unit is used to reset the expansion lock to an available state if the newly added service instance information is found in the cache middleware.

[0052] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned test device 200 for simulating large-scale Modbus devices and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0053] The aforementioned test apparatus for simulating large-scale Modbus devices can be implemented as a computer program, which can be used in, for example... Figure 9 It runs on the computer device shown.

[0054] Please see Figure 9 , Figure 9 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 900 is a device equipped with an Internet of Things (IoT) platform.

[0055] See Figure 9 The computer device 900 includes a processor 902, a memory, and an interface 907 connected via a system bus 901, wherein the memory may include a storage medium 903 and internal memory 904.

[0056] The storage medium 903 can store an operating system 9031 and a computer program 9032. When the computer program 9032 is executed, it causes the processor 902 to perform the aforementioned test method for simulating a large-scale Modbus device.

[0057] The processor 902 provides computing and control capabilities to support the operation of the entire computer device 900.

[0058] The internal memory 904 provides an environment for the execution of the computer program 9032 in the storage medium 903. When the computer program 9032 is executed by the processor 902, the processor 902 can execute a test method that simulates a large-scale Modbus device.

[0059] This interface 905 is used for communication with other devices. Those skilled in the art will understand that... Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 900 to which the present application is applied. The specific computer device 900 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0060] The processor 902 is used to run a computer program 9032 stored in a memory to implement the process steps of the above-described method embodiments.

[0061] It should be understood that in the embodiments of this application, the processor 902 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0062] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the wireless communication system to implement the process steps of the embodiments of the above methods.

[0063] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform any embodiment of the above-described test method for simulating a large-scale Modbus device.

[0064] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0065] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, wireless communication software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0066] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0067] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0068] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This wireless communication software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal wireless communication device, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0069] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0070] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0071] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A testing method for simulating large-scale Modbus devices, applied to device simulation services in the cloud, characterized in that, This includes simulated online requests, simulated data interaction requests, and simulated offline requests received from any service instance. Based on the device list, unit identifier resource list, and device online records stored in the cache middleware, it simulates large-scale Modbus device data online testing, data interaction testing, and offline testing. The unit identifier is the slave address. If a simulated online request is received from the front end through any service instance, the Modbus device is simulated for online testing based on the simulated online request, the device list, and the unit identifier resource list. If a simulated data interaction request / simulated offline request is received from the front end through any of the service instances, then the Modbus device is simulated to perform data interaction testing / offline testing based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware; The step of conducting online testing of the simulated Modbus device based on the simulated online request, the device list, and the unit identifier resource list includes: Determine whether the online notification conditions are met based on the simulated online request, the device list, and the unit identifier resource list. If the online notification conditions are met, a device online notification is sent to the device access service, wherein the device online notification carries the device ID and the unit identifier; If a successful online notification is received from the device access service, a communication link is established with the device access service, and the mapping relationship between the unit identifier and the device ID is stored in the unit identifier resource list. The IP address and port number of the current service instance are then stored in the cache middleware. Return a successful online notification to the front end to complete the simulated online test of the Modbus device; If a simulated data interaction request / simulated offline request is received from the front end through any of the service instances, then data interaction testing / offline testing is performed on the Modbus device based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware, including: Check if there is a device online record in the cache middleware; If the online record exists in the cache middleware, the online record is parsed to obtain the online IP address, and the online IP address is compared with the obtained IP address of the current service instance. If the online IP address is the same as the IP address of the current service instance and a simulated data interaction request sent by the front end is received through any of the service instances, then the data interaction operation corresponding to the simulated data interaction request is executed, wherein the data interaction operation is a query operation or a modification operation; If the online IP address is the same as the IP address of the current service instance and if a simulated offline request is received from the front end through any of the service instances, then the device online data in the cache middleware is cleared, and the device is notified to disconnect from the access service. A data interaction / offline success notification is returned to the front end to complete the data interaction test / offline test simulating the Modbus device.

2. The test method for simulating a large-scale Modbus device according to claim 1, characterized in that, The step of determining whether the online notification conditions are met based on the simulated online request, the device list, and the unit identifier resource list includes: Obtain the device ID carried in the simulated online request. Check if the device ID exists in the device list; If the device ID exists in the device list, then query the unit identifier resource list to see if there is a usable unit identifier. If the unit identifier is available in the unit identifier resource list, then the online notification conditions are met.

3. The test method for simulating a large-scale Modbus device according to claim 1, characterized in that, After the step of comparing whether the online IP address is the same as the obtained IP address of the current service instance, the method further includes: If the online IP address is different from the IP address of the current service instance, the simulated data interaction request / simulated offline request will be forwarded according to the online IP address and the port and service interface corresponding to the online IP address. If the forwarding is successful, the process returns to the step of sending a data interaction / offline success notification to the front end to complete the data interaction test / offline test simulating the Modbus device.

4. The test method for simulating a large-scale Modbus device according to claim 1, characterized in that, The method further includes: The available unit identifiers in the current service instance are periodically written to the cache middleware; If the unit identifier resource in any of the service instances is exhausted, then query whether there is an idle service instance in the cache middleware; If there is an idle service instance in the caching middleware, the simulated online request is forwarded to the idle server instance.

5. The test method for simulating a large-scale Modbus device according to claim 4, characterized in that, After the step of querying whether there is an idle service instance in the cache middleware, the method further includes: If there is no idle service instance in the cache middleware, then check whether the expansion lock in the cache middleware is occupied; If the expansion lock is not occupied, then the expansion lock is set to occupied state, and the expansion interface is called to add a new service instance; If the newly added service instance information is found in the cache middleware, the expansion lock is reset to an available state.

6. A testing apparatus for simulating large-scale Modbus devices, applied to device simulation services in the cloud, characterized in that, This includes simulated online requests, simulated data interaction requests, and simulated offline requests received from any service instance. Based on the device list, unit identifier resource list, and device online records stored in the cache middleware, it simulates large-scale Modbus device data online testing, data interaction testing, and offline testing. The unit identifier is the slave address. The first simulation test unit is used to simulate a Modbus device for online testing based on the simulated online request, the device list, and the unit identifier resource list if a simulated online request sent by the front end is received through any service instance. The second simulation test unit is used to simulate the Modbus device to perform data interaction test / offline test based on the simulated data interaction request / simulated offline request and the device online record stored in the cache middleware if a simulated data interaction request / simulated offline request is received from the front end through any of the service instances. Specifically, the first simulation test unit is used for: Determine whether the online notification conditions are met based on the simulated online request, the device list, and the unit identifier resource list. If the online notification conditions are met, a device online notification is sent to the device access service, wherein the device online notification carries the device ID and the unit identifier; If a successful online notification is received from the device access service, a communication link is established with the device access service, and the mapping relationship between the unit identifier and the device ID is stored in the unit identifier resource list. The IP address and port number of the current service instance are then stored in the cache middleware. Return a successful online notification to the front end to complete the simulated online test of the Modbus device; The second simulation test unit is specifically used for: Check if there is a device online record in the cache middleware; If the online record exists in the cache middleware, the online record is parsed to obtain the online IP address, and the online IP address is compared with the obtained IP address of the current service instance. If the online IP address is the same as the IP address of the current service instance and a simulated data interaction request sent by the front end is received through any of the service instances, then the data interaction operation corresponding to the simulated data interaction request is executed, wherein the data interaction operation is a query operation or a modification operation; If the online IP address is the same as the IP address of the current service instance and if a simulated offline request is received from the front end through any of the service instances, then the device online data in the cache middleware is cleared, and the device is notified to disconnect from the access service. A data interaction / offline success notification is returned to the front end to complete the data interaction test / offline test simulating the Modbus device.

7. A computer device, characterized in that, The computer device is equipped with an Internet of Things (IoT) platform. The computer device includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, it implements the method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-5.

Images