Device ad hoc network configuration method, electronic device, and device ad hoc network system

Abstract

The application provides a device self-organizing network configuration method, an electronic device and a device self-organizing network system. The method comprises the following steps: receiving a device network message from a sub-network device, and obtaining a check result of whether a complete configuration file matched with the sub-network device is stored; when the check result is that the complete configuration file matched with the sub-network device is missing, a configuration file request message is sent; obtaining a complete configuration file corresponding to the sub-network device, and analyzing the configuration file to generate a data collection scheme for the sub-network device. The application can reduce the pressure of the main network device on the configuration file of various sub-network devices in advance, avoid the influence of excessive storage pressure on the operation efficiency of the main network device, and realize automatic configuration of the self-organizing network device when the sub-network device is accessed, improve the configuration efficiency, and thus complete the data collection task of the sub-network device.

Description

[0001] This application claims priority to Chinese Patent Application No. 202311243700.9, filed with the State Intellectual Property Office on September 25, 2023, entitled "Device Self-Organizing Network Configuration Method, Electronic Device and Device Self-Organizing Network System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of device networking technology, and in particular to a device self-organizing network configuration method, electronic equipment, and device self-organizing network system. Background Technology

[0003] When configuring a batch of devices on the same platform, the same platform corresponds to many device models, and these devices have varying degrees of hardware differences. Current configuration schemes typically store configuration files on a host computer, which then distributes the configuration files to the target devices during batch configuration. In implementing the embodiments of this application, it was found that the prior art has at least the following technical problems:

[0004] When the host computer supports access to multiple access devices, the data storage pressure of relevant configuration files in the host computer is high before the devices are connected, which affects the computing efficiency of the host computer. Summary of the Invention

[0005] This application provides a device self-organizing network configuration method, an electronic device, and a device self-organizing network system to solve the problem of high data storage pressure on configuration files in the host computer, which affects the computing efficiency of the host computer.

[0006] In a first aspect, embodiments of this application provide a device self-organizing network configuration method for a primary network device, comprising:

[0007] Receive device networking messages from sub-network devices and obtain a verification result of whether a complete configuration file matching the sub-network device is stored;

[0008] If the verification result indicates that a complete configuration file matching the sub-network device is missing, a configuration file request message is sent.

[0009] Obtain the complete configuration file corresponding to the sub-network device, parse the configuration file, and generate a data acquisition scheme for the sub-network device.

[0010] In one possible implementation, obtaining the complete configuration file corresponding to the sub-network device includes:

[0011] Obtain multiple data blocks from the configuration file and concatenate them to obtain the complete configuration file.

[0012] In one possible implementation, when the verification result indicates that a complete configuration file matching the sub-network device is stored, the method further includes:

[0013] A configuration verification pass message is sent to indicate that the sub-network device has completed configuration and is uploading data.

[0014] In one possible implementation, obtaining the verification result of whether a complete configuration file matching the sub-network device is stored includes:

[0015] Based on the device networking message, verify whether a complete configuration file matching the sub-network device is stored; or...

[0016] A verification command is generated based on the device networking message and the stored configuration file, and the verification command is sent to the sub-networking device or third-party device, and the verification result fed back by the sub-networking device or third-party device is received.

[0017] In one possible implementation, obtaining the complete configuration file corresponding to the sub-network device includes:

[0018] Obtain the configuration file sent by the sub-network device, or obtain the configuration file corresponding to the sub-network device sent by a third-party device.

[0019] In one possible implementation, before receiving the configuration request message sent by the sub-network device, the following is also included:

[0020] Broadcast a network formation request message to instruct the sub-networking devices to respond with a device network formation message; and / or,

[0021] Send a network polling command to the sub-networking device to instruct the sub-networking device to send back the device network message.

[0022] In one possible implementation, when the sub-networking device is a network terminal device, the device networking message is actively sent by the sub-networking device; or, before receiving the configuration request message sent by the sub-networking device, the method further includes:

[0023] Broadcast a network formation request message to instruct the sub-networking devices to respond with a device network formation message;

[0024] When the sub-network device is a serial terminal device, before receiving the configuration request message sent by the sub-network device, the following is also included:

[0025] Send a network polling command to the sub-networking device.

[0026] In one possible implementation, when the sub-networking device is a network terminal device, it connects to the sub-networking device through a first interface, broadcasts the networking request message and receives the device networking message based on the ARP protocol, sends the configuration file request message and receives the configuration file sent by the sub-networking device based on the TCP-MODBUS protocol, and receives the data uploaded by the sub-networking device based on the SNMP protocol.

[0027] When the sub-networking device is a serial terminal device, it connects to the sub-networking device through the second interface, sends network polling commands based on the RTU-MODBUSARP protocol, receives network packets from the device, sends configuration file request packets, receives configuration files sent by the sub-networking device, and receives data uploaded by the sub-networking device.

[0028] In one possible implementation, when the verification result indicates that a complete configuration file matching the sub-network device is missing, a configuration file request message is sent, including:

[0029] Determine the total number of data blocks in the complete configuration file that matches the sub-network device;

[0030] Determine the number of data blocks and the data block sequence number corresponding to the configuration file currently stored that matches the sub-network device;

[0031] The configuration file request message is generated based on the number of data blocks and the sequence number of the data blocks, and then sent.

[0032] In one possible implementation, the configuration file request message includes at least the device type, configuration text information, data block sequence number, data block information, and checksum;

[0033] When the sub-network device sends the configuration file, the configuration file feedback message shall include at least the device type, configuration text information and data block sequence number.

[0034] In one possible implementation, the device networking message includes one or more of the following: device type, configuration text information, and default configuration file checksum.

[0035] Accordingly, before parsing the configuration file, the following steps are also included:

[0036] Based on the device type and / or configuration text information and / or default configuration file checksum, verify whether a complete configuration file matching the sub-network device is stored.

[0037] Secondly, embodiments of this application provide a device self-organizing network system, characterized in that it includes: a management unit, a data collector, and terminal devices;

[0038] The terminal equipment includes network terminal equipment and / or serial port terminal equipment;

[0039] The management unit performs the steps of the method as described in the first aspect or any possible implementation of the first aspect above, in order to connect to the collector;

[0040] The collector performs the steps of the method as described in the first aspect or any possible implementation thereof above to connect to the terminal device.

[0041] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in the first aspect or any possible implementation of the first aspect above.

[0042] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in the first aspect or any possible implementation of the first aspect.

[0043] This application provides a device self-organizing network configuration method, an electronic device, and a device self-organizing network system. By receiving device networking messages from sub-network devices and obtaining a verification result indicating whether a complete configuration file matching the sub-network device is stored, the system determines whether to perform a sub-network device configuration file retrieval operation. When the verification result indicates a missing complete configuration file matching the sub-network device, a configuration file request message is sent, instructing the system to retrieve the sub-network device's configuration file from the sub-network device or a third-party device. After retrieving the complete configuration file corresponding to the sub-network device, the configuration file is parsed to generate a data acquisition scheme for the sub-network device. This application can reduce the pressure on the main network device to pre-load configuration files of various sub-network devices, avoiding excessive storage pressure that could affect its own computational efficiency. Furthermore, when a sub-network device is connected, it can automatically configure the self-organizing device, improving configuration efficiency and thus completing the data acquisition task for the sub-network device. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1This is a flowchart illustrating the implementation of a device self-organizing network configuration method provided in an embodiment of this application;

[0046] Figure 2 This is a schematic diagram of the structure of a device self-organizing network system provided in another embodiment of this application;

[0047] Figure 3 This is a schematic diagram of the communication interaction between a data acquisition device and an upper-level platform management machine according to another embodiment of this application;

[0048] Figure 4 This is a schematic diagram of the communication interaction between the data collector and the terminal device provided in one embodiment of this application;

[0049] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0050] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0051] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0052] Unless otherwise stated, the term "multiple" means two or more. The character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B. The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B.

[0053] The terms used in this application are for describing embodiments only and are not intended to limit the claims. As used in the description of embodiments and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Similarly, the term “and / or” as used herein means including one or more of the associated listed elements and all possible combinations thereof. Additionally, when used in this application, the terms “comprise” and its variations “comprises” and / or “comprising” refer to the presence of stated 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 groups thereof. Without further limitation, an element defined by the phrase “comprising an…” does not exclude the presence of additional identical elements in the process, method, or apparatus that includes said element.

[0054] In this application, each embodiment focuses on describing the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, then the relevant parts can be referred to the description of the method section.

[0055] In projects that include integrated monitoring solutions, the projects often proceed smoothly during the solution design and engineering implementation phases. However, during the delivery phase, when the monitoring system is powered on and debugged, many problems are encountered, which prolongs the debugging cycle and delays the project progress.

[0056] The main problem lies in the fact that the monitoring system needs to connect to a large number of devices from different manufacturers and of different types, with diverse device protocols; the network conditions and hardware wiring at the monitoring system's location are also complex. Debugging personnel need to be familiar with the monitoring products and possess certain network and hardware debugging capabilities, requiring a high level of overall skill.

[0057] In actual delivery work, problems such as insufficient debugging personnel skills, complex software operation, and high difficulty in equipment debugging are often encountered. On the other hand, the monitoring system needs to connect a large number of devices from different manufacturers and of different types. If configuration files containing various types of devices that need to be connected and those that do not need to be connected are stored in advance, a large amount of storage space will be required.

[0058] Therefore, the embodiments of this application aim to propose an intelligent and efficient method for configuring self-organizing devices to solve these problems. This ensures that the configuration of devices to be connected can be completed even with limited storage space in the monitoring system.

[0059] To make the objectives, technical solutions, and advantages of this application clearer, the following description will be provided in conjunction with the accompanying drawings and specific embodiments.

[0060] Figure 1 This is a flowchart illustrating the implementation of a device self-organizing network configuration method according to an embodiment of this application, as follows: Figure 1 As shown, for primary network devices, this method includes the following steps:

[0061] S101, receive the device networking message from the sub-network device and obtain the verification result of whether a complete configuration file matching the sub-network device is stored.

[0062] Specifically, after receiving the device networking message from the sub-network device, the device networking message is parsed to determine one or more pieces of information, such as the sub-device type, model information, or configuration file identifier, so as to verify whether a complete configuration file matching the sub-network device is stored based on the parsed information.

[0063] Correspondingly, the device networking message sent by the sub-networking device shall include at least one or more of the following information: sub-device type, model information, or configuration file identifier.

[0064] Alternatively, during the process of obtaining the configuration file of the sub-network device, the process can be performed by obtaining the complete configuration file to ensure file integrity. Optionally, during the process of obtaining the configuration file of the sub-network device, the configuration file is transmitted in blocks to avoid transmission failure due to interruption caused by excessively large configuration file data. Therefore, the main network device may store a configuration file matching the sub-network device, but the configuration file may be incomplete. In step S101, after receiving the device networking message from the sub-network device, it is necessary not only to verify whether a configuration file matching the sub-network device is stored, but also to verify the integrity of the configuration file to ensure successful data collection from the sub-network device by the main network device.

[0065] S102, when the verification result indicates that a complete configuration file matching the sub-network device is missing, a configuration file request message is sent.

[0066] In different embodiments, the lack of a complete configuration file matching the sub-network device includes two different situations: there is no configuration file matching the sub-network device; or, there is a configuration file matching the sub-network device but it is incomplete.

[0067] Correspondingly, when sending a configuration file request message, the configuration file request message may optionally indicate a request for a complete configuration file, and delete and replace the currently stored incomplete configuration file to avoid outdated information in the incomplete configuration file, ensuring that the last obtained configuration file is the latest configuration file, and ensuring that the sub-network device is configured successfully.

[0068] Optionally, when sending a configuration file request message, the configuration file request message may indicate the request for the missing parts of the configuration file, in order to reduce the amount of data transmitted and improve configuration efficiency.

[0069] S103: Obtain the complete configuration file corresponding to the sub-network device, parse the configuration file, and generate a data acquisition scheme for the sub-network device.

[0070] In different embodiments, the methods for obtaining the configuration files of the sub-network devices differ. Optionally, in one possible implementation, obtaining the configuration files of the sub-network devices includes:

[0071] Obtain the configuration file sent by the sub-network device, or obtain the configuration file corresponding to the sub-network device sent by a third-party device.

[0072] In practice, the third-party device is a communicable device or server, independent of the sub-network devices and the main network device, used to store configuration files for various sub-network devices, improving centralized data management efficiency. Alternatively, the third-party device can be an independent storage device, such as a USB flash drive or hard drive. In this case, when the main network device obtains configuration files from the sub-network devices, it connects to the third-party device and reads the files from it.

[0073] In this embodiment, the process of receiving device networking messages from sub-network devices and obtaining a verification result indicating whether a complete configuration file matching the sub-network device is stored is used to determine whether to perform a sub-network device configuration file acquisition operation. If the verification result indicates a missing complete configuration file matching the sub-network device, a configuration file request message is sent, instructing the acquisition of the sub-network device's configuration file from the sub-network device or a third-party device. After acquiring the complete configuration file corresponding to the sub-network device, the configuration file is parsed to generate a data acquisition scheme for the sub-network device. This embodiment reduces the pressure on the main networking device to pre-load configuration files of various sub-network devices, avoiding excessive storage pressure that could affect its own computational efficiency. Furthermore, when a sub-network device is connected, it enables automatic configuration of the self-network device, improving configuration efficiency and thus completing the data acquisition task for the sub-network device.

[0074] Based on the aforementioned embodiments, since the sub-network devices send configuration files in different ways, in one possible implementation, step S103, obtaining the complete configuration file corresponding to the sub-network device, includes:

[0075] Obtain multiple data blocks from the configuration file and concatenate them to obtain the complete configuration file.

[0076] In one possible implementation, after the main network device sends a configuration file request message, it can continuously receive multiple configuration file data block information sent or transmitted in sequence, and the last data block information carries a termination identifier. The main device determines that the configuration file data block transmission is complete based on the termination identifier, and splices the multiple data blocks to obtain a complete configuration file.

[0077] In another possible implementation, multiple data blocks of the configuration file are obtained and concatenated to obtain the complete configuration file, including:

[0078] Retrieve the data blocks from the configuration file, and parse them to determine the data block sequence number and configuration text information for verification;

[0079] When the verification passes, a data block verification pass message is sent to instruct the ad hoc network device to continue sending data blocks; the data block verification pass message includes at least the data block sequence number to instruct the ad hoc network device to determine the data block to be sent based on the data block sequence number.

[0080] After the main network device sends the configuration file request message, it can continuously receive data block information of multiple configuration files sent or transmitted in sequence. After receiving each data block, it performs verification and sends back a success message to the self-organizing network device to ensure the accurate acquisition of each data block and achieve successful splicing of the complete configuration file.

[0081] In this embodiment, the main networking device receives the configuration file in the form of data blocks, which reduces the amount of data transmitted in a single transmission and reduces the probability of configuration file transmission failure due to network interruptions or other reasons.

[0082] In one possible implementation, when the verification result indicates that a complete configuration file matching the subnetting device is stored, it also includes:

[0083] A feedback configuration verification pass message indicates that the sub-network device configuration is complete and data upload is initiated.

[0084] In this embodiment, the main network device and the self-organizing network device confirm the successful configuration through configuration verification messages and simultaneously enter the data collection preparation stage, thereby improving the efficiency of data interaction.

[0085] In the actual implementation process, not only are the methods for obtaining configuration files different for the main network devices, but there are also multiple ways to obtain the verification result of whether a complete configuration file matching the sub-network devices is stored.

[0086] In one possible implementation, step S101, obtaining the verification result of whether a complete configuration file matching the sub-network device is stored, includes:

[0087] Based on the device networking message, verify whether a complete configuration file matching the sub-network device is stored.

[0088] In another possible implementation, step S101 involves obtaining a verification result regarding whether a complete configuration file matching the sub-network device is stored, including:

[0089] The system generates a verification command based on the device networking message and the stored configuration file, sends the verification command to the sub-network device or third-party device, and receives the verification result from the sub-network device or third-party device.

[0090] In this embodiment, the verification of whether a complete configuration file matching the sub-network device exists can be completed through any one of three methods: self-verification by the main network device, verification by the sub-network device or by a third-party device.

[0091] In one possible implementation, before receiving the configuration request message sent by the sub-network device, the following is also included:

[0092] Broadcast a network configuration request message to instruct sub-network devices to respond with a device network configuration message; and / or,

[0093] Send a network polling command to the sub-network devices to instruct them to send network packets.

[0094] In the specific implementation process, before completing the self-organizing network configuration, it is necessary to ensure that the sub-network devices and the main network devices are in the same network environment, and that the sub-network devices and the main network devices are aware of each other's existence. The sub-network devices and the main network devices can confirm each other's existence through active discovery and passive discovery.

[0095] Before receiving the configuration request message sent by the sub-network device, the main networking device broadcasts a networking request message to instruct the sub-network device to send a device networking message in return. In other words, the main networking device initiates device discovery as the active party.

[0096] In other embodiments, the primary networking device receives networking request messages broadcast by the sub-networking devices and sends back device networking messages to achieve passive discovery.

[0097] In addition, when the main networking device is connected to the sub-networking device via a wired connection, it can actively discover the sub-networking device by sending a networking polling command to the sub-networking device.

[0098] In this embodiment of the application, before receiving the configuration request message sent by the sub-network device, the main network device and the sub-network device complete device discovery in different ways to ensure that there are devices that can communicate in the same network environment before executing the configuration request, so that the networking process can proceed smoothly.

[0099] In specific embodiments, depending on the device type of the sub-network devices, the device discovery methods between the main network devices and the sub-network devices are different.

[0100] In one possible implementation, when the sub-networking device is a network terminal device, the device networking message is actively sent by the sub-networking device; or, before receiving the configuration request message sent by the sub-networking device, the following is also included:

[0101] Broadcast a network configuration request message to instruct the sub-network devices to respond with a device network configuration message;

[0102] When the sub-network device is a serial terminal device, before receiving the configuration request message sent by the sub-network device, the following is also included:

[0103] Send a network polling command to the sub-network devices.

[0104] When the sub-networking device is a network terminal device, in step S101, a device networking message is received from the sub-networking device. This device networking message is sent actively by the sub-networking device or is fed back by the sub-networking device in response to a networking request message sent by the master device.

[0105] When the sub-networking device is a serial port terminal device, in step S101, the device networking message from the sub-networking device is responded to by the serial port terminal device in response to the networking polling command.

[0106] In one possible implementation, when the sub-networking device is a network terminal device, it connects to the sub-networking device through the first interface, broadcasts networking request messages and receives device networking messages based on the ARP protocol, sends configuration file request messages and receives configuration files sent by the sub-networking device based on the TCP-MODBUS protocol, and receives data uploaded by the sub-networking device based on the SNMP protocol.

[0107] When the sub-networking device is a serial terminal device, it connects to the sub-networking device through the second interface, and sends network polling commands, receives device networking messages, sends configuration file request messages, receives configuration files sent by the sub-networking device, and receives data uploaded by the sub-networking device based on the RTU-MODBUSARP protocol.

[0108] In this embodiment, when the sub-network device is a network terminal device, device discovery, configuration file interaction, and data collection are completed through three protocols: ARP, TCP-MODBUS, and SNMP. This ensures that device discovery, configuration file interaction, and data collection do not interfere with each other. When a large number of devices are connected, device discovery, configuration file interaction, and data collection for different sub-network devices can also be performed simultaneously.

[0109] In one possible implementation, when the verification result indicates that a complete configuration file matching the sub-network device is missing, a configuration file request message is sent, including:

[0110] Determine the total number of data blocks in the complete configuration file that matches the subnetting devices;

[0111] Determine the number of data blocks and their sequence numbers corresponding to the configuration files currently stored that match the subnetting devices;

[0112] Generate a configuration file request message based on the number of data blocks and the data block sequence number, and send the configuration file request message.

[0113] In this embodiment, a configuration file request message is generated based on the total number of data blocks of the complete configuration file that matches the sub-network device, the number of data blocks corresponding to the currently stored configuration file that matches the sub-network device, and the data block sequence number. This message instructs the sub-network device to continue sending the remaining configuration file data blocks, thus avoiding duplication during configuration file transmission.

[0114] In one possible implementation, the configuration file request message includes at least the device type, configuration text information, data block sequence number, data block information, and checksum;

[0115] When a subnet device sends a configuration file, the configuration file feedback message should include at least the device type, configuration text information, and data block sequence number.

[0116] In one alternative embodiment, the protocol architecture of the configuration file request message is as follows:

[0117]

[0118] The device type is used when multiple sub-network devices access the network to indicate the device that needs to upload the configuration file. The configuration text information, data block sequence number, and data block information indicate the configuration file information currently stored and to be sent by the sub-network device, facilitating the sub-network device to continue sending the remaining configuration file data blocks. The CRC checksum indicates the verification result of the current configuration file. If the verification result is successful, the sub-network device uploads the next data block information based on the data block sequence number; otherwise, the sub-network device retransmits the data block information based on the data block sequence number. Optionally, the CRC checksum is represented by 1 or 0, where 1 represents a successful verification result and 0 represents a failed verification result.

[0119] The protocol architecture for the configuration file feedback message is as follows:

[0120]

[0121] Among them, the device type is used to indicate the device type of the uploaded configuration file, and the configuration text information and data block sequence number are used to provide feedback on the configuration file information and corresponding data block sequence number currently sent by the sub-network device.

[0122] In one possible implementation, the device networking message includes one or more of the following: device type, configuration text information, and default configuration file checksum.

[0123] Accordingly, before parsing the configuration file, the following is also included:

[0124] Verify whether a complete configuration file matching the subnet device is stored, based on the device type and / or configuration text information and / or default configuration file checksum.

[0125] In this embodiment, when the sub-network devices to be connected to the main network device include multiple types and are not duplicated, it can be determined whether a complete configuration file corresponding to the sub-network device is currently stored based on the device type. When a sub-network device of the same type is connected, it can be further determined whether a complete configuration file matching the sub-network device is stored based on the configuration text information and / or the default configuration file check code.

[0126] In one optional embodiment, the protocol architecture of the device networking message is as follows:

[0127]

[0128] In different embodiments, the protocol architecture based on the device networking messages can satisfy scenarios with sub-networking devices of the same type and sub-networking device types that do not overlap.

[0129] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0130] The following are device embodiments of this application. For details not described in detail, please refer to the corresponding method embodiments described above.

[0131] This application provides a device self-organizing network system, including: a management unit, a data collector, and terminal devices;

[0132] The terminal equipment includes network terminal equipment and / or serial port terminal equipment;

[0133] The management unit, acting as the main networking device, performs the steps of the method described in any of the above embodiments to connect with the collector.

[0134] The collector, acting as the main networking device, performs the steps of the method described in any of the above embodiments to connect with the terminal device.

[0135] In practical implementation, the interface between the data acquisition unit and the upper-level platform management machine is the first interface, and the interface between the terminal device and the upper-level data acquisition unit is the second interface. The first interface is a network communication interface, and the second interface is a combined interface, including both a network communication interface and a serial port. The network communication interface may include, for example, an Ethernet interface or a LAN interface. In one specific embodiment, the interface connections between the management machine, the data acquisition unit, and the terminal device are as follows: Figure 2 As shown.

[0136] Between the data acquisition device and the upper-level platform management machine, such as Figure 3 As shown, it is based on ARP, TCP-MODBUS and SNMP protocols, and communicates with each other through a network communication interface.

[0137] The data acquisition unit and the terminal device are connected via a network communication interface and a serial port, such as... Figure 4 As shown, the network communication interface is also based on ARP, TCP-MODBUS and SNMP protocols for communication and interaction, while the serial communication is based on the RTU-MODBUS protocol.

[0138] In practical implementation, the solution provided in this application is not only applicable to scenarios including three levels of devices: management machine, data collector, and terminal device, but also applicable to the following different application scenarios:

[0139] Scenario 1: In a multi-micro-module monitoring scenario within a small to medium-sized data center, a unified monitoring and management system is typically required to integrate and manage all micro-module data. Multiple micro-modules are usually present, using the same or different versions of data acquisition devices.

[0140] Based on the device self-organizing network configuration method provided in this application, the monitoring and management system, as the main networking device, can automatically search for and discover data acquisition devices within the local area network and add them to the communication list; the monitoring and management system automatically detects the device protocol of the acquisition device, automatically achieves protocol matching, and further completes data transmission.

[0141] Scenario 2: In a distributed branch centralized monitoring scenario, taking bank branch monitoring as an example, the scale of each branch is different, and each branch uses a different data collector; the physical distance between branches is far. A monitoring server is deployed in the central bank to unify the access of the data collectors of branches across regions and network segments for centralized monitoring and management.

[0142] Based on the device self-organizing network configuration method provided in this application, the monitoring server can import the list of collectors in batches, automatically create addresses, add collectors, automatically detect the type of collectors, automatically identify the device protocol of the collectors, automatically achieve protocol matching, and further complete data transmission.

[0143] Scenario 3: In the micro-module integrated monitoring scenario, the monitoring host connects and monitors various types of equipment, including power, environmental, security, and fire protection devices, within the entire micro-module through serial ports, networks, and other means.

[0144] Based on the device self-organizing network configuration method provided in this application, the monitoring host can automatically search and discover network devices in the micro-module local area network, identify information on self-produced devices and purchased devices, automatically identify the protocols of self-produced network devices, automatically achieve protocol matching, and further complete data communication transmission. It can also automatically identify the device type, quantity, and protocol of devices connected to the host serial port, and automatically identify the protocols of self-produced serial port devices, automatically achieve protocol matching, and further complete data transmission.

[0145] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device 5 in this embodiment includes: a processor 50, a memory 51, and a computer program 52 stored in the memory 51 and executable on the processor 50. When the processor 50 executes the computer program 52, it implements the steps in the various device self-organizing network configuration method embodiments described above, for example... Figure 1 The steps shown.

[0146] For example, the computer program 52 may be divided into one or more modules / units, which are stored in the memory 51 and executed by the processor 50 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 52 in the electronic device 5.

[0147] The electronic device 5 can be a desktop computer, laptop, handheld computer, or cloud server, etc. The electronic device 5 may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0148] The processor 50 may be a Central Processing Unit (CPU), or 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. A general-purpose processor may be a microprocessor or any conventional processor.

[0149] The memory 51 can be an internal storage unit of the electronic device 5, such as a hard disk or memory. The memory 51 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 51 can include both internal and external storage units of the electronic device 5. The memory 51 is used to store the computer program and other programs and data required by the electronic device. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0150] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

[0152] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.

[0153] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

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

[0156] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above-described embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the above-described device self-organizing network configuration method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0157] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A device ad hoc network configuration method characterized by comprising: Used for primary network devices, including: Receive device networking messages from sub-network devices and obtain a verification result of whether a complete configuration file matching the sub-network device is stored; If the verification result indicates that a complete configuration file matching the sub-network device is missing, a configuration file request message is sent. Obtain the complete configuration file corresponding to the sub-network device, parse the configuration file, and generate a data acquisition scheme for the sub-network device; The step of obtaining the verification result of whether a complete configuration file matching the sub-network device is stored includes: Based on the device networking message, verify whether a complete configuration file matching the sub-network device is stored; or... A verification command is generated based on the device networking message and the stored configuration file, and the verification command is sent to the sub-networking device or third-party device, and the verification result fed back by the sub-networking device or third-party device is received.

2. The device ad hoc network configuration method according to claim 1, wherein Before receiving the configuration file request message sent by the sub-network device, the following is also included: Broadcast a network formation request message to instruct the sub-networking devices to respond with a device network formation message; and / or, Send a network polling command to the sub-networking device to instruct the sub-networking device to send back the device network message.

3. The device ad hoc network configuration method according to claim 2, wherein When the sub-networking device is a network terminal device, the device networking message is actively sent by the sub-networking device; or, before receiving the configuration file request message sent by the sub-networking device, the following is also included: Broadcast a network formation request message to instruct the sub-networking devices to respond with a device network formation message; When the sub-network device is a serial terminal device, before receiving the configuration file request message sent by the sub-network device, the following is also included: Send a network polling command to the sub-networking device.

4. The device ad hoc network configuration method according to claim 3, wherein When the sub-networking device is a network terminal device, it connects to the sub-networking device through the first interface, broadcasts the networking request message and receives the device networking message based on the ARP protocol, sends the configuration file request message and receives the configuration file sent by the sub-networking device based on the TCP-MODBUS protocol, and receives the data uploaded by the sub-networking device based on the SNMP protocol. When the sub-networking device is a serial terminal device, it connects to the sub-networking device through the second interface, sends network polling commands based on the RTU-MODBUSARP protocol, receives network packets from the device, sends configuration file request packets, receives configuration files sent by the sub-networking device, and receives data uploaded by the sub-networking device.

5. The method of claim 1, wherein, When the verification result indicates that a complete configuration file matching the sub-network device is missing, a configuration file request message is sent, including: Determine the total number of data blocks in the complete configuration file that matches the sub-network device; Determine the number of data blocks and the data block sequence number corresponding to the configuration file currently stored that matches the sub-network device; The configuration file request message is generated based on the number of data blocks and the sequence number of the data blocks, and then sent.

6. The device ad hoc network configuration method according to claim 5, wherein The configuration file request message at least includes device type, configuration text information, data block serial number, data block information and check code; The configuration file feedback message at least includes device type, configuration text information and data block serial number when the sub-network device sends the configuration file.

7. The method of claim 6, wherein, The device networking message includes one or more of device type, configuration text information and default configuration file check code; Correspondingly, before the configuration file is parsed, the method further includes: According to the device type and / or configuration text information and / or default configuration file check code, it is checked whether a complete configuration file matching the sub-network device is stored.

8. A device ad hoc network system, characterized by comprising: It includes: The management machine, the collector and the terminal device; The terminal device includes network terminal device and / or serial port terminal device; The management machine executes the steps of the method according to any one of claims 1 to 7 to connect with the collector; The collector executes the steps of the method according to any one of claims 1 to 7 to connect with the terminal device.

9. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8. The computer program is executed by the processor to realize the steps of the method according to any one of claims 1 to 7.

Images