Equipment management method and system based on industrial internet identification analysis system

Abstract

The invention provides an equipment management method and system based on an industrial internet identification analysis system, which are applied to the technical field of industrial internet, and are used for receiving a data packet using a proprietary protocol from heterogeneous industrial equipment, and analyzing and converting the proprietary protocol data packet through a protocol conversion gateway deployed in a local private cloud environment. The standard format data is transmitted to the device identification management module through the security data channel, and data encryption is carried out, so that the security of the data in the transmission process is ensured. And carrying out equipment identity verification based on the extracted equipment identification information by utilizing an equipment identification management module, and carrying out equipment state management according to the equipment state information, thereby realizing unified management of the heterogeneous equipment. Therefore, the scheme has the advantages that under the local private cloud environment, enterprise special protocols are compatible, the confidentiality of protocol details is guaranteed, and unified management and secure data exchange of heterogeneous equipment are realized.

Description

Technical Field

[0001] This application relates to the technical field of industrial Internet, and particularly to a device management method and system based on the industrial Internet identification and resolution system. Background Art

[0002] In the intelligent workshop of a large manufacturing enterprise, in order to achieve the efficient collaboration and data security of production equipment, a large number of devices such as numerically controlled machine tools, automated robots, and sensors are deployed in the workshop. The data interaction between these devices and between the devices and the control center does not use a general industrial standard protocol, but a proprietary communication protocol independently developed by the enterprise in the early stage. In order to respond to the national industrial Internet strategy, the enterprise hopes to introduce the industrial Internet identification and resolution system to uniformly manage and conduct trusted authentication on various devices in the workshop. However, since this proprietary protocol involves the core technical secrets of the enterprise, the enterprise does not want to fully disclose it externally or migrate it to the public cloud platform. Therefore, it is necessary to build a device management solution based on the industrial Internet identification and resolution system in the enterprise's local private cloud environment. This solution should not only be able to be compatible with and resolve the enterprise's existing proprietary protocol to achieve unified identity management and status monitoring of devices of different brands and models, but also fully protect the technical details of the enterprise's proprietary protocol and sensitive production data from being leaked during the protocol parsing and data transmission processes, ensuring the maintenance of the enterprise's core technical competitiveness and data security while meeting the standards of the industrial Internet identification and resolution system.

[0003] When heterogeneous devices in an enterprise production workshop communicate using a proprietary protocol, traditional industrial Internet identification and resolution methods based on standard protocols are difficult to simultaneously meet the compatibility requirements of the proprietary protocol and the confidentiality requirements of protocol details in a local deployment environment.

[0004] Therefore, there is a lack of an industrial Internet identification and resolution solution in the prior art that is compatible with an enterprise's proprietary protocol without fully exposing the details of the proprietary protocol to achieve trusted management of heterogeneous devices and secure data exchange. Summary of the Invention

[0005] In view of the deficiencies of the above prior art, the device management method and system based on the industrial Internet identification and resolution system provided by this application are applied in the technical field of industrial Internet, and have the advantages of being compatible with an enterprise's proprietary protocol in a local private cloud environment, ensuring the confidentiality of protocol details, and achieving unified management of heterogeneous devices and secure data exchange.

[0006] In a first aspect, a device management method based on the industrial Internet identification and resolution system is applied to an industrial Internet platform in a local private cloud environment. The industrial Internet platform accesses heterogeneous industrial devices that communicate using a proprietary protocol. The method includes: S1: Receive data packets based on proprietary protocols from heterogeneous industrial devices; S2: Parse the data packets through a protocol conversion gateway, extract device identification information and device status information, and convert them into standard format data. The protocol conversion gateway is deployed in a local private cloud environment to isolate the privacy data in the data packets; S3: Transmit the standard format data to the device identification management module through a secure data channel for encrypted data transmission; S4: Through the device identification management module, authenticate the connected heterogeneous industrial devices based on the device identification information, and manage the device status according to the device status information.

[0007] A device management method based on the industrial Internet identification resolution system provided by this application. By receiving data packets using proprietary protocols from heterogeneous industrial devices, it shows that the method is targeted at industrial devices using diverse proprietary protocols. Through the protocol conversion gateway deployed in the local private cloud environment, the proprietary protocol data packets are parsed and converted. The standard format data is transmitted to the device identification management module through a secure data channel and encrypted to ensure the security of the data during transmission. Using the device identification management module, device authentication is performed based on the extracted device identification information, and device status management is carried out according to the device status information to achieve unified management of heterogeneous devices. Therefore, this solution isolates the proprietary protocol in the local private cloud environment through the protocol conversion gateway, extracts key information and converts it into a standard format, and then transmits it through a secure channel and processes it by the device identification management module, realizing effective management of heterogeneous industrial devices while ensuring the privacy of the proprietary protocol. It has the advantages of being compatible with enterprise proprietary protocols in the local private cloud environment, ensuring the confidentiality of protocol details, achieving unified management of heterogeneous devices, and secure data exchange.

[0008] Further, step S2 includes: S21: Obtain the protocol version information in the data packet; S22: Retrieve the corresponding version of the protocol parsing rule from the local protocol library according to the protocol version information; S23: Segmentally parse the data packet based on the protocol parsing rule to generate a data segment sequence; S24: Extract the device identification information and device status information from the data segment sequence, and mask the remaining data segments; S25: Convert the device identification information and device status information according to the data format standard of the industrial Internet identification resolution system to generate standard format data.

[0009] A device management method based on the industrial Internet identification and resolution system provided by this application obtains the protocol version information in the data packet, which provides a basis for subsequently selecting the correct parsing rules. Then, according to the obtained protocol version information, the protocol parsing rules of the corresponding version are retrieved from the local protocol library, ensuring the consistency between the parsing rules and the protocol version. Based on the retrieved protocol parsing rules, the data packet is segmented and parsed to generate a data segment sequence, laying a foundation for subsequent information extraction. The device identification information and device status information are accurately extracted from the data segment sequence, and the remaining data segments are masked, realizing the isolation of privacy data in the proprietary protocol, meeting the requirements for the confidentiality of protocol details in the background technology. Finally, the extracted device identification information and device status information are converted into the standard format data of the industrial Internet identification and resolution system, ensuring the unity of the data format and providing convenience for the data processing of the subsequent device management module.

[0010] Further, step S22 includes: S221: Obtain the manufacturer identifier and version number in the protocol version information; S222: Search for the corresponding manufacturer protocol rule set in the local protocol library according to the manufacturer identifier; S223: Determine whether there is a protocol parsing rule corresponding to the version number in the manufacturer protocol rule set; S224: When there is a corresponding protocol parsing rule, verify the integrity of the protocol parsing rule; S225: When the protocol parsing rule passes the verification, retrieve the protocol parsing rule; S226: When there is no corresponding protocol parsing rule or the verification fails, send a protocol rule request to the device, obtain the protocol rule currently used by the device, and store the obtained protocol rule in the local protocol library.

[0011] A device management method based on the industrial Internet identification and resolution system provided by this application initially locates the corresponding manufacturer protocol rule set in the local protocol library by using the manufacturer identifier. Under the manufacturer protocol rule set, it is further determined whether there is a protocol parsing rule that exactly matches the version number, aiming for more accurate positioning. When it is determined that there is a corresponding protocol parsing rule, the integrity of the locally stored protocol parsing rule is verified, and the rule is retrieved after the verification passes. This ensures that even if there is a rule locally, the validity and availability of the rule need to be guaranteed, avoiding using damaged or incomplete rules for parsing. When it is determined that there is no corresponding protocol parsing rule in the local protocol library, or the verification fails, it is no longer limited to the local protocol library, but actively sends a protocol rule request to the device, attempts to obtain the protocol rule currently used by the device from the device side, and stores the protocol rule obtained from the device side in the local protocol library for subsequent use.

[0012] Further, step S226 includes: S2261: Obtain the communication status information of the device; S2262: When the communication status information indicates that the device is online, send a protocol rule request to the device, receive the protocol rule data packet returned by the device, and perform an integrity check on the protocol rule data packet; S2263: When the protocol rule data packet passes the check, parse the protocol rule data packet into protocol rules, and perform a security scan on the protocol rules to detect whether there is malicious code; S2264: When the protocol rules pass the security scan, store the protocol rules in the local protocol library; S2265: When the protocol rules do not pass the security scan, mark the device as a restricted device and send an alarm message to the management module.

[0013] A device management method based on the industrial Internet identification resolution system provided by this application obtains the device communication status information to ensure that the device is online. When the device is online, a protocol rule request is sent to the device, and the protocol rule data packet returned by the device is received. Subsequently, an integrity check is performed on the received data packet to ensure that the data is not damaged or lost during transmission. After the data packet integrity check passes, the data packet is parsed into protocol rules and a security scan is performed to detect whether there is malicious code. This is to prevent malicious devices from attacking the system by providing malicious protocol rules. After the protocol rules pass the security scan, they are stored in the local protocol library for subsequent use without having to request from the device again. In the case where the security scan fails, the device is marked as a restricted device at this time, and an alarm message is sent to the management module. This is a security protection measure to avoid potential risk devices affecting system security.

[0014] Further, step S24 includes: S241: Obtain the position information of the preset device identification information field and device status information field; S242: Locate and extract the device identification information and device status information from the data segment sequence according to the position information, and perform masking processing on the remaining data segments in the data segment sequence; S243: Determine whether the extracted device identification information and device status information are complete; S244: When the judgment result is incomplete, complete the missing information according to the preset data completion rule, output the complete device identification information and device status information, and discard the masked data segment sequence.

[0015] Further, step S3 includes: S31: Detect the current network status of the secure data channel; S32: Select an encryption algorithm according to the network status. When the network status is good, select an asymmetric encryption algorithm; when the network status is poor, select a symmetric encryption algorithm; S33: Encrypt the standard format data using the selected encryption algorithm, and transmit the encrypted data in packets to the device identification management module; S34: After the device identification management module receives all the data packets, perform data integrity verification; S35: When the verification passes, decrypt and process the received data; when the verification fails, send a retransmission request to the protocol conversion gateway.

[0016] Further, step S34 includes: S341: Obtain a preset data packet integrity verification threshold; S342: Calculate the actual verification value of all the received data packets; S343: Compare the actual verification value with the integrity verification threshold; S344: When the actual verification value is not lower than the integrity verification threshold, determine that the data packet integrity verification passes; S345: When the actual verification value is lower than the integrity verification threshold, determine that the data packet integrity verification fails; S346: For the data packets that fail the verification, identify the damaged or lost parts therein to obtain an identification result, and according to the identification result, send a targeted retransmission request to the protocol conversion gateway, only requesting the retransmission of the damaged or lost data parts.

[0017] Further, in step S346, according to the identification result, sending a targeted retransmission request to the protocol conversion gateway, only requesting the retransmission of the damaged or lost data parts includes: S3461: Obtain the network bandwidth information and the current network load status; S3462: Calculate the estimated time required for retransmission according to the size of the damaged or lost data parts and the network bandwidth information; S3463: When the estimated time is less than the preset threshold and the current network load status permits, immediately send a retransmission request; S3464: When the estimated time is greater than the preset threshold or the current network load status does not permit, add the retransmission request to the waiting queue, periodically check the retransmission requests in the waiting queue, and evaluate the network condition; S3465: When the network condition improves, select the retransmission request with the highest priority from the waiting queue and send it; S3466: Receive the retransmitted data and verify the data integrity; S3467: If the data integrity verification passes, merge the retransmitted data with the original data; if the data integrity verification fails, add the retransmission request back to the waiting queue.

[0018] Further, step S4 includes: S41: Receive standard format data from the protocol conversion gateway, and extract device identification information and device status information from the standard format data; S42: Query device registration information in the local database according to the device identification information; S43: When matching device registration information is found, mark the device as authenticated; S44: When no matching device registration information is found, mark the device as unauthenticated and send an abnormal device alarm to the security management module; S45: For devices in the authenticated state, parse the device status information and update the device status database; S46: Detect whether the key parameters in the device status information exceed the preset threshold; S47: When it is detected that the key parameters exceed the preset threshold, trigger the device exception handling process and generate a device status report, which at least includes the device authentication status, the current operating status, and the abnormal situation; S48: Send the device status report to the control center for unified management and decision-making.

[0019] In a second aspect, a device management system based on the industrial Internet identification and resolution system operates according to any one of the above-mentioned device management methods based on the industrial Internet identification and resolution system. The system includes: A receiving module, configured to receive packets based on proprietary protocols from heterogeneous industrial devices; An analysis module, configured to analyze the packets through a protocol conversion gateway, extract device identification information and device status information, and convert them into standard format data. The protocol conversion gateway is deployed in the local private cloud environment to isolate the privacy data of the proprietary protocol; A transmission module, configured to transmit the standard format data to the device identification management module through a secure data channel for encrypted data transmission; A management module, configured to authenticate the access devices based on the device identification information through the device identification management module, and manage the device status according to the device status information.

[0020] Beneficial effects: The device management method and system based on the industrial Internet identification and resolution system proposed in this application receive data packets using proprietary protocols from heterogeneous industrial devices, indicating that the method targets industrial devices using diverse proprietary protocols. Through the protocol conversion gateway deployed in the local private cloud environment, the proprietary protocol data packets are parsed and converted. The standard format data is transmitted to the device identification management module through a secure data channel, and data encryption is performed to ensure the security of the data during transmission. Using the device identification management module, device authentication is performed based on the extracted device identification information, and device status management is performed according to the device status information, realizing the unified management of heterogeneous devices. Therefore, through the protocol conversion gateway, this solution isolates the proprietary protocol in the local private cloud environment, extracts key information and converts it into a standard format, and then transmits it through a secure channel and processes it by the device identification management module, achieving effective management of heterogeneous industrial devices while ensuring the privacy of the proprietary protocol. It has the advantages of being compatible with enterprise proprietary protocols in the local private cloud environment, ensuring the confidentiality of protocol details, realizing unified management of heterogeneous devices, and secure data exchange. Description of the Drawings

[0021] Figure 1 It is a flowchart of a device management method based on the industrial Internet identification and resolution system proposed in this application.

[0022] Figure 2 It is a structural diagram of a device management system based on the industrial Internet identification and resolution system proposed in this application.

[0023] Label description: 201, receiving module; 202, parsing module; 203, transmission module; 204, management module. Detailed Implementation Modes

[0024] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Usually, the components of the embodiments of this application described and marked in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of this application that is required to be protected, but only represents the selected embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of this application.

[0025] It should be noted that similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, terms such as "first", "second", etc. are only used for distinguishing descriptions and cannot be construed as indicating or implying relative importance.

[0026] In the prior art, when heterogeneous devices in an enterprise production workshop communicate using proprietary protocols, traditional industrial Internet identification and resolution methods based on standard protocols are difficult to simultaneously meet the compatibility requirements of proprietary protocols and the confidentiality requirements of protocol details in a local deployment environment.

[0027] To solve this problem, this application provides a device management method and system based on the industrial Internet identification and resolution system. Specifically: Please refer to Figure 1 , a device management method based on the industrial Internet identification and resolution system, which is applied to an industrial Internet platform in a local private cloud environment. The industrial Internet platform accesses heterogeneous industrial devices that communicate using proprietary protocols. The method includes: S1: Receive data packets based on proprietary protocols from heterogeneous industrial devices; S2: Parse the data packets through a protocol conversion gateway, extract device identification information and device status information, and convert them into standard format data. Among them, the protocol conversion gateway is deployed in the local private cloud environment to isolate the privacy data in the data packets; S3: Transmit the standard format data to the device identification management module through a secure data channel for encrypted data transmission; S4: Through the device identification management module, authenticate the accessed heterogeneous industrial devices based on the device identification information, and manage the device status according to the device status information.

[0028] Among them, the industrial Internet platform refers to a comprehensive cloud platform for the industrial field, which can specifically be built using technologies such as cloud computing, big data, and artificial intelligence, and provides services such as device management, data collection, and application development to support industrial intelligent applications. In this solution, the industrial Internet platform, as the carrier of the device management method, provides a basic platform for device access, data processing, and application integration. The industrial Internet platform accesses heterogeneous industrial devices that communicate using proprietary protocols.

[0029] In step S1, the data packets are data encapsulated by heterogeneous industrial devices according to their respective proprietary protocols, containing the operating status and identification information of the devices. The received data packets will serve as the original data for subsequent protocol parsing and data processing. Among them, heterogeneous industrial devices refer to diverse industrial devices that adopt different communication protocols, technical architectures, or data formats in industrial scenarios. These devices may come from different manufacturers and have different functions and uses, such as sensors, PLCs (Programmable Logic Controllers), numerically controlled machine tools, intelligent meters, etc.

[0030] In step S2, the protocol conversion gateway is deployed in the local private cloud environment. This deployment location ensures that the data processing process is carried out in a secure and controllable environment within the enterprise, effectively isolating the private data of the proprietary protocol. The core function of the protocol conversion gateway is to deeply parse the received proprietary protocol data packets and extract the device identification information and device status information from them. The device identification information and device status information are the key data for device management and status monitoring. After extracting this key data, the protocol conversion gateway converts it into standard format data. Standard format data is a data format that conforms to the specifications of the industrial Internet identification resolution system, such as JSON or XML. By converting to standard format data, the unified representation of different proprietary protocol data is achieved, laying a foundation for subsequent data processing and management. During the parsing and conversion process, the protocol conversion gateway only extracts and converts the necessary device identification and status information, while other detailed information in the proprietary protocol is isolated in the local private cloud environment, thus ensuring that the technical details of the proprietary protocol are not leaked.

[0031] In step S3, the establishment of a secure data channel is to ensure the security of data during transmission. The data will be encrypted before transmission, for example, using the TLS / SSL encryption protocol, to prevent the data from being stolen or tampered with during transmission. The encrypted data is reliably transmitted to the device identification management module through the secure data channel.

[0032] In step S4, the device identification management module authenticates the heterogeneous industrial devices accessing based on the device identification information. The authentication process includes querying the local database or remote identity authentication system to confirm the legitimacy and identity of the device. After the authentication is passed, the device is confirmed as a legally accessed device. Then, the device identification management module performs device status management according to the device status information. Device status management includes real-time monitoring of the device operating status, storage and analysis of status data, and alarms and controls based on the device status, etc. Through the device identification management module, the unified identity authentication and status management of the accessing heterogeneous industrial devices are achieved.

[0033] Among them, there is a solution to deploy a protocol conversion gateway in a local private cloud environment. As a bridge between proprietary protocols and standard protocols, the core function of the protocol conversion gateway is to parse proprietary protocol data packets, extract device identification information and device status information, and convert this information into data in the standard format required by the industrial Internet identification and resolution system.

[0034] Among them, the local private cloud environment refers to the cloud computing environment built in the enterprise's local data center, which can be specifically implemented by using virtualization technology, container technology, private cloud management platform, etc. Data and applications are stored within the enterprise, featuring high security and high controllability. In this solution, the local private cloud environment provides a secure and reliable operating environment for the deployment of the protocol conversion gateway and the device identification management module, ensuring that the private data of the enterprise's proprietary protocol will not be leaked to the external network.

[0035] Among them, the protocol conversion gateway refers to a network device or software module deployed in the local private cloud environment, which can be specifically implemented by using an embedded system, a server, virtualization software, etc., and is used to convert between proprietary protocols and standard protocols, isolating the private data of the proprietary protocol. In this solution, the protocol conversion gateway is a key component for achieving proprietary protocol compatibility and data security. It is responsible for parsing proprietary protocol data packets, extracting key information, and converting it into a standard format, while preventing the leakage of detailed information of the proprietary protocol.

[0036] Among them, the proprietary protocol refers to a non-public communication protocol independently developed or customized by an enterprise, which can be specifically implemented by using a custom data packet format, encoding method, communication mechanism, etc., and is used for communication between internal devices of the enterprise or between devices and control systems, featuring confidentiality and customization.

[0037] In some specific embodiments, in the intelligent workshop of a large manufacturing enterprise, heterogeneous devices such as numerically controlled machine tools, automated robots, and sensors are deployed. These devices use a proprietary communication protocol independently developed by the enterprise in the early stage for data interaction. In order to achieve unified management of these devices, a device management system based on the industrial Internet identification and resolution system is introduced.

[0038] First, at the data acquisition layer, heterogeneous industrial devices generate data packets according to their respective proprietary protocols. For example, the data packets of numerically controlled machine tools may contain information such as machine tool ID, spindle speed, and feed rate, encoded in a custom binary format. The data packets of automated robots may contain information such as robot ID, joint angles, and end effector status, using another custom protocol format. The data packets of sensors may contain environmental parameter information such as sensor ID, temperature, and humidity, using a proprietary protocol. These data packets are sent to the protocol conversion gateway through the internal network of the workshop.

[0039] The protocol conversion gateway is deployed in the enterprise's local private cloud environment and built with high-performance servers. The protocol conversion gateway is pre-configured with parsing rules for various proprietary protocols, and these rules are stored in the local protocol library. When the protocol conversion gateway receives a data packet from a heterogeneous industrial device, it first identifies the protocol type and version information of the data packet. For example, by parsing the packet header, the protocol version number and the device manufacturer identifier are obtained. Then, based on the protocol version information, the protocol conversion gateway retrieves the corresponding protocol parsing rules from the local protocol library. The protocol parsing rules define how to parse the data packets of a specific proprietary protocol, including the packet structure, the meaning of fields, data types, etc.

[0040] Based on the protocol parsing rules, the protocol conversion gateway performs segmented parsing on the proprietary protocol data packets to extract the device identifier information and the device status information. For example, for the data packets of a numerical control machine, the protocol conversion gateway extracts the machine ID as the device identifier information and extracts the spindle speed, feed rate, etc. as the device status information. For the data packets of an automated robot, the robot ID is extracted as the device identifier information, and the joint angles, end effector status, etc. are extracted as the device status information. For the data packets of a sensor, the sensor ID is extracted as the device identifier information, and the temperature, humidity, etc. are extracted as the device status information. While extracting the key information, the protocol conversion gateway masks other data segments in the proprietary protocol data packets, such as control instructions, debugging information, etc., to reduce the data transmission volume and further protect the privacy details of the proprietary protocol.

[0041] The extracted device identifier information and device status information are converted into standard format data, and the standard format data uses the JSON format. The converted standard format data is transmitted to the device identifier management module through a secure data channel. The secure data channel is established using VPN technology to create an encrypted tunnel between the protocol conversion gateway and the device identifier management module. Before the data is transmitted, it is encrypted using the AES symmetric encryption algorithm to further ensure the security of data transmission.

[0042] After the device identification management module receives the data in standard format, it first decrypts the data and performs integrity verification. The integrity verification uses the CRC verification algorithm to ensure that the data is not damaged or lost during transmission. After the verification passes, the device identification management module extracts the device identification information and device status information from the standard format data. Then, based on the device identification information, the device identification management module queries the local device registration database to verify the identity of the device. If the device is already registered, it marks the device as an authenticated state; if the device is not registered, it marks the device as an unauthenticated state and sends an abnormal device alarm to the security management module. For devices in the authenticated state, the device identification management module parses the device status information, updates the device status database, and monitors the key operating parameters of the device in real time. If it detects that a key parameter exceeds the preset threshold, for example, the spindle speed of a numerically controlled machine tool increases abnormally, it triggers the device exception handling process and generates a device status report. The device status report contains information such as the device authentication status, current operating status, and abnormal conditions, and is sent to the control center for unified management and decision-making. Based on the device status report, the control center can take corresponding control measures in a timely manner, such as shutting down for maintenance, adjusting the production plan, etc., to ensure the stable operation of the intelligent workshop. Among them, the security management module refers to the module used to monitor and manage the device security status in the industrial Internet platform, and its main functions can include: receiving the abnormal device alarm sent by the device identification management module, and recording and alarming unregistered or abnormally statused devices.

[0043] Further, step S2 includes: Step S21: Obtain the protocol version information in the data packet; Step S22: Retrieve the protocol parsing rules for the corresponding version from the local protocol library according to the protocol version information; Step S23: Segment and parse the data packet based on the protocol parsing rules to generate a data segment sequence; Step S24: Extract the device identification information and device status information from the data segment sequence and mask the remaining data segments; Step S25: Convert the device identification information and device status information according to the data format standard of the industrial Internet identification resolution system to generate data in standard format.

[0044] Among them, the protocol version information can be encoded in a specific field of the data header or indicated through a specific protocol field. As an implementation method, the protocol version information can be represented using numbers, strings, or enumeration types, such as version numbers "1.0", "2.0" or version identifiers "V1", "V2", etc. The acquisition of the protocol version information can be obtained by reading specific bytes of the data packet and parsing them according to a predetermined protocol format. The execution of step S21 provides a prerequisite for selecting the correct protocol parsing rules for subsequent steps.

[0045] The local protocol library can be constructed in the form of a database, a file system, or a memory cache, etc., for storing protocol parsing rules of different versions. The protocol parsing rules may include information such as packet structure definitions, field parsing methods, data type conversion rules, etc. Specifically, the parsing rules of multiple protocol versions can be pre-stored in the local protocol library, and each rule corresponds to specific protocol version information. When the protocol version information is obtained in step S21, step S22 will use this version information as an index to search for matching parsing rules in the local protocol library. For example, if the protocol version information is "V2", the parsing rules corresponding to the "V2" version are retrieved from the protocol library. This method ensures the adaptability of the parsing rules to the protocol version.

[0046] Segmented parsing means decomposing a data packet into multiple data segments with specific meanings according to the protocol parsing rules. For example, for a data packet conforming to a specific protocol, the protocol parsing rules may define different data segments such as a data packet header, a device identification field, a status information field, a data payload field, etc. Step S23 will split the data packet into the corresponding data segments according to these definitions and arrange them in order to form a data segment sequence. The data segment sequence provides a structured data basis for subsequent information extraction and data processing.

[0047] Device identification information and device status information are key data required by the device management method. According to the protocol parsing rules, the positions and formats of the device identification information field and the device status information field in the data segment sequence can be determined. Step S24 will extract the device identification information and the device status information from the data segment sequence according to these position information. At the same time, in order to protect the privacy data of proprietary protocols, for other data segments in the data segment sequence except the device identification information and the device status information, such as data segments containing enterprise proprietary control instructions or sensitive production parameters, step S24 will perform masking processing to prevent these data from being leaked or misused. The masking processing can include data erasure, replacing the data with invalid values, or data isolation, etc. Thus, the isolation of privacy data in the proprietary protocol is achieved.

[0048] Different device manufacturers and different protocols may use different data formats to represent device identification information and device status information. In order to achieve the unified management of heterogeneous devices by the device management platform, it is necessary to convert the data in these proprietary formats into a unified standard format. The industrial Internet identification and resolution system defines a series of standard data formats for representing information such as device identification and device status. Step S25 will convert the extracted device identification information and device status information into data in the standard format according to these standards.

[0049] Furthermore, step S22 includes: Step S221: Obtain the manufacturer identifier and version number in the protocol version information; Step S222: Search for the corresponding manufacturer protocol rule set in the local protocol library according to the manufacturer identifier; Step S223: Determine whether there is a protocol parsing rule corresponding to the version number in the manufacturer protocol rule set; Step S224: When there is a corresponding protocol parsing rule, verify the integrity of the protocol parsing rule; Step S225: When the protocol parsing rule passes the verification, retrieve the protocol parsing rule; Step S226: When there is no corresponding protocol parsing rule or the verification fails, send a protocol rule request to the device, obtain the protocol rule currently used by the device, and store the obtained protocol rule in the local protocol library.

[0050] Among them, in step S221, the protocol version information is obtained. The protocol version information can be extracted from the header field of the data packet. The manufacturer identifier can be, for example, the abbreviation of the device manufacturer's name, and the version number can be, for example, the version iteration number of the protocol.

[0051] In step S222, search in the local protocol library according to the manufacturer identifier obtained in step S221. The local protocol library can be organized as a multi-level directory structure. The first-level directory is distinguished by the manufacturer identifier, and the protocol rule set corresponding to each manufacturer identifier is stored under each manufacturer identifier directory.

[0052] In step S223, under the manufacturer protocol rule set initially located in step S222, further determine whether there is a protocol parsing rule that exactly corresponds to the version number. The protocol parsing rule can be stored in the form of a file, and the file name contains version number information for easy search.

[0053] In step S224, when it is determined in step S223 that there is a corresponding protocol parsing rule, the integrity of this rule needs to be verified. The integrity verification method can be, for example, cyclic redundancy checksum verification. By comparing whether the pre-stored checksum is the same as the calculated checksum, it is judged whether the rule file is complete.

[0054] In step S225, when the verification in step S224 passes, the protocol parsing rule is retrieved for subsequent data packet parsing.

[0055] Step S226 is a supplementary step, which is triggered when it is determined in step S223 that there is no corresponding protocol parsing rule, or when the integrity verification in step S224 fails. In step S226, the system sends a protocol rule request to the device, attempting to obtain the protocol rule from the device side. After receiving the request, the device sends the protocol rule it is currently using to the system. After receiving the protocol rule, the system stores it in the local protocol library, completing the update of the local protocol library. Thus, even if the initial state of the local protocol library is incomplete, the system can automatically expand the protocol library by interacting with the device.

[0056] Further, step S226 includes: S2261: Obtain the communication status information of the device; S2262: When the communication status information indicates that the device is online, send a protocol rule request to the device, receive the protocol rule data packet returned by the device, and perform an integrity check on the protocol rule data packet; S2263: When the protocol rule data packet passes the verification, parse the protocol rule data packet into a protocol rule, and perform a security scan on the protocol rule to detect whether there is malicious code; S2264: When the protocol rule passes the security scan, store the protocol rule in the local protocol library; S2265: When the protocol rule fails the security scan, mark the device as a restricted device and send an alarm message to the management module.

[0057] Among them, step S226 aims to provide a solution on how to obtain and process protocol parsing rules when the protocol parsing rule is not found or fails the verification in the local protocol library.

[0058] Step S2261 obtains the device communication status information to ensure that the device is online, which is a prerequisite for requesting the protocol rule from the device. The device communication status information can be obtained through various methods. For example, through a network connection detection mechanism, such as the ping command or TCP heartbeat detection, to determine whether the device is reachable and whether the network connection is normal. As an implementation method, the system can periodically send probe packets to the device and judge the online status of the device according to whether the device responds in time.

[0059] When the device is online, step S2262 sends a protocol rule request to the device and receives the protocol rule data packet returned by the device. Subsequently, an integrity check is performed on the received data packet to ensure that the data is not damaged or lost during transmission. The protocol rule request can be a predefined instruction. For example, a request message containing a specific code. After receiving this request, the device will encapsulate the protocol rules it is currently using into a data packet and return it. The integrity check of the data packet can use various algorithms, such as cyclic redundancy check code (CRC), message digest algorithm (MD5), or secure hash algorithm (SHA), etc. Specifically, when sending the protocol rule request, a check value calculated based on a specific algorithm can be sent simultaneously. After receiving the protocol rule data packet, the check value of the received data packet is calculated using the same algorithm, and the calculated result is compared with the received check value. If the two are consistent, it is considered that the integrity check of the data packet passes.

[0060] After the integrity check of the data packet passes, step S2263 parses the data packet into protocol rules and performs a security scan to detect whether there is malicious code. This is to prevent malicious devices from attacking the system by providing malicious protocol rules. The parsing process of the protocol rule data packet depends on the encapsulation format of the data packet. According to the pre-agreed format, each field in the data packet is parsed to obtain the various components of the protocol rules, such as the version number of the protocol, field definitions, parsing logic, etc. The security scan can be implemented with the help of professional code scanning tools or malicious code detection engines. The scanning process can include analyzing the executable code, scripts, or configuration parameters in the protocol rules to detect whether there are potential malicious behaviors, such as illegal access to system resources, implanting viruses or Trojans, etc.

[0061] After the protocol rules pass the security scan, step S2264 stores them in the local protocol library for subsequent use without having to request them from the device again. The local protocol library can be stored in the form of a database or a file system. The protocol rules in the local protocol library can be indexed and organized according to information such as manufacturer identification and version number, which facilitates quick search and invocation according to the protocol version information in the future.

[0062] Step S2265 takes into account the situation where the security scan fails. At this time, the device is marked as a restricted device, and an alarm message is sent to the management module. This is a security protection measure to prevent potential risky devices from affecting system security. There are various ways to mark a device as a restricted device. For example, in the device management list, the status of the device can be marked as "restricted", or it can be added to a list of restricted devices to limit its access to system permissions or functions. The alarm message can include information such as device identification, type of exception, and occurrence time. The alarm message can be sent to the system administrator or the security management module so that corresponding handling measures can be taken in a timely manner. For example, isolating the restricted device, manually reviewing protocol rules, etc.

[0063] Further, step S24 includes: S241: Obtain the position information of the preset device identification information field and device status information field; S242: Locate and extract the device identification information and device status information from the data segment sequence according to the position information, and mask the remaining data segments in the data segment sequence; S243: Determine whether the extracted device identification information and device status information are complete; S244: When the judgment result is incomplete, complete the missing information according to the preset data completion rule, output the complete device identification information and device status information, and discard the masked data segment sequence.

[0064] Among them, in step S241, the preset position information can be specified as the starting position and field length of the field in the data segment sequence. For example, the device identification information field can be preset to start from the 10th byte of the data segment sequence and have a length of 20 bytes; the device status information field can be preset to start from the 35th byte of the data segment sequence and have a length of 10 bytes. The position information can be obtained manually or by the system's automatic learning and recognition. As an implementation method, the position information can be stored in a configuration file. When the protocol parsing module executes step S241, it reads the corresponding position information from the configuration file. As another implementation method, the device management system can automatically analyze the structural characteristics of the proprietary protocol data packet during the initialization phase to automatically determine the positions of the device identification information field and the device status information field. Among them, the protocol parsing module is a key component for processing heterogeneous industrial device data. Its main function is to parse, extract, and convert the received data packets based on the proprietary protocol so that the data can be converted into a standardized format for subsequent module processing.

[0065] In step S242, according to the location information obtained in step S241, the device identification information field and the device status information field are accurately located from the data segment sequence, and the data in the fields are extracted. At the same time, the data segments in the data segment sequence other than the device identification information field and the device status information field are masked. The masking process can mark these data segments as invalid or directly delete them from the data segment sequence. The data extraction operation and the data masking operation are carried out synchronously, aiming to reduce the amount of data for subsequent data processing and highlight the key information.

[0066] In step S243, the basis for integrity judgment can be a preset integrity rule. For example, the device identification information cannot be empty, and the device status information must contain preset status parameters, etc. The specific method for integrity judgment can be to check whether the extracted information contains null values, or to check whether the extracted information conforms to the preset data format requirements. For example, if the device identification information field is preset as a string type, then it is judged whether the extracted information is a non-empty string. If the device status information field is preset to contain three parameters: temperature, humidity, and pressure, then it is judged whether the extracted information contains the data of these three parameters.

[0067] In step S244, when the judgment result of step S243 is that the information is incomplete, a data completion mechanism is started. The data completion rule is preset and can be customized according to specific application scenarios and data characteristics. The data completion rule can use default values to fill in the missing information. For example, when the temperature parameter is missing in the device status information, a preset default temperature value is used for filling. After data completion processing, complete device identification information and device status information are obtained for subsequent device management processes. At the same time, the data segment sequence after masking, since it only contains a small amount of key information or has been marked as invalid, is discarded and no longer processed subsequently, thereby reducing the occupation of system resources by invalid data.

[0068] Furthermore, step S3 includes: Step S31: Detect the current network status of the secure data channel; Step S32: Select an encryption algorithm according to the network status. When the network status is good, select an asymmetric encryption algorithm; when the network status is poor, select a symmetric encryption algorithm; Step S33: Encrypt the standard format data using the selected encryption algorithm and transmit the encrypted data in packets to the device identification management module; Step S34: After the device identification management module receives all the data packets, perform data integrity verification; Step S35: When the verification passes, decrypt and process the received data; when the verification fails, send a retransmission request to the protocol conversion gateway.

[0069] Among them, in step S31, the network status of the secure data channel can be detected in real time, and the network status parameters at the current moment t are obtained. The network status parameters include the bandwidth B(t), the packet loss rate PLR(t), and the latency L(t).

[0070] In step S32, the selection of the encryption algorithm is dynamically adjusted. The encryption type E_type(t) is determined by the network status parameters.

[0071] When the bandwidth B(t) is greater than the preset bandwidth threshold B_threshold, asymmetric encryption is selected, that is, E_type(t)=1; otherwise, symmetric encryption is selected, that is, E_type(t)=0; In step S33, the standard format data can be encrypted using the encryption algorithm corresponding to the selected encryption type E_type(t). Among them, when E_type(t)=0, a symmetric encryption algorithm is used, and the encryption cost per unit byte is C_sym; when E_type(t)=1, an asymmetric encryption algorithm is used, and the encryption cost per unit byte is C_asym, and C_asym > C_sym; In step S34, data integrity verification is performed, and various verification algorithms can be used, such as CRC verification, MD5 verification, or SHA verification, etc. The selection of the verification algorithm needs to consider both the computational complexity and the verification accuracy. For example, for data transmission with high real-time requirements, the computationally simple CRC verification can be selected; for data transmission with high security requirements, the more secure SHA verification can be selected.

[0072] In step S35, when the data integrity verification fails, the system sends a retransmission request to the protocol conversion gateway, requesting to retransmit all data packets or only the data packets with verification failures. The introduction of the retransmission mechanism improves the reliability of data transmission. If the data integrity verification fails, the retransmission request is processed according to the priority queue policy PriorityQueuePolicy(NetworkState(t)). The priority queue policy queues and manages the retransmission requests according to the network status parameters and the priority of the retransmission requests.

[0073] Among them, NetworkState(t) represents the network status at time t, including the bandwidth B(t), the packet loss rate PLR(t), and the latency L(t); E_type(t) represents the encryption type selected at time t; B_threshold represents the preset bandwidth threshold; C_sym represents the encryption cost per unit byte of symmetric encryption; C_asym represents the encryption cost per unit byte of asymmetric encryption.

[0074] Furthermore, step S34 includes: S341: Obtain the preset data packet integrity verification threshold; S342: Calculate the actual check value of all received data packets; S343: Compare the actual check value with the integrity check threshold; S344: When the actual check value is not lower than the integrity check threshold, determine that the integrity check of the data packet passes; S345: When the actual check value is lower than the integrity check threshold, determine that the integrity check of the data packet fails; S346: For data packets that fail the check, identify the damaged or missing parts therein to obtain an identification result, and based on the identification result, send a targeted retransmission request to the protocol conversion gateway, only requesting the retransmission of the damaged or missing data parts.

[0075] Among them, in step S341, the integrity check threshold of the data packet is a predefined reference value used to measure the integrity and accuracy of the data packet.

[0076] In step S342, the actual check value of the data packet content can be calculated through algorithms (such as CRC check, MD5, SHA, etc.), and the actual check value is used to reflect the integrity and accuracy of the data packet.

[0077] In steps S343 to S345, after comparison, if the actual check value is greater than or equal to the preset check threshold, it indicates that the integrity of the data packet meets the requirements and no serious damage or loss occurred during the transmission process; if the actual check value is lower than the preset check threshold, it indicates that the data packet may have been damaged, lost, or tampered with during the transmission process, and the integrity cannot be guaranteed.

[0078] In step S346, for data packets that fail the check, it is necessary to further analyze the content of the data packet to identify the specific damaged or missing parts. This can be achieved by comparing the original data and the received data.

[0079] Furthermore, in step S346, sending a targeted retransmission request to the protocol conversion gateway only requesting the retransmission of the damaged or missing data parts based on the identification result includes: S3461: Obtain the network bandwidth information and the current network load status; S3462: Calculate the estimated time required for retransmission based on the size of the damaged or missing data parts and the network bandwidth information; S3463: When the estimated time is less than the preset threshold and the current network load status permits, immediately send a retransmission request; S3464: When the estimated time is greater than the preset threshold or the current network load status does not permit, add the retransmission request to the waiting queue, periodically check the retransmission requests in the waiting queue, and evaluate the network condition; S3465: When the network condition improves, select the retransmission request with the highest priority from the waiting queue and send it; S3466: Receive the retransmitted data and verify the data integrity; S3467: If the data integrity verification passes, merge the retransmitted data with the original data; if the data integrity verification fails, add the retransmission request back to the waiting queue.

[0080] First, step S3461 performs the acquisition of network bandwidth information and the current network load status. The network bandwidth information can be directly read from the attributes of the network interface. The current network load status can be evaluated in various ways. For example, it can be judged by detecting the packet loss rate, latency, or congestion degree of the packets in the network. As an implementation method, small probe packets can be sent periodically, and their round-trip time (RTT) and packet loss situation can be analyzed to evaluate whether the current network is in a high-load state. As another implementation method, the network management system can be accessed to directly obtain the metric data of the network load. The network load status can be quantified into different levels, such as "slight", "medium", "busy", etc., or represented by specific load rate values.

[0081] Step S3462 performs the calculation of the estimated time required for retransmission. The estimated time is calculated based on the size of the damaged or lost data part and the current network bandwidth information. Specifically, if the size of the damaged or lost data part is M bits and the current network bandwidth is B bits per second, then the estimated time T can be calculated as T = M / B. In practical applications, in order to estimate the time more accurately, factors such as network latency and protocol overhead can be considered. For example, a fixed latency value can be added as compensation, or the average value and fluctuation range of network latency can be statistically analyzed based on historical data and incorporated into the formula for calculating the estimated time.

[0082] Steps S3463 to S3467 constitute a closed-loop process for retransmission strategy selection and execution. In step S3463, a preset threshold is used to determine whether to immediately send a retransmission request. The preset threshold can be adjusted according to the actual application scenario and network environment. For example, in an industrial control system with high real-time requirements, the preset threshold can be set relatively small, such as 0.1 second or lower, to ensure that the retransmission request can be sent and processed in a timely manner. The current network load status being allowed can be defined as the network load level being lower than a certain threshold. For example, a network load rate lower than 80% can be considered that the current network load status is allowed. When the estimated time is less than the preset threshold and the current network load status is allowed, immediately send the retransmission request to ensure the timeliness of data transmission.

[0083] Step S3464 takes into account the situation where the estimated time is long or the network load does not allow. When the estimated time is greater than the preset threshold, or the current network load status does not allow, the retransmission request is not sent immediately, but added to the waiting queue. The waiting queue is a data structure used to store retransmission requests to be processed. The waiting queue can be sorted according to priority, and the priority can be determined according to factors such as the importance of the data and the transmission time limit. Periodically check the retransmission requests in the waiting queue and evaluate the network condition. The period can be set to, for example, 1 second, 5 seconds, etc., and adjusted according to the actual application. The evaluation method of the network condition is similar to the evaluation method of the network load status in step S3461, and indicators such as the packet loss rate, delay, and congestion degree of the network can be detected.

[0084] In step S3465, when the network condition improves, the improvement of the network condition can be defined as the network load level dropping below a certain threshold. For example, when the network load rate is lower than 50%, it can be considered that the network condition has improved. Select the retransmission request with the highest priority from the waiting queue and send it to ensure that important data is retransmitted first. The retransmission request with the highest priority can be the request that entered the queue earliest, or the request with a higher data importance identifier.

[0085] Step S3466 performs the reception and integrity verification of the retransmitted data. The data integrity verification can adopt methods such as cyclic redundancy check (CRC), checksum, or hash algorithm. After receiving the retransmitted data, use the same data integrity verification method as before to verify the retransmitted data to ensure the reliability of the retransmitted data.

[0086] Step S3467 performs different operations according to the data integrity verification result. If the data integrity verification passes, indicating that the retransmitted data is complete and correct, at this time, merge the retransmitted data with the original data to complete the repair of the data packet. The data merging operation is carried out according to the structure of the data packet and the position information of the damaged / lost part. If the data integrity verification fails, indicating that there are still errors in the retransmitted data, at this time, re-add the retransmission request to the waiting queue and wait for the next retransmission opportunity to ensure the integrity of the data transmission.

[0087] In this regard, the present application further proposes that step S4 includes: S41: Receive the standard format data from the protocol conversion gateway, and extract the device identification information and device status information from the standard format data; S42: Query the device registration information in the local database according to the device identification information; S43: When the matching device registration information is queried, mark the device as the authenticated status; S44: When no matching device registration information is found, mark the device as unauthenticated and send an abnormal device alert to the security management module; S45: For devices in the authenticated state, parse the device status information and update the device status database; S46: Detect whether the key parameters in the device status information exceed the preset thresholds; S47: When it is detected that the key parameters exceed the preset thresholds, trigger the device exception handling process and generate a device status report, which at least includes the device authentication status, the current operating status, and the abnormal conditions; S48: Send the device status report to the control center for unified management and decision-making.

[0088] Among them, in step S41, the standard format data is received from the protocol conversion gateway, and the data contains device identification information and device status information. As an implementation method, the standard format data can be a data packet in JSON format or XML format. The device identification information can be the unique encoding of the device, the device model, or the device serial number. The device status information can include parameters such as the operating temperature, operating current, and fault code of the device.

[0089] In step S42, the local database is used to store the registration information of the registered devices, and the registration information contains the device identification information and other attribute information of the device. The query operation is performed by retrieving in the database through the device identification information. The database can be a relational database, such as MySQL, or a non-relational database, such as Redis.

[0090] Steps S43 and S44 describe two situations of device authentication status marking. When there is matching device registration information in the database, the device is marked as the authenticated state, indicating that the device is a legal device. On the contrary, when no matching device registration information is found in the database, the device is marked as the unauthenticated state, and the system sends an abnormal device alert to the security management module to prompt that there is an unregistered device access. The form of the abnormal device alert can be a text message notification, an email alert, or a system pop-up window.

[0091] In step S45, for the authenticated devices, the device status information is parsed and used to update the device status database. The device status database is used to record and track the real-time status information of the authenticated devices. The update operation can adopt the method of overwriting update or incremental update.

[0092] Steps S46 and S47 describe the device status monitoring and exception handling mechanism. The preset threshold is a parameter critical value set according to the normal operating range of the device. For example, the temperature threshold can be set to 80 degrees Celsius, and the current threshold can be set to 10 amperes. When a key parameter exceeds the preset threshold, the device exception handling process is triggered. The key parameters are important parameters set in advance by technicians, such as temperature, current, or other parameters that need to be focused on. The device exception handling process can include operations such as recording exception logs, shutdown protection, and sending maintenance notifications. A device status report is generated, which includes at least the device authentication status, the current operating status, and the exception situation, to comprehensively reflect the operating condition of the device.

[0093] In step S48, the device status report is sent to the control center. The control center aggregates and analyzes the received device status reports to achieve unified management and decision support for devices in the industrial Internet environment. The control center can perform operations such as remote device control, maintenance scheduling, or production plan adjustment based on the device status report. Thus, through the above steps, effective verification of device identity, real-time monitoring of device status, and timely handling of exceptions are achieved.

[0094] In a second aspect, the present application further proposes a device management system based on the industrial Internet identification and resolution system, which is used to achieve unified management of heterogeneous devices in an intelligent workshop of a manufacturing enterprise using a proprietary communication protocol, and runs a device management method based on the industrial Internet identification and resolution system as described in any one of the above. The system includes: A receiving module 201, configured to receive packets based on a proprietary protocol from heterogeneous industrial devices; An analysis module 202, configured to analyze the packets through a protocol conversion gateway, extract device identification information and device status information, and convert them into standard format data. The protocol conversion gateway is deployed in a local private cloud environment to isolate the privacy data in the packets; A transmission module 203, configured to transmit the standard format data to a device identification management module through a secure data channel for encrypted data transmission; A management module 204, configured to authenticate the heterogeneous industrial devices connected based on the device identification information through the device identification management module, and perform device status management according to the device status information.

[0095] Among them, the receiving module 201 is configured as a data access point for various heterogeneous industrial devices in the workshop, and it can adopt multiple industrial communication interfaces, such as Ethernet interfaces, RS485 interfaces, or wireless interfaces, to be compatible with different physical connection methods of devices.

[0096] The main function of the receiving module 201 is to stably receive data packets from devices and preliminarily collect these data packets to prepare a data basis for subsequent protocol parsing. As an implementation method, the receiving module 201 can be built with a caching mechanism to handle short-term data surges and ensure the integrity and reliability of data reception. In specific implementation, the receiving module can adopt a high-performance network receiver or a multi-channel data acquisition card to meet the high-concurrency and low-latency data reception requirements in the industrial field.

[0097] The parsing module 202 is the core component for implementing proprietary protocol parsing and data format conversion. The protocol conversion gateway is deployed in the local private cloud environment, and this deployment method ensures that proprietary protocol data is processed in the enterprise internal network environment, avoiding the risk of sensitive data leakage.

[0098] After receiving the data packets from the receiving module, the parsing module 202 first identifies the protocol type and version information of the data packets through the protocol conversion gateway. The protocol conversion gateway internally pre-sets a local protocol library containing parsing rules for multiple proprietary protocols. For different protocol types and versions, the protocol conversion gateway can dynamically load the corresponding parsing rules to implement the parsing of proprietary protocol data packets. The parsing process includes segment parsing of data packets, extraction of key fields, and standardization conversion of data formats. For example, for a Modbus TCP protocol data packet, the parsing module can extract the device identification information field and the device status information field according to the preset parsing rules, and convert the data in these fields into a data format that conforms to the standards of the industrial Internet identification parsing system, such as JSON or XML format. During the parsing process, the protocol conversion gateway can also perform desensitization processing on the proprietary protocol data, such as masking sensitive control instructions or process parameters in the protocol and only extracting the necessary information required for device management and status monitoring, further enhancing data security.

[0099] The transmission module 203 is responsible for securely and reliably transmitting the standard format data output by the parsing module 202 to the device identification management module. The establishment of a secure data channel is the key to ensuring data transmission security. As a preferred implementation method, the secure data channel can adopt the TLS / SSL encryption protocol to establish an encrypted connection between the protocol conversion gateway and the device identification management module, and all transmitted data is encrypted to prevent data from being eavesdropped or tampered with during transmission.

[0100] The transmission module 203 can dynamically adjust the data transmission strategy according to the network conditions. For example, in the case of sufficient network bandwidth, an asymmetric encryption algorithm, such as the RSA algorithm, can be adopted to provide higher security; in the case of limited network bandwidth or unstable network, it can be switched to a symmetric encryption algorithm, such as the AES algorithm, to reduce the encryption overhead and ensure the real-time nature of data transmission. The transmission module can also implement a data packet splitting and retransmission mechanism to ensure the integrity and reliability of data transmission in the case of a large amount of data.

[0101] The management module 204 is the core control center of the device management system, and the device identification management module is a key component of the management module. The management module 204 receives the encrypted data from the transmission module and first authenticates the access device through the device identification management module. The device identification management module internally maintains a device registration information database, which stores the identity identification information of all devices allowed to access the system.

[0102] The management module 204 compares the parsed device identification information with the registration information in the database to verify the legitimacy of the device. For the devices that pass the authentication, the management module performs device status management according to the parsed device status information. Device status management includes functions such as monitoring the device operation status, real-time display of device parameters, generation and handling of device exception alarms, etc.

[0103] The management module 204 can also store the device status information in the device status database to provide data support for subsequent data analysis and applications. The management module is also responsible for generating a device status report and sending the report to the control center to achieve unified management and centralized monitoring of all devices in the workshop. The device status report can include information such as the authentication status of the device, the current operation status, abnormal conditions, and historical operation data of the device, providing a comprehensive view of the device operation status for the control center and assisting managers in making decisions.

[0104] The above are only the embodiments of the present application and are not used to limit the protection scope of the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A device management method based on an industrial Internet identification resolution system is applied to an industrial Internet platform in a local private cloud environment, wherein the industrial Internet platform accesses heterogeneous industrial devices that communicate using a proprietary protocol, and is characterized in that: The method includes: S1: Receives data packets based on proprietary protocols from heterogeneous industrial devices; S2: parsing the data packet through a protocol conversion gateway, extracting device identification information and device status information, and converting them into standard format data, wherein the protocol conversion gateway is deployed in a local private cloud environment to isolate the privacy data in the data packet; S3: transmitting the standard format data to the device identification management module through a secure data channel for data encryption transmission; S4: The device identification management module authenticates the connected heterogeneous industrial device based on the device identification information, and manages the device status according to the device status information.

2. According to claim 1, a device management method based on the industrial Internet identification resolution system is characterized in that: Step S2 includes: S21: Acquire protocol version information in the data packet; S22: Retrieving a protocol parsing rule of a corresponding version from a local protocol library according to the protocol version information; S23: Parsing the data packet segment by segment based on the protocol parsing rule to generate a data segment sequence; S24: extracting device identification information and device status information from the data segment sequence, and masking the remaining data segments; S25: Convert the device identification information and device status information according to the data format standard of the industrial Internet identification resolution system to generate standard format data.

3. According to claim 2, a device management method based on the industrial Internet identification resolution system is characterized in that: Step S22 includes: S221: Obtain the manufacturer identifier and version number in the protocol version information; S222: searching for a corresponding manufacturer protocol rule set in a local protocol library according to the manufacturer identifier; S223: Determine whether there is a protocol parsing rule corresponding to the version number in the manufacturer protocol rule set; S224: When a corresponding protocol parsing rule exists, verify the integrity of the protocol parsing rule; S225: When the protocol parsing rule is verified to be passed, calling the protocol parsing rule; S226: When there is no corresponding protocol parsing rule or the verification fails, a protocol rule request is sent to the device to obtain the protocol rule currently used by the device, and the obtained protocol rule is stored in the local protocol library.

4. According to claim 3, a device management method based on an industrial Internet identification resolution system is characterized in that: Step S226 includes: S2261: Obtaining communication status information of the device; S2262: When the communication status information indicates that the device is online, send a protocol rule request to the device, receive a protocol rule data packet returned by the device, and perform integrity check on the protocol rule data packet; S2263: When the protocol rule data packet passes verification, the protocol rule data packet is parsed into a protocol rule, and a security scan is performed on the protocol rule to detect whether there is malicious code; S2264: When the protocol rule passes the security scan, the protocol rule is stored in a local protocol library; S2265: When the protocol rule fails the security scan, the device is marked as a restricted device, and an alarm message is sent to the management module.

5. According to claim 2, a device management method based on an industrial Internet identification resolution system is characterized in that: Step S24 includes: S241: Acquire location information of a preset device identification information field and a device status information field; S242: locating and extracting device identification information and device status information from the data segment sequence according to the position information, and performing masking processing on the remaining data segments in the data segment sequence; S243: Determine whether the extracted device identification information and device status information are complete; S244: When the judgment result is incomplete, the missing information is completed according to the preset data completion rules, the complete device identification information and device status information are output, and the masked data segment sequence is discarded.

6. According to claim 1, a device management method based on the industrial Internet identification resolution system is characterized in that: Step S3 includes: S31: Detect the current network status of the secure data channel; S32: selecting an encryption algorithm according to the network status, selecting an asymmetric encryption algorithm when the network status is good, and selecting a symmetric encryption algorithm when the network status is poor; S33: Encrypt the standard format data using the selected encryption algorithm, and transmit the encrypted data in packets to the device identification management module; S34: After the device identification management module receives all data packets, a data integrity check is performed; S35: When the verification passes, the received data is decrypted and processed; when the verification fails, a retransmission request is sent to the protocol conversion gateway.

7. The device management method based on the industrial Internet identification resolution system according to claim 6 is characterized in that: Step S34 includes: S341: Obtaining a preset data packet integrity check threshold; S342: Calculate the actual checksum values ​​of all received data packets; S343: Compare the actual check value with the integrity check threshold; S344: When the actual check value is not lower than the integrity check threshold, it is determined that the data packet integrity check passes; S345: When the actual check value is lower than the integrity check threshold, determine that the data packet integrity check fails; S346: For the data packets that fail the verification, the damaged or lost parts thereof are identified, an identification result is obtained, and based on the identification result, a targeted retransmission request is sent to the protocol conversion gateway, requesting only the damaged or lost data part to be retransmitted.

8. The device management method based on the industrial Internet identification resolution system according to claim 7 is characterized in that: In step S346, according to the identification result, a targeted retransmission request is sent to the protocol conversion gateway, and only the damaged or lost data part is requested to be retransmitted, including: S3461: Obtain network bandwidth information and current network load status; S3462: Calculate an estimated time required for retransmission according to the size of the damaged or lost data portion and the network bandwidth information; S3463: When the estimated time is less than the preset threshold and the current network load status allows, immediately send a retransmission request; S3464: When the estimated time is greater than a preset threshold or the current network load status does not allow, the retransmission request is added to a waiting queue, and the retransmission requests in the waiting queue are periodically checked to evaluate the network status; S3465: When the network condition improves, select the retransmission request with the highest priority from the waiting queue and send it; S3466: receiving retransmitted data and verifying data integrity; S3467: If the data integrity verification passes, merge the retransmitted data with the original data; if the data integrity verification fails, add the retransmission request to the waiting queue again.

9. The device management method based on the industrial Internet identification resolution system according to claim 1 is characterized in that: Step S4 includes: S41: receiving standard format data from a protocol conversion gateway, and extracting device identification information and device status information from the standard format data; S42: Query device registration information in a local database according to the device identification information; S43: When matching device registration information is found, the device is marked as authenticated; S44: When no matching device registration information is found, the device is marked as unauthenticated and an abnormal device alarm is sent to the security management module; S45: For the authenticated device, parse the device status information and update the device status database; S46: Detect whether key parameters in the device status information exceed a preset threshold; S47: When it is detected that the key parameter exceeds the preset threshold, the device abnormality handling process is triggered, and a device status report is generated, wherein the device status report at least includes the device authentication status, the current operation status and the abnormal situation; S48: Send the equipment status report to the control center for unified management and decision-making.

10. An equipment management system based on the industrial Internet identification resolution system, characterized in that: Running a device management method based on an industrial Internet identification resolution system as described in any one of claims 1 to 9 above, the system comprises: A receiving module, used for receiving data packets based on a proprietary protocol from heterogeneous industrial devices; A parsing module, used to parse the data packet through a protocol conversion gateway, extract device identification information and device status information, and convert them into standard format data, wherein the protocol conversion gateway is deployed in a local private cloud environment and is used to isolate the privacy data in the data packet; A transmission module, used for transmitting the standard format data to the device identification management module through a secure data channel for data encryption transmission; A management module is used to authenticate the connected heterogeneous industrial equipment based on the equipment identification information through the equipment identification management module, and to manage the equipment status according to the equipment status information.

Images