Real-time dynamic linking method and system for programmable logic controller

Abstract

The invention discloses a real-time dynamic link method and system for a programmable logic controller, and the method comprises the steps: analyzing a dynamic link instruction embedded in a PLC program source code in a compiling stage, and generating a link metadata table; in a system initialization stage, a runtime environment executes a process comprising a verification sub-stage and a submission sub-stage, after verification of all to-be-linked components is completed, whether a fatal link error is formed or not is judged according to a preset failure processing strategy, and if not, the to-be-linked components are submitted. If so, filling callable entry references of all the verified components to corresponding address placeholders in one time in an atomic manner; in a real-time execution phase, when a call occurs, an indirect call is made by a stub function through a callable entry reference when an enable input is true and an address placeholder is filled. According to the invention, through cooperative work of the compiler and the runtime environment, runtime analysis and binding of the PLC program and the external function are realized.

Description

Technical Field

[0001] This application relates to the field of industrial automation control technology, specifically to a real-time dynamic link method and system for programmable logic controllers. Background Technology

[0002] Currently, PLC programs conforming to industrial automation control standards generally adopt static compilation and linking. All source code written by the developer is processed by the compiler at once, generating a single, complete executable binary file. This model has significant drawbacks: the application logic is tightly coupled with the underlying function implementation, resulting in poor flexibility; updates and maintenance require replacing the entire program and interrupting equipment operation, leading to high costs; modularization and code reuse are inefficient; and function library licensing management is difficult.

[0003] This traditional static model has the following significant drawbacks:

[0004] 1. Tight coupling and poor flexibility: The application logic and its dependent underlying functions (such as hardware drivers, communication protocol stacks, and specific algorithm libraries) are "welded" together at compile time. If it is necessary to port the program to different hardware platforms or change a different implementation of an underlying library, it is often necessary to modify the source code and recompile the entire project.

[0005] 2. Difficult updates and maintenance, high downtime costs: In industrial production environments, the stable operation of PLCs is crucial. If only a low-level library function needs to be updated or fixed (e.g., updating a communication library to fix a bug), static mode requires stopping the PLC and then downloading and replacing it with a completely new, fully compiled firmware. This process can cause production line downtime, resulting in significant economic losses.

[0006] 3. Low modularization and code reuse efficiency: Although code can be reused through libraries, this reuse remains at the source code level. Ultimately, each PLC project statically compiles the library code into its own executable file, resulting in bloated firmware and the inability to share or dynamically replace common modules at runtime.

[0007] 4. Rigid Development and Deployment Process: Application developers must have the concrete implementations of all dependent libraries during the development phase, making it impossible to separate program logic development from underlying driver / algorithm development, thus reducing the efficiency of parallel development. It also makes it difficult to manage the authorization of specific library usage.

[0008] Dynamic link libraries (DLLs / SOs) are widely used in general computing to achieve modularity. However, these general mechanisms have two fundamental drawbacks when applied to the highly deterministic and highly reliable special domain of programmable logic controllers (PLCs):

[0009] 1. Lack of an endogenous, deterministic security model:

[0010] The core of general dynamic linking is address resolution, and its failure typically results in program loading aborts or runtime crashes. This "hard failure" mode is unacceptable for industrial control systems that require continuous operation. While some real-time operating systems (RTOS) can load shared libraries, the linking mechanism itself does not provide a predictable "soft failure" handling capability that integrates with PLC scan execution models (such as EN / ENO logic). It cannot guarantee that the main body of the PLC program can still run safely and only gracefully degrade at the functional level when linking fails.

[0011] 2. The linking process lacks domain-specific semantic verification capabilities:

[0012] The standard linking process is a purely symbolic string matching process; it does not understand or handle metadata that is critical to the industry. For example, it cannot natively execute critical business rules such as "verifying component version compatibility" or "verifying function usage authorization" during linking. These verifications must be handled by the application itself after linking, which not only increases the complexity of the application but also fails to provide security guarantees during critical stages of linking, leaving incompatible or unauthorized code at risk of being incorrectly loaded and executed.

[0013] Therefore, there is an urgent need in this field for a novel dynamic linking method specifically designed for PLCs that deeply integrates deterministic safety models with semantic verification at link time. Summary of the Invention

[0014] The technical problem this application aims to solve is that the static linking mode of PLC in the prior art is too rigid, while the general dynamic linking technology lacks a built-in deterministic safety model and semantic verification capability that is integrated with the PLC execution model, and cannot directly meet the stringent requirements of industrial control for high reliability and high security.

[0015] Therefore, the purpose of this application is to provide a dynamic linking method and system specifically designed for PLC environments. This solution, through the collaboration of the compiler and runtime environment, integrates deterministic safety checks and rich semantic verification into the core stage of the linking process, thereby achieving flexible decoupling and secure updates of software components while ensuring industrial-grade real-time performance and security.

[0016] To achieve the above objectives, this application provides the following technical solution:

[0017] In a first aspect, this application provides a dynamic linking method for a programmable logic controller, comprising the following steps:

[0018] During the compilation phase, the dynamic link instructions embedded in the PLC program source code are parsed to generate a link metadata table containing component identifiers, version constraints, and symbol names. This table is used to store address placeholders for the calling target and stub functions with embedded safe execution logic.

[0019] During the system initialization phase, the runtime environment executes a process that includes a verification sub-phase and a submission sub-phase. The verification sub-phase locates software components based on the linked metadata table and performs at least version constraint verification. After verifying all components to be linked, it determines whether a fatal linking error has occurred according to a preset failure handling strategy: if it has, the program is prevented from entering the real-time execution phase and diagnostic information is output; if it has not, the callable entry references of all verified components are atomically filled into their corresponding address placeholders.

[0020] During the real-time execution phase, when a call occurs, the stub function makes an indirect call through the callable entry reference if the enable input is true and the address placeholder is filled; otherwise, the call is blocked and a predefined failure handler is executed, which is used to place the system in a determined safe state.

[0021] A further optimization is that the dynamically linked object includes a function or a data object, and the callable entry reference is correspondingly a function call reference or a data access reference.

[0022] A further optimization is that the authorization verification includes at least one of the verifications of license status, hardware binding, or validity period, and if the verification fails, the execution of the submission sub-stage is blocked and diagnostic information is recorded.

[0023] A further optimization is that the version constraint verification is used to parse the version requirement in the metadata into a range expression and match it with the actual version of the software component. If they do not match, the process is rejected from entering the submission sub-stage.

[0024] A further optimization is that the method further includes performing runtime updates on the software components during the real-time execution phase, wherein the runtime update specifically includes the following steps:

[0025] The link update operation is encapsulated as a real-time task scheduled by the runtime environment scheduler according to a preset priority;

[0026] During the execution of a real-time task, it is determined whether the execution duration of the real-time task exceeds a preset time budget;

[0027] If the real-time task times out or fails, the update is aborted and a rollback operation is performed.

[0028] A further optimization is that the predefined failure handling procedure includes:

[0029] Perform control flow safety operations, which include at least setting the enable output to false; and perform system-level diagnostic operations, which include at least calling an interface provided by the runtime environment to log a diagnostic event containing error context information.

[0030] A further optimization is that the atomic filling method is suitable for updating multiple scattered address placeholders.

[0031] A further optimization is that the link metadata table also includes a failure policy flag for defining the importance level of components; and during the system initialization phase, the runtime environment performs differentiated processing based on the failure policy flag.

[0032] Secondly, this application provides a dynamic linking system for a programmable logic controller, characterized in that it is used to implement the dynamic linking method for a programmable logic controller as described above; the system includes:

[0033] A compilation unit is used to parse the dynamic link instructions embedded in the PLC program source code to generate a link metadata table containing component identifiers, version constraints and symbol names, which is used to store address placeholders for the calling target and stub functions with embedded safe execution logic.

[0034] An initialization management unit is configured to execute a two-phase initialization process, including a verification sub-phase and a submission sub-phase, upon program startup. The verification sub-phase locates software components based on the linked metadata table and performs at least version constraint checks. After verifying all components to be linked, it determines whether a fatal linking error has occurred according to a preset failure handling strategy: if so, it prevents the program from entering the real-time execution phase and outputs diagnostic information; if not, it atomically populates the callable entry references of all verified components into their corresponding address placeholders.

[0035] An execution control unit is configured to execute the stub function during a real-time scan cycle and, based on the link status of the enable input signal and the address placeholder, safely decide whether to execute the indirect call or set the enable output signal to false.

[0036] A further optimization includes a runtime update management unit, which schedules runtime link update requests as real-time tasks with priority and time budget, and can perform rollback operations when a task times out or fails.

[0037] Compared with the prior art, this application has the following advantages and beneficial effects:

[0038] It decouples the PLC program logic from the specific function implementation, enhances the portability and platform independence of the code, and allows some platform-related APIs to be directly encapsulated in the device firmware;

[0039] It supports upgrading or fixing functions by updating runtime components without recompiling and downloading the entire PLC program, significantly reducing downtime;

[0040] Standardized functions can be developed independently of the final application and encapsulated as independent runtime components, which can be dynamically linked and shared by multiple PLC programs;

[0041] An optional authorization verification mechanism can be used to manage the authorization and control the license for the use of core or advanced functional components;

[0042] Through comprehensive stub function logic and RTE linking error handling mechanism, program crashes caused by linking failures are effectively prevented, ensuring the stability and security of system operation.

[0043] Using program annotations, stub code, and metadata insertion, the dynamic loading process is completed by simple lookup via RTE and replacement of the call address. The runtime overhead is extremely low and fixed, with good real-time performance. It is not dependent on the operating system and has low hardware requirements.

[0044] An innovative dynamic linking framework for PLC programs is provided, which achieves runtime parsing and binding of PLC programs and external function implementations through the collaborative work of the compiler and runtime environment. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the exemplary embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0046] Figure 1 A flowchart illustrating a real-time dynamic linking method for a programmable logic controller provided in an embodiment of this application;

[0047] Figure 2 A flowchart illustrating the dynamic linking and execution of a PLC program provided in this application embodiment;

[0048] Figure 3 A flowchart of the compilation stage provided for embodiments of this application;

[0049] Figure 4 A flowchart of the runtime linking phase provided for embodiments of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the embodiments and accompanying drawings. The illustrative embodiments and descriptions of this application are only for explaining this application and are not intended to limit this application.

[0051] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0052] API: Application Programming Interface;

[0053] CPU: Central Processing Unit;

[0054] DLL: Dynamic Link Library;

[0055] EN: Enable;

[0056] ENO: Enable Output;

[0057] GOT: Global Offset Table;

[0058] I / O: Input / Output module;

[0059] IEC: International Electrotechnical Commission;

[0060] MMU: Memory Management Unit;

[0061] OS: Operating System;

[0062] PLC: Programmable Logic Controller;

[0063] POU: Program Organization Unit;

[0064] RTE: Run-Time Environment;

[0065] SO: Shared Object, shared library;

[0066] Stub: Stub function;

[0067] In this application, the term 'callable entry reference' should be interpreted broadly, encompassing not only direct memory addresses pointing to target functions or data (i.e., function pointers or data pointers), but also any indirect identifiers that can ultimately resolve to the target function or data, such as handles, object IDs, or indexes in a specific table. Essentially, it refers to any information entity that the runtime environment can use to perform indirect calls or accesses.

[0068] Firstly, such as Figure 1 As shown, this application provides a dynamic linking method for a programmable logic controller, including the following steps:

[0069] Step S1: During the compilation stage, the dynamic linking instructions embedded in the PLC program source code are parsed to generate a link metadata table containing component identifiers, version constraints, and symbol names, which is used to store address placeholders for the calling target and stub functions with embedded safe execution logic; wherein, the dynamic linking instructions are specific format instructions that are used to parse the PLC program source code to mark the program organization units to be linked and carry link metadata.

[0070] Step S2: Load the PLC program and enter the system initialization phase before entering the real-time scanning loop. First, enter the verification sub-phase. The runtime environment (RTE) locates the software components based on the link metadata table and performs at least version constraint verification. After verifying all components to be linked, determine whether a fatal link error has occurred according to the preset failure handling strategy. If a fatal link error has occurred, prevent entry into the real-time execution phase and output diagnostic information. If no fatal link error has occurred, allow the program to continue loading and running after downgrading the functionality of the failed components and enter the submission sub-phase. Atomicity submission fills all the callable entry references of the verified components into their corresponding address placeholders at once.

[0071] Step S3: If initialization is successful, the PLC will officially start the real-time scanning cycle and enter the real-time execution phase. In the real-time execution phase, when a call occurs, the stub function will be indirectly called through the callable entry reference if the enable input (EN) is true and the address placeholder has been filled. Otherwise, the call will be blocked and the enable output (ENO) will be set to false and a safe default value will be output.

[0072] Based on the aforementioned dynamic linking method for programmable logic controllers (PLCs), this application provides an innovative PLC dynamic linking framework. Through the collaboration of the compiler and runtime environment, it decouples program logic from functional implementation, thereby enhancing code portability and platform independence. This framework supports encapsulating standardized functions into independent runtime components, allowing for functional upgrades or repairs by updating components without recompiling the entire program, significantly reducing downtime. Through authorization verification, comprehensive stub functions, and an atomic linking error handling mechanism, it effectively prevents program crashes caused by linking failures, ensuring system security. Furthermore, this solution, based on program annotations and metadata insertion technologies, has extremely low runtime overhead and is not dependent on any specific operating system, providing a highly real-time and highly secure dynamic linking solution.

[0073] In one embodiment, developers can use predefined dynamic linking instructions in the source code of IEC 61131-3 to mark program organization units (POUs) that need to be dynamically linked. These instructions carry metadata required for linking, mainly including component identifiers, version constraints, and optional symbol names. The component identifier is used to uniquely identify the name or identifier of the runtime function component that provides the POU implementation. The version constraint is the version requirement for the component to ensure compatibility. The symbol name is the actual function name exported by the POU in the target component. If not specified, it can default to the name of the POU in the source code.

[0074] In one embodiment, the dynamically linked object in step S1 includes a function or a data object, and the callable entry reference is correspondingly a function call reference or a data access reference.

[0075] To implement the aforementioned dynamic linking mechanism, this application makes key enhancements to the traditional PLC compiler. When this dedicated compiler parses the dynamic linking instructions in the source code, it does not directly generate specific implementation code for the marked POU, but instead constructs a specific intermediate structure to support runtime binding. This structure specifically includes the following core elements:

[0076] POU Interface Definition: The compiler generates data structure definitions that describe the POU memory layout and function interface declarations with their call signatures, establishing a standard for subsequent calls.

[0077] Function address placeholder: The compiler defines a global variable as a function address placeholder and initializes it to an "unlinked" state. This placeholder will be replaced with the actual function's entry address at runtime.

[0078] Embedded security logic stub function: The compiler generates a stub function as the proxy entry point for the POU. All calls to the POU are redirected to this stub function, which is responsible for executing critical security logic: First, it verifies the validity of the enable input (EN); then it checks the linking status of the address placeholders; if the linking is correct, it indirectly calls the actual function implementation; if the linking fails, it executes security fallback logic, including setting the enable output (ENO) to invalid and returning a preset safe value, thereby ensuring the deterministic behavior of the system in abnormal states.

[0079] Link Metadata Table: The compiler creates a structured static data table (i.e., the link metadata table), where each record corresponds to a tagged POU and records all metadata (component identifier, version constraints, symbol names) parsed from the dynamic link instructions embedded in the PLC program source code, as well as a reference that can locate the corresponding function address placeholder.

[0080] In one embodiment, the license verification in step S2 includes at least one of the verifications of license status, hardware binding, or usage validity period, and if the verification fails, the execution of the submission sub-stage is blocked and diagnostic information is recorded.

[0081] In one embodiment, the version constraint verification in step S2 parses the version requirements in the metadata into a range expression and matches it with the actual version of the software component. If they do not match, the process is rejected from entering the submission sub-stage.

[0082] In one embodiment, in step S2, the diagnostic information output when the verification fails includes:

[0083] The error message includes the POU name, target component identifier, and reason for failure, such as component not found, authorization failure, version mismatch, or symbol not found.

[0084] In one embodiment, when loading the PLC program in step S2, the runtime environment (RTE) assumes the responsibility of the dynamic linker, and its linking process is as follows:

[0085] First, read and parse the linker metadata table generated during the compilation phase;

[0086] Subsequently, RTE will traverse each record in the table and perform the linking operation in turn. Its core task is to locate the corresponding function provider component within its jurisdiction based on the component identifier in the record. These components can be external shared library files, RTE's built-in functional modules, or API sets registered by other modules at runtime.

[0087] Once the component is located, RTE performs a series of critical verifications to ensure the legitimacy and security of the link. First, it performs optional authorization checks based on preset policies to confirm that the current runtime environment has the right to use the component. Next is a mandatory version check, which compares the actual version number of the component with the version constraints specified in the metadata to ensure version compatibility.

[0088] After all verifications pass, RTE will search for and resolve the actual address of the target function within the component based on the symbol name, and finally write this address into the address placeholder reserved in advance at the call site to complete the linking.

[0089] With the traversal and parsing task now complete, RTE can begin scheduling and running the PLC program after completing other loading tasks.

[0090] In one embodiment, the present invention also provides a configurable, tiered initialization failure handling strategy to achieve a balance between maximum security and maximum availability. This strategy is implemented by adding a failure policy flag to each dynamic linker entry in the linker metadata table during the compilation phase. This flag can define the external software component as one of two types:

[0091] Critical components: Failure to load such components (e.g., drivers that control the core motion axes, safety logic modules) is considered an unacceptable failure that would jeopardize system safety.

[0092] Non-critical components: The failure of such components (e.g., a logging module for data reporting, a status monitoring function for human-machine interface display) does not affect core control security.

[0093] Based on this, the runtime environment (RTE) executes differentiated error handling logic in the verification sub-phase of step S2 as follows:

[0094] When a component marked as "critical" fails during the verification process (such as not found, authorization failure, version mismatch, etc.), RTE will immediately abort the entire PLC program loading process, prevent it from entering the execution phase, and report precise, critical-level diagnostic information.

[0095] When a component marked as "non-critical" fails verification, RTE will not abort the loading process, but will perform functional degradation: it will keep the address placeholder corresponding to the component in an "unlinked" state, log a non-fatal warning or error message, and allow the PLC program to continue loading and enter real-time operation.

[0096] This mechanism ensures that any subsequent calls to this failed non-critical component during the real-time execution phase (step S3) will be automatically and gracefully handled by the built-in safety logic of its stub function (i.e., when EN is true, ENO will also be set to false because the address is not linked), thus achieving a "soft failure" without interrupting the core task.

[0097] In a more specific embodiment, during the real-time execution phase in step S3, the source code's call to the POU is routed to a stub function, which is configured to execute the following core logic flow:

[0098] Handle PLC-specific execution enable logic (such as EN / ENO). If the enable input is invalid, return directly; if the enable input is valid, continue executing the subsequent link parsing process.

[0099] By querying the dynamic symbol table or metadata records, determine whether the current function component has completed address resolution and check whether the corresponding resolvable address entry is still in the "unlinked" state;

[0100] If the entry has been resolved, the actual function is passed and invoked using the address stored in the entry; if it has not been resolved (indicating linking failure), safe fallback logic is executed, such as setting an error status and returning a default value, and disabling the enable output signal.

[0101] In one embodiment, the method further includes performing runtime updates on the software components during the real-time execution phase, the runtime update specifically including the following steps:

[0102] The link update operation is encapsulated as a real-time task scheduled by the runtime environment scheduler according to a preset priority;

[0103] During the execution of a real-time task, it is determined whether the execution duration of the real-time task exceeds a preset time budget;

[0104] If the real-time task times out or fails, the update is aborted and a rollback operation is performed.

[0105] In one embodiment, in step S3, atomic commit is completed through a one-time batch atomic write operation or a double-buffered switching mechanism.

[0106] The instructions, parameters, and variable names used in this embodiment are merely examples and do not constitute a limitation of this application.

[0107] like Figure 2As shown, the following provides a complete embodiment of the dynamic linking process, using ST language as the IEC 61131-3 source code language and C language as the generated intermediate language for description. However, this is not the only limitation of this application. Those skilled in the art will understand that the core ideas of this application are also applicable to generating other types of intermediate representations (such as LLVM IR), other high-level languages ​​(such as Rust), assembly language, or specific target bytecode.

[0108] Write the source code:

[0109] The developer wrote a function block called DeviceReader_DB to read data from an external device. To dynamically link it to a runtime component called IO.Drivers, the developer added a fictitious dynamic linking directive before its definition:

[0110] { DYNAMIC_BIND COMPONENT_ID="IO.Drivers" COMPATIBILITY="^2.1" SYMBOL="Read_Device_v2"}

[0111] FUNCTION_BLOCK DeviceReader_DB

[0112] VAR_INPUT

[0113] Channel: UINT;

[0114] END_VAR

[0115] VAR_OUTPUT

[0116] Value: REAL;

[0117] Status: INT;

[0118] END_VAR (*Other action statements and expressions within the function block are ignored*)

[0119] END_FUNCTION_BLOCK

[0120] compilation stage, such as Figure 3 As shown:

[0121] The compiler parses the DYNAMIC_BIND instruction and extracts the component identifier "IO.Drivers", the version constraint "^2.1" and the symbol name "Read_Device_v2".

[0122] In the compilation artifacts, a data structure definition is generated for DeviceReader_DB.

[0123] At the same time, the following will be generated in the compilation output:

[0124] A function address placeholder: static void* g_func_DeviceReader_DB_entry = NULL;

[0125] A stub function, DeviceReader_DB_StubBody(...), internally checks the EN signal status and determines if g_func_DeviceReader_DB_entry is NULL. If not NULL, it passes parameters to g_func_placeholder_DeviceReader and calls it. Simultaneously, calls to the DeviceReader_DB function block instance are redirected to the stub function DeviceReader_DB_StubBody, completing the insertion of the call logic.

[0126] Finally, add an entry to the link metadata table with the following content: { "DeviceReader_DB", "IO.Drivers", "^2.1", "Read_Device_v2", &g_func_DeviceReader_DB_entry}, to pass the information required for dynamic loading to the RTE.

[0127] runtime linking phase, such as Figure 4 As shown:

[0128] After the runtime environment (RTE) loads the PLC program, it first reads and parses the linker metadata table generated during the compilation phase. Then, the RTE locates the corresponding software components within the runtime environment based on the component identifiers (such as "IO.Drivers") recorded in the table.

[0129] After successfully locating the component, RTE performs two key checks in sequence:

[0130] License verification: The system checks the usage permissions of the target component. If the component requires authorization but the verification fails (e.g., the license is invalid), the program loading will be terminated immediately.

[0131] Version constraint verification: The system compares the actual version number of the component with the version range specified in the metadata. If the versions are incompatible, the loading process will also be aborted.

[0132] Only after all the above verifications pass will RTE search for the specified exported symbol within the target component. Upon successful resolution, the obtained function memory address is written to the corresponding address placeholder, completing the dynamic linking process.

[0133] If an error occurs during verification or parsing, RTE determines whether it constitutes a fatal link error based on the preset failure handling strategy, and then decides whether to abort the entire program loading or allow the program to continue running after functional degradation.

[0134] This process, through layered verification and atomic commits, ensures that dynamic links provide flexibility without sacrificing the reliability and security requirements of industrial control systems.

[0135] The linking mechanism for EN / ENO instructions provided in this application ensures semantic consistency between function enabling and state passing during dynamic linking. Simultaneously, an automatic termination strategy is introduced to prevent control logic malfunction due to abnormal component loading, thus improving system reliability. Furthermore, by integrating the GOT (Global Offset Table, a link metadata table used to record external symbol addresses during dynamic linking) with stub functions, efficient redirection of external function calls is achieved. This allows library function updates to be completed without recompiling the main program, significantly reducing the complexity of industrial field maintenance and downtime. The organic integration of these PLC-specific mechanisms not only enhances the applicability of dynamic linking in real-time control environments but also produces synergistic enhancements in deployment flexibility and operational stability.

[0136] Secondly, this application also provides a compiler for generating dynamically linkable PLC programs, used to implement the dynamic linking method for programmable logic controllers as described above; the compiler includes:

[0137] The instruction parsing module is used to parse the dynamic link instructions embedded in the PLC program source code during the compilation stage, and extract component identifiers, version constraints and symbol names;

[0138] The code generation module is used to generate stub functions and function address placeholders corresponding to the target program organization unit in response to the dynamic linking instructions. The stub functions have embedded PLC safe execution logic.

[0139] The metadata table generation module is used to create a link metadata table, which contains metadata parsed from the dynamic linking instructions and records references to the function address placeholders.

[0140] Thirdly, this application provides a runtime environment for a programmable logic controller (PLC) to implement the dynamic linking method for a PLC as described above; the runtime environment includes:

[0141] The linker module is used to read and parse the linker metadata table generated by the compiler after loading the PLC program during the system initialization phase; locate the software components based on the table, and perform authorization and version constraint verification; after the verification is passed, the callable entry reference of the corresponding symbol is obtained.

[0142] The atomic submission module is used to atomically fill the callable entry reference into the corresponding address placeholder only when all link entries have passed verification and parsing.

[0143] The safe execution module is used to make indirect calls through the stub function during the real-time execution phase when the enable input is true and the address placeholders are filled; otherwise, the call is safely blocked and the default value is returned.

[0144] Fourthly, this application provides a dynamic linking system for a programmable logic controller, which is a complete product consisting of a front-end tool (editor) and a back-end execution engine (runtime environment) for implementing the dynamic linking method for a programmable logic controller as described above; the system includes a compilation unit, an initialization management unit, and an execution control unit;

[0145] The compilation unit is used to parse the dynamic linking instructions in the source code and generate a compilation artifact containing a linking metadata table, address placeholders, and stub functions that embed the PLC's safe execution logic.

[0146] The initialization management unit is used to execute a two-stage initialization process when the program starts. The two stages include a verification sub-stage and a submission sub-stage. The verification sub-stage is used to perform authorization, version verification and address resolution. The submission sub-stage is used to perform a deterministic address submission operation after successful verification.

[0147] The execution control unit is used to execute the stub function during the real-time scan cycle and, based on the link status of the enable input signal and the address placeholder, safely decide whether to execute the indirect call or set the enable output signal to false.

[0148] In one embodiment, a runtime update management unit is also included, which is used to schedule runtime link update requests as real-time tasks with priority and time budget, and to perform rollback operations when the task times out or fails.

[0149] The runtime update management unit provided in this embodiment is a functional extension module of the runtime environment (RTE). It works in conjunction with the real-time scheduler, linker and memory manager in the RTE, and aims to transform a potentially time-consuming and uncertain update operation into a deterministic atomic operation that is harmless to the real-time system.

[0150] In a more specific embodiment, the runtime update management unit mainly consists of several logical parts: an update request interface, an offline preparation and verification area, a linked task encapsulation unit, and a state management and rollback unit.

[0151] The update request interface is responsible for receiving component update instructions from external sources. These instructions include the binary data of the new component, the target component identifier, and related deployment strategies.

[0152] The offline preparation and verification area is an independent memory area and execution context, used to perform complete preloading and verification of new component packages without affecting real-time tasks. The verification process here is completely consistent with the verification sub-stage of the system initialization phase, including license verification, version constraint verification, symbol resolution, etc.

[0153] Once the new component successfully passes all verifications in the offline area, the link task encapsulation unit is responsible for encapsulating the final "address switching" operation into a lightweight, high-priority real-time task. The core content of this task is extremely simple: replace the old address in the address placeholder with the newly resolved address.

[0154] Before initiating an update, the State Management and Rollback Unit backs up the valid addresses in all currently affected address placeholders. This backup constitutes the "verified state before the update." If the update task fails for any reason (such as timeout), this unit is responsible for performing a rollback operation, which atomically writes the backed-up old addresses back to the corresponding address placeholders, restoring the system to its stable state before the update.

[0155] When the system is in the real-time execution phase, a safe runtime update process is as follows:

[0156] When the runtime update management unit receives an update request, it loads the new component in the offline preparation area and executes the complete verification process. This stage does not affect real-time scanning. If verification fails, the update is rejected and an error is reported.

[0157] Once the new component passes offline verification, the system enters the update task encapsulation phase, where the linked task encapsulation unit creates a real-time task with a preset high priority. Simultaneously, the RTE allocates a strict time budget to this task (e.g., no more than a few hundred microseconds) to prevent it from encroaching on the main control task's CPU time.

[0158] RTE's real-time scheduler executes this high-priority linking task at an appropriate time (e.g., between two scan cycles), with the runtime update management unit timing and monitoring its execution. The core operation of the update task is to perform one or more atomic write operations, pointing address placeholders to the function entry points of the new component. To ensure the absolute atomicity of the address write process, the scheduler temporarily enters a critical execution state when executing this high-priority linking task. In this state, other tasks, especially the main PLC scan task, are prohibited from preempting the CPU until all address placeholders have been successfully updated. Since this process involves only extremely fast memory write operations, the duration of this critical execution period is strictly controlled at the microsecond level, thus preventing the dangerous state of 'partial linking' without affecting the overall determinism of the system.

[0159] If the task completes successfully within the time budget, the update is successful. When the system calls the POU in the next scan cycle, it will seamlessly use the functionality of the new component and begin reclaiming the resources of the old component.

[0160] If the task times out or any abnormality occurs during execution, the monitoring mechanism will immediately trigger a rollback operation. The state management unit will restore the pre-backed-up original address to the placeholder. The entire system logic remains unchanged, ensuring the continuity and stability of the main control task.

[0161] This application also provides a readable storage medium.

[0162] The present application has a readable storage medium storing a real-time dynamic link program for a programmable logic controller, wherein when the real-time dynamic link program for the programmable logic controller is executed by a processor, the steps of the real-time dynamic link method for the programmable logic controller as described above are implemented.

[0163] The method implemented when the real-time dynamic link program for the programmable logic controller is executed can be referred to in various embodiments of the real-time dynamic link method for the programmable logic controller in this application, and will not be repeated here.

[0164] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A dynamic linking method for a programmable logic controller, characterized in that, The method comprises the following steps: In the compiling stage, dynamic linking instructions embedded in the PLC program source code are parsed to generate a linking metadata table containing component identifiers, version constraints and symbol names, address placeholders for storing call targets and a stub function with security execution logic embedded therein; In the system initialization stage, a process including a verification sub-stage and a commit sub-stage is executed by the runtime environment, wherein the verification sub-stage locates software components according to the linking metadata table and performs at least version constraint checking, and after verification of all components to be linked is completed, it is determined whether a fatal linking error is constituted according to a preset failure handling strategy: if yes, the program is prevented from entering the real-time execution stage and diagnostic information is output; if no, the callable entry of all verified components is filled into the corresponding address placeholder in an atomic manner; In the real-time execution stage, when a call occurs, the stub function performs indirect calling through the callable entry reference when the enable input is true and the address placeholder is filled, otherwise, the call is prevented and a predefined failure handling program is executed to put the system into a determined safe state.

2. The dynamic linking method for programmable logic controller according to claim 1, wherein, The objects of dynamic linking include function or data objects, and the callable entry reference is a function call reference or a data access reference accordingly.

3. The dynamic linking method for programmable logic controller according to claim 1, wherein, The authorization permission check includes at least one of checking of license status, hardware binding or use validity period, and when the check fails, the execution of the commit sub-stage is prevented and diagnostic information is recorded.

4. The dynamic linking method for programmable logic controller according to claim 1, wherein, The version constraint check is used to parse the version requirement in the metadata as a range expression and match it with the actual version of the software component, and if the match fails, the commit sub-stage is refused to enter.

5. The dynamic linking method for programmable logic controller according to claim 1, wherein, The method further comprises runtime updating of software components in the real-time execution stage, which specifically comprises the following steps: The linking updating operation is encapsulated as a real-time task scheduled by a runtime environment scheduler according to a preset priority; During execution of the real-time task, it is determined whether the execution duration of the real-time task exceeds a preset time budget; If the real-time task is timed out or failed, the updating is aborted and a rollback operation is performed.

6. The dynamic linking method for programmable logic controller according to claim 5, wherein, The predefined failure handling program includes: performing a control flow safety operation which at least includes setting the enable output to false; and performing a system-level diagnostic operation which at least includes calling an interface provided by the runtime environment to record a diagnostic event containing error context information.

7. The dynamic linking method for programmable logic controller according to claim 1, wherein, The filling in an atomic manner is applicable to updating multiple dispersed address placeholders.

8. The dynamic linking method for programmable logic controller according to claim 1, wherein, The linking metadata table further includes a failure strategy marker for defining component importance levels; and in the system initialization stage, the runtime environment performs differential processing according to the failure strategy marker.

9. A dynamic linking system for a programmable logic controller, characterized by The system comprises: a compiling unit for parsing dynamic linking instructions embedded in the PLC program source code to generate a linking metadata table containing component identifiers, version constraints and symbol names, address placeholders for storing call targets and a stub function with security execution logic embedded therein; An initialization management unit is configured to perform a two-stage initialization process including a verification sub-phase and a commit sub-phase at program startup; wherein the verification sub-phase locates software components according to the linking metadata table and performs at least version constraint checking, and after completing verification of all components to be linked, determines whether a fatal linking error is constituted according to a preset failure handling strategy; if so, the program is prevented from entering a real-time execution phase and diagnostic information is output; if not, the callable entry of all verified components is filled into the corresponding address placeholder in an atomic manner; and An execution control unit is configured to execute the stub function in a real-time scanning period, and according to the enabling input signal and the linking state of the address placeholder, safely decides whether to execute the indirect call or set the enabling output signal to false.

10. The dynamic linking system for programmable logic controllers according to claim 9, characterized in that, A runtime update management unit is further included, configured to schedule a runtime linking update request as a real-time task with a priority and a time budget, and perform a rollback operation when the task times out or fails.

Images