Method and system for multi-console collaborative control and dynamic arbitration of device permissions based on PLC

Abstract

The application discloses a kind of based on PLC multi-control console collaborative control and equipment authority dynamic arbitration method and system;The method comprises: establishing equipment control authority mapping table in PLC global data block, establish PLC as only truth source;Deprive the direct write authority of console to mapping table and equipment control coil, console can only send preemption application to PLC;PLC executes conditional preemption hard logic verification in bottom scanning cycle, and only when and if device is in stationary state, PLC itself triggers to update mapping table and open driving channel;If the device is in motion or fault state, PLC directly intercepts and discards the request in the bottom hardware logic layer, realizes the absolute veto of physical running state to logic authority flow.The application sinks authority arbitration to PLC bottom hard logic, completely eliminates the risk of brain split caused by multi-control console concurrency and software anti-penetration fault, guarantees the absolute physical safety of stage heavy machinery.

Description

Technical Field

[0001] This invention relates to the fields of stage machinery control and industrial automation technology, and in particular to a PLC-based method and system for multi-control console collaborative control and dynamic arbitration of device permissions. Background Technology

[0002] In large-scale stage plays, live performances, and complex industrial sites, there are often a large number of controlled devices (such as booms, wires, and lifting platforms). To meet the collaborative operation needs of multiple areas and different jobs, multiple control consoles are usually configured. However, traditional multi-control console systems face the following significant drawbacks in collaborative control and access control:

[0003] Data inconsistency and the risk of "split-brain": Traditional permission allocation is mostly implemented at the host computer (controller software) level, lacking an absolute source of truth at the underlying level. When there is network latency or multiple devices send commands simultaneously, it is very easy to cause status data to become out of sync, leading to multiple control consoles vying for control of the same device. Once the host computer software crashes, it can easily lead to permission lockout, making it impossible to switch control consoles on-site.

[0004] Security risks of software-layer arbitration (anti-penetration layer): If operations are restricted only at the software UI level, once the console software crashes, is cracked, or is misoperated, the erroneous command will still penetrate the software defense and be sent to the underlying layer because the host computer has direct write access to the underlying coil, causing physical collisions or damage to heavy equipment.

[0005] Lack of disconnection protection and closed-loop permissions: When multiple consoles operate at the same level, if a console unexpectedly loses network access while controlling a device, the current technology can only shut down the device, but the control rights remain under the disconnected console and become "orphan permissions", which cannot be taken over by other healthy consoles; at the same time, the lack of an atomic arbitration mechanism for device group linkage can easily lead to the tearing of group actions. Summary of the Invention

[0006] In view of the aforementioned existing problems, the present invention is proposed.

[0007] Therefore, this invention provides a PLC-based multi-control console collaborative control and dynamic arbitration method and system for device permissions to solve the above problems.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] In a first aspect, the present invention provides a PLC-based multi-control console collaborative control and dynamic device permission arbitration method, comprising the following steps:

[0010] Step S1: In the global data block of the PLC, define a structure for each controlled device that includes the device identifier, current control ownership, and physical operating status, and establish a "device control permission mapping table" to establish the PLC as the sole source of permission truth in the system; multiple control consoles access the mapping table in a round-robin manner via industrial Ethernet in a read-only manner, and each control console only has read-only access to the PLC mapping table and is deprived of direct write access to the device control coils. Any control console that wants to acquire control can only send a preemption request to the PLC;

[0011] Step S2: When any console requests to take over the target device, it sends a permission preemption request to the PLC;

[0012] Step S3: After receiving the preemption request, the PLC performs conditional preemption hard logic verification within its underlying scan cycle: it reads the physical operating status of the target device in the mapping table. If and only if the target device is in a stationary state, the PLC itself triggers an update to the mapping table, changing the control of the target device to the requesting console and opening the drive channel of the corresponding control coil. If the target device is in a moving state or in an emergency stop fault state, the PLC directly intercepts and discards the preemption request at the underlying hardware logic layer, refuses to modify the mapping table, and keeps the original control coil output unchanged, thus achieving absolute rejection of the logical access flow by the physical operating status.

[0013] Preferably, the conditional preemption hard logic verification in step S3 also includes an equal authorization mechanism:

[0014] The system assigns equal preemption priority to all consoles. When the target device is stationary, the PLC adopts the "latest request first" principle and updates the control ownership in the mapping table to the console ID that most recently initiated the preemption request. When the target device is in motion or in an abnormal state, the PLC forcibly discards the preemption request regardless of the priority or timing of the console that initiated the request, thus achieving physical-level anti-penetration protection against preemption during movement.

[0015] Preferably, it also includes a device group permission coordination arbitration step:

[0016] When a console requests to take over a device group containing multiple controlled devices, the PLC iterates through the status and ownership of all devices in the group in the mapping table. If any device in the group is in motion or is exclusively controlled by another console, the takeover request for the entire device group is rejected. Only when all devices in the group are in a static state and no other console is exclusively controlling them, does the PLC update the ownership of all devices in the group in an atomic transaction manner.

[0017] Preferably, it also includes a loss-of-connection security mechanism based on a heartbeat watchdog:

[0018] A heartbeat monitoring system is established between the PLC and each control console. The PLC monitors the heartbeat messages of each control console in real time. Once the heartbeat of the control console holding the control of the device is lost for more than the preset timeout threshold, the PLC immediately triggers a safety response, automatically and forcibly reclaims the control of all devices under the name of the lost control console, clears the ownership in the mapping table, restores the device to an ownerless state that can be taken over by other healthy control consoles, and issues a safety stop command to the running devices.

[0019] Preferably, the specific implementation method of heartbeat monitoring is as follows:

[0020] A heartbeat counter is set up for each console in a specific data block of the PLC; the console increments the count value of the heartbeat counter at fixed intervals; the PLC's scan cycle program monitors the count value, and if the count value does not change within a preset timeout threshold, the console is determined to be disconnected or offline.

[0021] Preferably, this also includes a real-time mirroring and visual feedback step of the console interface:

[0022] All consoles frequently poll the device control permission mapping table in the PLC and mirror the status in real time on the local UI. If it is determined that a device is controlled by this console, the first visual state is presented on the interface and the interaction logic is unlocked. If it is determined that a device is controlled by another console, the second warning visual state is presented on the interface, the number of the console occupying the device is displayed, and the interaction operation of the device is disabled at the code level.

[0023] Preferably, it also includes permission flow logs and underlying audit tracing steps:

[0024] An access control log data block is established within the PLC. Each time a device access control change event occurs, the PLC records the change timestamp, the original console ID, the new console ID, and the device status at the time of the change in this log data block, forming a low-level audit trail chain that cannot be tampered with by the host computer.

[0025] Secondly, the present invention provides a PLC-based multi-control console collaborative control and dynamic device permission arbitration system for implementing the above-mentioned method, including:

[0026] Multiple collaborative control consoles: As human-machine interaction terminals, they only have read-only access to the PLC mapping table;

[0027] Industrial Ethernet network layer: carries high-frequency read-only polling and access preemption request data for the control console;

[0028] Core Arbitration PLC: As the sole source of truth and the core of arbitration, its internal storage device controls the access permission mapping table and solidifies the operating condition preemption hard logic module; the condition preemption hard logic module forcibly executes the physical operating state to veto the access permission flow, and only the PLC itself completes the updating of the mapping table and the driving of the control coil.

[0029] Stage controlled equipment and drives: Only receive motion commands from the core arbitration PLC.

[0030] Preferably, the core arbitration PLC also includes:

[0031] The heartbeat monitoring module has a built-in watchdog timer and heartbeat counter to monitor the online status of the console and trigger forced reclaim of control and clearing of the mapping table ownership when the connection is lost.

[0032] The device group atomicity verification module is used to traverse the device status within the group and perform a veto judgment when a device group takeover request is received, in order to decide whether to allow overall takeover.

[0033] Preferably, the multiple collaborative consoles include physical hardware consoles and digital twin visualization consoles built on the Unity3D engine;

[0034] The digital twin visualization control console establishes a long TCP connection with the PLC through the communication library to read the mapping table and device status data. Based on the read control ownership ID, it changes the material status of the 3D model in real time and locks or unlocks the interactive scripts accordingly.

[0035] The beneficial effects of this invention are as follows: Preventing penetration of security boundaries: By stripping the console of direct write access and embedding the "no-fighting-in-motion" mechanism into the PLC's underlying hard logic, it replaces the traditional upper-level software arbitration. Even if the console is hacked or misoperated, it cannot bypass the PLC's defenses to issue conflicting commands, achieving absolute veto of logical permissions by the physical operating state and ensuring the absolute physical safety of heavy machinery.

[0036] Zero-conflict equal collaboration: The innovative logic of "static power grab, dynamic power yielding" perfectly addresses the actual pain points of stage performances, and achieves a smooth handover of permissions among multiple operators while ensuring physical safety.

[0037] Highly reliable disaster recovery and closed-loop mechanism: Heartbeat loss not only triggers shutdown, but also forcibly reclaims and clears permissions, eliminating the deadlock of "orphan permissions" and realizing a self-healing closed loop for the permission lifecycle; the veto and atomic takeover of device group linkage effectively prevents grouping action tearing.

[0038] Panoramic visualization to prevent accidental operation: Real-time mirroring of the interface and interactive locking at the code level completely eliminate the possibility of multiple people accidentally operating the same device at the same time from an ergonomic perspective. Attached Figure Description

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

[0040] Figure 1 The flowchart illustrates a PLC-based multi-control console collaborative control and dynamic arbitration method for device permissions, as provided in this embodiment of the invention. Detailed Implementation

[0041] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0042] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0043] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0044] Reference Figure 1 As one embodiment of the present invention, this embodiment provides a PLC-based multi-control console collaborative control and dynamic device permission arbitration method, including the following steps:

[0045] Step S1: In the global data block of the PLC, define a structure for each controlled device that includes the device identifier, current control ownership, and physical operating status, and establish a "device control permission mapping table" to establish the PLC as the sole source of authorization in the system. Multiple control consoles access the mapping table in a round-robin manner via industrial Ethernet in a read-only manner. Each control console only has read-only access to the PLC mapping table and is deprived of direct write access to the device control coil. Any control console that wants to acquire control can only send a preemption request to the PLC.

[0046] This step specifically involves: 1. Constructing a unique source of truth and mapping table data structure:

[0047] In the programming environment of a core arbitration PLC (such as the Siemens S7-1500 series), create a global data block (e.g., DB100). Within DB100, define a structure array named "Device_Auth_Map". The length of the array is determined by the total number of actual controlled devices (such as booms, lifting platforms, etc.) on site. Each array element corresponds to one controlled device, and its structure contains the following core fields:

[0048] Device_ID (INT type): Unique identifier for the device;

[0049] Owner_Console_ID (INT type): The console ID to which the current control belongs. The default value is 0, which means that the device is in an ownerless and idle state. 1~N represent the corresponding console number.

[0050] Status (WORD type): The physical operating status word of the device, where 0 represents a stationary state, and non-zero values ​​(such as 1 for movement, 2 for emergency stop, 3 for fault, etc.) represent abnormal or moving states.

[0051] Heartbeat_Counter (INT type): Used to associate the heartbeat counter of the current controller of the device (reused when devices in the group are uniformly assigned, or a separate console heartbeat table is set up).

[0052] By centrally defining the permissions and status of all devices in the PLC's DB block, the possibility of the host computer software caching permission status locally is completely eliminated, establishing the PLC as the "sole source of true permissions" for the entire control system from the perspective of data storage architecture.

[0053] 2. Depriving console write access and establishing an asymmetric communication architecture:

[0054] To ensure that "each console only has read-only access to the PLC mapping table and is deprived of direct write access to the device control coils," this embodiment configures the PLC hardware configuration and communication security strategy as follows:

[0055] In the PLC properties of TIA Portal, configure the area protection rules for S7 communication. For the IP address or communication connection resources of each collaborative console (host computer), restrict its access permissions to: only have "read" permissions for DB100 (mapping table) and Q area (physical output coil image area), and revoke its "write" permissions for the core fields of DB100 and any operation permissions for Q area.

[0056] 3. Establishing a preemptive application channel:

[0057] Because the console is deprived of the authority to directly modify the mapping table and control coils, this embodiment creates a dedicated "request mailbox" data block (e.g., DB10_Request) in the PLC. When the console wants to gain control of a device, it can only do so through a write operation of the S7 communication protocol, writing a request message containing its own Console_ID and the target Device_ID to DB10_Request. This ensures that "preemption requests can only be sent to the PLC." The console can never directly modify the Owner_Console_ID in DB100 or drive the output coils of the frequency converter via instructions.

[0058] 4. Industrial Ethernet high-frequency read-only polling synchronization:

[0059] Each collaborative control console acts as a human-machine interface terminal, establishing a communication connection with the PLC via industrial Ethernet (such as PROFINET or standard TCP / IP Ethernet). The console software runs a background high-frequency communication thread (e.g., based on the S7.Net or Snap7 library) to continuously send read requests for the DB100 to the PLC at a set polling period (e.g., 50ms~100ms). The PLC responds to the read requests, sending the latest "Equipment Control Authority Mapping Table" data to each control console as is. After obtaining this read-only data, the control console performs status rendering and logical judgments on its local UI. Because all control consoles read a snapshot of the same DB block from the PLC at the same moment, data inconsistency and the risk of "split-brain" errors between multiple control consoles are completely eliminated.

[0060] Step S2: When any console requests to take over the target device, it sends a permission preemption request to the PLC.

[0061] This step specifically involves: 1. The mechanism for triggering preemption requests:

[0062] On any of the multiple collaborative control consoles (e.g., console A, assigned ID=1 by the system), the operator selects the target controlled device (e.g., stage hoist #1, Device_ID=1) through the human-machine interface (HMI) and performs a "takeover / request control" operation (e.g., clicking the "takeover" button on the UI or turning on the authorization key switch on the physical control console). The console's background program captures this interaction event and determines that the operator intends to gain control of the device.

[0063] 2. Encapsulation of preempted request data:

[0064] In response to this event, the console software constructs a "privilege preemption request" datagram in memory. This datagram contains at least the following key fields:

[0065] Req_Console_ID (Requester console ID): Enter the ID of this console (e.g., value 1);

[0066] Target_Device_ID: Enter the device ID selected by the operator (e.g., value 1);

[0067] Req_Type (Request Type): Identifies the "preemption of control" opcode (e.g., value 0x01, distinct from operations such as releasing permissions or emergency stop).

[0068] 3. Asymmetric writing based on industrial Ethernet:

[0069] Since the console has been deprived of direct write permissions to the "Device Control Permission Mapping Table" (DB100) and the physical output coil through architectural design in step S1, the console cannot directly modify the ownership status of boom number 1.

[0070] Therefore, the console uses industrial Ethernet communication protocols (such as Siemens S7 communication protocol) to call write data instructions (such as the DBWrite method in the S7.Net library or the DB_Write method in the Snap7 library) to write the encapsulated preemption request data message to a predefined dedicated "request mailbox" data block (such as the DB10_Request area) in the PLC, instead of directly writing to the permission mapping table DB100.

[0071] 4. Queuing and debouncing of request tokens (preferred implementation strategy):

[0072] To prevent multiple consoles from concurrently preempting requests at the same millisecond level, leading to request overwriting, the DB10_Request area can be designed as a circular buffer or each console can be allocated an independent request slot. For example, console A can only write requests to its dedicated slot starting with DB10.DBX0.0, while console B can write to its dedicated slot starting with DB10.DBX10.0. After writing a request, the console sets the Req_Ready flag for that slot to True (e.g., set it to 1) to declare the request valid to the PLC main loop.

[0073] 5. Awaiting arbitration and status polling:

[0074] After the console completes the writing of the preemption request, it does not immediately change the control state of the local UI. Instead, it continues to poll the PLC's permission mapping table (DB100) in a high-frequency (e.g., 50ms cycle) read-only manner. The console continuously compares whether the Owner_Console_ID field of the No. 1 boom in the mapping table is updated to its own ID (1) to determine whether the PLC's underlying hard logic (step S3) has approved the preemption request, thereby providing visual feedback of "takeover successful" or "takeover rejected" on the interface.

[0075] Through the above implementation method, step S2 strictly implements the asymmetric security architecture that "the console can only send preemption requests and has no right to directly rewrite permissions and control coils", and completely hands over the absolute discretion of permission changes to the subsequent PLC underlying hard logic execution.

[0076] Step S3: After receiving the preemption request, the PLC performs conditional preemption hard logic verification within its underlying scan cycle: it reads the physical operating status of the target device in the mapping table. If and only if the target device is in a stationary state, the PLC itself triggers an update to the mapping table, changing the control of the target device to the requesting console and opening the drive channel of the corresponding control coil. If the target device is in a moving state or in an emergency stop fault state, the PLC directly intercepts and discards the preemption request at the underlying hardware logic layer, refuses to modify the mapping table, and keeps the original control coil output unchanged, thus achieving absolute rejection of the logical access flow by the physical operating status.

[0077] This step specifically involves: 1. Request detection and status reading during the underlying scanning cycle:

[0078] The PLC uses the underlying loop scan cycle of its core processing unit (such as the OB1 main program loop, with a cycle of approximately 10ms to 50ms) as the time base for permission arbitration. At the beginning of each scan cycle, the PLC executes conditional preemption of hard logic modules (such as the FC100 function block).

[0079] The PLC first detects the status in the dedicated "request mailbox" data block (such as DB10_Request). When it detects that the Req_Ready flag for boom 1 (Device_ID=1) initiated by console A (ID=1) is True (i.e., a preemption request has been received), the PLC immediately addresses the structure array element corresponding to boom 1 in the "Device Control Authority Mapping Table" (DB100) based on the Target_Device_ID carried in the request, and reads the current value of its Status field.

[0080] 2. Conditional preemption hard logic verification (executing of physical veto):

[0081] The PLC loads the target device Status value into the accumulator, compares it with the preset static state value (0) in binary, and executes a hard logic branch judgment that cannot be overridden by the host computer:

[0082] Scenario A (Successful Preemption and Open Drive Channel): If and only if the target device is in a stationary state.

[0083] If the comparison result is Status == 0, the PLC determines that the device is in a safe and manageable state. At this time, the PLC itself triggers an update operation: in the ladder logic, the comparison result enables the MOVE instruction, and the PLC writes the Req_Console_ID (value 1) from the request mailbox into the Owner_Console_ID field of the No. 1 boom in DB100, completing the modification of the control ownership.

[0084] Meanwhile, in order to "open the drive channel for the corresponding control coil," the PLC establishes a binding relationship between the device's output enable and the console ID at the logic layer. Specifically, the PLC sets the intermediate enable bit (e.g., M10.0) before the motion control output coil of boom 1 (e.g., Q0.0 inverter forward start) to 1. At this time, the physical drive channel of the device only allows motion commands issued by the console with Owner_Console_ID=1.

[0085] Scenario B (Failed Preemption and Absolute Rejection Due to Low-Level Interception): If the target device is in motion or experiencing an emergency stop failure.

[0086] If the comparison result is Status != 0 (e.g., 1 represents movement, 2 represents emergency stop, and 3 represents fault), the PLC's hard logic interception mechanism will take effect immediately:

[0087] 1) Refuse to modify the mapping table: The comparison result does not enable the MOVE instruction, the Owner_Console_ID in DB100 remains the original value (such as 0 or the previous console ID), and the transfer of control to the requesting console is refused;

[0088] 2) Directly intercept and discard the preemption request: The PLC skips the write operation to Owner_Console_ID and at the end of the current scan cycle, it forcibly resets the Req_Ready flag in DB10_Request to False, that is, directly discards the preemption request message from the bottom layer, so that it cannot be processed repeatedly in subsequent cycles.

[0089] 3) Keep the original control coil output unchanged: Since the conduction condition of the intermediate enable bit (M10.0) is not met, the logic state of the output image area (Q area) is not disturbed by any preemption request, the control of the original control console is not lost, and the inverter and other drives continue to operate according to the existing instructions.

[0090] 3. A penetration prevention mechanism that absolutely vetoes the flow of logical permissions based on physical operating status:

[0091] Through the aforementioned hard logic verification, the "physical movement / fault status of the device (Status bit)" is used as an absolute prerequisite constraint for "authorization flow (Owner modification and channel opening)". This means that no matter how many illegal preemptive write requests are generated by the host computer control console software due to crashes, hacks, or network storms, as long as the PLC's underlying layer detects that the device is not in a stationary state through physical sensors, the MOVE instruction will never be triggered, and the control coil output will be absolutely self-locking. This achieves absolute rejection of logical authorization flow based on physical operating status, completely blocking the security risks of software-level faults penetrating to the physical layer.

[0092] Preferably, the conditional preemption hard logic verification in step S3 also includes an equal authorization mechanism:

[0093] The system assigns equal preemption priority to all consoles. When the target device is stationary, the PLC adopts the "latest request first" principle and updates the control ownership in the mapping table to the console ID that most recently initiated the preemption request. When the target device is in motion or in an abnormal state, the PLC forcibly discards the preemption request regardless of the priority or timing of the console that initiated the request, thus achieving physical-level anti-penetration protection against preemption during movement.

[0094] This step specifically involves: 1. Constructing an equal priority architecture:

[0095] In the design of the PLC's "Device Control Authority Mapping Table" (DB100) and arbitration logic function block (FC100), no fields or comparison logic related to console priority are established. All collaborative consoles connected to the system, regardless of their physical location or operator rank, are given completely equal preemption priority at the PLC's underlying level. The PLC's hard logic makes objective decisions based solely on the timing of request arrival and the current physical state of the equipment, completely eliminating the potential safety hazards caused by logical complexity due to priority ranking or by high-priority consoles forcibly depriving low-priority consoles of control rights.

[0096] 2. Implementation of the "latest request first" principle in a static state:

[0097] When the target device is in a stationary state (Status == 0), the PLC adopts the "latest request first" processing logic:

[0098] Request-Response and Overwrite Mechanism: The PLC sequentially checks the "Request Mailbox" (DB10) within the underlying scan cycle. Assuming boom 1 is currently in an ownerless state (Owner_Console_ID = 0), if console A (ID=1) initiates a preemption at time T1, the PLC determines the device is stationary and triggers a MOVE instruction to update Owner_Console_ID to 1. Subsequently, if console B (ID=2) also initiates a preemption at time T2 (T2>T1), since the device is still stationary, the PLC unconditionally executes a new MOVE instruction, overwriting and updating Owner_Console_ID to 2. Under this mechanism, the console that most recently initiated the request immediately gains control, achieving a smooth and seamless handover of permissions between consoles at the same level.

[0099] Deterministic arbitration of concurrent requests within the same cycle: In the extremely rare event that multiple consoles simultaneously write preemption requests to the request mailbox within the same PLC scan cycle, the PLC processes them sequentially according to its inherent scan execution order (such as ladder diagram execution flow from top to bottom or left to right). The later executed MOVE instruction naturally overwrites the result of the earlier executed instruction. The final ownership ID in the mapping table will definitely be the console last executed in this cycle, thus ensuring the determinism and uniqueness of the single arbitration result and avoiding ambiguity in permission allocation.

[0100] 3. Penetration-resistant mechanism for "forced discard" during movement or abnormal conditions:

[0101] When the target device is in a motion or emergency stop fault state (Status != 0), regardless of how many consoles initiate requests or the order in which the requests arrive, the PLC's hard logic interlock mechanism is forcibly activated:

[0102] When the PLC performs a conditional check, the branch where Status != 0 will directly block the execution path of all MOVE instructions.

[0103] At this point, the PLC not only refuses to modify the Owner_Console_ID, but also forcibly clears the "request mailbox" at the end of the current scan cycle, resetting the Req_Ready flag for all devices in that motion to False. This means that these preemption requests are directly discarded at the PLC's underlying layer and do not even qualify for the access control evaluation process.

[0104] Through this hard logic interception, even if a certain console software is maliciously cracked and continuously sends preemption commands to the PLC at the highest frequency, ignoring UI restrictions, the PLC will absorb and discard all of them at the underlying level. The control of the original console remains as stable as Mount Tai, and the corresponding physical output coils are not disturbed, thus truly achieving physical-level anti-penetration protection of "preemption during movement".

[0105] Preferably, it also includes a device group permission coordination arbitration step:

[0106] When a console requests to take over a device group containing multiple controlled devices, the PLC iterates through the status and ownership of all devices in the group in the mapping table. If any device in the group is in motion or is exclusively controlled by another console, the takeover request for the entire device group is rejected. Only when all devices in the group are in a static state and no other console is exclusively controlling them, does the PLC update the ownership of all devices in the group in an atomic transaction manner.

[0107] This step specifically involves: 1. Defining the device group data structure and triggering requests:

[0108] In the PLC's global data block (such as DB200), a "device group mapping table" is predefined. This mapping table contains multiple device group structures, each defining a Group_ID (group identifier), a Member_Count (total number of devices in the group), and a Device_List_Array (an array of device IDs within the group). For example, device group G1 contains 3 lifting platforms (device IDs 3, 4, and 5).

[0109] When console A (ID=1) wants to take over device group G1, it writes Target_Group_ID = G1 and Req_Console_ID = 1 to the PLC's request mailbox data block (DB10) to trigger the group takeover request.

[0110] 2. Execution of iteration verification and veto logic:

[0111] The PLC calls the device group atomicity verification module (such as the FC200 function block) during the low-level scan cycle. Upon detecting a group takeover request for G1, the PLC initiates a loop traversal logic (such as using a FOR loop statement in SCL language or indirect addressing in a ladder diagram):

[0112] The PLC extracts the member device IDs (3, 4, 5) sequentially from Device_List_Array in G1 of DB200, and addresses each device to the corresponding device structure in the "Device Control Permission Mapping Table" (DB100) to read its Status and Owner_Console_ID fields.

[0113] During the traversal, the PLC sets a global decision flag, Group_Allow_Flag (initially set to True, indicating that takeover is allowed). Once the PLC detects that any device in the group meets one of the following conditions:

[0114] The equipment is in a non-stationary state (i.e., Status != 0, such as a motion or emergency stop fault).

[0115] The device is exclusively used by another console (i.e., Owner_Console_ID != 0 and Owner_Console_ID != the requester ID).

[0116] The PLC will immediately trigger a veto mechanism: forcibly resetting Group_Allow_Flag to False and immediately terminating subsequent traversal using a break instruction. At this point, the PLC rejects the takeover request for the entire equipment group G1, maintaining the original mapping table state of all equipment within the group unchanged.

[0117] 3. Overall update of atomized transaction method:

[0118] If the entire traversal process completes successfully without triggering a veto (i.e., Group_Allow_Flag remains True), it proves that all devices within the group are in a static state and no other console has exclusive access. Only then will the PLC execute the change of permission ownership.

[0119] To prevent the fragmentation of device permission status within the group due to program interruption or network disturbance during the update process, resulting in "partially updated and partially not updated" status, the PLC uses atomic transactions for overall updates.

[0120] Within the same scan cycle, the PLC, based on the Device_List_Array, loops again and continuously executes the MOVE instruction, overwriting the Owner_Console_ID of devices 3, 4, and 5 in group G1 to the requested console ID (1) in one continuous and uninterrupted manner, and simultaneously opening the control coil drive channels of these three devices. Because PLC program execution possesses "process-level atomicity" (it will not be interrupted by higher-priority I / O refreshes during user program execution), this continuous batch write operation within the same cycle logically ensures the indivisibility and safety of the grouping action, completely eliminating the risk of mechanical grouping tearing.

[0121] Preferably, it also includes a loss-of-connection security mechanism based on a heartbeat watchdog:

[0122] A heartbeat monitoring system is established between the PLC and each control console. The PLC monitors the heartbeat messages of each control console in real time. Once the heartbeat of the control console holding the control of the device is lost for more than the preset timeout threshold, the PLC immediately triggers a safety response, automatically and forcibly reclaims the control of all devices under the name of the lost control console, clears the ownership in the mapping table, restores the device to an ownerless state that can be taken over by other healthy control consoles, and issues a safety stop command to the running devices.

[0123] Preferably, the specific implementation method of heartbeat monitoring is as follows:

[0124] A heartbeat counter is set up for each console in a specific data block of the PLC; the console increments the count value of the heartbeat counter at fixed intervals; the PLC's scan cycle program monitors the count value, and if the count value does not change within a preset timeout threshold, the console is determined to be disconnected or offline.

[0125] Preferably, this also includes a real-time mirroring and visual feedback step of the console interface:

[0126] All consoles frequently poll the device control permission mapping table in the PLC and mirror the status in real time on the local UI. If it is determined that a device is controlled by this console, the first visual state is presented on the interface and the interaction logic is unlocked. If it is determined that a device is controlled by another console, the second warning visual state is presented on the interface, the number of the console occupying the device is displayed, and the interaction operation of the device is disabled at the code level.

[0127] Preferably, it also includes permission flow logs and underlying audit tracing steps:

[0128] An access control log data block is established within the PLC. Each time a device access control change event occurs, the PLC records the change timestamp, the original console ID, the new console ID, and the device status at the time of the change in this log data block, forming a low-level audit trail chain that cannot be tampered with by the host computer.

[0129] Secondly, the present invention provides a PLC-based multi-control console collaborative control and dynamic device permission arbitration system for implementing the above-mentioned method, including:

[0130] Multiple collaborative control consoles: As human-machine interaction terminals, they only have read-only access to the PLC mapping table;

[0131] Industrial Ethernet network layer: carries high-frequency read-only polling and access preemption request data for the control console;

[0132] Core Arbitration PLC: As the sole source of truth and the core of arbitration, its internal storage device controls the access permission mapping table and solidifies the operating condition preemption hard logic module; the condition preemption hard logic module forcibly executes the physical operating state to veto the access permission flow, and only the PLC itself completes the updating of the mapping table and the driving of the control coil.

[0133] Stage controlled equipment and drives: Only receive motion commands from the core arbitration PLC.

[0134] Preferably, the core arbitration PLC also includes:

[0135] The heartbeat monitoring module has a built-in watchdog timer and heartbeat counter to monitor the online status of the console and trigger forced reclaim of control and clearing of the mapping table ownership when the connection is lost.

[0136] The device group atomicity verification module is used to traverse the device status within the group and perform a veto judgment when a device group takeover request is received, in order to decide whether to allow overall takeover.

[0137] Preferably, the multiple collaborative consoles include physical hardware consoles and digital twin visualization consoles built on the Unity3D engine;

[0138] The digital twin visualization control console establishes a long TCP connection with the PLC through the communication library to read the mapping table and device status data. Based on the read control ownership ID, it changes the material status of the 3D model in real time and locks or unlocks the interactive scripts accordingly.

[0139] In this system, the Unity side of the digital twin visualization console establishes a long TCP connection with the core arbitration PLC through the S7.Net communication library, and asynchronously polls and reads DB100 (device permission mapping table) and DB200 (real-time 3D coordinates / velocity data of the device) at a period of 50ms.

[0140] The Unity3D engine's main thread renders the materials and interaction states of the corresponding device in the 3D scene in real time based on the read Owner_Console_ID:

[0141] If Owner_Console_ID equals the current Unity console ID, Unity modifies MeshRenderer.material.color via script to overlay a green highlight material onto the 3D model, and then executes GetComponent. <collider>().enabled = true unlocks the interactive script, allowing operators to issue motion command requests via mouse drag and drop;

[0142] If Owner_Console_ID belongs to another console (e.g., ID=2), the 3D model is rendered with a red semi-transparent locked material, and a "Occupied by console 02" text tooltip is overlaid on the UI Canvas layer. Simultaneously, GetComponent is executed from the code layer. <collider>().enabled = false disables the Raycast click interaction logic of the device.

[0143] When the user selects a device group in the Unity interface and clicks "Take Over Control", Unity does not directly issue action commands either. Instead, it packages the selected group of device IDs and sends a device group take over request to the PLC, and the PLC executes the aforementioned atomic one-veto check to ensure absolute safe synchronization of authority transfer between the digital twin and the physical entity.

[0144] In summary, compared with the prior art, the present invention has the following remarkable beneficial effects:

[0145] 1. Safety bottom-line penetration prevention, realizing physical-level conflict prevention:

[0146] The present invention subverts the traditional upper computer software arbitration architecture. By depriving the console of direct write authority to the mapping table and device coils, the discretion over authority transfer is completely enclosed at the underlying layer of the PLC. In particular, the hard logic check of "prohibited preemption during motion" establishes the absolute veto power of the physical operating state over the logical authority transfer. Even if the console software crashes, is maliciously cracked or generates misoperation, illegal preemption requests will be directly intercepted and discarded at the PLC hardware logic layer, and can never penetrate to the underlying drive coils, fundamentally eliminating the physical collision risk of heavy stage machinery, and increasing the safety redundancy from the SIL0 level of the upper computer to the SIL2 / SIL3 level of the PLC.

[0147] 2. Zero-conflict equal collaboration and smooth authority handover:

[0148] The innovative "equal authorization + latest request priority" mechanism perfectly meets the actual pain points of multi-trade cooperative rehearsal. Within the safety boundary when the device is stationary, the cumbersome priority preemption and negotiation process are eliminated, any operator can immediately take over the device according to on-site requirements, and realize seamless and zero-conflict authority transfer between multiple consoles; when the device is in operation, authority change is forcibly locked, which balances the flexibility of collaboration and the absoluteness of safety.

[0149] 3. High-reliability disaster-tolerant closed loop and tear prevention protection:

[0150] Aiming at the defect of the traditional system that "network disconnection leads to out-of-control, authority is permanently locked", the present invention proposes a closed-loop self-healing mechanism after heartbeat disconnection. The PLC not only issues a safety stop command to the operating device, but more importantly, forcibly clears all authorities under the name of the disconnected console, so that the device instantly returns to an ownerless state that can be taken over by surrounding healthy consoles, eliminating "orphan authority"; at the same time, the one-veto and atomic transaction update mechanism for device groups ensures the indivisibility of grouped devices during authority transfer, and thoroughly prevents mechanical tearing and stage accidents caused by partial preemption when multiple devices are linked.

[0151] 4. Panoramic visualization prevents accidental operation, providing dual protection for human safety:

[0152] The system forces all consoles to frequently poll for the unique source of permission information in a read-only manner, ensuring absolute consistency of views across all nodes. The intuitive visual color differentiation and usage indicators in the UI interface make it clear to each operator who has control. More importantly, the visual warning is coupled with "disabling interactive operations at the code level," completely preventing unintentional touches from both ergonomic and software architecture perspectives.

[0153] 5. Unalterable underlying audit traceability:

[0154] By establishing a permission transfer log directly within the PLC, which serves as the sole source of truth, the timestamp of each permission change, the IDs of both parties, and the device status are all directly recorded by the PLC's underlying hardware. This log is completely read-only by the host computer, forming an audit trail chain that cannot be tampered with by any external software. This provides a reliable and legally binding basis for determining liability and conducting post-accident reviews in large-scale performances.

[0155] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.< / collider> < / collider>

Claims

1. A PLC-based multi-control console collaborative control and dynamic device permission arbitration method, characterized in that, Includes the following steps: Step S1: In the global data block of the PLC, define a structure for each controlled device that includes the device identifier, current control ownership, and physical operating status, and establish a "device control permission mapping table" to establish the PLC as the sole source of permission truth in the system; multiple control consoles access the mapping table in a round-robin manner via industrial Ethernet in a read-only manner, and each control console only has read-only access to the PLC mapping table and is deprived of direct write access to the device control coils. Any control console that wants to obtain control can only send a preemption request to the PLC; Step S2: When any console requests to take over the target device, a permission preemption request is sent to the PLC; Step S3: After receiving the preemption request, the PLC performs conditional preemption hard logic verification within its underlying scan cycle: it reads the physical operating status of the target device in the mapping table. If and only if the target device is in a stationary state, the PLC itself triggers an update to the mapping table, changing the control of the target device to the request console and opening the drive channel of the corresponding control coil. If the target device is in a moving state or in an emergency stop fault state, the PLC directly intercepts and discards the preemption request at the underlying hardware logic layer, refuses to modify the mapping table, and keeps the original control coil output unchanged, thus achieving absolute rejection of the logical permission flow by the physical operating status.

2. The method according to claim 1, characterized in that, The conditional preemption hard logic verification in step S3 also includes an equal authorization mechanism: The system assigns equal preemption priority to all consoles. When the target device is stationary, the PLC adopts the "latest request first" principle and updates the control ownership in the mapping table to the console ID that most recently initiated the preemption request. When the target device is in motion or in an abnormal state, the PLC forcibly discards the preemption request regardless of the priority or timing of the console that initiated the request, thus achieving physical-level anti-penetration protection against preemption during movement.

3. The method according to claim 1, characterized in that, It also includes the device group permission coordination arbitration step: When a console requests to take over a device group containing multiple controlled devices, the PLC traverses the status and permission ownership of all devices in the device group in the mapping table; if any device in the group is in a moving state or is exclusively controlled by another console, the takeover request for the entire device group is rejected. The PLC only updates the control ownership of all devices in the group in an atomic transaction manner when all devices in the group are in a static state and no other console has exclusive control.

4. The method according to claim 1, characterized in that, It also includes steps for a disconnection security mechanism based on a heartbeat watchdog: A heartbeat monitoring system is established between the PLC and each control console. The PLC monitors the heartbeat messages of each control console in real time. Once the heartbeat of the control console holding the control of the device is lost for more than the preset timeout threshold, the PLC immediately triggers a safety response, automatically and forcibly reclaims the control of all devices under the name of the lost control console, clears the ownership in the mapping table, restores the device to an ownerless state that can be taken over by other healthy control consoles, and issues a safety stop command to the running devices.

5. The method according to claim 4, characterized in that, The specific implementation method of the heartbeat monitoring is as follows: A heartbeat counter is set up for each console in a specific data block of the PLC; the console increments the count value of the heartbeat counter at fixed intervals; the PLC's scanning cycle program monitors the count value, and if the count value does not change within the preset timeout threshold, the console is determined to be disconnected or offline.

6. The method according to claim 1, characterized in that, This also includes a live mirror of the console interface and visual feedback steps: All consoles frequently poll the device control permission mapping table in the PLC and mirror the status in real time on the local UI; if it is determined that a device is controlled by this console, the first visual status is presented on the interface and the interaction logic is unlocked. If it is determined that a device is controlled by another console, a second warning visual state is presented on the interface, displaying the number of the console in use, and interactive operations on that device are disabled at the code level.

7. The method according to claim 1, characterized in that, It also includes permission flow logs and underlying audit and tracing steps: An access control log data block is established within the PLC. Each time a device access control change event occurs, the PLC records the change timestamp, the original console ID, the new console ID, and the device status at the time of the change in this log data block, forming a low-level audit trail chain that cannot be tampered with by the host computer.

8. A PLC-based multi-control console collaborative control and dynamic device permission arbitration system, used to implement the method described in any one of claims 1 to 7, characterized in that, include: Multiple collaborative control consoles: As human-machine interaction terminals, they only have read-only access to the PLC mapping table; Industrial Ethernet network layer: carries high-frequency read-only polling and access preemption request data for the control console; Core Arbitration PLC: As the sole source of truth and the core of arbitration, its internal storage device control permission mapping table and fixed operating conditions preempt the hard logic module; The conditional preemption hard logic module forcibly executes the veto right of the physical operating state on the transfer of permissions, and only the PLC itself completes the update of the mapping table and the driving of the control coil. Stage controlled equipment and drives: Only receive motion commands from the core arbitration PLC.

9. The system according to claim 8, characterized in that, The core arbitration PLC also includes: The heartbeat monitoring module has a built-in watchdog timer and heartbeat counter to monitor the online status of the console and trigger forced reclaim of control and clearing of the mapping table ownership when the connection is lost. The device group atomicity verification module is used to traverse the device status within the group and perform a veto judgment when a device group takeover request is received, in order to decide whether to allow overall takeover.

10. The system according to claim 8, characterized in that, The multiple collaborative consoles include physical hardware consoles and digital twin visualization consoles built on the Unity3D engine; The digital twin visualization console establishes a long TCP connection with the PLC through the communication library to read the mapping table and device status data. Based on the read control ownership ID, it changes the material status of the 3D model in real time and locks or unlocks the interactive script accordingly.

Images