Microkernel operating system industrial controller plc hot update control method and system

Abstract

The microkernel operating system industrial controller PLC hot update control method and system belong to the field of industrial controller, create a shadow instance in an isolated address space, and bind with a shadow I / O mirror and a shadow communication stack; a stop point is captured in a scanning period, the stop point is located between input sampling completion and output submission; running state information is obtained from a live instance, and is converted and delivered to the shadow instance; the shadow instance is accelerated or equal-speed pre-run in an isolated channel, and if verification is passed, the I / O channel is switched from the live instance to the shadow I / O mirror of the shadow instance at the next stop point; a certain period is continuously run in parallel, and if continuous running is qualified, the old instance is unloaded, and if an exception occurs, rollback is performed. Relying on the microkernel operating system, the shadow instance is practiced and switched under a controlled priority, real-time and determinacy are met, a time delay defect of period gap switching is overcome, and update and switching are atomically completed in a single or several scanning periods.

Description

Technical Field

[0001] This invention belongs to the field of industrial controllers, specifically a microkernel operating system industrial controller PLC hot update control method and system. Background Technology

[0002] When traditional PLC industrial controllers are running on production lines, modifications and upgrades to the application typically require shutdown, download, and reset, leading to production line interruptions and safety risks. Existing online modification methods mostly involve variable-level or small-scale function block replacements, making it difficult to achieve atomic-level switching across tasks and modules while ensuring real-time performance and determinism. Moreover, existing PLC controllers often employ an embedded monolithic kernel architecture, placing drivers, protocol stacks, and task management in kernel mode, lacking sufficient isolation and rollback mechanisms. This means that if a hot update fails, it may escalate into a system-wide failure. Furthermore, existing methods are time-consuming during version switching. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a method and system for hot-updating PLC application tasks, function block groups, communication protocol stacks or parameter sets without interrupting production cycle and without compromising real-time determinism.

[0004] The technical solution adopted by this invention to solve the above-mentioned technical problems is: a microkernel operating system industrial controller PLC hot update control method. The industrial controller adopts a microkernel operating system, and uses a PLC program running in the user mode of the microkernel operating system to control the operation of industrial equipment based on the collected data. During the operation of the industrial controller, hot update control is performed using the following steps:

[0005] (1) Prepare the target update package, which includes the updated version of the program or parameters, the interface contract and the migration script.

[0006] (2) Create a shadow instance in the microkernel operating system with an isolated address space. The shadow instance is built based on the updated version in the target update package and runs in parallel with the live instance using the current version. Create a shadow I / O image of the live I / O data and a shadow communication stack with a copy of the fieldbus protocol stack. Bind the shadow instance to the shadow I / O image and the shadow communication stack.

[0007] (3) Capture the stop point within the scanning cycle of the live network instance. The stop point is located between the completion of input sampling and the unsubmission of output. After capturing the stop point, record the timestamp and cycle phase of the current scanning cycle for timing alignment of the switching between the shadow instance and the live network instance.

[0008] (4) Obtain the running status information from the live instance and transfer it to the shadow instance after conversion according to the migration script.

[0009] (5) Run the shadow instance in the isolation channel at an accelerated or constant speed for a certain period of time, and perform consistency and real-time verification.

[0010] (6) If the verification is successful, the I / O channel will be switched from the live instance to the shadow I / O mirror of the shadow instance at the next blocking point, so that the shadow instance becomes the new instance and the original live instance becomes the old instance.

[0011] (7) Allow the old and new instances to continue running in parallel for a certain period of time and monitor their operation.

[0012] (8) If the new instance runs successfully during the monitoring period, the old instance will be uninstalled; if an abnormality occurs during the monitoring period, a rollback operation will be performed at the same stop point to switch the I / O channel back to the old instance.

[0013] In step (1), the target update package is stored in the version repository of the microkernel operating system. Signature verification, integrity verification and interface compatibility checks are performed in the user-mode version management service. The next step is allowed only if the update version is backward compatible or a migration script is provided.

[0014] Both the shadow I / O mirror of the shadow instance and the live I / O buffer of the live instance adopt a dual-buffering structure. The shadow I / O mirror includes a shadow input mirror and a shadow output mirror. The shadow input mirror and shadow output mirror are stored independently from the input buffer and output buffer of the live I / O buffer. The data stored in the shadow input mirror is the same as the data in the input buffer of the live instance, and the shadow output mirror stores the instruction data generated by the shadow instance. Switching from the live instance to the shadow instance or rolling back from the new instance to the old instance is achieved by switching the I / O channel to the shadow I / O mirror or the live I / O buffer.

[0015] After capturing the stop point, step (3) freezes the current input data in the shadow I / O mirror, prevents subsequent sampling data from overwriting the input data, and keeps the time base stable.

[0016] In step (4), the running status information obtained from the live network instance is converted based on the mapping rules in the migration script. Incompatible fields are converted and filled with default values ​​through the migration script, and then transferred to the shadow instance in batches through the zero-copy shared page or IPC of the microkernel operating system.

[0017] In step (5), the verification content includes the consistency of the calculation case, the maximum execution time per cycle and memory usage. The consistency of the calculation case is the deviation between the calculation results of the key variables and the actual network instance. The maximum execution time per cycle does not exceed the threshold set within the scanning cycle.

[0018] The shadow instance uses a virtual clock to pre-run at 2-5 times the speed of the live network clock. After completing a predetermined number of pre-run cycles, the virtual clock is adjusted to be at the same speed as the live network clock, and then the phase of the virtual clock of the shadow instance is aligned with the phase of the live network clock.

[0019] The shadow instance is pre-run with a lower priority than the live instance. When switching from the live instance to the shadow instance, the priority of the shadow instance is temporarily increased within a controlled time window to ensure the real-time nature of the switching operation.

[0020] In step (7), a health score is performed based on jitter, timeout rate, and abnormal event rate during the monitoring period to determine whether to commit a transaction to unload the old instance or to perform a rollback operation.

[0021] This invention also provides a microkernel operating system industrial controller PLC hot update control system employing the above-described control method. The control system includes an industrial controller running a microkernel operating system, wherein the user-mode deployment of the microkernel operating system includes:

[0022] Update coordinator: Used for stop point detection, instance switch orchestration, and transaction commit control;

[0023] State Migrator: Used for collecting and transforming the running status information of live instances and injecting it into shadow instances;

[0024] Version repository: Used for signing and storing update packages;

[0025] Health monitoring component: used to build a health scoring model, output a health score, and trigger commit or rollback commands;

[0026] Rollback Manager: Used to perform rollback operations and store the reasons for failures in the log system;

[0027] I / O services: Used to manage local I / O and remote fieldbus process data mirroring, maintain a double-buffered structure and handle data synchronization;

[0028] Fieldbus communication stack: Provides user-space protocol services and exposes data to the shadow communication stack through the PDO / SDO interface.

[0029] The beneficial effects of this invention are as follows: Based on the microkernel operating system, the application tasks, I / O services, and fieldbus stacks to be updated are isolated from each other, making it difficult for errors to propagate across boundaries during the update process. A shadow instance is created in parallel with the live instance within the isolated address space. During the pre-running period, the shadow instance does not actually communicate with the field devices. After a certain pre-running period and successful verification, it is switched over. In case of an anomaly, it can be quickly rolled back, with the rollback completed at the same stop point. The maximum latency does not exceed one scan cycle, avoiding program anomalies from affecting production. The selection of the stop point for switching avoids I / O data interruption and eliminates the need to wait for the cycle to end, resulting in shorter switching latency. Relying on the scheduling and isolation of the microkernel, the shadow instance is rehearsed and switched under controlled priority, satisfying real-time and deterministic requirements, overcoming the latency defects of inter-cycle switching, and enabling updates and switching to be completed atomically within one or several scan cycles.

[0030] Based on this, a shadow I / O mirror for the shadow instance is set up. The shadow I / O mirror is stored independently from the live I / O buffer of the live instance. When switching versions, only the I / O channel needs to be switched to the shadow I / O mirror. There is no need for batch memory copying, avoiding data transmission delay and realizing periodic atomic switching. There is no pulse disturbance to the field equipment during switching, which solves the I / O disturbance problem during switching.

[0031] This hot update control method and system is widely adaptable to various updates, supporting task-level, function block group-level, protocol stack-level, and parameter set-level hot updates, and is compatible with multiple fieldbuses and the IEC 61131-3 standard. Through version signing, sandbox restrictions, and a closed-loop health scoring system, update risks are reduced, ensuring security and controllability. No maintenance downtime is required during updates, shortening production line downtime and verification cycles. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the system architecture of the present invention.

[0033] Figure 2 This is a flowchart of the method of the present invention.

[0034] Figure 3 This is a diagram of the shadow instance switching state machine.

[0035] Figure 4 It is a timing diagram of the scan cycle and the switching time window.

[0036] Figure 5 This is a diagram illustrating the relationship between state transitions and data mapping. Detailed Implementation

[0037] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings and specific embodiments. The specific contents listed in the following embodiments are not limited to the technical features necessary to solve the technical problem of the present invention. Furthermore, the listed embodiments are merely a part of the present invention, and not all embodiments.

[0038] The industrial controller of this invention employs a microkernel operating system. This system, using a "minimal kernel + user-space services" model, retains the scheduler, IPC (inter-process communication), and basic memory management within the kernel, while drivers, file systems, networking, and higher-level services run in user space. This achieves strong isolation and controllable evolution through capability and message passing. The PLC program runs in the user space of the microkernel operating system, controlling the operation of industrial equipment based on collected data. The PLC hot-update control method is as follows: Figure 2 The steps shown are as follows:

[0039] (1) Version preparation and verification: Prepare the target update package and store it in the version repository of the microkernel operating system user space. The update package contains the update version task image of the program or parameter, function block description, interface contract, migration script (XML / JSON format, including state mapping rules) and rollback point definition.

[0040] For versioned interface contracts and compatibility, versioned IDL (Interface Definition Language) is used to describe message interfaces / service channels, data structures, and semantics. The compatibility rule is backward compatibility if the main version number is the same; if the main version numbers are different, a migration script must be provided. The data evolution rule is that newly added fields use optional default values ​​(e.g., newly added parameters are filled with 0 by default), and deleted fields require a mapping strategy (e.g., mapping old field values ​​to new fields or marking them as "obsolete").

[0041] Signature verification, integrity verification, and interface compatibility checks are performed within the user-mode version management service. Proceeding to the next stage is only allowed if the new version is backward compatible or a migration script is provided.

[0042] (2) Shadow Instance Creation: A shadow instance is created in the task manager of the microkernel operating system using an isolated address space. This shadow instance is built based on the updated version of the target update package and runs in parallel and in isolation with the existing network instance using the current version before the update. The shadow instance can independently generate control commands for industrial equipment based on the collected data. The shadow instance runs with the minimum necessary permissions (such as access to I / O image, message channel, log and audit permissions) to limit the impact of failures and ensure the controllability of subsequent pre-run and switchover. At the same time, a shadow I / O image and a shadow communication stack are established. The message channel and connection of the shadow instance are bound to the shadow I / O image and shadow communication stack using virtual channels to avoid direct interaction with the existing network instance.

[0043] The shadow I / O mirror serves as an I / O data buffer mirror for the shadow instance. Both the shadow I / O mirror of the shadow instance and the live I / O buffer of the live instance adopt a double-buffered structure. The shadow I / O mirror includes a shadow input mirror and a shadow output mirror. The shadow input mirror stores the collected data from field sensors, actuators, etc., and its stored content is identical to the input buffer data of the live instance, written during sampling. The shadow output mirror stores the instruction data generated by the shadow instance. The shadow input and shadow output mirrors are stored independently from the input and output buffers of the live instance, without affecting each other. In case of problems during version switching, a quick rollback can be performed without affecting the operation of field industrial equipment. Before the version replacement is completed, the field industrial equipment is controlled by the instructions in the output buffer of the live instance; data from the shadow output mirror is not sent to the industrial equipment. For example, the live instance corresponds to input buffer I_img_a and output buffer O_img_a, while the shadow instance corresponds to shadow input mirror I_img_b and shadow output mirror O_img_b. Before the version switch, the I / O channels point to the input buffer I_img_a and output buffer O_img_a of the live instance. During the version switch, simply changing the I / O channel binding addresses from I_img_a and O_img_a to I_img_b and O_img_b is sufficient to switch between the live instance and the shadow instance, eliminating the need for batch memory copying and avoiding data transfer latency.

[0044] The shadow communication stack is a user-mode copy of the fieldbus protocol stack (supporting EtherCAT / PROFINET / Modbus, etc.). The shadow communication stack is bound to the shadow I / O mirror. During the pre-run phase, it only receives shadow I / O data and does not communicate directly with field devices to avoid interfering with the existing network communication.

[0045] The shadow communication stack enables hot-swapping of the communication stack. The fieldbus driver and protocol stack run in microkernel user-space services, exposing process data (PDO) and service data (SDO) through standardized message interfaces. PDOs (Process Data Objects) are used for real-time transmission of high-frequency control data (such as real-time sensor values ​​and actuator control commands), with the transmission cycle synchronized with the PLC scan cycle. SDOs (Service Data Objects) are used for non-real-time configuration data (such as device parameter modifications and firmware version queries), transmitted using a request-response model. The shadow communication stack can perform pre-run drills by reading PDO / SDO data, and directly take over communication after a switch, ensuring a seamless protocol stack upgrade.

[0046] (3) Scan cycle stop point capture: During the scan cycle of the live network instance, identify the stop point used for version switching. The stop point is located between the completion of input sampling and the unsubmission of output, or at the boundary of the function block specified by the user (such as the gait switching point of the sequential control program).

[0047] This invention preferably selects the stopping point within the interval between input sampling and output submission, at which point the existing network instance has acquired complete input data and has not yet issued an output command. Switching versions at this stopping point only requires changing the next output calculation to be performed by the new instance (shadow instance). Since the old and new instances are based on the same input snapshot, the causal chain of "input → logic → output" is guaranteed not to be broken, avoiding I / O data interruption during switching, and eliminating the need to wait for the cycle to end, resulting in shorter switching latency.

[0048] After capturing the containment point, the input mirror and time base for the current cycle are frozen. The current shadow input mirror data in the shadow I / O mirror is locked, preventing subsequent sampling data from overwriting this input mirror data. The time base is kept stable (e.g., timers and counters are paused from updating). The timestamp and cycle phase φ of the current cycle are recorded. The timer / counter is injected into the shadow instance in the form of "frozen value + phase offset". The recorded cycle phase φ is used for subsequent timing alignment between shadow instances and live network instances, ensuring data and time consistency during state transitions.

[0049] (4) Status Acquisition and Mapping: Extract necessary runtime information (such as current timer value, counter cumulative value, register data, function block internal state, historical data window, etc.) from the live instance, and transfer the information to the shadow instance after data conversion according to the migration description in the migration script. The core content of the migration description includes status field mapping rules (such as the live instance "Timer1" corresponding to the shadow instance "Timer_new"), data type conversion instructions (such as 32-bit integer to 64-bit integer), and default value configuration (such as newly added fields being filled with 0 or process thresholds by default). For fields that are incompatible between the old and new versions (such as parameters that are not present in the old version but added in the new version), ensure the integrity of the shadow instance status through script-level type conversion (such as calling Lua / Python scripts to implement unit conversion and range scaling) or default filling (such as setting default values ​​according to process requirements). The converted data is transferred to the shadow instance in batches through the zero-copy shared page or IPC of the microkernel operating system.

[0050] The state graph mapping function (including data structure version compatibility) in the migration description is:

[0051]

[0052] in: This is a set of states for the new program version (including counters, timers, history windows, sequential gait, etc.). This is the original program version status set; This is a state mapping operator, which includes field matching, type conversion, and default fill logic. For migration script parameters (such as default values, conversion factors); This indicates a switch from an older to a newer data structure version (e.g., V1.0 → V2.0).

[0053] (5) Shadow instance pre-run: The shadow instance sets a virtual clock, allowing the shadow instance to pre-run for a certain period of time in the isolated channel at an accelerated speed (e.g., 2-5 times the live network speed) or at a constant speed (e.g., completing 1-3 pre-run cycles), and performs consistency and real-time verification. The verification content includes instance consistency, maximum execution time per cycle (WCET), and memory usage.

[0054] During constant-speed pre-running, the virtual clock speed is the same as the live network clock. The shadow instance directly reads the current frame of the shadow input mirror of the shadow I / O mirror, generates control commands through the logic operations of the shadow instance, and stores them in the shadow output mirror. During double-speed pre-running, the virtual clock advances at a speed of v=2-5 times. The shadow instance consumes the timestamped recorded dataset (historical data), the timeline is compressed at 1 / v, and all timers are driven by the virtual clock, enabling multi-cycle consistency verification to be completed in a shorter time.

[0055] The consistency of the calculation case refers to the deviation between the calculation results of key variables and the actual network instance. It can be verified by calculating the hash value of the core process variables (such as temperature, pressure, speed and other key control quantities) before and after the switchover.

[0056] If hash error If they are equal, then they are considered functionally equivalent. The hash value of the key variable before the switch. This is the hash value of the key variable after the switch. This represents a hash value error metric function (such as Euclidean distance). This represents the consistency tolerance threshold, for example, setting... This represents the typical tolerance threshold.

[0057]

[0058]

[0059] in This represents the set of key process variables before the switchover. This represents the set of key process variables after the switch, where K is the key variable selection set (defined by the user according to process requirements). Describe the hash function.

[0060] The maximum execution time per cycle does not exceed the threshold set within the scan cycle. During the pre-run period, the shadow instance only consumes recorded playback or mirror data. Recorded playback data refers to historical I / O data from the live network (such as sensor data from the past 10 cycles), while mirror data refers to a real-time copy of the current live network I / O (shadow I / O mirror data). It does not interact directly with field devices to avoid impacting production.

[0061] If the verification fails to meet the threshold, for example, if WCET exceeds 80% of the scan cycle, the update will be terminated and the live instance will be retained. If the verification passes, instance switching will be allowed.

[0062] (6) Atomic Switching: At the next stopping point, after the shadow instance and the live instance are time-aligned, the live instance is switched to the shadow instance, making the shadow instance the new instance and the original live instance the old instance. Output submission is taken over by the shadow instance, including the following operations:

[0063] Timing Alignment: For pre-running at a constant speed, align the phase of the shadow instance's virtual clock with the live network clock. The alignment condition is as follows: ,in, For phase difference, To set a threshold. At the next stopping point if If the limit is exceeded, the system will enter a waiting window to fine-tune the phase, ensuring that the output of the first frame after the switch is consistent with the phase of the existing network, thus avoiding periodic jitter.

[0064] In the case of accelerated operation, after the shadow instance completes M virtual cycles (M≥1), the virtual clock of the shadow instance is adjusted to be at the same speed as the live network clock. Then the shadow instance enters the phase waiting window and aligns the virtual clock phase with the live network clock phase at the next stopping point. The alignment conditions are the same as those in the above-mentioned constant speed pre-operation case.

[0065] I / O Mirror Switching: Version switching is only allowed after timing alignment. By changing the I / O channel pointer binding, the I / O channel is made to point to the shadow I / O mirror (e.g., the input is switched from I_img_a to I_img_b, and the output is switched from O_img_a to O_img_b), and the I / O channel is atomically switched from the live instance to the shadow instance in ≤0.1ms.

[0066] Message channel redirection: The microkernel message channel management and user-mode switching coordinator work together to redirect the communication connections of field devices and host computers to the shadow instance.

[0067] Real-time scheduling guarantee: Live instances use fixed task scheduling priority preemption and priority inheritance (core task priority ≥ 8). During the shadow instance pre-running phase, the shadow instance priority is lower than the live instance priority (e.g., priority = 4) to avoid consuming core resources. At the instant of switching from the live instance to the shadow instance, the shadow instance priority is temporarily increased within a controlled time window (same as the live instance, e.g., priority = 8) to ensure the real-time nature of the switchover operation. This temporary priority increase only occurs within the switchover time window (…). Within a controlled time window, after the switchover is complete, the system will revert to its normal priority (e.g., priority = 6) to prevent system instability caused by prolonged preemption. < , This refers to the PLC scan cycle.

[0068] (7) Transaction Commit and Monitoring: Allow the new and old instances to continue running in parallel for a certain period of time and monitor their operation. For example, the new and old instances can run in parallel for N monitoring periods (N=3-5, configurable). During the monitoring period, a health score is calculated based on jitter, timeout rate, and abnormal event rate.

[0069] The health scoring function is:

[0070] in, , , As weight, , The maximum execution time for a single cycle of a shadow instance. For PLC scan cycle, Indicates the timeout rate; , The jitter is before and after the switch. This indicates the maximum allowable jitter (usually 10% of the process limit). Indicates the abnormal event rate. Indicates the upper limit of allowed exceptions.

[0071] Over N consecutive cycles, determine whether the health score meets a set threshold, i.e. ,in For health score thresholds (e.g.) =0.6 is a typical threshold), and the update can be completed based on the health score results.

[0072] (8) If the health score results of N consecutive cycles meet the set threshold, and the new instance runs continuously and qualified during the monitoring period, the transaction can be committed, the old instance can be unloaded and resources released.

[0073] If an anomaly occurs during monitoring, for example If issues such as I / O data jitter exceeding limits occur, a rollback operation will be performed at the same stop point, switching the I / O channel back to the old instance, i.e., restoring the I / O channel pointer to its state before the switch. The shadow instance state will be revoked (memory cleared, virtual channel closed), and the reason for failure will be recorded (e.g., WCET limit exceeded, compatibility error). Maximum rollback time. This ensures that the equipment on site does not experience prolonged malfunctions.

[0074] Figure 3 The diagram shows the state machine for switching shadow instances. The states are: Idle; PreRun; Ready; Abort; Switch; Parallel; Rollback; and Commit.

[0075] To ensure the determinism and controllability of the switchover process, the switchover between shadow instances and live instances, as well as the rollback from new instances to old instances, must meet certain constraints, including:

[0076] 1. Real-time constraints:

[0077] 1.1 New instance execution and switching time constraints

[0078]

[0079] in, This represents the maximum execution time (WCET) of a shadow instance per cycle. To switch time windows, This refers to the PLC scan cycle.

[0080] 1.2 Rollback Time Constraints

[0081]

[0082] in, This refers to the rollback time.

[0083] 2. Jitter Constraint: Upper limit constraint on the difference in jitter before and after switching.

[0084]

[0085] in, , The jitter is before and after the switch. This indicates the maximum allowed jitter.

[0086] 3. Health scoring model and submission requirements:

[0087] 3.1 Health scoring function (value range: 0 for best, 1 for worst)

[0088]

[0089] The weights satisfy the normalization condition:

[0090]

[0091] 3.2 Instance Submission Requirements (must continuously meet monitoring cycle requirements):

[0092] And in It remains valid for several consecutive periods, among which... As the health score threshold, This refers to the number of monitoring cycles.

[0093] 4. Port rebinding and I / O mirroring timing model:

[0094] 4.1 Three-stage breakdown of switching time windows (closing - rebinding - refreshing)

[0095]

[0096] in:

[0097] The old connection closing time is used to close the communication connection between the live network instance and I / O devices and the host computer.

[0098] When rebinding a new connection takes time, the communication connection will be bound to the shadow instance.

[0099] : I / O cache refresh time, ensuring that the shadow instance's I / O cache data is up-to-date.

[0100] 4.2 I / O Mirrored Double-Buffered Pointer Switching (Only the pointer is changed during switching, no data is copied)

[0101]

[0102] in:

[0103] : Input read pointer (points to the currently read input buffer);

[0104] : Output write pointer (points to the currently written output buffer);

[0105] Double-buffered storage areas (buffer A and buffer B) only change the pointer direction when switching, without copying data.

[0106] 4.3 IPC (Inter-Process Communication) Throughput Constraints (Ensuring Efficiency of Batch State Transitions)

[0107]

[0108] in:

[0109] Minimum throughput capacity of the IPC channel;

[0110] The total amount of data required for state transition;

[0111] : Window duration of the state transition halt point.

[0112] This invention relates to a microkernel operating system industrial controller PLC hot update control system, comprising an industrial controller running a microkernel operating system, combined with... Figure 1 The system architecture includes the following components:

[0113] 1. Kernel-mode components, including:

[0114] Scheduler and time source: Provides deterministic scheduling (supports fixed priority preemptive scheduling) and high-precision clock (clock error ≤1μs) to provide a time reference for stop point capture;

[0115] Message channel management: Supports synchronous message passing, connection redirection, and capability control, enabling rapid switching between communication channels for new and old instances;

[0116] Memory management: Supports page-level sharing and copy-on-write (COW) to reduce memory overhead during state transitions.

[0117] 2. User-mode services and modules, including:

[0118] Update coordinator: Used for stop point detection, instance switch orchestration, and transaction commit control;

[0119] State Migrator: Used to collect runtime status information of live instances. Based on the state graph, it performs field mapping, unit conversion and default filling to transform the collected status information and inject the transformed status information data into shadow instances.

[0120] Version repository: Used for signing, verifying and storing update packages and metadata (such as version number and compatibility identifier), supporting differential transmission and multiple versions coexisting;

[0121] Health monitoring component: used to build health scoring models for WCET, jitter, and anomaly rate, output health scores and trigger commit or rollback commands;

[0122] Rollback Manager: Used to perform rollback operations and store the reasons for failures in the log system;

[0123] I / O services: Used to manage local I / O and remote fieldbus process data mirroring, maintain a double-buffered structure and handle data synchronization;

[0124] Fieldbus communication stack: Provides user-space protocol services and exposes data to the shadow communication stack through the PDO / SDO interface;

[0125] Security Sandbox: Performs static analysis (detects malicious code) and runtime restrictions (limits CPU / memory usage) on update packages to reduce security risks;

[0126] Audit and traceability: Record switching, rollback, and metrics;

[0127] APIs and toolchains: IDL generation, state graph generator, simulation and playback tools.

[0128] 3. Application layer, including:

[0129] IEC 61131-3 Task and Function Block Diagrams: Supports four programming languages: ST (Structured Text), LD (Ladder Diagram), FBD (Function Block Diagram), and SFC (Sequential Function Chart).

[0130] Scan Organizer: Defines a periodic sequence of "input sampling - logical operation - output submission", identifies and marks the stopping point;

[0131] Shadow instance: A replaceable task graph that runs in parallel with the live instance, with the ability to run in isolation and perform pre-run verification.

[0132] Example 1:

[0133] Based on the above, one embodiment of the present invention can be summarized as follows:

[0134] 1) Update package creation: Compile the newly added or revised task graph and function block set into a new version image, generate interface contract and migration script, calculate data structure hash, package and sign.

[0135] 2) Deployment and verification: Transfer the update package to the version repository and complete the signature and integrity verification; use IDL version tools to verify the compatibility of message interfaces / service channels and data types.

[0136] 3) Shadow Instance: Create a shadow instance in user space, bind the shadow I / O image and shadow communication stack, and enter the pre-running stage after startup; during the pre-running period, it is isolated from production I / O and only consumes recorded playback or image data.

[0137] 4) Stop Point Capture: The scan organizer sends a toggle signal after entering "input lock" in each cycle; the update coordinator freezes the input mirror and starts status acquisition accordingly.

[0138] 5) State Transition: The state transitioner reads the counters, timers, history windows, sequential gait and other information of the live instance, and injects them into the shadow instance after script conversion.

[0139] 6) Consistency exercise: The shadow instance executes M cycles (M≥1) in the isolation channel, recording WCET, memory curves and hashes of key variables; the health monitoring service outputs a score.

[0140] 7) Atomic Switching: Upon reaching a threshold, the microkernel operating system initiates connection redirection of message channels at the next stopping point: I / O write channels, alarm channels, and audit channels are switched to the shadow instance; the switching duration is controlled within... Inside.

[0141] 8) Transaction Commit: After continuously meeting the target for N monitoring periods (N is configurable), commit the transaction and unload the old instance; if any metric exceeds the limit, a rollback will be triggered.

[0142] 9) Rollback: When the switch fails or an abnormality is triggered, the old instance is pointed back at the same stop point to preserve the stability of the current output.

[0143] Typical configuration: , , ;

[0144] Evaluation threshold: , , Take 10% of the upper limit of the process;

[0145] IPC bandwidth: , suggestion

[0146] Typical scenarios for hot updates in this invention include:

[0147] 1) Cross-functional block group hot update: Update the formula and constraint logic of a certain production line, and use the state graph to migrate the key cache window to the new version to complete the periodic seamless switching.

[0148] 2) Protocol stack upgrade: Upgrade Modbus from v1 to v2 without downtime. The new stack is pre-run with a shadow channel and the timing is verified. The old stack is unloaded after the switch.

[0149] 3) Security policy adjustment: The overcurrent protection threshold can be adjusted online. The updated parameter set takes effect immediately and supports rollback.

[0150] The methods for handling boundaries and exceptions during the update process are as follows:

[0151] If the shadow instance WCET exceeds the budget threshold, the update is rejected;

[0152] If the state graph is missing key fields, a script to fill them in or a declaration that it cannot be hot-updated is required.

[0153] If the field I / O jitter exceeds the limit, it will automatically roll back and retry later;

[0154] If the version signature is invalid, the update process will be terminated immediately and an alert will be issued.

[0155] The above description of specific embodiments is only for the purpose of helping to understand the technical concept and core idea of ​​the present invention. Although specific preferred embodiments have been used to describe and illustrate the technical solutions, they should not be construed as limiting the present invention itself. Those skilled in the art can make various changes in form and detail without departing from the technical concept of the present invention. These easily conceived changes or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A microkernel operating system industrial PLC hot update control method, wherein the industrial controller adopts a microkernel operating system, and uses a PLC program running in the user mode of the microkernel operating system to control the operation of industrial equipment based on acquired data, characterized in that: During the operation of the industrial controller, the following steps are used for hot update control: (1) Prepare the target update package, which includes the updated version of the program or parameters, the interface contract and the migration script; (2) Create a shadow instance in the microkernel operating system with an isolated address space. The shadow instance is built based on the updated version in the target update package and runs in parallel with the live instance using the current version. Build a shadow I / O image of the live I / O data and a shadow communication stack with a copy of the fieldbus protocol stack. Bind the shadow instance to the shadow I / O image and the shadow communication stack. (3) Capture the stop point within the scanning cycle of the live network instance. The stop point is located between the completion of input sampling and the unsubmission of output. After capturing the stop point, record the timestamp and cycle phase of the current scanning cycle for timing alignment of the switching between the shadow instance and the live network instance. (4) Obtain the running status information from the live instance and transfer it to the shadow instance after conversion according to the migration script; (5) Run the shadow instance in the isolation channel at an accelerated or constant speed for a certain period of time, and perform consistency and real-time verification. (6) If the verification is successful, the I / O channel will be switched from the live instance to the shadow I / O mirror of the shadow instance at the next stopping point, so that the shadow instance becomes the new instance and the original live instance becomes the old instance. (7) Allow the old and new instances to continue running in parallel for a certain period of time and monitor their operation; (8) If the new instance runs successfully during the monitoring period, the old instance will be uninstalled; if an abnormality occurs during the monitoring period, a rollback operation will be performed at the same stop point to switch the I / O channel back to the old instance.

2. The microkernel operating system industrial PLC hot update control method as described in claim 1, characterized in that: In step (1), the target update package is stored in the version repository of the microkernel operating system. Signature verification, integrity verification and interface compatibility checks are performed in the user-mode version management service. The next step is allowed only if the update version is backward compatible or a migration script is provided.

3. The microkernel operating system industrial PLC hot update control method as described in claim 1, characterized in that: The shadow I / O image of the shadow instance and the live I / O buffer of the live instance both adopt a double buffer structure. The shadow I / O image includes a shadow input image and a shadow output image. The shadow input image and the shadow output image are stored independently from the input buffer and output buffer of the live I / O buffer. The data stored in the shadow input mirror is the same as the input buffer data of the live instance, while the shadow output mirror stores the instruction data generated by the shadow instance. Switching from the live instance to the shadow instance or rolling back from the new instance to the old instance can be achieved by switching the I / O channel to the shadow I / O mirror or the live I / O buffer.

4. The microkernel operating system industrial PLC hot update control method as described in claim 1, characterized in that: After capturing the stop point, step (3) freezes the current input data in the shadow I / O mirror, prevents subsequent sampling data from overwriting the input data, and keeps the time base stable.

5. The microkernel operating system industrial PLC hot update control method as described in claim 1, characterized in that: In step (4), the running status information obtained from the live network instance is converted based on the mapping rules in the migration script. Incompatible fields are converted and filled with default values ​​through the migration script, and then transferred to the shadow instance in batches through the zero-copy shared page or IPC of the microkernel operating system.

6. The microkernel operating system industrial controller PLC hot update control method as described in claim 1, characterized in that: In step (5), the verification content includes the consistency of the calculation case, the maximum execution time per cycle and memory usage. The consistency of the calculation case is the deviation between the calculation results of the key variables and the actual network instance. The maximum execution time per cycle does not exceed the threshold set within the scanning cycle.

7. The microkernel operating system industrial PLC hot update control method as described in claim 1, characterized in that: The shadow instance uses a virtual clock to pre-run at 2-5 times the speed of the live network clock. After completing a predetermined number of pre-run cycles, the virtual clock is adjusted to be at the same speed as the live network clock, and then the phase of the virtual clock of the shadow instance is aligned with the phase of the live network clock.

8. The microkernel operating system industrial controller PLC hot update control method as described in claim 1, characterized in that: The shadow instance is pre-run with a lower priority than the live instance. When switching from the live instance to the shadow instance, the priority of the shadow instance is temporarily increased within a controlled time window to ensure the real-time nature of the switching operation.

9. The microkernel operating system industrial PLC hot update control method as described in claim 1, characterized in that: In step (7), a health score is performed based on jitter, timeout rate, and abnormal event rate during the monitoring period to determine whether to commit a transaction to unload the old instance or to perform a rollback operation.

10. A microkernel operating system industrial PLC hot update control system, employing the control method described in claims 1-9, characterized in that: The control system includes an industrial controller running a microkernel operating system, with the following user-mode deployments of the microkernel operating system: Update coordinator: Used for stop point detection, instance switch orchestration, and transaction commit control; State Migrator: Used for collecting and transforming the running status information of live instances and injecting it into shadow instances; Version repository: Used for signing and storing update packages; Health monitoring component: used to build a health scoring model, output a health score, and trigger commit or rollback commands; Rollback Manager: Used to perform rollback operations and store the reasons for failures in the log system; I / O services: Used to manage local I / O and remote fieldbus process data mirroring, maintain a double-buffered structure and handle data synchronization; Fieldbus communication stack: Provides user-space protocol services and exposes data to the shadow communication stack through the PDO / SDO interface.

Images