A device level based industrial wireless network adaptive role negotiation method, system and storage medium

Abstract

This invention discloses an adaptive role negotiation method, system, and storage medium for industrial wireless networks based on device hierarchy. The method predefines the correspondence between device types and hierarchy values, where the hierarchy value reflects the degree to which a device is close to the field execution layer or core application and management layer in the network topology. When a local device receives an authentication message with a peer device type identifier embedded in its header, it acquires its own hierarchy value in real time and compares it with the peer's hierarchy value to dynamically determine whether it should act as the authentication initiator or responder, and routes the request to the corresponding processor. The intermediate layer device initializes a dual-role processor simultaneously upon startup. Before formal authentication, encryption capabilities are pre-negotiated and pre-interception matched through pre-exchange of encryption mode, cryptographic algorithm type, and storage state level. This invention achieves seamless dynamic switching of intermediate layer device roles, significantly reducing the overall security deployment and maintenance costs of large-scale industrial wireless networks.

Description

Technical Field

[0001] This invention relates to the field of industrial wireless networks, and in particular to an adaptive role negotiation method, system, and storage medium for industrial wireless networks based on the device level. Background Technology

[0002] Existing industrial wireless network communication systems typically employ a hierarchical network architecture, including various types of devices such as field devices, access devices, gateways, and application servers. In these systems, secure authentication and encrypted communication are required between devices at different topology levels. Existing technologies present the following technical challenges regarding device authentication role configuration and encryption capability negotiation:

[0003] Device role configuration is complex and error-prone: Traditional solutions require manual configuration of each device to determine whether it acts as an authentication initiator or response in the authentication process. This is especially true for devices in the middle layer (such as access devices and gateway devices), which need to act as authentication initiators for upper-layer devices and as authentication responses for lower-layer devices. This dual-role configuration is extremely complex, and in large-scale deployments in industrial fields, not only is the manual configuration workload enormous, but it is also highly prone to configuration errors.

[0004] Incompatible encryption capabilities lead to authentication failures and wasted resources: In industrial networks, devices at different levels often support different encryption algorithms, encryption modes, or cryptographic components due to varying hardware computing power and security requirements. If security capability negotiation is not conducted before the authentication process begins, authentication is highly likely to fail midway due to algorithm incompatibility. This not only wastes valuable computing resources but also increases unnecessary network signaling overhead and time delays.

[0005] Intermediate layer device role switching is difficult and network scalability is poor: In traditional solutions, the authentication roles of devices are usually fixed at the factory or during deployment, making it impossible to flexibly and seamlessly switch roles according to changes in peer devices, resulting in poor dynamic expansion capabilities of the network topology. When a new device layer needs to be added to the network architecture or the device location needs to be adjusted, it is often necessary to modify the role configuration of all relevant devices in the entire network, resulting in extremely high costs for system maintenance and efficient operation and maintenance. Summary of the Invention

[0006] The purpose of this invention is to provide a device-level adaptive role negotiation method, system, and storage medium for industrial wireless networks to solve the problems existing in the prior art.

[0007] The above-mentioned technical objective of the present invention is achieved through the following technical solution:

[0008] An adaptive role negotiation method for industrial wireless networks based on device hierarchy includes the following steps:

[0009] Step S1. Device hierarchy definition: Predefine the correspondence between device type and hierarchy value of each device in the network. Among them, the lower the hierarchy value of the device, the closer it is to the field execution layer in the network topology, and the higher the hierarchy value of the device, the closer it is to the core application and management layer in the network topology.

[0010] Step S2. Message Reception and Type Parsing: When the local device receives an authentication message sent by the peer device, it parses the device type identifier of the peer device from the message header of the authentication message;

[0011] Step S3. Dynamic Role Determination and Routing: The local device obtains its own level value based on its device type, and compares the local level value with the peer level value corresponding to the peer device type identifier; based on the comparison result, it dynamically determines the authentication role that the local device should play, and routes the authentication message to the corresponding processor for processing.

[0012] Furthermore, in step S1, each device in the network performs processor initialization configuration according to its device type upon startup. The correspondence between device type and hierarchical value, and the processor initialization configuration, include at least the following four levels:

[0013] The field device has a level value of 0 and only initializes the authentication initiator processor upon startup.

[0014] The access device has a level value of 1 and initializes both the authentication initiator processor and the authentication responder processor upon startup.

[0015] The gateway device, with a level value of 2, initializes both the authentication initiator processor and the authentication responder processor upon startup.

[0016] The application server, with a tier value of 3, initializes only the authentication responder processor upon startup.

[0017] Furthermore, in step S2, the device type identifier is embedded in the message header of the authentication message.

[0018] Furthermore, in step S3, the rule for dynamically determining the authentication role is as follows:

[0019] If the local device's hierarchical value is lower than the peer device's hierarchical value, then the local device is determined to be playing the role of the authentication initiator.

[0020] If the local device's hierarchical value is higher than the peer device's hierarchical value, then the local device is determined to be playing the role of an authentication responder.

[0021] If the local layer value is equal to the peer layer value, the authentication role played by the local device is determined according to a preset strategy.

[0022] Furthermore, in step S3, the process of routing the authentication message to the corresponding processor includes:

[0023] If the local device is determined to be the authentication initiator, then check whether the authentication initiator processor is enabled; if it is enabled, route the authentication message to the authentication initiator processor for synchronization processing.

[0024] If the local device is determined to act as the authentication responder, then check whether the authentication responder processor is enabled.

[0025] If enabled, a dedicated session for the peer device is located or created locally, and the authentication message is delivered to the message queue of the dedicated session for asynchronous concurrent processing by an independent worker thread.

[0026] Furthermore, after the role determination in step S3 is completed, a pre-negotiation step for encryption capabilities is also included before the formal authentication begins:

[0027] The authentication initiator sends an encryption capability negotiation request to the authentication responder. The encryption capability negotiation request includes at least: the desired encryption mode identifier, the supported cryptographic algorithm type identifier, and the local storage status level.

[0028] After receiving the encryption capability negotiation request, the authentication responder checks the local encryption mode configuration and supported algorithm types, and matches them with the information in the encryption capability negotiation request.

[0029] The authentication responder will reply to the authentication initiator with the negotiation result generated by the matching determination.

[0030] Furthermore, the encryption mode identifier includes: no encryption mode, authentication-only mode, and full encryption mode.

[0031] Furthermore, the rules by which the authentication responder matches and determines the encryption capability negotiation request include:

[0032] If the authentication responder is configured in unencrypted mode, it will directly reply to the authentication initiator with the authentication skip result, and the two parties will directly enter open communication.

[0033] If the authentication responder supports encryption, the cryptographic algorithm type identifiers of both parties are compared; if the algorithm types do not match, an authentication failure result is returned and the authentication process is terminated.

[0034] If the algorithm types match, the target verification level is determined by combining the local storage status levels of both parties, and the target verification level is carried in the negotiation response sent back to the authentication initiator.

[0035] An adaptive role negotiation system for industrial wireless networks based on device hierarchy, comprising:

[0036] Configuration module: Used to define the correspondence between device types and hierarchical values ​​for each device in the network;

[0037] Parsing module: When the local device receives an authentication message sent by the peer device, it parses the device type identifier of the peer device from the message header of the authentication message;

[0038] The routing determination module is used to obtain the local layer value based on the local device type, compare the local layer value with the peer layer value, dynamically determine the authentication role that the local device should play based on the comparison result, and thus route the authentication message to the corresponding processor.

[0039] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the device-level-based industrial wireless network adaptive role negotiation system.

[0040] In summary, the present invention has the following beneficial effects:

[0041] By using a predefined mapping between device types and hierarchical values, the role of a device is automatically determined by its topology level, eliminating the need for tedious manual role configuration for each device. In large-scale industrial wireless network deployments, this significantly reduces the workload of network initialization configuration and completely eliminates authentication failures caused by human error.

[0042] As intermediate layer access and gateway devices, the authentication initiator and authentication responder processors are initialized in parallel during startup. During operation, a simple numerical comparison based on the peer device type parsed from the message header is sufficient to achieve seamless dynamic switching between "acting as a responder when facing a lower-layer device and as an initiator when facing an upper-layer device," without requiring device restarts or reloading configurations, greatly enhancing the network's topology adaptive capability.

[0043] This invention introduces a pre-negotiation step for encryption capabilities before formal authentication begins. By comparing the cryptographic algorithm type identifier beforehand, invalid authentication caused by algorithm incompatibility can be detected and terminated in advance, avoiding subsequent complex cryptographic calculations and multiple rounds of authentication signaling interactions, effectively saving computing resources and bandwidth of limited equipment in industrial settings.

[0044] When an industrial network needs to expand or add device layers, the role determination and routing logic of existing devices do not require any modification; only the layer value of the new device needs to be defined. Simultaneously, the system supports automatic negotiation in three modes: unencrypted, authenticated only, and fully encrypted, perfectly balancing the efficiency of open communication with the robustness of secure communication, adapting to the operational and maintenance needs of various industrial automation systems. Attached Figure Description

[0045] Figure 1 A flowchart illustrating the dynamic role routing process in a device-level adaptive role negotiation method for industrial wireless networks, provided in an embodiment of the present invention.

[0046] Figure 2 A flowchart illustrating the encryption capability pre-negotiation process in a device-level-based adaptive role negotiation method for industrial wireless networks, provided in an embodiment of the present invention.

[0047] Figure 3 This diagram illustrates the authentication role switching in a multi-level cascading scenario within a device-level-based adaptive role negotiation method for industrial wireless networks, as provided in an embodiment of the present invention. Detailed Implementation

[0048] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to the figures and specific embodiments.

[0049] The primary embodiment of this invention constructs a multi-level hierarchical structure for industrial wireless network devices that is fully adaptive to digital and intelligent factory environments. In heterogeneous industrial wireless networks, significant differences exist in the physical topology, hardware computing power redundancy, battery life constraints, and data flow aggregation functions of each communication entity (node). This invention predefines an explicit mapping relationship between device types and abstract logical layer values ​​during network initialization or factory configuration. These layer values ​​strictly reflect the uplink and downlink order of nodes in the topology-decoupled architecture: devices with lower layer values ​​extend further down the network topology and are closer to the high-real-time, low-power field execution layer; conversely, devices with higher layer values ​​converge towards the top of the network topology and are closer to the core applications and management layers with strong computing power and high trust levels.

[0050] I. Multi-level device hierarchy and hardware / software readiness initialization in industrial wireless heterogeneous topology networks

[0051] Combination Figure 3 The hierarchical mapping and typical scenario illustrations shown in this embodiment of the invention demonstrate that, in a specific software-defined network (SDN) or distributed network topology, at least four levels of device entities belonging to different topology levels and possessing independent functional boundaries are explicitly identified:

[0052] Field Devices (FDs): Physically, these are wireless sensors, wireless actuators, RFID readers / writers, or PLC remote I / O modules deployed in industrial settings. In the topology hierarchy, they belong to the field execution layer and are pre-assigned the lowest level value, i.e., a level value of 0. Figure 1 and Figure 2 In this context, based on its underlying connection-initiating attribute, field devices are also referred to as terminal devices. Due to their limited computing power and location at the outermost edge of the network, their network behavior involves only a single logic: requesting access from the upper-layer aggregation node. Therefore, when the software protocol stack starts and the hardware microcontroller (MCU) is initialized, the field device adopts a minimal state machine configuration, initializing only the authentication initiator processor (TERMINAL processor) to maximize memory space release and reduce static power consumption.

[0053] Access Device (AD): Physically, it manifests as an industrial wireless access point (AP), an industrial wireless router, or a data concentrator deployed at the edge of the production line. In the topology hierarchy, it belongs to the middle layer and is assigned a level value of 1.

[0054] Gateway Device (GW): Physically, it manifests as an edge computing gateway, an industrial protocol conversion gateway, or a heterogeneous network cross-domain communication gateway (such as converting the ISA100.11a / WirelessHART protocol stack to Ethernet / 5G core network protocols). It is also classified as part of the middle layer, but with a higher priority, assigned a layer value of 2.

[0055] Application Server (AS): Physically, it manifests as a data server in an industrial control center, a SCADA system host, a MES system server, or a cloud-based manufacturing execution system. In the network topology, it belongs to the core application and management layer, enjoys the highest trust level, and is assigned the highest level value of 3. Due to its absolute superior status as the data endpoint and control center of the entire network, it only acts as a security boundary guardian and authentication verifier in network behavior. Therefore, during system boot, it only initializes the authentication responder processor (ACCESS processor).

[0056] For access devices (ADs) and gateway devices (GWs) in the middle layer, they exhibit typical bidirectional communication characteristics, as they both aggregate and manage lower-level terminal nodes and forward and report to the upper-level core network. Therefore, in this embodiment of the invention, when the underlying operating system (such as embedded Linux or RTOS) completes kernel boot and enters network protocol stack initialization, the access devices and gateway devices perform a dual-role parallel ready initialization configuration: simultaneously initializing the authentication initiator processor (TERMINAL processor) and the authentication responder processor (ACCESS processor) in physical memory. Although these two processors share physical hardware chips (such as wireless baseband chips and hardware encryption chips) and security certificate public and private key resources at the underlying level, they maintain completely independent contexts, different state machine models, and isolated memory buffer queues at the protocol stack application layer. This design enables the middle-layer devices to be prepared for parallel ready switching of "dual roles" without delay at both the software and architectural levels.

[0057] II. Dynamic Role Routing and Multi-Thread Flow Distribution Mechanism for Bursting Authentication Messages Based on Single-Byte Message Header Parsing (corresponding) Figure 1 )

[0058] In industrial production environments, due to production cycle scheduling, intermittent sleep / wake-up of field equipment, or occasional re-entry into the network, equipment may generate sudden security authentication interaction requirements. When the local device (the entity currently processing the message) receives an authentication message asynchronously sent by the peer device (the sending entity) on its wireless network interface, in order to achieve role alignment without introducing multi-round handshake signaling or compromising the channel's energy efficiency, the local device immediately triggers, during the data link layer or transport layer parsing phase of the underlying protocol stack, a security authentication mechanism such as... Figure 1 The dynamic role-adaptive routing process shown below:

[0059] Zero-overhead single-byte header parsing: Upon receiving the authentication message, the local device does not need to read the complete message payload; instead, it directly extracts and strips the message header structure. A key feature of this embodiment is that the device type identifier is directly embedded in the authentication message header as a lightweight 1-byte (8-bit) integer. The local device can accurately parse and obtain the sender's device type identifier within a single clock cycle using low-level bit-mask or direct offset read operations. This design completely avoids the multi-round handshake message interactions required in traditional security architectures to negotiate master-slave roles, reducing bandwidth and latency overhead to their absolute theoretical limits.

[0060] Local hardware topology context read: The local device retrieves its current local device type and corresponding local hierarchy value from its own non-volatile memory (NVRAM) or global system control block.

[0061] High-throughput numerical comparison and multi-dimensional routing determination: The local device compares the obtained local layer value with the peer layer value corresponding to the peer device type identifier obtained through parsing. At this time, the system dynamically and in real time determines the authentication role that the local device should play on this specific communication link through the underlying hardware comparator or efficient conditional branch, to determine whether the local device belongs to ACCESS (i.e., whether it should act as an authentication responder):

[0062] Traffic splitting path one: Determined as TERMINAL (authentication initiator role)

[0063] If, after numerical comparison, the local end's hierarchical value is lower than the peer end's hierarchical value (for example, the local end is a level 1 access device and the peer end is a level 2 gateway device; or the local end is a level 0 field device and the peer end is a level 1 access device), or in a very rare peer-to-peer communication scenario where the peer end's hierarchical value is equal to the local end's hierarchical value, the system's preset conflict avoidance strategy is met (for example, the local end's MAC address is less than the peer end's MAC address), the system determines that the local end should act as the TERMINAL (authentication initiator) in this local communication.

[0064] At this point, the routing determination module immediately performs a preliminary security status check: checking whether the local TERMINAL processor (authentication initiator processor) is currently enabled and ready.

[0065] If the check result indicates that the authentication message is enabled, the routing determination module generates an internal routing interrupt, dynamically routes and delivers the pointer to the authentication message and the current communication context to the TERMINAL processor. The TERMINAL processor then processes the authentication message synchronously, using a single thread or state machine to sequentially advance the logic, ensuring strict state management of the single authentication sequence and maintaining the normal progress of the authentication process.

[0066] If the check result is that it is not enabled (for example, the local end is a Tier 3 application server and the TERMINAL handler has not been initialized at all), the underlying exception capture mechanism of the system is triggered. The system refuses the processing of the illegal role, performs the operation of discarding the message and recording the error log, and then enters the error handling process.

[0067] Second route: Determined as ACCESS (Authentication Response Role)

[0068] If, after numerical comparison, the local end's level value is higher than the peer end's level value (for example, the local end is a level 1 access device and the peer end is a level 0 field device; or the local end is a level 3 application server and the peer end is a level 2 gateway device), or if the level values ​​are equal and the preset policy is met, the system dynamically determines that the local end plays the role of ACCESS (authentication responder) in the current session.

[0069] At this point, the system immediately invokes the concurrency safety mechanism: checking whether the local ACCESS processor (authentication responder processor) is currently enabled and ready.

[0070] If the check result indicates that the service is enabled, to handle high-concurrency industrial access and avoid network-wide Denial-of-Service (DoS) attacks caused by single-node blocking, the ACCESS processor first uses the peer device's device fingerprint (such as a globally unique EUI-64 address or MAC address) as the key to perform a hash index in the system's fast lookup table, precisely searching in local memory space or creating a new dedicated session (Session Context) for the peer device. Next, the system delivers and pushes the authentication message into the dedicated session's unique message queue (session message queue). At this point, the independent worker thread residing in the operating system background and bound to this dedicated session is awakened to perform asynchronous concurrent processing on the data in the message queue. This deeply decoupled multi-threaded asynchronous architecture ensures that when multiple low-level field devices simultaneously access the high-level intermediate node, their respective authentication states and buffers are isolated and do not interfere with each other, greatly improving the system's concurrent throughput.

[0071] If the check result is that it is not enabled (for example, the local device is a level 0 field device, the attacker maliciously sends a response request, and the field device has not initialized the ACCESS processor), the system immediately rejects the route, performs the operation of discarding the message and logging the error, cuts off the potential unauthorized attack link, and safely imports the error handling.

[0072] III. Three-level encryption capabilities prior to formal authentication, adaptive pre-negotiation, and resource pre-interception mechanism (corresponding to...) Figure 2 )

[0073] To address the technical pain point of wasted computing resources and communication bandwidth during high-performance authentication processes in heterogeneous industrial networks due to incompatible security algorithm standards supported by hardware nodes from different manufacturers and batches, this invention... Figure 1 After the role determination and processor routing proceed normally, and before the formal authentication process, which involves high overhead such as asymmetric encryption or large-scale digital certificate chain verification, is initiated, a forcibly introduced mechanism is introduced. Figure 2 The three-level encryption capability pre-negotiation mechanism shown:

[0074] The construction and active transmission of S1 request signaling: already in place. Figure 1 In the process, the terminal device (TERMINAL) determined to be the authentication initiator encapsulates and sends a high-density integrated security signaling message—"S1: Encryption Capability Negotiation Request"—to the access device (ACCESS) determined to be the authentication responder. To ensure sufficient security criteria, the payload of this request message explicitly carries and structurally aligns at least three core security descriptors: encryption mode identifier (encrypt_mode), representing the communication security level the initiator expects to achieve; cryptographic algorithm type identifier (alg_type), representing the set of cryptographic algorithms supported or enabled by the initiator's local hardware (such as commercial cryptography SM2 / SM3 / SM4 or international standards AES-128 / SHA-256); and local storage status level (store_info), representing whether the initiator has cached historical trust credentials for the current peer responder (such as session key fingerprints, historical security hierarchy relationships, etc.).

[0075] Multi-branch pre-matching and resource-protected traffic splitting: After the asynchronous worker thread of the access device (ACCESS) retrieves and receives the encryption capability negotiation request from the session message queue, it immediately checks the local encryption mode configuration and performs a deep comparison with the information carried in the request, triggering the following matching rules with strong defense features in sequence:

[0076] Unencrypted Direct Communication Bypass: If the access device retrieves its current security policy and finds that it is forcibly configured to "unencrypted mode" (fully open communication mode) due to a specific debugging phase or being located in a non-sensitive industrial production area with high latency sensitivity and low security requirements, then the access device determines that no substantive identity security verification is needed. It directly bypasses all key generation and algorithm comparisons and directly replies to the terminal device with the authentication skip result (BYPASS result). Upon receiving this result, both parties directly bypass all identity authentication steps and enter open communication (direct communication) state. This mechanism gives industrial systems excellent dynamic performance scalability.

[0077] Security Algorithm Mismatch Forced Interception Branch (TERMINATE): If the access device is configured to support encrypted mode (i.e., not unencrypted mode, requiring identity compliance checks), the system first extracts and reads the cryptographic algorithm type identifier (alg_type) of the terminal device (TERMINAL), and performs a hardware-level comparison with the currently enabled algorithm categories and versions in the local security chip or algorithm library. If a low-level conflict is found between the two parties' algorithm standards, or if the versions are completely incompatible (e.g., the terminal device only supports low-power symmetric stream encryption, while the access device mandates asymmetric signature verification based on the national cryptographic standard SM2), the access device determines that the two parties cannot establish a compliant secure link. At this point, the access device immediately triggers a process termination signal, replying to the other end with an authentication failure result, and the authentication process is prematurely terminated. Through this pre-interception, incompatible nodes are successfully blocked before the formal authentication high-power computation, effectively protecting the extremely valuable battery power and CPU time of industrial edge nodes.

[0078] The security algorithm matching success branch (CONTINUE) indicates that if the cryptographic algorithm type identifiers and version comparison results of both parties match perfectly, it means that both parties have a compatible foundation for secure communication. At this point, to further optimize the granularity of subsequent authentication, the access device further queries and extracts its own storage state level, and cross-compares this local level with the reverse `store_info` carried in the request message to determine the target verification level for this formal authentication. To ensure the rigor of the security strategy, the mathematical rule for determining the target verification level is: take the minimum value of the storage state levels of both parties (i.e., using the "barrel principle," if either party has not saved its historical state, a higher level of full verification must be performed).

[0079] Deterministic response and Nonce-based replay fingerprint construction: After determining the target authentication level, the processor of the access device performs final conditional routing processing on its value:

[0080] If the calculated target authentication level is equal to "no storage" (meaning that at least one party is joining the network for the first time, or the historical cache has expired), it means that the two parties cannot resume the session quickly, and the system will directly notify and import the full-process strong identity authentication process.

[0081] If the calculated target authentication level indicates that both parties have intact saved the historical session fingerprints, the system determines that lightweight fast authentication can be performed. At this time, in order to prevent wireless channel recording and replay attacks that may exist in the industrial field, the hardware random number generator (TRNG) of the access device generates a 32-byte high-entropy physical random number (Nonce) locally, which is used for subsequent salted challenge responses to the historical fingerprints.

[0082] The closed-loop transmission of the S2 negotiation response: The access device (ACCESS) packages all the security parameters generated by the above determination into a structured package and sends an "S2: Negotiation Response" message to the terminal device (TERMINAL). The payload of this response message achieves a closed loop of parameters: it includes the access end encryption mode identifier, a negotiation result identifier for clear status indication (covering three states: success, failure, and skip), the calculated target authentication level, and a dynamically generated 32-byte random number (Nonce) when the fast authentication conditions are met. The terminal device can clearly know the negotiation result through a single reception and parsing (if it is BYPASS, communication is directly opened; if it is failure, it terminates; if it is success, authentication continues), and adaptively select one of the following modes: no encryption mode, authentication-only mode (verifying identity but not encrypting subsequent data), or full encryption mode (authentication and full data encryption), to securely, efficiently, and deterministically advance the subsequent security assurance process.

[0083] IV. Dynamic Role Switching and Behavioral Coordination in Complex Heterogeneous Multi-Level Linkage Environments in Industrial Sites (Corresponding to) Figure 3 )

[0084] To further demonstrate the technological evolution and adaptive switching capabilities of this invention in real-world multi-level cascaded scenarios in industrial settings, combined with... Figure 3 The diagram illustrating a typical authentication role switching scenario uses a multi-level interconnected wireless topology network deployed vertically along the workshop floor, consisting of "Field Devices (FD, level 0) — Access Devices (AD, level 1) — Gateway Devices (GW, level 2) — Application Servers (AS, level 3)". Its dynamic adaptive role negotiation and behavioral coordination are reflected in the following interrelated operational scenarios:

[0085] Application Scenario 1: A field device (FD) at the bottom edge of the network initiates a network access request to an intermediate layer access device (AD).

[0086] After the field device (FD) powers on and performs hardware initialization, it only runs the terminal processor internally. When the FD asynchronously sends a message containing its 1-byte device type identifier to a nearby access device (AD), the AD's internal protocol stack is triggered. Figure 1 Process: AD detects that the hierarchical value corresponding to the peer device type identifier is 0, while AD's own hierarchical value is 1. According to the core hierarchical determination rule of this invention (devices with lower hierarchical values ​​automatically become authentication initiators, and devices with higher hierarchical values ​​automatically become authentication responders), since 1>0, AD's dynamic routing determination module instantly determines that this end should act as an authentication responder (ACCESS) in this local area connection. The ACCESS processor inside AD is then activated, calling an independent worker thread to find a dedicated session for FD and guiding FD into it. Figure 2The system employs a three-level encryption pre-negotiation (such as comparing alg_type, or, if the target authentication level allows, having AD generate a 32-byte random number Nonce for fast access verification). On this communication arc, role assignment is adaptively locked by hierarchical values, requiring no manual configuration.

[0087] Application Scenario 2: Data link aggregation and reporting from the intermediate layer access device (AD) to the higher-level network gateway device (GW).

[0088] When an access device (AD) in the workshop needs to transmit its aggregated field data across the network to the upper-level gateway device (GW) due to a full data buffer or a periodic policy scheduling command, the AD sends an authentication message containing its own AD type identifier to the gateway GW. Upon receiving this message, the gateway GW's underlying single-byte parsing module extracts the peer's level value as 1, while its own preset level value is 2. Through hardware-level numerical comparison, since 2 > 1, the gateway GW dynamically determines that it should act as the authentication responder (ACCESS) and allocates an independent session queue and worker thread to it. For the access device AD ​​that initiated the request, since it perceives that the gateway GW's level value (2) is higher than its own level value (1), based on the comparison result of 1 < 2, the AD automatically and necessarily acts as the authentication initiator (TERMINAL) when facing the gateway GW. The AD then activates its internal TERMINAL processor and executes the request to the upper layer. Figure 2 The encryption capabilities are pre-negotiated.

[0089] Application Scenario 3: Seamless dynamic switching between dual processors in parallel when the same middleware device faces different upper / lower-level counterparts.

[0090] The core technical value and application advantages of this invention are concentrated in the fact that, for the same access device AD ​​(layer value 1) or gateway device GW (layer value 2) in the middle layer, it does not need to rely on any manual offline role designation during operation, nor does it need to go through any restart, reset or reload configuration file process that would disrupt network continuity.

[0091] like Figure 3As shown in Scenario 3, since the AD has already completed the dual-parallel ready configuration of the TERMINAL processor and ACCESS processor in memory during the initialization phase, when a low-level field device FD (level 0) suddenly sends data to it, the AD can seamlessly take on the role of authentication responder through its internal ACCESS processor with a microsecond-level switching latency by comparing the level values ​​in real time (1>0), efficiently handling the asynchronous concurrent access of FD. At almost the same time, when the AD needs to perform an identity compliance handshake with the upper-level gateway device GW (level 2), it can perfectly call its internal parallel TERMINAL processor by comparing the level values ​​in real time (1<2), adaptively switching to the role of authentication initiator to cooperate with GW. This highly intelligent, fully data-flow-driven adaptive dual-role seamless switching mechanism completely breaks through the technical bottlenecks of rigid configuration and poor dynamic topology scalability in traditional industrial network security, greatly reducing the overall operation and maintenance and security deployment costs of large-scale modern industrial wireless networks.

[0092] In this document, the terms "upper," "lower," "front," "back," "left," "right," "top," "bottom," "inner," "outer," "vertical," and "horizontal," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only used for the clarity of expressing the technical solution and for the convenience of description, and therefore should not be construed as limiting the present invention.

[0093] In this document, the terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, which includes not only the elements listed but also other elements not expressly listed.

[0094] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A device-level adaptive role negotiation method for industrial wireless networks, characterized in that, Includes the following steps: Step S1. Device hierarchy definition: Predefine the correspondence between device type and hierarchy value of each device in the network. Among them, the lower the hierarchy value of the device, the closer it is to the field execution layer in the network topology, and the higher the hierarchy value of the device, the closer it is to the core application and management layer in the network topology. Step S2. Message Reception and Type Parsing: When the local device receives an authentication message sent by the peer device, it parses the device type identifier of the peer device from the message header of the authentication message; Step S3. Dynamic Role Determination and Routing: The local device obtains its own level value based on its device type, and compares the local level value with the peer level value corresponding to the peer device type identifier; based on the comparison result, it dynamically determines the authentication role that the local device should play, and routes the authentication message to the corresponding processor for processing.

2. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 1, characterized in that, In step S1, each device in the network performs processor initialization configuration according to its device type upon startup. The correspondence between device type and hierarchical value, and the processor initialization configuration, include at least the following four levels: The field device has a level value of 0 and only initializes the authentication initiator processor upon startup. The access device has a level value of 1 and initializes both the authentication initiator processor and the authentication responder processor upon startup. The gateway device, with a level value of 2, initializes both the authentication initiator processor and the authentication responder processor upon startup. The application server, with a tier value of 3, initializes only the authentication responder processor upon startup.

3. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 1, characterized in that, In step S2, the device type identifier is embedded in the message header of the authentication message.

4. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 1, characterized in that, In step S3, the rule for dynamically determining the authentication role is as follows: If the local device's hierarchical value is lower than the peer device's hierarchical value, then the local device is determined to be playing the role of the authentication initiator. If the local device's hierarchical value is higher than the peer device's hierarchical value, then the local device is determined to be playing the role of an authentication responder. If the local layer value is equal to the peer layer value, the authentication role played by the local device is determined according to a preset strategy.

5. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 1, characterized in that, In step S3, the process of routing the authentication message to the corresponding processor includes: If the local device is determined to be the authentication initiator, then check whether the authentication initiator processor is enabled; if it is enabled, route the authentication message to the authentication initiator processor for synchronization processing. If the local device is determined to act as the authentication responder, then check whether the authentication responder processor is enabled. If enabled, a dedicated session for the peer device is located or created locally, and the authentication message is delivered to the message queue of the dedicated session for asynchronous concurrent processing by an independent worker thread.

6. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 1, characterized in that, After the role determination in step S3 is completed, a pre-negotiation step for encryption capabilities is also included before the formal authentication begins: The authentication initiator sends an encryption capability negotiation request to the authentication responder. The encryption capability negotiation request includes at least: the desired encryption mode identifier, the supported cryptographic algorithm type identifier, and the local storage status level. After receiving the encryption capability negotiation request, the authentication responder checks the local encryption mode configuration and supported algorithm types, and matches them with the information in the encryption capability negotiation request. The authentication responder will reply to the authentication initiator with the negotiation result generated by the matching determination.

7. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 6, characterized in that, The encryption mode identifiers include: no encryption mode, authentication-only mode, and full encryption mode.

8. The adaptive role negotiation method for industrial wireless networks based on device hierarchy according to claim 7, characterized in that, The rules by which the authentication responder matches and determines the encryption capability negotiation request include: If the authentication responder is configured in unencrypted mode, it will directly reply to the authentication initiator with the authentication skip result, and the two parties will directly enter open communication. If the authentication responder supports encryption, the cryptographic algorithm type identifiers of both parties are compared; if the algorithm types do not match, an authentication failure result is returned and the authentication process is terminated. If the algorithm types match, the target verification level is determined by combining the local storage status levels of both parties, and the target verification level is carried in the negotiation response sent back to the authentication initiator.

9. A device-level adaptive role negotiation system for industrial wireless networks, used to implement the device-level adaptive role negotiation method for industrial wireless networks as described in any one of claims 1-8, characterized in that, include: Configuration module: Used to define the correspondence between device types and hierarchical values ​​for each device in the network; Parsing module: When the local device receives an authentication message sent by the peer device, it parses the device type identifier of the peer device from the message header of the authentication message; The routing determination module is used to obtain the local layer value based on the local device type, compare the local layer value with the peer layer value, dynamically determine the authentication role that the local device should play based on the comparison result, and thus route the authentication message to the corresponding processor.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the device-level-based adaptive role negotiation system for industrial wireless networks as described in claim 9.

Images