Method for performing incremental compiling and hot updating on program in real-time system

Abstract

The invention relates to the field of industrial automation control and real-time systems, and discloses a PLC incremental compiling and hot updating method based on a data stream and time stream mixed graph, which comprises the following steps: in a development environment, performing differential calculation based on a stored compiling reference line and a modified source program workpiece set, determining dirty sub-graphs influenced by changes, and determining the data stream and time stream mixed graph according to the dirty sub-graphs; generating a hot update package; the compilation datum line comprises a complete data stream and time stream mixed graph intermediate representation and a full-quantity node hash table; and in a runtime environment, receiving and verifying the hot update package, constructing an updated program mirror image in an isolated update temporary storage area, dynamically verifying the behavior consistency of the updated program mirror image through shadow execution and equivalence verification, and atomically switching to the updated program mirror image after verification is passed. According to the automatic state transition mechanism, updating of the complex function block is simplified, and human errors are reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of industrial automation control and real-time systems, and in particular to a method for incremental compilation and hot update of programs in real-time systems. BACKGROUND

[0002] Currently, mainstream PLC development platforms have supported the "online change" or "hot update" function. These functions allow developers to modify and download programs without completely stopping the PLC.

[0003] However, the existing online change technology generally has the following deep limitations:

[0004] 1. Coarse granularity of change analysis: Online change is usually performed in units of program blocks (POU) or tasks. When a POU is modified, the system often cannot accurately analyze its impact range, which may result in unnecessary replacement of a larger range of code, increasing the risk and system burden.

[0005] 2. Lack of a unified formal model: Change analysis is mostly based on text / structure comparison of source program artifacts or symbol tables, lacking a unified intermediate representation that can describe data dependencies and real-time constraints (such as task period, execution order). This makes it difficult to discover timing-related potential problems (such as race conditions, period overruns) in the compilation phase.

[0006] 3. Insufficient verification mechanism, security relies on experience: The safety of updates mainly depends on the static checks of the compiler and the experience of the developer. The system lacks a mechanism to dynamically verify whether the update will introduce unintended behavior at runtime before switching. A small logic error can cause abnormal output and trigger production accidents.

[0007] 4. Simple state migration processing: For the internal state (variables) of the modified function block, the existing technology mostly uses the simple memory retention (Retain) strategy. When the data structure changes (such as adding, deleting, or modifying variables), intelligent and safe state migration cannot be performed, which may cause data inconsistency or program errors.

[0008] Therefore, there is an urgent need for a new technical framework that can achieve more accurate, safer, and more intelligent PLC program hot update, fundamentally overcoming the above-mentioned defects of existing technologies. SUMMARY

[0009] To solve the above problems, the application provides a method for incremental compilation and hot update of programs in a real-time system, a PLC incremental compilation and safe hot update framework based on a "data flow-time flow" mixed graph, which, through innovative intermediate representation (IR) and compilation-run-time collaborative mechanism, significantly improves the accuracy and safety of the update compared with the prior art.

[0010] The application is implemented by the following technical solutions:

[0011] The application discloses a method for incremental compilation and hot update of programs in a real-time system, comprising:

[0012] In the development environment, differential calculation is performed based on the stored compilation baseline and the modified source program artifact set to determine dirty subgraphs affected by changes, and a hot update package is generated; the compilation baseline contains a complete data flow and time flow mixed graph intermediate representation and a full node hash table; the hot update package contains verification metadata for defining the equivalence judgment rules of external observable variables;

[0013] In the runtime environment, the hot update package is received and verified, an updated program image is constructed in an isolated update staging area, and equivalence verification is performed on the behavior of the updated program image and the current production program according to the verification metadata; after the verification passes, the updated program image is switched atomically.

[0014] As an optimization, the creation process of the compilation baseline comprises:

[0015] After the first full compilation of the PLC project and successful deployment, a compilation baseline is created and stored in the development environment; wherein the compilation baseline is a snapshot of the project of the current deployment version, comprising:

[0016] A complete data flow and time flow mixed graph intermediate representation, which is used to describe the logic, data and timing relationship of the project of the version;

[0017] A full node hash table, which records the hash value of each node in the mixed graph intermediate representation calculated according to its own logic and dependency relationship, as the digital fingerprint of the PLC project corresponding to the current deployment version.

[0018] As an optimization, the process of performing differential calculation based on the stored compilation baseline and the modified source program artifact set to determine the dirty subgraphs affected by changes comprises:

[0019] The mixed graph intermediate representation and the full node hash table contained in the compilation baseline are loaded;

[0020] According to the modified source program workpiece set, a new local graph is generated, and the hash values of the nodes in the new local graph are calculated. The hash values of the nodes in the new local graph are compared with the old hash values of the corresponding nodes in the compilation baseline, so as to identify the initial dirty nodes that are changed;

[0021] On the mixed graph intermediate representation, starting from the initial dirty node, pollution propagation analysis is performed along the data flow dependence edge and the time flow dependence edge, and all nodes directly or indirectly affected by the initial dirty node change are marked as dirty nodes;

[0022] All the marked dirty nodes and the edges between the dirty nodes constitute a subgraph, which is determined as the dirty subgraph.

[0023] As an optimization, the hot update package includes a manifest and a relocation and linking table; and can further include one or more of a code segment, a data segment, and a state transition stub, wherein the manifest contains target device information, a compilation baseline version based on which, memory requirements, and verification metadata for runtime equivalence checking;

[0024] The code segment contains linkable executable machine code compiled from the dirty subgraph;

[0025] The data segment is used to define the memory space layout and initialization value required for the new variable;

[0026] The relocation and linking table contains low-level update action instructions for the runtime environment to perform, for completing the linking of the code segment and the data segment in the update staging area and the address resolution of external symbols;

[0027] The state transition stub is a binary function generated by the compiler, which is used to migrate the valid state in the old data area to the new data area before atomic switching.

[0028] As an optimization, in the runtime environment, the hot update package is received and verified, and an updated program image is constructed in an isolated update staging area. The behavior consistency of the updated program image is dynamically verified through shadow execution and equivalence checking, and the specific process of atomically switching to the updated program image after verification is passed is:

[0029] The hot update package is received, and it is verified whether the baseline version carried in the manifest of the hot update package matches the current running program version. If it matches, the subsequent steps are continued; otherwise, the update is rejected;

[0030] According to the memory requirements in the hot update package, the memory required by the code segment and the data segment is allocated in the independent update staging area;

[0031] According to the relocation and linking table in the hot update package, linking of code and data is completed in the update staging area to build a runnable updated program image;

[0032] In a subsequent scanning cycle, the updated program image is executed using the same input snapshot as the production task to obtain its output;

[0033] According to the verification metadata in the hot update package, for each externally observable variable defined in the manifest, it is verified whether the output value of the production task is consistent with the output value of the updated program image; if the verification results of all externally observable variables are consistent in the last N scanning cycles, it is determined that the verification is passed, and the next step is entered, otherwise, the rollback path is entered, wherein N is a positive integer;

[0034] After the verification is passed, the state migration stub in the hot update package is called to migrate the data state, and the task entry point pointer in the task control block is atomically modified to switch to the updated program image.

[0035] As an optimization, the output of the production task and the output of the updated program image are variables in the set of externally observable variables; the set of externally observable variables includes physical output points and data variables mapped to external communication protocols.

[0036] As an optimization, the equivalence verification strategy is defined by the verification metadata, including at least one selected from:

[0037] Exact equality verification: requires the output values of the production task and the updated program image to be exactly the same in each verification cycle;

[0038] Value range tolerance verification: requires the absolute difference between the output values of the production task and the updated program image to be less than or equal to the tolerance threshold defined in the verification metadata;

[0039] Time domain tolerance verification: requires the difference in occurrence time of the same state jump event in the output of the production task and the updated program image to be less than or equal to the time tolerance window defined in the verification metadata.

[0040] As an optimization, the runtime environment for implementing safe hot update includes the following components working together:

[0041] An update manager for receiving the hot update package and driving the safe hot update process as a finite state machine;

[0042] A memory manager for managing heap memory, the memory manager including a memory allocator for allocating the update staging area;

[0043] A task scheduler for managing periodic scheduling of PLC tasks, the task scheduler being provided with a task control block for supporting atomic modification of a task entry point pointer;

[0044] An equivalence checker for comparing output of the production task with output of the updated program image according to the check metadata in the hot update package.

[0045] As an optimization, entering the rollback path specifically comprises:

[0046] The memory manager is instructed by the update manager in the runtime environment to release all memory resources allocated in the update staging area for this hot update;

[0047] Wherein, in the rollback process, all memory resources of the update staging area are released, while the code and data of the currently running production task remain unchanged; the system state is restored to the state before the hot update attempt without loss.

[0048] The application further discloses a system for performing incremental compilation and hot update on programs in a real-time system, which is used to perform the method.

[0049] The incremental compilation module is deployed in a development environment, and is used to perform differential calculation based on the stored compilation baseline and the modified source program artifact set in the development environment, to determine dirty subgraphs affected by changes, and to generate a hot update package; the compilation baseline comprises a complete data flow and time flow hybrid graph intermediate representation and a full-quantity node hash table; the hot update package comprises check metadata for defining equivalence judgment rules of external observable variables.

[0050] The safe hot update module is integrated in a runtime environment of a programmable logic controller, and is used to receive and verify the hot update package, to build an updated program image in an isolated update staging area, and to perform equivalence check on behaviors of the updated program image and the current production program according to the check metadata; after the check passes, the updated program image is switched to atomically.

[0051] The application further discloses a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the method.

[0052] The application further discloses a computing device, which comprises a memory, a processor and a computer program stored on the memory and executable on the processor, and the processor implements the method when executing the program.

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

[0054] The prior art is based on program blocks or modules for coarse-grained comparison of text or structure; and the present application uses a formalized compilation baseline (including a complete hybrid graph IR and a node hash table) as an explicit baseline to perform semantic hash difference at the graph level, thereby significantly improving accuracy. Change impact analysis is no longer based on POU, but through two-dimensional pollution propagation of data flow and time flow, to accurately locate the affected dirty sub-graphs, and to realize a leap in update granularity from block level to instruction level. This avoids the misoperation of irrelevant code, greatly reduces the update package size, and reduces the runtime disturbance to the production system.

[0055] The update instruction of the prior art often directly modifies the production environment; and the present application bridges the compilation and runtime through the hot update package, and the RTE only executes binary action instructions without the need to identify high-level graph semantics, thereby solving the graph-execution gap. At the same time, a shadow execution and a configurable equivalence checking mechanism are introduced, thereby bringing high safety. By constructing and testing a new image in an isolated staging area, and performing dynamic behavior comparison on external observable variables including time domain / value domain tolerance, verification is realized before switching, thereby intercepting a defective update before it affects physical devices, which is a proactive safety mechanism that cannot be matched by the prior art.

[0056] The present application completes the time-consuming linking and verification work in the staging area, and the final switching is only an atomic modification of the TCB pointer. This ensures the real-time performance of the system. The atomic switching time is extremely short, which can be on the order of magnitude of a scanning period, and the influence on the real-time performance of the system can be ignored, thereby fundamentally eliminating the period overrun caused by the update operation itself. In combination with the optional scheduling certificate in the HUP, the influence on the real-time performance can be predicted before the update.

[0057] The prior art simply handles the state migration of complex data structure changes or relies on manual operation; the present application automatically analyzes the new and old data layouts by the compiler and generates a state migration stub. This realizes intelligence and automation. The memory state migration is automatically and accurately completed before the atomic switching, without the need for shutdown and manual intervention, thereby simplifying the update of complex function blocks and fundamentally reducing the risk of human error.

[0058] Through the systematic integration of the above-mentioned technologies, the present application constructs a closed-loop update process with high precision and high safety. This promotes agile development and CI / CD in the industrial automation field. The PLC program update is transformed from a high-risk shutdown operation and maintenance operation to a low-risk and online regular release. This lays a technical foundation for establishing a continuous integration / continuous deployment pipeline similar to the IT field, significantly accelerates the speed of function iteration and defect repair, and improves production efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0059] The accompanying drawings, which are included to provide a further understanding of the embodiments of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the principles of the application. In the drawings:

[0060] Fig. 1 is a whole flow chart of the method of the present application;

[0061] Fig. 2 is an incremental compilation workflow chart of the present application;

[0062] Fig. 3 is a runtime RTE security hot update flow chart of the present application. DETAILED DESCRIPTION

[0063] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the embodiments and drawings, the illustrative embodiments of the present application and the description thereof are only used to explain the present application, and do not limit the present application.

[0064] In order to solve the deep-seated problems in the background art, the present application proposes a closed-loop technical solution in which a compiler and a runtime environment (RTE) work cooperatively. The core of the present application is that the compiler maintains a high-level project panoramic model (mixed graph IR) in a development environment, and generates a hot update package (HUP) containing low-level binary instructions based on the model, for a specially designed RTE which only understands machine code and a predetermined instruction set to perform safe and accurate online update.

[0065] Before introducing the specific embodiments, some terms to be involved in the present application are described.

[0066] 1. Mixed graph: represented as .

[0067] V: a node set, the elements of which are atomic units in a program, including but not limited to: variables, constants, operators, instances or calls of program organization units (POUs), tasks, and control flow elements.

[0068] E: a data flow edge set, representing the dependency relationship of data values from a producer node to a consumer node.

[0069] E: a time flow edge set, representing the timing constraint relationship of a program, including but not limited to: task ownership, execution order, and step-transition relationship in a sequential function chart (SFC).

[0070] 2. Node hash: a hash value of each node in the mixed graph The hash value H(v) of a node v is calculated as follows: .

[0071] logic(v): The operational logic or declarative semantics of the node.

[0072] sig(v): The type signature and interface signature of the node.

[0073] in_hashes(v): The ordered set of hash values of all incoming edges' source nodes. This definition ensures that the hash value can reflect the logic of the node itself and its context in the dataflow / timeflow topology.

[0074] 3. Dirty node: A node v is marked as a dirty node if its newly calculated hash value is not equal to the old hash value H(v) stored in the compilation baseline, i.e. .

[0075] 4. Pollution propagation analysis: An algorithm to determine the scope of change impact on the graph structure. This analysis starts from the initial set of dirty nodes and recursively propagates along the edges of the hybrid graph . When the semantics or timing dependency of a downstream node y is affected by the change of an upstream dirty node x, causing a possible change in its output or execution timing, the downstream node y is marked as a dirty node and added to the set until no new node is marked and the algorithm converges.

[0076] 5. Dirty subgraph: The subgraph induced by the final set of dirty nodes obtained by the pollution propagation analysis, denoted as . To ensure that this subgraph can be independently compiled and linked, the set also needs to include the necessary interfaces and entry nodes that enable these dirty nodes to form a minimal functional closure.

[0077] 6. Compilation baseline: The complete snapshot of the PLC project version that has successfully undergone a full compilation and deployment. Its content mainly includes: the complete hybrid graph G; the full set of node hash table ; and the symbol-address mapping table consistent with the executable machine code of this version.

[0078] 7. External observable variable set: The set of variables whose values are visible to the external world or can have external effects. This set is the comparison target for runtime equivalence checking and mainly includes: physical output image area (such as Q); memory area mapped to various communication channels (such as fieldbus, industrial Ethernet, OPC-UA, MQTT) (such as M, DB); if necessary, it can include persistent variables with Retain properties.

[0079] 8. Equivalence policy: comparison rules for external observable variable sets, generated by the compiler and delivered to the runtime environment with the hot update package. The policy is encapsulated in the verification metadata, and specific modes include:

[0080] Exact equality: requires the new and old values to be exactly the same bit by bit.

[0081] Value range tolerance: allows the difference between the new and old values of variables such as floating-point numbers to be within a specified tolerance range.

[0082] Time domain tolerance: allows a certain acceptable time lag or advance window between the outputs of the new and old code for Boolean state changes or numerical jumps.

[0083] At the same time, it should be understood that the present application is based on the following system model and boundary conditions:

[0084] Compilation-runtime responsibility separation: the core of the present application is the strict division of labor between the compilation end and the runtime environment. The compilation end is responsible for all high-level semantic analysis, differential calculation and hot update package generation; while the runtime environment only executes the machine code generated by AOT and interprets the low-level action instructions in the hot update package, without recognizing high-level semantics such as nodes and edges.

[0085] Deterministic task model: tasks in PLC systems have a deterministic cycle and priority, and are managed by task control blocks, the core of which is the task entry point pointer, which is the basis for atomic switching.

[0086] Safety and real-time guarantee: the system has watchdog and cycle budget mechanisms. To ensure real-time performance, shadow execution supports three strategies: time slicing, selective shadowing and multi-core parallelism. The entire update process follows the principle of "non-destructive modification", i.e. the code and data of the production environment are not affected before atomic submission, and any failure at any stage will trigger a safe rollback to ensure the system state is restored without damage.

[0087] On the basis of meeting the above conditions, the following embodiments are further described.

[0088] Next, the present application will be described through specific embodiments.

[0089] This embodiment 1 provides a method for incremental compilation and hot update of programs in real-time systems, as shown in Figs. 1-3 , comprising:

[0090] S1, incremental compilation process: in the development environment, based on the stored compilation baseline and the modified source program workpiece set, differential calculation is performed to determine the dirty subgraph affected by the change, and a hot update package is generated; the compilation baseline includes a complete data flow and time flow mixed graph intermediate representation and a full node hash table; the hot update package includes verification metadata for defining the equivalence judgment rule of external observable variables;

[0091] S2, safe hot update process: in the runtime environment, the hot update package is received and verified, the updated program image is constructed in the isolated update staging area, and the equivalence check of the updated program image and the current production program is performed according to the verification metadata; after the check is passed, the updated program image is switched atomically.

[0092] Next, the details of steps S1 and S2 are described.

[0093] In some embodiments, the creation process of the compilation baseline includes:

[0094] After the first full compilation of the PLC project and successful deployment, a compilation baseline is created and persisted in the development environment; wherein the compilation baseline is a snapshot of the project of the current deployment version, including:

[0095] S1.1, complete data flow and time flow mixed graph intermediate representation, which is used to describe the logic, data and timing relationship of the project of the version;

[0096] S1.2, full node hash table, which records the hash value of each node in the mixed graph intermediate representation calculated according to its own logic and dependency relationship, as the digital fingerprint of the PLC project corresponding to the current deployment version.

[0097] The present application first determines the calculation baseline of the difference.

[0098] Creation of the compilation baseline: after the first full compilation of a PLC project and successful deployment, the compiler not only outputs complete machine code. It also creates and persists a "compilation baseline" in the development environment. The baseline is a complete snapshot of the successfully deployed version, and its core content is:

[0099] a. Complete data flow-time flow mixed graph intermediate representation (IR): describes the logic, data and timing relationship of the project of the version.

[0100] b. Full graph hash table: Each node (variable, operation, POU call, etc.) in the hybrid graph has a hash value computed based on its own logic and dependencies. This hash table is the precise numerical fingerprint of the versioned project.

[0101] In some embodiments, the process of determining the dirty sub-graphs affected by the changes based on the stored compilation baseline and the modified source program artifact set comprises:

[0102] S1.3, loading and parsing the hybrid graph intermediate representation, the full graph hash table and the modified source program artifact set contained in the compilation baseline.

[0103] Load the hybrid graph intermediate representation G, the full graph hash table {H(v)} and the symbol-address mapping contained in the compilation baseline. At the same time, parse the modified source file set , construct a new local graph Glocal within the affected compilation unit, and bind it with the global type table and symbols in the baseline to maintain naming consistency.

[0104] S1.4, generate a new local graph according to the modified source program artifact set, calculate the hash value of the nodes in the new local graph, and compare the hash value of the nodes in the new local graph with the old hash value of the corresponding nodes in the compilation baseline to identify the initial dirty nodes that have changed.

[0105] For the nodes involved in the local graph Glocal generated in step S1.3, calculate their new hash values . The core of this algorithm is to combine the operation logic logic(v), the interface signature sig(v) and the ordered set of all incoming edge source node hash values in_hashes(v) to calculate the hash. Then, compare the newly calculated hash value with the old hash value H(v) of the corresponding node stored in the compilation baseline. The new hash value and the old hash value that are not consistent are the initial dirty nodes.

[0106] S1.5, on the hybrid graph intermediate representation, starting from the initial dirty nodes, conduct pollution propagation analysis along the data flow dependency edges and the time flow dependency edges, and mark all nodes affected directly or indirectly by the changes in the initial dirty nodes as dirty nodes.

[0107] By hash comparison, initialize the initial dirty node set . Among them, type signature change, control flow change, interface offset change, task ownership change, cross-task data synchronization point change, etc. will cause hash difference.

[0108] Subsequently, on the hybrid graph intermediate representation, starting from the initial dirty set Start, propagate along data flow edges according to the following pre-defined propagation rules along time flow edges Perform pollution propagation analysis:

[0109] along data flow edges :

[0110] Pure value propagation: the output of an upstream operation node changes, polluting all downstream consumer nodes that directly depend on the output.

[0111] Interface / type change: the interface or type signature of a node changes, polluting all call sites that invoke the node, requiring adaptation or recompilation.

[0112] along time flow edges :

[0113] Task attribute change: the task ownership, priority or period of a task changes, polluting all nodes that are related to the scheduling of the task.

[0114] SFC step sequence change: the step or transition condition in a sequential function chart changes, polluting all subsequent step conditions and action nodes.

[0115] This recursive propagation process continues until no new nodes are added to the dirty set, i.e., a convergence state is reached.

[0116] S1.6, determine the subgraph composed of all marked dirty nodes and edges between them as the dirty subgraph.

[0117] All dirty nodes after the pollution propagation analysis converges are recorded as Set and the subgraph composed of the nodes in Set and edges between them is the dirty subgraph.

[0118] Therefore, the differential calculation of the present application is based on an explicit, historical and complete snapshot of a successful version of compilation, ensuring the accuracy and consistency of the differential.

[0119] In some embodiments, the Hot Update Package (HUP) is a bridge connecting the compiler and the runtime, and is a highly structured, binary execution-oriented update plan. The present application solves the gap between the model and the execution environment by reducing the high-level graph semantic results to low-level binary instructions. The RTE is designed only for AOT machine code, and only needs to identify and execute the instructions defined in the HUP, without understanding high-level concepts such as nodes, edges, etc.

[0120] The compiler side lowers the graph results to binary level update plan, and the RTE only needs to recognize the following structures: Manifest, Code Segments, Data Segments, Relocation & Linking Table, and State Transition Stub.

[0121] 1. The Manifest contains target device information, the based compilation baseline version, memory requirement, and check metadata for runtime equivalence check.

[0122] The target device information and the based compilation baseline version together form the header information.

[0123] Target device information: includes target PLC model and hardware architecture.

[0124] Baseline identification: the based compilation baseline version number and checksum, used to ensure that the patch matches the current running version and prevent incorrect application.

[0125] Memory requirement: accurately lists the memory size of the code segment and data segment required for temporary storage in this update.

[0126] Equivalence policy: a list of external observable variables and their corresponding check metadata. This metadata defines comparison rules such as exact equality, value range tolerance (floating point or time domain tolerance (change time window), providing comparison instructions for the runtime (RTE) checker.

[0127] Scheduling certificate: optional scheduling certificate containing the worst-case execution time or duty cycle budget of the task, for the RTE to evaluate the impact of the update on real-time performance.

[0128] 2. The Code Segments contain the linkable executable machine code blocks obtained by compiling the dirty sub-graphs These are pure, directly loadable into memory and executable instructions, corresponding to all modified dirty node logic.

[0129] 3. The Data Segments are used to define the memory space layout and initialization values required for newly added or extended variables in this update.

[0130] 4. The Relocation & Linking Table is the core of HUP, containing low-level update action instructions for the runtime environment to perform, used to complete the linking of code segments and data segments in the update temporary area and address resolution for external symbols. Typical instructions include:

[0131] ACTION_ALLOC_CODE(size)→addr_staging: Allocate code memory of specified size in staging area.

[0132] ACTION_WRITE_CODE(addr_staging, blob): Write compiled machine code blob to staging area at specified address.

[0133] ACTION_ALLOC_DATA(id, size, init_blob): Allocate data memory for specified variable and initialize it.

[0134] ACTION_PATCH_CALL(site_addr, new_target_addr_staging): Patch function call site address to jump to new target in staging area.

[0135] ACTION_REPLACE_TASK_ENTRY(task_id, new_entry_addr_staging): Replace entry point of specified task to new code address.

[0136] ACTION_REGISTER_EQ_POLICY(var_id, policy_struct): Register equivalence checking policy for specified variable.

[0137] ACTION_CALL_STUB(stub_entry, args...): Call state migration stub function.

[0138] 5、The state migration stub (State Migration Stub) is a tiny binary function generated by the compiler. It is called before atomic switching according to the mapping relationship between the old and new data structures, and is responsible for safely copying or converting the valid state in the old data instance to the corresponding position in the new data area.

[0139] In summary, through the design of the hot update package, the compiler undertakes all complex high-level analysis and accurately translates it into specific low-level binary update plans that can be directly understood and executed by the RTE, thereby achieving safe and accurate incremental updates.

[0140] The RTE in the present application is an execution environment specially designed for real-time control and safe updating, which internally contains key components such as an update manager (as a finite state machine), a memory manager (including an update staging area allocator), a task scheduler (managing TCB list), an equivalence checker, etc. They work together to complete the following safe hot update process.

[0141] Update Manager, for receiving the hot update package and driving the safe hot update process as a finite state machine; as the overall commander of the hot update process, it is a finite state machine responsible for receiving the HUP, driving the entire update process, and making the final "commit" or "rollback" decision.

[0142] Memory Manager, for managing the heap memory of the PLC, including a memory allocator for allocating the update staging area; it contains a special "staging area" allocator to ensure that the memory allocated for updates is physically isolated from the current active production code until the last moment.

[0143] Task Scheduler, for managing the periodic scheduling of PLC tasks, provided with a task control block for supporting atomic modification of task entry point pointers; its core data structure is a list of task control blocks (TCB), each containing the entry point address, priority, period, and other information of the task. The scheduler of the present application is designed to safely and atomically modify these TCBs.

[0144] Equivalence Checker, for comparing the output of the production task with the output of the updated program image according to the check metadata in the hot update package. This is a special module responsible for comparing the new and old values of the specified "externally observable variables" at the end of each scan period according to the metadata provided by the HUP.

[0145] In some embodiments, the detailed workflow of safe hot update is as follows:

[0146] S2.1, receiving and checking

[0147] The update manager receives the hot update package and verifies whether the baseline version loaded in the manifest of the hot update package matches the current running program version (it can also verify whether the target architecture, baseline version number, and checksum loaded match), if they match, go to S2.2, otherwise, immediately reject the update and return an error code.

[0148] S2.2, resource staging

[0149] The memory manager allocates the memory required for the code segment and data segment in the independent update staging area according to the memory requirements (i.e. code / data staging area size requirements) in the hot update package. This staging area is logically marked as non-executable and invisible to the outside, ensuring isolation from the production environment.

[0150] S2.3, Patch application and linking

[0151] According to the relocation and linking table in the hot update package, the linking of code and data is completed in the update staging area to build a runnable updated program image; the update manager interprets and executes the relocation and linking table in the HUP one by one in the update staging area. This process includes writing code segments and data segments, completing symbol resolution and function call point patching, and registering external observable variables and their equivalence strategies for the verifier to use. After this stage is completed, an executable but inactive updated program image is built in the staging area.

[0152] S2.4, Shadow execution

[0153] In the subsequent scanning period, using the same input snapshot as the production task, the updated program image is executed, and all outputs of the updated program image are written into the shadow output memory area.

[0154] In each related task period, the system starts the shadow execution according to the predetermined strategy:

[0155] Time slicing: first run the production task (old code), then reuse its input snapshot to immediately run the shadow task (new code), and write its output to the shadow output area.

[0156] Selective shadowing: to improve efficiency, only run the code paths affected by the dirty subgraph.

[0157] Multi-core parallelism: on a multi-core PLC, the shadow task is scheduled to idle cores to execute in parallel with the production task. The entire shadow execution process is strictly monitored, and the total time cannot exceed the task period budget or the watchdog threshold.

[0158] S2.5, Equivalence verification

[0159] According to the verification metadata in the hot update package, for each external observable variable defined in the list, verify whether the output value of the production task is consistent with the output value of the updated program image; if the verification results of all external observable variables are consistent in the next N scanning periods, it is determined that the verification is passed, and the next step is entered, otherwise, the rollback path is entered, where N is a positive integer.

[0160] At the end of each period or time window after shadow execution, the equivalence verifier is triggered. It compares the old and new values of external observable variables (such as physical output Q, mapped memory area M / DB, etc.) according to the equivalence strategies registered in the HUP. The strategies include:

[0161] Exact equality: suitable for Boolean, integer, time, etc.

[0162] Value range tolerance: applicable to floating-point numbers, requires , is the value of the variable calculated by the updated program image in shadow execution; is the value of the same variable calculated by the current production task in the same scan cycle. is the value range tolerance, a real number greater than zero, which is pre-set by the developer according to the control accuracy and engineering experience before compilation, and is packaged in the verification metadata of the HUP.

[0163] Time domain tolerance: allows an acceptable time lag window between the old and new outputs for a Boolean edge or state change , is the observed time difference. Refers to the actual time interval between the old code output and the new code (shadow) output for the same state change event (such as an output point changing from OFF to ON). Usually measured in units of scan cycles. is the time domain tolerance, a positive integer representing the maximum allowed time difference (e.g., 1 or 2 scan cycles). It is also pre-set by the developer and packaged in the verification metadata of the HUP.

[0164] The update manager maintains a continuous success counter. When the number of consecutive successes reaches the pre-set value N, it is determined that the update is "stable" and the verification is passed; any failure will reset the counter and trigger a rollback.

[0165] S2.6, atomic commit

[0166] After the verification is passed, the state migration stub in the hot update package is called to migrate the data state, and the task entry point pointer in the task control block is atomically modified to switch to the updated program image.

[0167] In some embodiments, entering the rollback path specifically is:

[0168] The memory manager is instructed by the update manager in the runtime environment to release all memory resources allocated in the update staging area for this hot update;

[0169] wherein, during the rollback process, all memory resources of the update staging area are released, and the code and data of the currently running production task remain unchanged; the system state is restored without loss to the state before the hot update attempt.

[0170] That is, when a HUP is downloaded to the PLC, the update manager is activated and strictly executes the following six stages:

[0171] Phase 1: Reception & Validation

[0172] a. The Update Manager receives the HUP and first reads the header information in its Manifest.

[0173] b. It strictly compares the "Baseline Version Number and Checksum" in the HUP with the version number of the program currently running, as recorded by the RTE itself.

[0174] c. If not matching, the update is immediately rejected and an error code is returned, preventing the application of a faulty patch. If matching, it proceeds to the next phase.

[0175] Phase 2: Resource Staging

[0176] a. The Update Manager requests from the Memory Manager, based on the memory requirements in the HUP Manifest, all code segment and data segment memory needed in the "Update Staging Area".

[0177] b. This staging area is logically "non-executable" and "inaccessible", completely independent from the currently running production code.

[0178] Phase 3: Patch Application & Linking in Staging Area

[0179] a. The Update Manager starts interpreting and executing the "Relocation & Linking Table" in the HUP, one instruction at a time. All operations are confined to the Update Staging Area.

[0180] b. For example, for the ACTION_UPDATE_CALL(address, new_target) instruction, it does not modify the instruction at address in the current production code, but builds a new, replacement function or code block in the staging area, and fills it with the correct jump address new_target.

[0181] c. Upon completion of this phase, a complete, independently runnable, updated copy of the program is ready in the "Update Staging Area".

[0182] Phase 4: Shadow Execution

[0183] a. The Update Manager registers a temporary, "shadow task" with the Task Scheduler, associated with the task being updated.

[0184] b. At the beginning of the next scan cycle, the task scheduler will invoke the entry point of the "shadow task" (i.e. the entry point of the new code in the "update staging area") immediately after the original production task has finished executing, using the same input snapshot.

[0185] c. All outputs generated by the execution of the shadow task are written to a temporary "shadow output memory area" without touching the real physical I / O or communication buffers.

[0186] Phase 5: Configurable Equivalence Checking:

[0187] a. The equivalence checker is invoked by the update manager immediately after the shadow task has finished executing.

[0188] b. The checker takes the value of each target variable from the production memory area and the shadow output memory area according to the "list of externally observable variables" in the HUP manifest and the "check metadata".

[0189] c. It decides according to the metadata whether to perform a bit-by-bit exact comparison or a comparison with time / value domain tolerance.

[0190] d. The update manager maintains a "counter of consecutive successful checks". If a check fails, the counter is reset to zero. Only when the counter reaches a pre-set value N (e.g. 5 consecutive cycles), the update is considered stable and safe.

[0191] Phase 6: Final Decision: Atomic Commit or Safe Rollback:

[0192] Commit Path:

[0193] a. After N consecutive successful checks, the update manager enters the commit procedure.

[0194] b. It first invokes the state migration stub function provided in the HUP. This function is responsible for safely copying the relevant variable values from the old data area to the new data area in the "update staging area".

[0195] c. Subsequently, the update manager issues an atomic switch instruction of the highest priority and non-interruptable to the task scheduler.

[0196] d. Upon receiving the instruction, the task scheduler performs a very short critical section operation: it replaces the function pointer in the TCB that points to the entry point of the old code with a pointer to the entry point of the new code in the update staging area.

[0197] e. After the switch is complete, the update manager instructs the memory manager to mark the old code and data regions as recyclable, and the update staging region as the new production region. The update process is now complete.

[0198] Rollback Path:

[0199] If any failures occur during the validation phase, or errors such as resource shortages occur at any stage, the update manager will immediately enter the rollback procedure.

[0200] a. It issues an instruction to the memory manager to release the entire update staging region.

[0201] b. Since no modifications have been made to the TCB, code, or data of any production environment prior to this point, the system state naturally and losslessly reverts to the state prior to the update. The entire hot update attempt is declared a failure, leaving no side effects.

[0202] In simple terms, the hot update implementation process is as follows:

[0203] Compilation Side:

[0204] 1. Load the baseline and modification sources; construct the partial graph and calculate the new hash;

[0205] 2. Generate the initial dirty set and perform pollution propagation; obtain the dirty subgraph;

[0206] 3. Re-compile only the dirty subgraph; generate HUP (code / data / linking / migration / validation metadata).

[0207] Runtime:

[0208] 4. The RTE checks the HUP for consistency with the baseline; apply the patch in the staging region;

[0209] 5. Start shadow execution (time-slicing / selective / parallel), generate shadow output;

[0210] 6. Perform equivalence checking on externally observable variables (including tolerance strategies);

[0211] 7. Continuous N passes → migrate state → atomic replace TCB entry → mark new image as production state;

[0212] 8. Any failure → release staging region → production state unchanged (safe rollback).

[0213] The atomic commit path is as follows:

[0214] 1. Call the state migration stub in the HUP to map the valid state of the old data region according to the new and old layouts, copy or convert it to the new data region in the staging region.

[0215] 2. Enter the dispatch critical section, atomically replace the entry point pointer in the relevant task control block by the new mirror entry in the staging area.

[0216] 3. Mark the staging area as the new production area, and the old production area as recyclable. The update is successfully completed.

[0217] Safe rollback path:

[0218] At any stage (e.g. resource shortage, deadline timeout, equivalence unsatisfied, state migration exception), the update manager immediately enters the rollback procedure, releasing the entire update staging area. Since the production-state code and data have not been modified before, the system state is restored without loss. For typical failure cases (e.g. shadow execution timeout, long-term equivalence unsatisfied), the system can output a detailed difference report and record the on-site log for the developer to analyze.

[0219] Next, a specific case will be used to illustrate the method of the present application, which is to perform online field expansion on the core product recipe data structure shared by multiple tasks on a high-speed packaging production line.

[0220] This embodiment aims to prove that the present application can safely and non-disruptively complete a task that is extremely dangerous or even impossible for conventional PLC online change functions: online modification of a core data structure shared by multiple real-time tasks with different cycles.

[0221] 1. Scene description: an update task that poses a serious challenge to conventional online change functions:

[0222] 1.1. Application scenario: a high-speed automated pharmaceutical packaging production line that requires 7x24 hours of uninterrupted operation.

[0223] 1.2. Core control logic:

[0224] 1.2.1. Core data structure: a global structure named STRUCT_ProductRecipe that defines all key parameters of the current production batch.

[0225] TYPE STRUCT_ProductRecipe :

[0226] STRUCT

[0227] BoxLength_mm : LREAL; / / Package box length

[0228] SealTemp_C : LREAL; / / Heat sealing temperature

[0229] ProductionID : DINT; / / Production batch number

[0230] END_STRUCT

[0231] END_TYPE

[0232] VAR_GLOBAL

[0233] g_CurrentRecipe : STRUCT_ProductRecipe;

[0234] END_VAR

[0235] 1.2.2 Concurrent execution of multiple tasks:

[0236] a. Task_Motion_5ms: A high-speed motion control task with a 5-millisecond cycle. It reads g_CurrentRecipe.BoxLength_mm and g_CurrentRecipe.SealTemp_C to control the servo motor for precise carton forming and heat sealing.

[0237] b. Task_Logic_20ms: A regular logic task with a 20-millisecond cycle. It reads g_CurrentRecipe.ProductionID to control the inkjet printer to print the correct batch number on the packaging box.

[0238] 1.3 Hot update required: In order to comply with the new drug traceability regulations, a new field needs to be added to STRUCT_ProductRecipe to store encrypted QR code information without stopping the production line.

[0239] 1.3.1 Change requirement: Add a new field QRCode_Data :STRING

[64] to STRUCT_ProductRecipe;

[0240] 1.3.2 At the same time, a new function block call is added in Task_Logic_20ms, which will use this new QRCode_Data to drive a QR code laser marking machine.

[0241] 1.4 Why did the conventional approach fail?

[0242] 1.4.1 Any conventional PLC "online change" function will fail or be disabled in this scenario. This is because modifying the definition of STRUCT_ProductRecipe fundamentally changes the memory layout and size of this data type.

[0243] 1.4.2. The compiler detects that the "interface" or "signature" of all function blocks that use the g_CurrentRecipe variable (including all relevant code in Task_Motion_5ms and Task_Logic_20ms) has changed.

[0244] 1.4.3. The system cannot understand the internal logic of this change, it can only consider this as a "major incompatible change" and forces the user to perform a "stop PLC and full download". This will result in an expensive production line downtime. It cannot safely handle this restructuring of a cross-task shared data structure at runtime.

[0245] 2. Using the implementation steps of the invention: the impossible becomes possible.

[0246] A. Developer operations and incremental compilation

[0247] 1. Modification of code: the developer modifies the definition of STRUCT_ProductRecipe in the development environment, adding the QRCode_Data field. At the same time, code is added in Task_Logic_20ms to call the new function block.

[0248] 2. Triggering of incremental compilation: the developer clicks on "Incremental compilation and apply updates".

[0249] 3. Compiler performs deep semantic analysis (based on the compilation baseline):

[0250] 3.1. Identification of the change: the compiler compares the modified code with the compilation baseline. It first discovers that the hash value of the STRUCT_ProductRecipe definition has changed, marking it as "dirty".

[0251] 3.2. Contamination propagation:

[0252] 3.2.1. This dirty state propagates to the global variable g_CurrentRecipe.

[0253] 3.2.2. Then, it propagates to all nodes that read g_CurrentRecipe. This is the key:

[0254] 3.2.2.1. In Task_Motion_5ms, the compiler discovers that the logic that accesses BoxLength_mm and SealTemp_C has not changed itself, only the offset address in memory of these two fields has changed due to the data structure becoming larger.

[0255] 3.2.2.2. In Task_Logic_20ms, the logic to access ProductionID is again only about offset address change. The newly added code to access QRCode_Data is identified as a brand new logic.

[0256] 3.2.3. Generate dirty sub-graph: The final dirty sub-graph is very refined, it mainly contains: ① the type definition of STRUCT_ProductRecipe; ② the definition of global variable g_CurrentRecipe; ③ the reorganized machine instructions in Task_Motion_5ms that only involve memory address calculation and access; ④ the reorganized instructions in Task_Logic_20ms that involve memory access and the brand new machine code for the newly added QR code printing logic.

[0257] 4. Generate hot update package (HUP): The compiler generates a HUP, which contains:

[0258] 4.1. Manifest: declares the new memory requirement (for larger g_CurrentRecipe) and indicates the baseline version on which this update is based.

[0259] 4.2. Code segment: contains a small part of the reorganized / additional binary machine code generated for the two tasks above.

[0260] 4.3. Relocation and linking table: contains a series of low-level instructions, such as: ACTION_ALLOC_CODE(24576)→0x7000_0000

[0261] ACTION_WRITE_CODE(0x7000_0000, <blob A>)

[0262] ACTION_ALLOC_DATA(id=2203, size=8, init=<00..>)

[0263] ACTION_PATCH_CALL(site=0x4001_00AC, new_target=0x7000_0120)

[0264] ACTION_REPLACE_TASK_ENTRY(task_id=2, new_entry=0x7000_1000)

[0265] ACTION_REGISTER_EQ_POLICY(var_id=1001, policy={TIME_TOL, 200ms})

[0266] ACTION_CALL_STUB (stub = 0x7000_1F00, args = {old_data_ptr, new_data_ptr} ).

[0267] 4.4, State Migration Stub: A tiny piece of automatically generated binary code. Its function is: memcpy(new_recipe_addr, old_recipe_addr, old_recipe_size). That is, copy all data from the old recipe into the first half of the new recipe memory region.

[0268] B. RTE performs a safe hot update:

[0269] The RTE's update manager, upon receiving HUP, begins executing a six-phase safe protocol:

[0270] 1, Receive and Verify: Success, HUP matches the current running version.

[0271] 2, Resource Reservation: Successfully allocated memory in the "update staging area" to hold the new machine code and the new, larger g_CurrentRecipe variable.

[0272] 3, Patch Application and Linking: The RTE, using the linking table from HUP, constructs a complete, runnable, but not yet activated, new program image in the staging area.

[0273] 4, Shadow Execution: Task_Motion_5ms and Task_Logic_20ms begin executing the code from both the old and new versions in parallel. The old version continues to control the physical servo motors and the printhead, and the new version runs in shadow memory.

[0274] 5, Equivalence Verification:

[0275] 5.1, Verification Goal: The externally observable variable set, i.e., all physical I / O. In this example, the most critical are the servo motor position outputs controlled by Task_Motion_5ms, and the printhead I / O controlled by Task_Logic_20ms.

[0276] 5.2, Verification Process: Since the shadow code accesses BoxLength_mm, SealTemp_C, ProductionID with the exact same logic as the old code (only the memory offsets are different, but the compiler has handled that), and the new QRCode_Data field has not yet affected the outputs of these old logics, during shadow execution, the servo positions and printhead control signals produced by the new code are identical, cycle by cycle, to those produced by the old code.

[0277] 5.3, Check result: N consecutive period checks succeed. This proves in engineering that the re-computation of memory offset by the compiler is completely correct.

[0278] 6, Atomic commit:

[0279] 6.1, State migration: The update manager invokes the state migration stub provided in HUP, instantaneously copying the values in the old g_CurrentRecipe memory (e.g. length = 100.5, temperature = 120.0, batch number = 12345) to the newly allocated g_CurrentRecipe memory.

[0280] 6.2, Atomic switch: The update manager issues an instruction to the task scheduler to atomically point the function entry point pointers in the task control blocks (TCB) of Task_Motion_5ms and Task_Logic_20ms to the new code addresses in the "update staging area".

[0281] Done: From the next scan cycle, both tasks seamlessly start executing the new code. Task_Motion_5ms correctly reads data from the new memory offset, as does Task_Logic_20ms, and starts executing the newly added 2D code printing logic. The old memory is recycled.

[0282] This embodiment proves that, through the deep semantic analysis of the compiler (precise distinction between "logical changes" and "data layout changes") and the runtime verification mechanism of the RTE (ensuring that even such low-level changes as memory layout will not cause unexpected behavior), the invention successfully converts a high-risk, multi-task core data structure modification that cannot be handled by a conventional solution into a fully validated, safe and reliable online hot update that does not disturb production at all. This provides an effective and reliable technical solution for the online maintenance, upgrade and functional iteration of complex industrial equipment that requires continuous operation.

[0283] Embodiment 2 discloses an incremental compilation and hot update system for programs in real-time systems, for performing the incremental compilation and hot update method based on the mixed graph of data flow and time flow of embodiment 1, comprising:

[0284] The incremental compilation module is deployed in the development environment, and is used for performing differential calculation based on the stored compilation baseline and the modified source program workpiece set in the development environment, determining the dirty sub-graphs affected by the changes, and generating a hot update package; the compilation baseline includes a complete intermediate representation of the mixed graph of data flow and time flow and a full node hash table; the hot update package includes verification metadata for defining the equivalence judgment rules of external observable variables;

[0285] The security hot update module is integrated in a runtime environment of the programmable logic controller, and is configured to receive and verify the hot update package, build an updated program image in an isolated update staging area, and perform equivalence verification on behaviors of the updated program image and a current production program according to the verification metadata; and atomically switch to the updated program image after the verification passes.

[0286] Embodiment 3 discloses a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the method for incremental compilation and hot update of a program in a real-time system according to Embodiment 1.

[0287] Embodiment 4 discloses a computing device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the program to implement the method for incremental compilation and hot update of a program in a real-time system according to Embodiment 1.

[0288] The above detailed description further illustrates the purpose, technical solutions and beneficial effects of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for incremental compilation and hot updating of programs in a real-time system, characterized in that, include: In the development environment, differential calculations are performed based on the stored compilation baseline and the modified source program artifact set to determine the dirty subgraph affected by the changes and generate a hot update package; the compilation baseline contains a complete intermediate representation of the mixed data flow and time flow graph and a full node hash table; the hot update package contains verification metadata for defining the equivalence judgment rules of external observable variables; In the runtime environment, the hot update package is received and verified, the updated program image is built in the isolated update staging area, and the equivalence verification between the updated program image and the behavior of the current production program is performed based on the verification metadata. After successful verification, the system atomically switches to the updated program image.

2. The method for incremental compilation and hot updating of programs in a real-time system according to claim 1, characterized in that, The process of creating the compilation baseline includes: After the initial full compilation and successful deployment of the PLC project, a compilation baseline is created and persistently stored in the development environment; wherein, the compilation baseline is a snapshot of the project in the current deployment version, including: The intermediate representation of the complete data flow and time flow is used to describe all the logic, data, and timing relationships of this version of the project; A full node hash table, which records the hash value calculated by each node in the intermediate representation of the hybrid graph based on its own logic and dependencies, serves as the digital fingerprint of the PLC project corresponding to the current deployment version.

3. A method for incremental compilation and hot updating of programs in a real-time system according to claim 1 or 2, characterized in that, The process of determining the dirty subgraph affected by the change by performing differential calculations based on the stored compilation baseline and the modified source program artifact set includes: Load and parse the hybrid graph intermediate representation, full node hash table, and modified source program artifact set contained in the compilation baseline; A new local graph is generated based on the modified source program artifact set. The hash values ​​of the nodes in the new local graph are calculated. The hash values ​​of the nodes in the new local graph are compared with the old hash values ​​of the corresponding nodes in the compilation baseline to identify the initial dirty nodes that have changed. In the middle representation of the hybrid graph, starting from the initial dirty node, pollution propagation analysis is performed along the data flow dependency edge and the time flow dependency edge, and all nodes directly or indirectly affected by the change of the initial dirty node are marked as dirty nodes. The subgraph formed by all marked dirty nodes and the edges between the dirty nodes is defined as the dirty subgraph.

4. The method for incremental compilation and hot updating of programs in a real-time system according to claim 1, characterized in that, The hot update package includes a manifest and a relocation and linking table; it may further include one or more of code segments, data segments, and state transition stubs, wherein the manifest contains target device information, the compilation baseline version on which it is based, memory requirements, and verification metadata for runtime equivalence verification. The code segment contains linkable executable machine code compiled from the dirty subgraph; The data segment is used to define the memory space layout and initialization values ​​required for newly added variables; The relocation and linking table contains low-level update action instructions for the runtime environment to execute, used to link code segments and data segments and resolve the addresses of external symbols within the update staging area. The state transition stub is a binary function generated by the compiler to migrate the valid state in the old data area to the new data area before an atomic switch.

5. The method for incremental compilation and hot updating of programs in a real-time system according to claim 1, characterized in that, In the runtime environment, the hot update package is received and verified. An updated program image is built in an isolated update staging area. The behavioral consistency of the updated program image is dynamically verified through shadow execution and equivalence checks. After successful verification, the process of atomically switching to the updated program image is as follows: Receive the hot update package and verify whether the baseline version contained in the hot update package's manifest matches the currently running program version. If they match, continue with the subsequent steps; otherwise, reject the update. Based on the memory requirements in the hot update package, allocate the memory required for the code segment and data segment in the independent update staging area; Based on the relocation and linking table in the hot update package, the code and data are linked in the update staging area to build a runnable updated program image. In subsequent scan cycles, using the same input snapshot as the production task, the updated program image is executed to obtain its output; Based on the verification metadata in the hot update package, for each external observable variable defined in the list, verify whether the output value of its production task matches the output value of the updated program image; If the verification results of all externally observable variables are consistent within N consecutive scan cycles, the verification is considered successful and the process proceeds to the next step; otherwise, the process enters the rollback path, where N is a positive integer. After successful verification, the state transition stub in the hot update package is invoked to migrate the data state, and the task entry point pointer in the task control block is atomically modified to switch to the updated program image.

6. The method for incremental compilation and hot updating of programs in a real-time system according to claim 5, characterized in that, The outputs of the production task and the updated program image are variables in the set of externally observable variables; the set of externally observable variables includes physical output points and data variables mapped to external communication protocols.

7. A method for incremental compilation and hot updating of programs in a real-time system according to claim 4 or 5, characterized in that, The equivalence verification strategy is defined by the verification metadata and includes at least one of the following: Exact equality check: requires that the output values ​​of the production task and the updated program image be exactly the same in each check cycle; Value range tolerance verification: requires that the absolute difference between the output value of the production task and the updated program image be less than or equal to the tolerance threshold defined in the verification metadata; Time-domain tolerance verification: requires that the difference between the occurrence time of the same state transition event in the output of the production task and the updated program image is less than or equal to the time tolerance window defined in the verification metadata.

8. A method for incremental compilation and hot updating of programs in a real-time system according to claim 5, characterized in that, The runtime environment, designed to enable secure hot updates, includes the following components that work together: The update manager is used to receive the hot update package and drive the secure hot update process; A memory manager for managing heap memory, the memory manager including a memory allocator for allocating the update staging area; A task scheduler is used to manage the periodic scheduling of PLC tasks. The task scheduler has a task control block, which is used to support the atomic modification of the task entry point pointer. An equivalence checker is used to compare the output of the production task with the output of the updated program image based on the verification metadata in the hot update package.

9. A method for incremental compilation and hot updating of programs in a real-time system according to claim 8, characterized in that, The specific steps to enter the rollback path are: The update manager in the runtime environment instructs the memory manager to release all memory resources allocated for this hot update in the update staging area; During the rollback process, all memory resources in the update staging area are released, while the code and data of the currently running production tasks remain unchanged; the system state is restored to the state before the hot update attempt without loss.

10. A system for incremental compilation and hot updating of programs in a real-time system, used to execute the PLC incremental compilation and hot updating method based on a hybrid data flow and time flow graph as described in any one of claims 1-9, characterized in that, include: An incremental compilation module, deployed in the development environment, is used to perform differential calculations based on a stored compilation baseline and a modified set of source program artifacts in the development environment to determine the dirty subgraph affected by the changes and generate a hot update package. The compilation baseline includes a complete intermediate representation of the mixed data flow and time flow graph and a full node hash table. The hot update package includes verification metadata for defining the equivalence judgment rules for external observable variables. The secure hot update module is integrated into the runtime environment of the programmable logic controller. It is used to receive and verify the hot update package, build the updated program image in an isolated update staging area, and perform equivalence verification between the updated program image and the behavior of the current production program based on the verification metadata. After successful verification, the system atomically switches to the updated program image.

Images