Non-IO device protocol adaptation and virtualization access method and system based on IO-Link gateway

Abstract

The invention relates to the technical field of industrial automation and communication, discloses a non-IO equipment protocol adaptation and virtualization access method and system based on an IO-Link gateway, and aims to solve the problem that non-IO equipment is difficult to access a standard IO-Link network. The method comprises the steps that a protocol adaptation engine analyzes non-IO equipment original data according to a protocol description template and converts the non-IO equipment original data into a standard intermediate data model; the virtualization service interface module dynamically constructs a virtual IO-Link equipment interface and a description file based on the model; and the equipment life cycle management module establishes a state model for the virtual equipment and monitors the virtual equipment. The system comprises a protocol adaptation engine, a virtualization service interface module, an equipment life cycle management module and a resource scheduling and communication optimization module. According to the technical scheme, universal analysis and conversion of various industrial protocols can be achieved, non-IO equipment can be accessed and monitored in a standard IO-Link mode, and communication real-time performance and system stability during concurrent access of multiple equipment are ensured.

Description

Technical Field

[0001] This invention relates to the fields of industrial automation and communication technology, specifically to a method and system for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway. Background Technology

[0002] With the deepening of industrial automation and intelligent manufacturing, the interconnection of field devices has become a core requirement for building efficient and flexible production systems. In industrial field networks, IO-Link, as a standardized point-to-point communication technology, has been widely used for the intelligent connection of sensors and actuators, possessing capabilities such as parameter configuration, status diagnosis, and bidirectional data interaction. However, a large number of existing non-IO devices (such as traditional analog sensors, RS485 instruments, Modbus devices, etc.) are difficult to directly connect to modern industrial network architectures based on IO-Link due to closed protocols, heterogeneous interfaces, or lack of intelligent communication capabilities. This results in severe information silos among devices, hindering the overall progress of digital upgrades in production lines.

[0003] Among these, protocol adaptation and device access technology based on IO-Link gateways has become a key path to achieve the integration of heterogeneous devices. This technology aims to parse, convert, and encapsulate the original communication protocols of non-IO devices through a gateway, enabling them to transparently access the upper-layer control system as virtual IO-Link devices. However, existing solutions still face multiple challenges: First, the protocol adaptation process heavily relies on customized development, lacking universality and scalability, making it difficult to cope with the complexities and frequent version iterations of protocols in industrial settings; second, most gateways only implement simple pass-through or one-way mapping, failing to virtualize complete service interfaces conforming to the IO-Link specification for non-IO devices, including core functions such as event reporting, parameter writing, and dynamic generation of device description files (IODDs); third, the lack of unified modeling and management of device status, communication quality, and lifecycle during virtualization access prevents the upper-layer system from implementing the same level of monitoring and maintenance as native IO-Link devices; finally, in scenarios with multiple devices accessing concurrently, existing gateways generally suffer from rigid resource scheduling and uncontrollable communication latency, making it difficult to meet the stringent real-time requirements of industrial control applications. The aforementioned defects result in non-IO devices being physically connected but logically disconnected, severely hindering the large-scale expansion and intelligent evolution of the IO-Link ecosystem. There is an urgent need for a systematic solution with high compatibility, strong virtualization capabilities, and support for dynamic protocol adaptation. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method and system for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway, which can effectively solve the problems mentioned in the background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway, characterized in that the system comprises the following components: The protocol adaptation engine module is used to parse the raw communication protocol of non-IO devices and convert the raw data into a standardized intermediate data model based on a predefined protocol description template. The protocol adaptation engine includes a protocol parsing submodule, a template library submodule, and a conversion execution submodule. The protocol parsing submodule calls the corresponding driver library to receive and decode the raw data frames based on the physical interface type and communication protocol of the non-IO device. The template library submodule stores structured description templates for different industrial protocol families. Each template defines the data frame structure, function code mapping relationship, data field parsing rules, and mapping relationship with intermediate data model for that protocol. The conversion execution submodule fills the parsed raw data values, status bits and device identifiers into the corresponding fields of the intermediate data model according to the selected protocol description template. The intermediate data model adopts a unified JSON-LD format and includes device ID, data type, data value, timestamp, quality code and metadata tag. The virtualization service interface module is used to dynamically construct and publish virtual device service interfaces that conform to the IO-Link specification based on the intermediate data model. The device lifecycle management module is used to establish a unified state model for each virtualized non-IO device, and monitor its communication quality, operating status, and lifecycle events in real time. This module maintains a device state matrix, which records the following state dimensions for each virtual device: connection status, communication quality score, data freshness, operating mode, and fault code. The communication quality score is calculated based on historical communication success rate, response latency jitter, and bit error rate, using the following formula: Q=α·Sr+β·(1-Jmax)+γ·(1-Eb); Where Sr is the communication success rate, Jmax is the maximum value of the root mean square error of the response delay, Eb is the bit error rate, and α, β, and γ are weighting coefficients and α+β+γ=1. The module also defines a set of standardized lifecycle events, including device online, device offline, parameter change, communication degradation and fault recovery, and ensures that these events can be reliably reported through the event service channel; The resource scheduling and communication optimization module is used to dynamically allocate the gateway's computing and communication resources and optimize the data exchange queue in scenarios with concurrent access from multiple devices, based on device priority, data update cycle, and real-time requirements. The resource scheduling and communication optimization module adopts a scheduling strategy that combines priority-based dynamic time-division multiple access with weighted fair queues. The module assigns a dynamic weight Wi to the data stream of each virtual device. Wi is determined by the device's basic priority Pi, the reciprocal of the data update cycle Ti, and the real-time requirement factor Ri, i.e., Wi = k1·Pi + k2·Ti + k3·Ri, where K is the weight coefficient. The module dynamically divides the communication time slices according to the weight ratio of all active devices and manages a multi-level data buffer queue.

[0006] Preferably, the protocol description template is defined using Extensible Markup Language and includes protocol family identifier, frame header and frame tail mode, verification algorithm, data field offset, data type conversion rules, and mapping path to intermediate data model fields. The protocol adaptation engine supports hot loading of new protocol description templates.

[0007] Preferably, the process of dynamically generating the device description file by the IODD dynamic generation submodule includes: extracting device manufacturer information, device type identifier, all accessible data indexes and parameter indexes from the intermediate data model; defining the data type, read / write attributes, value range and physical unit of each index according to the IO-Link specification; organizing the above information into a document structure that conforms to IODDXMLSchema, and publishing it to a specified network location via HTTP or FTP service.

[0008] Preferably, the monitoring process of the device lifecycle management module includes periodically sending diagnostic query commands to non-IO devices, updating the communication quality score and data freshness in the device status matrix according to the response results, and generating a fault event containing a fault code, timestamp and associated device ID when a communication timeout, verification error or data value exceeds a reasonable range is detected, and immediately reporting it through the event service channel.

[0009] Preferably, the resource scheduling and communication optimization module implements a feedback control loop. This module collects the actual transmission delay of each virtual device's data stream in real time: Dactual and its target delay Dtarget, calculates the delay deviation e=Dactual-Dtarget, and dynamically adjusts the weight coefficient k2 or k3 of the device's data stream in the scheduling queue according to the sign and magnitude of the deviation e, thereby adaptively changing its resource allocation ratio.

[0010] Preferably, for control data with high real-time requirements, the resource scheduling and communication optimization module adopts preemptive scheduling and places it in a high-priority queue; for periodic monitoring data, it adopts polling scheduling and places it in a normal queue; for non-real-time parameter configuration data, it adopts batch transmission during idle periods.

[0011] Another technical problem to be solved by the present invention is to provide a method for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway, comprising the following steps: S110, the protocol adaptation engine receives raw communication data from non-IO devices, parses and decodes it according to the pre-configured protocol description template, and converts the raw data into a standardized intermediate data model. S120, the virtualization service interface module instantiates a virtual IO-Link device object based on the intermediate data model, dynamically generates the corresponding device description file, and establishes process data, parameter service and event service channels; S130, the device lifecycle management module creates and maintains a unified state model for the virtual device, continuously monitors its communication connection, data quality and operating status, and triggers corresponding lifecycle events; S140, the resource scheduling and communication optimization module dynamically schedules the gateway's processor resources and network bandwidth based on the attributes and requirements of all connected non-IO devices, and optimizes the data packet sending queue and timing.

[0012] Preferably, in step S110, the protocol description template is defined using Extensible Markup Language and includes protocol family identifier, frame header and frame tail mode, verification algorithm, data field offset, data type conversion rules, and mapping path to intermediate data model fields. The protocol adaptation engine supports hot loading of new protocol description templates.

[0013] Preferably, in step S120, the process of dynamically generating the device description file includes: extracting device manufacturer information, device type identifier, all accessible data indexes and parameter indexes from the intermediate data model; defining the data type, read / write attributes, value range and physical unit of each index according to the IO-Link specification; organizing the above information into a document structure conforming to IODDXMLSchema, and publishing it to a specified network location via HTTP or FTP service for access and parsing by the IO-Link main site.

[0014] Preferably, in step S140, the dynamic scheduling process implements a feedback control loop, and the resource scheduling and communication optimization module collects the actual transmission delay of the data stream of each virtual device in real time.

[0015] Compared with existing technologies, the present invention provides a method and system for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway, which has the following advantages: 1. This method and system for non-IO device protocol adaptation and virtualization access based on IO-Link gateway, by introducing a protocol adaptation engine based on structured templates, realizes the generalized parsing and conversion of various types and versions of industrial communication protocols, significantly improving protocol compatibility and system scalability, and reducing the customized development cost for specific devices.

[0016] 2. This method and system for non-IO device protocol adaptation and virtualization access based on IO-Link gateway can dynamically build complete IO-Link service interfaces (including process data, parameter services and event services) and device description files for non-IO devices through the virtualization service interface module. This enables the upper-layer control system to access, configure and diagnose in a way that is completely consistent with native IO-Link devices, thus completely eliminating the access barrier at the logical level. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall technical solution architecture of the non-IO device protocol adaptation and virtualization access system based on IO-Link gateway proposed in this invention; Figure 2 This is a schematic diagram of the core principle framework of the protocol adaptation engine and virtualization service interface module in this invention; Figure 3 This is a logical flow diagram of the device lifecycle management module in this invention; Figure 4 This is a schematic diagram of the multi-level interaction relationship and data flow of the resource scheduling and communication optimization module in this invention; logical access barriers. Detailed Implementation

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

[0019] Example 1 In a highly automated automotive parts assembly line, there are numerous industrial devices from different manufacturers using different communication protocols. These include vision inspection cameras using Modbus TCP, six-axis robots using PROFINET, tightening guns using EtherNet / IP, and vibration sensors using custom serial protocols. These devices are not IO-Link devices and cannot be directly connected to a central control system that uses IO-Link as the mainstream fieldbus standard. To achieve unified access, standardized data acquisition, and refined management of these heterogeneous devices, this embodiment deploys a non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway.

[0020] See Figure 1 This system is physically deployed in an industrial edge computing gateway. Its core functional modules include a protocol adaptation engine, a virtualization service interface module, a device lifecycle management module, and a resource scheduling and communication optimization module. These modules work together to virtualize the aforementioned non-IO devices into standard IO-Link devices for access and control by the upper-layer IO-Link master station.

[0021] The protocol adaptation engine is the first layer for interaction between the system and physical non-IO devices. This engine continuously monitors data streams from the communication interfaces of various physical devices. When a raw ModbusTCP data frame is received from a vision inspection camera, the engine first identifies the sender as "Vision Camera_Station A" based on the pre-configured device registry and associates it with the corresponding "ModbusTCP_V1.0" protocol description template. This template is defined in Extensible Markup Language and stored in the template library submodule within the engine. The template precisely describes the data frame structure of the ModbusTCP protocol, including the transaction identifier, protocol identifier, length field, unit identifier, function code, and the starting offset and length of the data field. For example, the template defines function code 03 as corresponding to reading the holding register and specifies that the "pass / fail" status bit of the camera inspection result is located in the second byte of the data field, while the "defect code" is located in the third and fourth bytes.

[0022] Based on this template, the protocol parsing submodule calls the corresponding ModbusTCP driver library to decode the original data frame, extracting the Boolean value of the "status bit" (1 for qualified, 0 for unqualified) and the 16-bit unsigned integer value of the "defect code". The conversion execution submodule then fills these original data values, along with the device identifier, current system timestamp, and quality code generated based on the data verification result, into a standardized intermediate data model field. This intermediate data model uses a unified JSON-LD format, and an example fragment is shown below: it contains a "Device ID" field with the value "Vision_Cam_A", a "Data Type" field indicating "Mixed Type", a "Data Value" field that is a nested object containing two sub-items: "Detection Result" and "Defect Code", a "Timestamp" field with UTC time accurate to milliseconds, a "Quality Code" field marked as "Good" based on the CRC check result, and a "Metadata Tag" field recording the protocol type as "ModbusTCP". For robots using the PROFINET protocol, the protocol adaptation engine calls different drives and templates to parse the joint angles, torques, and status words in their cyclic data and maps them to the corresponding fields in the intermediate data model. The protocol adaptation engine supports a hot-loading mechanism. When a laser rangefinder using a new protocol (such as CC-LinkIEFieldBasic) is introduced to the production line, maintenance personnel only need to upload the pre-written new protocol description template file to the gateway's designated directory, and the engine can load and apply the template without restarting the service, immediately expanding its support capabilities for the new device.

[0023] The core task of the virtualization service interface module is to construct a logically equivalent IO-Link device for each physical non-IO device based on the standardized intermediate data model output by the protocol adaptation engine. See also... Figure 2When the intermediate data model is first delivered from the protocol adaptation engine, the virtual device instantiation submodule is triggered. This submodule reads information such as the "Device ID" and "Data Type" from the model and dynamically creates a virtual IO-Link device object in the gateway's internal memory space. This object is assigned a unique logical address within the local IO-Link network; for example, logical address 5 corresponds to the vision camera, and logical address 6 corresponds to the six-axis robot. Next, the IODD dynamic generation submodule begins its work. It deeply parses the intermediate data model, extracting all necessary information: deriving the manufacturer and model description of the virtual device from the "Device ID" and "Metadata Tags"; and defining the data indices accessible to the virtual device based on the structure of the "Data Value" object. For example, for the vision camera, index 1 corresponds to "Detection Result" (data type: Boolean, read-only), and index 2 corresponds to "Defect Code" (data type: 16-bit unsigned integer, read-only). For the robot, indices 10-15 might correspond to the angles of the six joints (data type: 32-bit floating-point, read-write). The submodule strictly adheres to the IO-Link device description file specification, organizing device identifiers, communication parameters, all data indices, and parameter index definitions (including index number, name, data type, read / write attributes, value range, physical unit, and text description) into a rigorously structured XML document. This dynamically generated IODD file is then published via a miniature HTTP server built into the gateway. When the IO-Link master station of the upper-level control system performs a device scan, it discovers the "new devices" at these logical addresses and retrieves the corresponding IODD file via the HTTP protocol for parsing, thus presenting a configuration interface in the engineering software that is completely consistent with the native IO-Link devices. Simultaneously, the service channel management submodule establishes and maintains three core service channels for each virtual device object. The process data channel proactively encapsulates the latest "data values" in the intermediate data model into IO-Link process data frames and sends them to the IO-Link master station at fixed intervals (e.g., 100 milliseconds for vision cameras and 10 milliseconds for vibration sensors). The parameter service channel listens for parameter read / write requests from the master station; for example, if the master station requests to write the target angle of robot index 11 (joint 2), this request is translated into a PROFINET write command to the physical robot controller. The event service channel is in standby mode, ready to asynchronously report changes in device status.

[0024] The device lifecycle management module establishes a comprehensive status monitoring view for each virtual device. See also... Figure 3This module maintains a device status matrix, with each row corresponding to a virtual device. For the visual camera virtual device, the module continuously tracks multiple status dimensions. "Connectivity status" is confirmed by periodically (e.g., once per second) sending ModbusTCP diagnostic requests to the physical camera (e.g., function code 01 to read coil status). A valid response is received, marking it as "online," and three consecutive timeouts mark it as "offline." "Communication quality score" is a quantitative health indicator, calculated based on three sub-items: communication success rate (based on the number of successful diagnostic queries in the last 100 queries); response latency jitter (obtained by calculating the root mean square error of the last 50 response times); and bit error rate (obtained by analyzing the number of checksum errors in received data frames). These three sub-items are multiplied by weighting coefficients α, β, and γ (in this embodiment, α=0.5, β=0.3, γ=0.2) and summed to obtain a score between 0 and 1. A score below 0.6 triggers a "communication degradation" event. "Data Freshness" records the difference between the last successful update time of the device's process data and the current time. Data exceeding a preset period (e.g., twice the update period) is considered outdated. When the module detects that the communication quality score of the vision camera drops from 0.8 to 0.55 due to network interference, it immediately generates a standardized lifecycle event. This event includes the event type "Communication Degradation," the event source device ID "Vision_Cam_A," the timestamp of the event, and the specific quality score value. This event is immediately pushed to the virtual device's event service channel, which packages it into an IO-Link event message and reports it to the master station, allowing the operator in the control room to see a "Workstation A Camera Communication Quality Alarm" message on the monitoring screen in real time.

[0025] The resource scheduling and communication optimization module is responsible for ensuring system performance in concurrent scenarios. See also... Figure 4When four virtual devices—a vision camera, a robot, a tightening gun, and a vibration sensor—are active simultaneously, this module faces the challenge of allocating limited gateway CPU time and network bandwidth resources. The module calculates a dynamic weight for the data stream of each device. Taking the tightening gun as an example, its basic priority is set to "high" because the tightening result directly affects product quality; its data update cycle is 50 milliseconds; and its real-time requirement factor is also set to "high" because the tightening process requires real-time torque monitoring. According to the formula, its dynamic weight will have a relatively large value. For the vibration sensor, which is only used for periodic monitoring, its priority and real-time requirement are both "medium," with an update cycle of 10 milliseconds. The reciprocal of the update cycle contributes significantly to its weight calculation. The module dynamically divides communication time slices according to the proportion of weights for all devices. Within a scheduling cycle, the tightening gun's process data and event data, due to their high weight and high real-time requirements, are placed in the highest-priority preemptive queue to ensure that their data packets are sent first. The robot's periodic joint data uses polling scheduling and is placed in a normal queue. The vision camera's IODD file download requests (non-real-time data) are scheduled for batch transmission during communication idle periods.

[0026] Furthermore, the module implements closed-loop feedback control. It continuously monitors the actual transmission delay of the tightening gun process data from generation to confirmation by the master station. Assuming the target delay is 20 milliseconds, while the actual measured average delay is 25 milliseconds, a positive deviation occurs. Based on this deviation, the module dynamically fine-tunes the coefficients related to the real-time requirement factor in the tightening gun data stream weight formula, thereby allocating slightly more resources to it in the next scheduling cycle, gradually converging its actual delay towards the target value of 20 milliseconds, ensuring the performance stability of the critical control loop.

[0027] Based on the above system, the access method corresponding to this embodiment is executed according to the following steps: In step S110, the protocol adaptation engine receives raw communication data from non-IO devices, parses and decodes it according to a pre-configured protocol description template, and converts the raw data into a standardized intermediate data model. Specifically, for a six-axis robot, the network interface of the protocol adaptation engine continuously receives real-time cyclic frames from PROFINET. The protocol parsing submodule identifies the IO data area in the frame according to the "PROFINET_Robot_Station" template. The template defines the mapping between each data word and the robot state: bytes 1-2 are the status words, where bit 0 represents "enabled state" and bit 3 represents "fault state"; bytes 3-10 are four 32-bit floating-point joint position feedback values. The conversion execution submodule extracts the status bits and floating-point values ​​and performs the necessary byte order conversion. Subsequently, it creates a new intermediate data model instance, sets the device ID to "Robot_Station1", fills the data value field with a structured object containing arrays of "enabled", "fault", and "joint position", sets the timestamp to the current time, and provides the quality code after verification based on the continuity of the PROFINET frame cycle counter. At this point, the robot's real-time operational data is transformed into a standardized format for unified processing within the system.

[0028] In step S120, the virtualization service interface module instantiates a virtual IO-Link device object based on the intermediate data model, dynamically generates the corresponding device description file, and establishes process data, parameter service, and event service channels. When the robot's intermediate data model is generated for the first time, the virtual device instantiation submodule immediately takes action. It creates a virtual device object in memory, allocates logical address 7, and permanently binds this address to the physical device "Robot_Station1". The IODD dynamic generation submodule analyzes the model and finds that the data values ​​contain readable and writable status bits and joint positions. Therefore, the generated IODD file defines: index 1 as "Enabled State" (Boolean, read / write), index 2 as "Fault State" (Boolean, read-only), and indices 10-13 as "Joint 1-4 Position Feedback" (floating-point, read-only). It also defines a set of writable "Joint 1-4 Target Position" parameter indices (indices 20-23). ​​This XML file is generated in real-time and stored in the gateway's " / iodd / " virtual directory. The service channel management submodule then activates the three channels corresponding to logical address 7. The process data channel is configured with a 50-millisecond cycle, sending the latest "enable," "fault," and four joint position feedback values ​​in a package each time. The parameter service channel begins listening for write operations to index 1 (enable) and indices 20-23 (target positions).

[0029] In step S130, the device lifecycle management module creates and maintains a unified state model for the virtual device, continuously monitors its communication connection, data quality, and operating status, and triggers corresponding lifecycle events. The module initializes one row in the state matrix for the robot virtual device. It starts a background monitoring task, sending a PROFINET diagnostic read request to the physical robot every 500 milliseconds via the protocol adaptation engine to read its device name or status summary. Based on the response time and success rate of this request, it updates the "communication quality score." Simultaneously, it checks the update status of the process data channel, ensuring that the "data freshness" is always within 100 milliseconds (twice the cycle time). At a certain moment, the physical robot controller triggers an internal fault due to overload, and the fault bit of its status word is set. This change, through steps S110 and S120, is ultimately reflected in the process data of the virtual device. The device lifecycle management module detects the state transition from "false" to "true" by comparing the "fault status" bit in the process data before and after. It immediately generates a "device failure" lifecycle event, which includes a failure code (parsed from the status word), the device ID, and a precise timestamp, and immediately reports it to the IO-Link master station through the event service channel.

[0030] In step S140, the resource scheduling and communication optimization module dynamically schedules the gateway's processor resources and network bandwidth based on the attributes and requirements of all connected non-IO devices, optimizing the data packet sending queue and timing to ensure the real-time performance of critical data and the overall system throughput. During full-speed production line operation, all device virtualization tasks run concurrently. The resource scheduling module allocates tasks to each communication cycle (e.g., a basic time unit of 1 millisecond) based on the weight of each device. Within a cycle, it prioritizes the data sending task of the tightening gun (high priority), then processes the process data packaging task of the robot (medium-high priority). Simultaneously, it monitors the network stack's sending buffer. If it detects an accumulation of image result data packets (large data volume) from the vision camera, and the tightening gun's next sending time is imminent, the module temporarily pauses the framing operation of the vision camera data packets, allocating CPU time slices to the tightening gun's real-time data sending process, ensuring that the tightening gun's latency target is met. This weighted and real-time feedback-based dynamic scheduling enables the system to maintain deterministic performance of critical data flows even under resource-constrained conditions.

[0031] Example 2 The intelligent warehousing and logistics system deploys various automated devices, such as shuttles using the CANopen protocol, AGV scheduling servers using the MQTT protocol, stacker crane height sensors using the RS-485 Modbus RTU protocol, and package sorting status indicator lights using the TCPSocket custom text protocol. This embodiment uses the same IO-Link gateway-based system to achieve unified access and monitoring of these heterogeneous devices.

[0032] The protocol adaptation engine needs to handle more complex protocol hybrids. For shuttles using the CANopen protocol, the engine uses the corresponding template to parse the COB-ID, mapping the received PDO (Process Data Object) to fields such as "vehicle speed," "cargo status," and "battery level" in the intermediate data model. For AGV scheduling servers using the MQTT protocol, the engine subscribes to its published topics, parses the JSON-formatted "AGV real-time location" and "task queue length" messages, and fills them into the intermediate data model. Stacker crane sensors are connected via serial ports, and the engine reads their registers using a ModbusRTU template to obtain "current height" and "limit switch status." For indicator lights using custom protocols, the template defines the format of text commands, such as "LED_ID,ON,RED," which the engine parses to generate intermediate data such as "device ID," "switch status," and "color."

[0033] The virtualization service interface module creates a virtual IO-Link device for each type of device. The shuttle is virtualized as a device with multiple data indices, such as index 1 for "vehicle speed" (integer, read-only) and index 2 for "cargo status" (enumeration, read-only). The AGV scheduling server is virtualized as a special device with index 1 for "total number of tasks" (integer, read-only) and index 2 for "average waiting time" (floating-point, read-only), and provides a writable parameter index for issuing "emergency stop" commands. The stacker crane sensor is virtualized as a simple analog input device. The virtual device for indicator lights provides a readable and writable Boolean index to control their on / off state, and a readable and writable enumeration index to select their color.

[0034] The equipment lifecycle management module faces various monitoring challenges. For AGV servers connected via MQTT, their "connection status" is determined through MQTT's heartbeat mechanism and "last will" feature, while the communication quality score combines message delivery rate and server response latency. For CANopen shuttles, in addition to monitoring communication, the module confirms the device's liveness by parsing its heartbeat messages or node daemon protocols. Monitoring the data freshness of stacker crane sensors is crucial; if no new data is received within a preset time, a "sensor failure" event is immediately triggered.

[0035] In this scenario, the resource scheduling and communication optimization module needs to balance data flows of different natures. The shuttle's control commands and status feedback (high real-time performance, high priority) are assigned the highest scheduling weight to ensure timely motion control. The AGV server's status data (medium real-time performance, medium priority) is scheduled using a round-robin approach. Stacker crane sensor data updates are slower but are crucial for safety, and are given a high basic priority. Indicator light control commands are low-priority, non-real-time data, and are sent in batches only when the network is idle. The module continuously monitors the actual closed-loop delay of the shuttle commands and dynamically adjusts its scheduling parameters to ensure that the shuttle's response performance always meets control requirements despite fluctuations in warehouse network traffic.

[0036] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway, characterized in that, The system includes the following components: The protocol adaptation engine module is used to parse the raw communication protocol of non-IO devices and convert the raw data into a standardized intermediate data model based on a predefined protocol description template. The protocol adaptation engine includes a protocol parsing submodule, a template library submodule, and a conversion execution submodule. The protocol parsing submodule calls the corresponding driver library to receive and decode the raw data frames based on the physical interface type and communication protocol of the non-IO device. The template library submodule stores structured description templates for different industrial protocol families. Each template defines the data frame structure, function code mapping relationship, data field parsing rules, and mapping relationship with intermediate data model for that protocol. The conversion execution submodule fills the parsed raw data values, status bits and device identifiers into the corresponding fields of the intermediate data model according to the selected protocol description template. The intermediate data model adopts a unified JSON-LD format and includes device ID, data type, data value, timestamp, quality code and metadata tag. The virtualization service interface module is used to dynamically construct and publish virtual device service interfaces that conform to the IO-Link specification based on the intermediate data model. The device lifecycle management module is used to establish a unified state model for each virtualized non-IO device, and monitor its communication quality, operating status, and lifecycle events in real time. This module maintains a device state matrix, which records the following state dimensions for each virtual device: connection status, communication quality score, data freshness, operating mode, and fault code. The communication quality score Q is calculated based on historical communication success rate, response latency jitter, and bit error rate, using the following formula: Q=α·Sr+β·(1-Jmax)+γ·(1-Eb); Where Sr is the communication success rate, Jmax is the maximum root mean square error of the response delay, Eb is the bit error rate, and α, β, and γ are weighting coefficients with α+β+γ=1. The device lifecycle management module also defines a set of standardized lifecycle events, including device online, device offline, parameter change, communication degradation and fault recovery, and ensures that these events can be reliably reported through the event service channel; The resource scheduling and communication optimization module is used to dynamically allocate the gateway's computing and communication resources and optimize the data exchange queue in scenarios with concurrent access from multiple devices, based on device priority, data update cycle, and real-time requirements. This module employs a scheduling strategy combining priority-based dynamic time-division multiple access (TDMA) and weighted fair queues. The module assigns a dynamic weight Wi to the data stream of each virtual device. Wi is determined by the device's base priority Pi, the reciprocal of the data update cycle Ti, and the real-time requirement factor Ri. Wi = k1·Pi + k2·Ti + k3·Ri, where K is the weighting coefficient. The resource scheduling and communication optimization module dynamically divides communication time slices according to the weight ratio of all active devices and manages a multi-level data buffer queue.

2. The non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway according to claim 1, characterized in that, The protocol description template is defined using Extensible Markup Language and includes protocol family identifier, frame header and frame tail mode, verification algorithm, data field offset, data type conversion rules, and mapping path to intermediate data model fields. The protocol adaptation engine supports hot loading of new protocol description templates.

3. The non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway according to claim 1, characterized in that, The process of dynamically generating device description files by the IODD dynamic generation submodule includes: extracting device manufacturer information, device type identifier, all accessible data indexes and parameter indexes from the intermediate data model; defining the data type, read / write attributes, value range and physical unit of each index according to the IO-Link specification; organizing the above information into a document structure that conforms to IODDXMLSchema; and publishing it to a specified network location via HTTP or FTP service.

4. The non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway according to claim 1, characterized in that, The monitoring process of the device lifecycle management module includes periodically sending diagnostic query commands to non-IO devices, updating the communication quality score and data freshness in the device status matrix according to the response results, and generating a fault event containing a fault code, timestamp and associated device ID when a communication timeout, verification error or data value exceeds a reasonable range is detected, and immediately reporting it through the event service channel.

5. The non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway according to claim 1, characterized in that, The resource scheduling and communication optimization module implements a feedback control loop. This module collects the actual transmission delay of each virtual device's data stream in real time: Dactual and its target delay Dtarget, calculates the delay deviation e=Dactual-Dtarget, and dynamically adjusts the weight coefficient k2 or k3 of the device's data stream in the scheduling queue according to the sign and magnitude of the deviation e, thereby adaptively changing its resource allocation ratio.

6. The non-IO device protocol adaptation and virtualization access system based on an IO-Link gateway according to claim 1, characterized in that, For control data with high real-time requirements, the resource scheduling and communication optimization module adopts preemptive scheduling and places it in a high-priority queue; for periodic monitoring data, it adopts polling scheduling and places it in a normal queue; for non-real-time parameter configuration data, it adopts batch transmission during idle periods.

7. A method for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway, characterized in that, Includes the following steps: S110, the protocol adaptation engine receives raw communication data from non-IO devices, parses and decodes it according to the pre-configured protocol description template, and converts the raw data into a standardized intermediate data model. S120, the virtualization service interface module instantiates a virtual IO-Link device object based on the intermediate data model, dynamically generates the corresponding device description file, and establishes process data, parameter service and event service channels; S130, the device lifecycle management module creates and maintains a unified state model for the virtual device, continuously monitors its communication connection, data quality and operating status, and triggers corresponding lifecycle events; S140, the resource scheduling and communication optimization module dynamically schedules the gateway's processor resources and network bandwidth based on the attributes and requirements of all connected non-IO devices, and optimizes the data packet sending queue and timing.

8. The method for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway according to claim 7, characterized in that, In step S110, the protocol description template is defined using Extensible Markup Language and includes protocol family identifier, frame header and frame tail mode, verification algorithm, data field offset, data type conversion rules, and mapping path to intermediate data model fields. The protocol adaptation engine supports hot loading of new protocol description templates.

9. The method for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway according to claim 7, characterized in that, In step S120, the process of dynamically generating the device description file includes: extracting device manufacturer information, device type identifier, all accessible data indexes and parameter indexes from the intermediate data model; defining the data type, read / write attributes, value range and physical unit of each index according to the IO-Link specification; organizing the above information into a document structure that conforms to IODDXMLSchema, and publishing it to a specified network location via HTTP or FTP service for access and parsing by the IO-Link main site.

10. The method for non-IO device protocol adaptation and virtualization access based on an IO-Link gateway according to claim 7, characterized in that, In step S140, the dynamic scheduling process implements a feedback control loop, and the resource scheduling and communication optimization module collects the actual transmission delay of the data stream of each virtual device in real time.

Images