Intelligent remote device cooperative control system

Abstract

This invention relates to the field of industrial automation control technology, specifically to an intelligent remote device collaborative control system. The system includes protocol abstraction and adaptation, unified runtime snapshot aggregation, and unified access, status expression, and control management of remote devices with different industrial protocols. Through independent execution tracks, track-based zero-code programming, independent device queues, and device scheduling, it achieves visualized generation of control flows, independent operation, and isolated scheduling by device. This invention improves system compatibility and scalability by achieving unified access, status expression, and capability identification of heterogeneous remote devices through unified runtime snapshots; reduces the difficulty of control flow configuration and avoids interface anomalies affecting execution through track-based zero-code programming and independent execution tracks; and enhances the real-time performance, stability, security, and reliability of remote device collaborative control through independent device queues, read / write separation scheduling, reconnection cooling, request cleanup, and runtime status verification.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, and in particular to an intelligent remote equipment collaborative control system. Background Technology

[0002] With the development of industrial automation, the Industrial Internet of Things (IIoT), and cyber-physical systems (CIPS), the number of remote devices in production sites is constantly increasing, and the types of devices are gradually expanding from traditional input / output modules to a variety of objects such as servo drives, motion control devices, register access devices, fieldbus devices, and industrial Ethernet devices. Different devices typically use different communication protocols, status expression methods, and control interfaces. The upper-level control system needs to complete tasks such as device access, status acquisition, remote monitoring, command issuance, process linkage, anomaly response, and human-machine interaction within the same operating environment.

[0003] Meanwhile, smart manufacturing scenarios place higher demands on remote equipment collaborative control. Control systems not only need to identify and manage multi-protocol devices, but also need to organize equipment status, communication information, execution progress, and control processes in a unified manner, enabling operators to orchestrate and manage complex processes through a visual interface. Against this backdrop, control block-based process configuration, graphical interface-independent execution mechanisms, device-oriented request management, remote connection maintenance, operational status feedback, and audio prompts are gradually becoming important components of intelligent remote control systems.

[0004] By incorporating heterogeneous industrial equipment into a unified control framework, and combining it with track-based process execution and adaptive communication scheduling, a more integrated, visualized, and collaborative control foundation can be provided for industrial sites with multiple devices, multiple protocols, and multiple tasks operating in parallel. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and propose an intelligent remote device collaborative control system.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: an intelligent remote equipment collaborative control system, the system comprising: an industrial control host: the industrial control host includes a processor, a memory, a display interaction unit and an industrial communication interface; Multiple remote devices: The multiple remote devices include at least a first type of device using a first industrial protocol and a second type of device using a second industrial protocol; The first protocol device management unit is used to manage the first type of device, and the second protocol device management unit is used to manage the second type of device. Protocol abstraction and adaptation module: used to convert device read and write requests under different industrial protocols into unified control objects, and to convert device feedback status under different industrial protocols into runtime snapshot objects in a unified format; Unified runtime snapshot aggregation module: used to receive device status data output by the first protocol device management unit and the second protocol device management unit, and map device status data under different protocols to unified runtime snapshot objects; Independent execution track module: used to generate control requests for the target device according to the control track and control block sequence configured by the user, and run in an execution channel independent of the graphical interface; Track-based zero-code programming module: Provides a control block toolbox, drag-and-drop track editing, and parametric property configuration, allowing users to generate control tracks without writing scripts; Device Independent Queue Module: Used to establish an independent request queue for each target device and route control requests to the corresponding device's independent request queue based on the device identifier; Device scheduling module: Used for limited concurrent scheduling of read requests and serial scheduling of write requests within a single device. Persistent connection and recovery module: Used to maintain the device connection status and perform reconnection cooling and pending request cleanup when a connection-level failure is detected; Runtime verification module: Used to continue to obtain the target device's feedback status after the control request is issued, and to determine whether the target device has actually completed the corresponding action based on the unified runtime snapshot object; Track audio processing module: used to enable the control track to trigger the playback of audio files during execution, and to allocate independent audio channels to different tracks.

[0007] As a further aspect of the present invention, the unified runtime snapshot object includes at least several of the following: device identifier, protocol type, device status or status text, latency information, queue depth, error information, device capability identifier, and protocol extension information. The device capability identifier is used to characterize whether the target device has register monitoring, general read / write, servo motion control, status monitoring or device testing capabilities. The unified runtime snapshot aggregation module standardizes and maps the device status data generated by the first protocol device management unit and the second protocol device management unit to form a unified runtime device list that can be reused by the device management interface, device monitoring interface and control attribute interface.

[0008] As a further embodiment of the present invention, the independent execution track module maintains an independent execution state, execution lock, and stop event for each control track. The independent execution track module runs the control track through a background thread, thread pool, or event loop coroutine. The independent execution track module sends start events, stop events, error events, and progress events back to the display interaction unit through an independent event queue. When the interactive display unit experiences interface lag, partial interface refresh, or destruction of interface controls, the independent execution track module still maintains the continuity of track execution.

[0009] As a further aspect of the present invention, the track-based zero-code programming module includes: Control Block Toolbox: Provides a variety of predefined control blocks; Drag-and-drop track editor: Used to drag and drop predefined control blocks into a target track, and supports rearranging predefined control blocks within the track; Control Block Factory: Used to automatically create control block instances based on the control block type; Property panel parameter configuration mechanism: used to edit, write back, and save control block parameters; Users can generate a control flow that can be interpreted and executed by an independent execution track module by dragging and dropping control blocks onto the control track and configuring device identifiers, register addresses, target values, delay times, or action parameters in the property panel.

[0010] As a further aspect of the present invention, the device independent queue module establishes independent request queues according to the device dimension. Each device independent queue maintains at least one or more of the following: request priority, request waiting timeout, queue capacity, queue backlog alarm threshold, number of successful processing, number of failed processing, and queue full load statistics. When any target device experiences a communication abnormality, the communication abnormality only affects the independent request queue corresponding to that target device, and does not affect the request processing of other target devices.

[0011] As a further aspect of the present invention, the device scheduling module performs read-write separation scheduling within a single device, allowing limited concurrent execution of read requests and serial execution of write requests; The device scheduling module avoids conflicts between multiple write requests within the same device and improves read throughput while ensuring write consistency.

[0012] As a further aspect of the present invention, when at least one of the following events occurs—timeout, connection disconnection, connection reset, decoding failure, or no response—the persistent connection and recovery module identifies the corresponding anomaly as a connection-level fault, and performs the following operations after identifying the connection-level fault: marks the current connection as unavailable, records the number of consecutive faults, calculates the reconnection cooling time window, suppresses invalid repeated reconnections within the reconnection cooling time window, clears pending requests for the corresponding device, and periodically attempts to restore the connection in the background.

[0013] As a further embodiment of the present invention, the running state verification module performs motion completion judgment on servo devices or motion devices based on at least one or more of the following: alarm code, software enable state, running state bit, real-time speed, current position and position error. In position mode, when the position change of the target device is lower than the preset threshold and the remaining displacement is still greater than the preset tolerance within multiple consecutive sampling periods, the running state verification module determines that the target device has experienced motion interruption, failure to reach its position, or jamming.

[0014] As a further aspect of the present invention, the first type of device includes a device based on a register access protocol; The system also includes an adaptive batch write mechanism for register access protocol devices. The adaptive batch write mechanism maintains a device-level batch write capability memory mode. The device-level batch write capability memory mode includes at least a whole packet batch write mode, a block batch write mode, and an item-by-item write mode. Initially, the whole-packet batch write mode is preferred. When the whole-packet batch write fails, it switches to the block batch write mode. When the block batch write fails, it switches to the item-by-item write mode. The switching result is recorded as the priority execution mode for subsequent batch writes of the same type on the device.

[0015] A method for collaborative control of intelligent remote devices, wherein the method is executed based on the aforementioned intelligent remote device collaborative control system, includes the following steps: The device configuration and control track configuration of multiple remote devices using different industrial protocols are obtained. The first protocol device management unit and the second protocol device management unit respectively obtain the device status data of devices using different protocols. The protocol abstraction and adaptation module converts device read / write requests under different industrial protocols into a unified control object, and converts device feedback status under different industrial protocols into a unified runtime snapshot object. The unified runtime snapshot aggregation module maps device status data under different protocols to unified runtime snapshot objects, and forms unified runtime device information for device management, device monitoring and control attribute configuration. The track-based zero-code programming module generates control tracks by dragging and dropping control blocks and configuring parameters. The independent execution track module generates control requests for the target device according to the control track sequence and runs the control tracks in an execution channel independent of the graphical interface. The device independent queue module routes control requests to the corresponding device's independent request queue based on the target device identifier. The device scheduling module uses limited concurrent scheduling for read requests and serial scheduling for write requests within a single device. The persistent connection and recovery module performs reconnection cooling and pending request cleanup when a connection-level failure is detected. The runtime verification module continues to obtain the target device feedback status after the control request is executed, and determines whether the target device action is completed based on the unified runtime snapshot object. The track audio processing module triggers audio playback based on the sound effect control block in the control track, and allocates an independent audio channel for the current track.

[0016] Compared with the prior art, the advantages and positive effects of the present invention are as follows: 1. This invention, through the collaborative setup of an industrial control host, multiple remote devices, a first protocol device management unit, a second protocol device management unit, a protocol abstraction and adaptation module, and a unified runtime snapshot aggregation module, transforms device read / write requests and feedback states under different industrial protocols into unified control objects and unified runtime snapshot objects. This enables remote devices with different protocols, types, and capabilities to be identified, displayed, scheduled, and verified under the same runtime view. It also avoids the problems of scattered states, unidentifiable capabilities, and difficulty in summarizing error information caused by protocol differences, thereby improving the compatibility, scalability, and consistency of operation monitoring after heterogeneous devices are connected.

[0017] 2. This invention, through the cooperation of an independent execution track module, a track-based zero-code programming module, a device independent queue module, a device scheduling module, a persistent connection and recovery module, a runtime verification module, and a track audio processing module, enables users to generate control tracks by dragging and dropping control blocks and configuring parameters. The control tracks run independently of the graphical interface thread. Control requests enter corresponding independent request queues according to device identifiers. Within a single device, read requests are limited to concurrency, while write requests are executed serially. Invalid reconnections and request backlogs are suppressed through reconnection cooling and pending request cleanup. After a control request is issued, the runtime verification module continues to determine whether the action has been truly completed based on the device feedback status. The track audio processing module can also associate sound prompts with the control flow, improving the system's real-time performance, stability, security, and human-computer interaction. Attached Figure Description

[0018] Figure 1 This is a system flowchart of the present invention; Figure 2This is a flowchart illustrating the unified runtime snapshot aggregation process of the present invention; Figure 3 This is a flowchart illustrating the independent execution path of this invention; Figure 4 This is a structural diagram of the track-based zero-code programming interface of the present invention; Figure 5 This is a diagram illustrating the independent queue and single-device scheduling structure of the device in this invention; Figure 6 This is a flowchart of the connection-level fault recovery process of the present invention. Detailed Implementation

[0019] The specific implementation of the intelligent remote device collaborative control system will be described below in conjunction with the technical solution of the present invention. It should be understood that the following embodiments are only for explaining the present invention and are not intended to limit the scope of protection of the present invention. Without departing from the core concept of the present invention, those skilled in the art can make adaptive adjustments to the specific implementation form according to the type of industrial field equipment, the type of communication protocol, and the complexity of the control process.

[0020] Example 1: This example provides an intelligent remote device collaborative control system. (See attached document.) Figure 1 The system includes an industrial control host and multiple remote devices. The industrial control host includes a processor, memory, display interaction unit and industrial communication interface. The multiple remote devices include at least a first type of device using a first industrial protocol and a second type of device using a second industrial protocol.

[0021] The first type of device can be a remote input / output device, servo drive device, or local register service device based on a register access protocol. The second type of device can be a fieldbus device or an industrial Ethernet device, such as an EtherCAT device. The industrial control host can establish communication connections with remote devices of different protocol types through an industrial communication interface, and display device status, configure control tracks, edit control block parameters, monitor operating status, and provide abnormal information prompts in the display and interaction unit.

[0022] When the processor executes the program stored in the memory, it can implement the first protocol device management unit, the second protocol device management unit, the protocol abstraction and adaptation module, the unified runtime snapshot aggregation module, the independent execution track module, the track-based zero-code programming module, the device independent queue module, the device scheduling module, the persistent connection and recovery module, the runtime verification module, and the track audio processing module.

[0023] The first protocol device management unit is used to manage the first type of devices, including device connection, device status acquisition, read / write request processing, connection anomaly identification, and request feedback processing. The second protocol device management unit is used to manage the second type of devices, including device status acquisition, control request issuance, communication status feedback, and protocol extension information maintenance.

[0024] The protocol abstraction and adaptation module is located between the device management unit and the upper-level control flow of different protocols. It is used to convert device read and write requests under different industrial protocols into a unified control object and to convert device feedback status under different industrial protocols into a unified runtime snapshot object. As a result, track execution, device scheduling, status monitoring and running status verification do not need to directly rely on the underlying data structure of specific protocols, but are processed based on the unified control object and the unified runtime snapshot object.

[0025] In this embodiment, the user can complete the control track configuration in the display interaction unit. The system generates control requests according to the control track and control block sequence. The control requests are routed to the independent request queue of the corresponding device through the device independent queue module. Then, the device scheduling module performs read-write separation scheduling within the scope of a single device. If the device communication is abnormal, the persistent connection and recovery module performs reconnection cooling and pending request cleanup. After the control request is issued, the running state verification module continues to obtain the feedback status of the target device and determines whether the target device has actually completed the corresponding action. If there is a sound effect control block in the control track, the track audio processing module triggers the corresponding audio playback during track execution and allocates independent audio channels for different tracks.

[0026] With the above structure, the system can achieve unified device management, independent process execution, request isolation scheduling, connection failure recovery, action closed-loop verification, and track audio linkage in scenarios with multiple protocols, multiple devices, and multiple tracks running concurrently.

[0027] Example 2 illustrates the unified runtime snapshot aggregation process. (See attached document.) Figure 2 .

[0028] The first protocol device management unit periodically or on demand acquires device status data of the first type of devices. The device status data may include device identifier, connection status, device status text, communication delay, queue depth, error information, register status, servo status, device capability information, and first protocol extension information. The second protocol device management unit periodically or on demand acquires device status data of the second type of devices. The device status data may include device identifier, protocol type, operating status, communication status, error status, motion status, capability information, and second protocol extension information.

[0029] The protocol abstraction and adaptation module performs field identification and format conversion on device status data under different protocols, and generates a unified runtime snapshot object. The unified runtime snapshot object includes at least several of the following: device identifier, protocol type, device status or status text, latency information, queue depth, error information, device capability identifier, and protocol extension information.

[0030] Device capability identifiers are used to characterize whether a target device has register monitoring, general read / write, servo motion control, status monitoring, or device testing capabilities. For example, for devices based on register access protocols, device capability identifiers may include register read capability, register write capability, multi-register batch write capability, coil write capability, or servo control capability; for EtherCAT devices, device capability identifiers may include motion control capability, status feedback capability, or bus diagnostic capability.

[0031] The unified runtime snapshot aggregation module receives device status data output by the first protocol device management unit and the second protocol device management unit, and maps device status data under different protocols to unified runtime snapshot objects. The mapping process may include status field standardization, error information standardization, latency information normalization, queue depth statistics, capability field merging, and protocol extension information retention.

[0032] The unified runtime snapshot aggregation module forms a unified runtime device list, which can be reused by the device management interface, device monitoring interface, and control attribute interface. The device management interface can display the online status, protocol type, and error information of the devices based on the unified runtime device list; the device monitoring interface can display the real-time status, communication latency, and operating status based on the unified runtime device list; and the control attribute interface can provide the control block with the basis for selectable devices, available capabilities, and parameter configuration based on the unified runtime device list.

[0033] In one implementation, the upper layer of the system uses device_id to uniformly identify and route Modbus devices, EtherCAT devices, and other extended protocol devices. The underlying processing logic of different protocol devices is completed by the corresponding device management unit, while the upper layer control track, device scheduling, and status verification are all processed based on a unified runtime snapshot object. Thus, different protocol devices can participate in monitoring, scheduling, control, and verification in a unified manner.

[0034] Example 3 illustrates the process of track-based zero-code programming and control block arrangement. (See attached document.) Figure 4 .

[0035] The track-based zero-code programming module includes a control block toolbox, a drag-and-drop track editor, a control block factory, and a property panel parameter configuration mechanism. The control block toolbox provides a variety of predefined control blocks, which may include read blocks, write blocks, delay blocks, combo blocks, track control blocks, servo control blocks, EtherCAT motion control blocks, and sound effect control blocks.

[0036] The drag-and-drop track editor is used to drag and drop predefined control blocks into the target track and supports the rearrangement of predefined control blocks within the track. In one implementation, users can perform drag, sort, copy, paste, undo, and redo operations on control blocks in the interface. Each control block has a corresponding block type, block identifier, execution parameters, and display status. The order in which the control blocks are arranged in the track constitutes the execution order of the control flow.

[0037] The control block factory is used to automatically create control block instances based on the control block type. When a user adds a control block of a certain type to a target track, the control block factory generates a corresponding control block instance based on the control block type and assigns a unique identifier, default parameters, and initial state to the control block instance. The attribute panel parameter configuration mechanism is used to edit, write back, and save control block parameters. Parameters may include device identifier, register address, target value, delay time, motion target position, speed parameters, audio file, volume, and loop parameters.

[0038] During the control flow setup process, users do not need to write flow scripts or underlying protocol code. They only need to drag and drop control blocks to the control track and configure the corresponding parameters in the property panel to generate an executable control flow. The track-based zero-code programming module saves the control block arrangement results in the user interface as a control track configuration, which can be interpreted and executed by the independent execution track module.

[0039] In a further implementation, the system compiles the control blocks before track execution to form an executable sequence. For control blocks that have already been compiled, the system can cache the compilation results to reduce the overhead caused by repeated parsing and reconstruction. For write-type control blocks, when the user modifies the device identifier, register address, target value or other key parameters, the system triggers recompilation to avoid continuing to use the old configuration to execute the control flow. Thus, the system can balance the flexibility of control block arrangement and the stability of track execution.

[0040] Example 4 illustrates the independent execution trajectory process. (See attached document.) Figure 3 .

[0041] The independent execution track module is used to generate control requests for the target device according to the control track and control block sequence configured by the user, and runs in an execution channel independent of the graphical interface. Each control track maintains an independent execution status, execution lock, and stop event. The execution status is used to record whether the track is currently in a non-running, running, paused, stopped, or abnormal state. The execution lock is used to prevent the same track from being started repeatedly or executed concurrently. The stop event is used to interrupt track execution when the user stops the track, an emergency stop is triggered, an abnormality occurs, or the system exits.

[0042] The independent execution track module can run the control track using a background thread, thread pool, or event loop coroutine. After the control track starts, the independent execution track module reads the sequence of control blocks in the track and interprets and executes them sequentially. For read blocks, the independent execution track module generates read requests; for write blocks, it generates write requests; for delay blocks, it waits according to the configured time; for servo control blocks or motion control blocks, it generates corresponding motion control requests and, after the requests are sent, works with the runtime verification module to determine the completion of the action; for track control blocks, it executes start, stop, jump, or linkage control; for sound effect control blocks, it calls the track audio processing module to trigger audio playback.

[0043] The independent execution track module sends start events, stop events, error events, and progress events back to the display interaction unit through an independent event queue. The display interaction unit refreshes the interface state according to the events in the event queue. However, the track execution process does not depend on the continuous operation of the interface thread. Even if the display interaction unit experiences interface lag, partial interface refresh, or destruction of interface controls, the control track can still maintain execution continuity in the independent execution channel.

[0044] In one implementation, during track operation, the system controls the background monitoring reads of the same device to avoid mutual interference between control requests and monitoring requests. For example, when a device is executing a critical write request or motion control request, the system can reduce the background monitoring read frequency of that device or limit the number of concurrent monitoring reads of the same device, thereby ensuring that control requests are executed first.

[0045] In a further implementation, the system supports safe emergency stop processing. Hardware emergency stop has higher priority than software emergency stop. When hardware emergency stop is active, software cannot deactivate it. After an emergency stop is triggered, the system stops the currently executing control track, disables automatic execution, clears the track execution status, and performs batch shutdown processing on related outputs. After the emergency stop is deactivated, the system can restore the necessary output status, but it does not automatically resume the operation of the stopped control track. The user needs to restart it or it needs to be retried by an automatic execution mechanism that meets the conditions. As a result, the system can improve the safety of remote device collaborative control.

[0046] Example 5 illustrates the independent queue and scheduling process for equipment. (See attached document.) Figure 5 .

[0047] The device-independent queue module establishes independent request queues according to the device dimension. Each target device corresponds to an independent request queue. Control requests are routed to the corresponding device's independent request queue based on the device identifier, instead of entering the global request queue shared by all devices. Each device-independent queue can maintain one or more of the following: request priority, request waiting timeout, queue capacity, queue backlog alarm threshold, number of successful processing, number of failed processing, and queue full load statistics.

[0048] When any target device experiences a communication anomaly, response timeout, or connection loss, the anomaly only affects the independent request queue corresponding to that target device and will not block the request processing of other target devices. For example, if the first device's request waiting time increases due to a network anomaly, the requests of the second and third devices can still be scheduled and executed by their respective independent request queues, thereby avoiding the anomaly device slowing down all devices.

[0049] The device scheduling module performs read-write separation scheduling within a single device. Read requests are allowed to be executed concurrently with limited concurrency, while write requests are executed serially. Limited concurrency means that the system can set the maximum number of concurrent read requests based on device capabilities, communication protocols, current load, or configuration parameters. Serial writing means that multiple write requests within the same device are executed sequentially to avoid multiple write requests acting on the same device at the same time, which could lead to state conflicts or write overwriting.

[0050] The device scheduling module improves read throughput while ensuring write consistency. For example, for the same remote input / output device, multiple status read requests can be executed concurrently within a limited range to improve the status refresh speed. For register write, coil write, or motion control write requests, they are executed serially to ensure the order and consistency of control instructions.

[0051] In one implementation, when a request enters the device's independent queue, the system checks whether the target device is available, whether the queue exceeds its capacity, whether the request has a valid waiting time, and whether the request priority meets the scheduling conditions. If the device is unavailable or the queue is full, the system generates an error response and sends it back to the track execution logic. If the request is successfully enqueued, the device scheduling module executes the request according to the read-write separation strategy and returns the execution result to the independent execution track module.

[0052] Example 6 illustrates the connection-level fault recovery process. (See attached document.) Figure 6 .

[0053] The persistent connection and recovery module is used to maintain the device connection state and perform recovery processing when a connection-level failure is detected. Connection-level failures may include at least one of the following events: timeout, connection disconnection, connection reset, decoding failure, or no response.

[0054] When the system detects a connection-level failure, the persistent connection and recovery module marks the current connection as unavailable and records the number of consecutive failures. The system calculates the reconnection cooldown time window based on the number of consecutive failures. The more consecutive failures there are, the longer the reconnection cooldown time window can be. When the system is within the reconnection cooldown time window, it suppresses invalid repeated reconnections to avoid connection storms, request backlogs, or excessive system resource consumption caused by frequent reconnections in a short period of time.

[0055] After identifying a connection-level failure, the persistent connection and recovery module also cleans up the pending requests for the corresponding device. The cleanup objects can include requests that have been queued but not yet executed, requests that have been sent but have not received a response, and requests that continue to wait in an abnormal connection state. For the cleaned-up requests, the system can return an error result to the upper-level track execution logic, so that the independent execution track module can enter the exception handling process in a timely manner, instead of continuing to wait on invalid requests.

[0056] After the cooldown period ends, the persistent connection and recovery module can periodically attempt to restore the connection in the background. If the connection is successfully restored, the system updates the device connection status and allows subsequent new requests to enter the corresponding device's independent queue. If the connection restoration fails, the system continues to accumulate the failure count and recalculates the cooldown window.

[0057] In a further implementation, the system can record connection anomaly diagnostic information, which may include the time of the fault occurrence, device identification, connection status, error type, number of consecutive faults, cooldown time, number of queue cleanups, and recovery results. The system can also perform queue deadlock detection, concurrent conflict detection, long-term operation detection, and connection storm detection to enable maintenance personnel to analyze the cause of the fault.

[0058] Example 7 illustrates the runtime verification process.

[0059] The runtime verification module is used to continue to acquire the target device's feedback status after the control request is issued, and to determine whether the target device has actually completed the corresponding action based on the unified runtime snapshot object. For ordinary read and write devices, the runtime verification module can determine whether the control request has been completed based on the read and write response, device status, error information and subsequent status feedback. For servo devices or motion devices, the runtime verification module makes a judgment on the completion of the action based on at least one or more of the following: alarm code, software enable status, running status bit, real-time speed, current position and position error.

[0060] In one implementation, after the independent execution track module sends a motion control request to the servo device, the runtime verification module periodically obtains the runtime snapshot object of the target device. If there is an alarm code in the runtime snapshot object, the runtime verification module determines that the action has failed and generates an error result containing alarm information. If the software enable state does not meet the preset conditions, the runtime verification module determines that the device does not have the conditions to continue moving. If the target device does not enter the motion state within the preset start time, the runtime verification module determines that the device has not started. If the target device's speed drops to zero or the running status bit shows a stop before reaching the target position, the runtime verification module determines that the device has stopped prematurely.

[0061] In position mode, the running verification module continuously collects the current position and target position, and calculates the remaining displacement and position change. When the position change of the target device is lower than the preset threshold and the remaining displacement is still greater than the preset tolerance within multiple consecutive sampling periods, the running verification module determines that the target device has experienced motion interruption, failure to reach the target position, or jamming. When the current position reaches the target position or enters the allowable error range, and the target device does not have any alarms, enable abnormalities, or premature stop states, the running verification module determines that the action is completed.

[0062] Therefore, the system does not only determine the completion of the action based on the successful communication return, but also continues to perform closed-loop verification by combining the device feedback status after the control request is issued, thereby improving the reliability of the servo and motion control process.

[0063] Example 8 illustrates the adaptive batch write process for a register access protocol device.

[0064] The first type of device may include devices based on register access protocols. For this type of device, the system maintains a device-level batch write capability memory mode, which includes at least a whole packet batch write mode, a block batch write mode, and an item-by-item write mode.

[0065] When the system receives a batch write request, it first identifies whether the address to be written meets the conditions for continuous batch writing. If the conditions for continuous batch writing are met, the system initially prioritizes the whole-packet batch write mode. If the whole-packet batch write is successful, the system records the whole-packet batch write mode as the priority execution mode for subsequent batch writes of the same type on the device. If the whole-packet batch write fails, the system switches to the block batch write mode.

[0066] The block-based batch write mode generates a block plan based on the amount of data to be written, and performs batch writes in segments according to the block plan. If the block-based batch write is successful, the system records the block-based batch write mode as the priority execution mode for subsequent similar batch writes on the device. If the block-based batch write fails, the system switches to the item-by-item write mode. The item-by-item write mode executes the write one by one according to the address or data item, and records the item-by-item write mode as the priority execution mode for subsequent similar batch writes on the device.

[0067] In one implementation, when the underlying protocol is Modbus, the whole packet batch write mode can correspond to FC16 whole packet write to multiple registers, the block batch write mode can correspond to block FC16 write to multiple registers, and the item-by-item write mode can correspond to single register write. For multi-coil write, the whole packet batch write mode can correspond to FC15 whole packet write to multiple coils, the block batch write mode can correspond to block FC15 write to multiple coils, and the item-by-item write mode can correspond to FC5 point-by-point write.

[0068] With the device-level batch write capability memory mode, the system can automatically adjust the write strategy according to the actual support of different devices for whole packet write, block write and item-by-item write, avoid overall failure due to fixed batch write strategy and improve compatibility in complex field.

[0069] Example 9 illustrates the track audio processing process.

[0070] The track audio processing module is used to trigger audio file playback during the execution of the control track and incorporate audio processing into the track control process. The track audio processing module may include sound effect control block, track audio manager, audio environment initialization and rollback mechanism, and track-level stop control.

[0071] The sound effect control block is used to declare the audio file to be played, volume, and loop parameters in the control track. Users can drag and drop the sound effect control block to the target track in the track-based zero-code programming module, and configure the audio file path, volume, whether to loop, and playback trigger position in the property panel. When the track module is executed independently and reaches the sound effect control block, the track audio processing module triggers audio playback according to the parameters in the sound effect control block.

[0072] The track audio manager is used to assign independent audio channels to different tracks. Each control track can have an independent audio channel, and audio from different tracks can be played concurrently without interfering with each other. When a track stops, exits abnormally, or the system exits, the track-level stop control stops the audio playback corresponding to the current track without affecting the audio processing of other tracks.

[0073] The audio environment initialization and fallback mechanism is used to switch to a backup backend when the preferred audio backend is unavailable. For example, when the preferred audio playback environment initialization fails, the system can try a backup audio backend or return to an audio unavailable state without affecting the continued execution of other control blocks in the control track.

[0074] In this way, audio playback is interpreted and executed by an independent track module, eliminating the need for users to write additional audio scripts. Audio processing, together with the read, write, delay, servo, and track control blocks in the track, forms a unified control flow, enabling sound prompts, alarm tones, or process voices to be precisely associated with the remote device control process.

[0075] Example 10 illustrates the extended applications of the system.

[0076] In one extended implementation, the system supports KET serial keyboard access. The KET serial keyboard can send JSON messages to the industrial control host via the CH340 serial port. The system parses the key events, encoder events, and emergency stop events in the JSON messages and maps them to control track start, control track stop, parameter adjustment, or emergency stop control. As a result, users can quickly trigger the control process through external physical input devices, improving the convenience of on-site operation.

[0077] In another extended implementation, the system supports a map mode. The system can import a site plan as the display background and place track icons or equipment icons on the plan. Users can click on the track icon to trigger the corresponding control track to run, and long press the track icon to view site photos or related information. For high-privilege operations such as map editing and background deletion, the system can set dynamic password protection to prevent unauthorized modifications.

[0078] In another extended implementation, the system supports automated timed execution. Users can configure one or more time periods. Once the specified time period is reached, the system automatically starts the automatic execution state; once the specified time period is over, the system automatically stops the automatic execution state. This method is not a simple infinite loop, but a scheduling and control based on time periods, which is suitable for timed inspections, timed start and stop, and periodic remote control scenarios.

[0079] In another extended implementation, the system supports crash detection and diagnostic logging. The system can detect queue deadlocks, concurrent conflicts, long-running events, and connection storms, and record sentinel information, exception stacks, and diagnostic logs. The diagnostic logs can be used by developers or maintenance personnel to analyze the system's operating status and improve fault location efficiency.

[0080] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An intelligent remote device collaborative control system, characterized in that, include: Industrial control host: The industrial control host includes a processor, memory, display and interaction unit and industrial communication interface; Multiple remote devices: The multiple remote devices include at least a first type of device using a first industrial protocol and a second type of device using a second industrial protocol; The first protocol device management unit is used to manage the first type of device, and the second protocol device management unit is used to manage the second type of device. Protocol abstraction and adaptation module: used to convert device read and write requests under different industrial protocols into unified control objects, and to convert device feedback status under different industrial protocols into runtime snapshot objects in a unified format; Unified runtime snapshot aggregation module: used to receive device status data output by the first protocol device management unit and the second protocol device management unit, and map device status data under different protocols to unified runtime snapshot objects; Independent execution track module: used to generate control requests for the target device according to the control track and control block sequence configured by the user, and run in an execution channel independent of the graphical interface; Track-based zero-code programming module: Provides a control block toolbox, drag-and-drop track editing, and parametric property configuration, allowing users to generate control tracks without writing scripts; Device Independent Queue Module: Used to establish an independent request queue for each target device and route control requests to the corresponding device's independent request queue based on the device identifier; Device scheduling module: Used for limited concurrent scheduling of read requests and serial scheduling of write requests within a single device. Persistent connection and recovery module: Used to maintain the device connection status and perform reconnection cooling and pending request cleanup when a connection-level failure is detected; Runtime verification module: Used to continue to obtain the target device's feedback status after the control request is issued, and to determine whether the target device has actually completed the corresponding action based on the unified runtime snapshot object; Track audio processing module: used to enable the control track to trigger the playback of audio files during execution, and to allocate independent audio channels to different tracks.

2. The intelligent remote device collaborative control system according to claim 1, characterized in that, The unified runtime snapshot object includes at least several of the following: device identifier, protocol type, device status or status text, latency information, queue depth, error information, device capability identifier, and protocol extension information. The device capability identifier is used to characterize whether the target device has register monitoring, general read / write, servo motion control, status monitoring or device testing capabilities. The unified runtime snapshot aggregation module standardizes and maps the device status data generated by the first protocol device management unit and the second protocol device management unit to form a unified runtime device list that can be reused by the device management interface, device monitoring interface and control attribute interface.

3. The intelligent remote device collaborative control system according to claim 1, characterized in that, The independent execution track module maintains an independent execution state, execution lock, and stop event for each control track. The independent execution track module runs the control track through a background thread, thread pool, or event loop coroutine. The independent execution track module sends start events, stop events, error events, and progress events back to the display interaction unit through an independent event queue. When the interactive display unit experiences interface lag, partial interface refresh, or destruction of interface controls, the independent execution track module still maintains the continuity of track execution.

4. The intelligent remote device collaborative control system according to claim 1, characterized in that, The track-based zero-code programming module includes: Control Block Toolbox: Provides a variety of predefined control blocks; Drag-and-drop track editor: Used to drag and drop predefined control blocks into a target track, and supports rearranging predefined control blocks within the track; Control Block Factory: Used to automatically create control block instances based on the control block type; Property panel parameter configuration mechanism: used to edit, write back, and save control block parameters; Users can generate a control flow that can be interpreted and executed by an independent execution track module by dragging and dropping control blocks onto the control track and configuring device identifiers, register addresses, target values, delay times, or action parameters in the property panel.

5. The intelligent remote device collaborative control system according to claim 1, characterized in that, The device-independent queue module establishes independent request queues according to the device dimension. Each device-independent queue maintains at least one or more of the following: request priority, request waiting timeout, queue capacity, queue backlog alarm threshold, number of successful processing, number of failed processing, and queue full load statistics. When any target device experiences a communication anomaly, the communication anomaly only affects the independent request queue corresponding to that target device, without affecting the request processing of other target devices.

6. The intelligent remote device collaborative control system according to claim 1, characterized in that, The device scheduling module performs read-write separation scheduling within a single device. Read requests are allowed to be executed concurrently with limited concurrency, while write requests are executed serially. The device scheduling module avoids conflicts between multiple write requests within the same device and improves read throughput while ensuring write consistency.

7. The intelligent remote device collaborative control system according to claim 1, characterized in that, When at least one of the following events occurs: timeout, connection disconnection, connection reset, decoding failure, or no response, the persistent connection and recovery module will identify the corresponding exception as a connection-level fault and perform the following operations after identifying the connection-level fault: mark the current connection as unavailable, record the number of consecutive faults, calculate the reconnection cooling time window, suppress invalid repeated reconnections within the reconnection cooling time window, clear the pending requests of the corresponding device, and periodically attempt to restore the connection in the background.

8. The intelligent remote device collaborative control system according to claim 1, characterized in that, The running state verification module, for servo devices or motion devices, makes a judgment on the completion of actions based on at least one or more of the following: alarm code, software enable state, running state bit, real-time speed, current position, and position error. In position mode, when the position change of the target device is lower than the preset threshold and the remaining displacement is still greater than the preset tolerance within multiple consecutive sampling periods, the running state verification module determines that the target device has experienced motion interruption, failure to reach its position, or jamming.

9. The intelligent remote device collaborative control system according to claim 1, characterized in that, The first type of device includes devices based on register access protocols; The system also includes an adaptive batch write mechanism for register access protocol devices. The adaptive batch write mechanism maintains a device-level batch write capability memory mode. The device-level batch write capability memory mode includes at least a whole packet batch write mode, a block batch write mode, and an item-by-item write mode. Initially, the whole-packet batch write mode is preferred. When the whole-packet batch write fails, it switches to the block batch write mode. When the block batch write fails, it switches to the item-by-item write mode. The switching result is recorded as the priority execution mode for subsequent batch writes of the same type on the device.

10. A method for collaborative control of intelligent remote devices, characterized in that, The method, applied to the intelligent remote device collaborative control system according to any one of claims 1-9, comprises: The device configuration and control track configuration of multiple remote devices using different industrial protocols are obtained. The first protocol device management unit and the second protocol device management unit respectively obtain the device status data of devices using different protocols. The protocol abstraction and adaptation module converts device read / write requests under different industrial protocols into a unified control object, and converts device feedback status under different industrial protocols into a unified runtime snapshot object. The unified runtime snapshot aggregation module maps device status data under different protocols to unified runtime snapshot objects, and forms unified runtime device information for device management, device monitoring and control attribute configuration. The track-based zero-code programming module generates control tracks by dragging and dropping control blocks and configuring parameters. The independent execution track module generates control requests for the target device according to the control track sequence and runs the control tracks in an execution channel independent of the graphical interface. The device independent queue module routes control requests to the corresponding device's independent request queue based on the target device identifier. The device scheduling module uses limited concurrent scheduling for read requests and serial scheduling for write requests within a single device. The persistent connection and recovery module performs reconnection cooling and pending request cleanup when a connection-level failure is detected. The runtime verification module continues to obtain the target device feedback status after the control request is executed, and determines whether the target device action is completed based on the unified runtime snapshot object. The track audio processing module triggers audio playback based on the sound effect control block in the control track, and allocates an independent audio channel for the current track.

Images