⚡ electrical engineering

VICP: A Majority-Lease Runtime for Highly Available Industrial Edge Clusters

This paper presents VICP, a runtime for industrial edge clusters that ensures highly available and safe service failover by decoupling reversible state replication from irreversible physical output authority via majority-backed leases and fencing, achieving a 50.54% reduction in output interruption compared to active standby while maintaining precise control accuracy.

Original authors: Ruifeng Ding, Jie Zhou, Benjun Dou, Xingwu Zhu, Shengyang Gao

Published 2026-08-10

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Ruifeng Ding, Jie Zhou, Benjun Dou, Xingwu Zhu, Shengyang Gao

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a world where the machines keeping our lights on, our water clean, and our factories running are no longer just dumb, hard-wired boxes, but smart, flexible software programs living on clusters of computers. This is the frontier of industrial edge computing. But there's a tricky problem: in the old days, if a controller broke, a backup would take over. In the new software world, if a computer crashes and restarts, it might try to talk to the real-world machines at the exact same time as the one that just woke up. If two computers both tell a giant valve to "open" simultaneously, chaos ensues. This paper tackles a very specific, high-stakes question: How do we let software run on many computers for speed and safety, without ever letting two of them accidentally push the same physical button at the same time? It's like trying to have a team of chefs all cooking the same meal, but making sure only one person is allowed to actually turn on the stove at any given moment.

The researchers behind this study, from Rundian Energy Science and Technology Co., Ltd., have built a system called VICP (Virtualized Industrial Control Platform) to solve this puzzle. They realized that while we can easily copy and sync digital data (like a recipe or a temperature reading), we cannot "un-push" a physical button once it's been pressed. So, they split the problem in two. First, they let every computer in the cluster keep a local, up-to-date copy of the data so they can think fast. Second, they created a strict "permission slip" system. To actually send a command to the physical world (like opening a valve), a computer must hold a majority-backed lease. Think of this like a "golden ticket" that is only valid if a majority of the other computers in the group agree it's still valid and hasn't expired. If the network splits in half, or if a computer crashes and tries to come back, it can't just start shouting orders; it has to wait until it can prove to the majority that it's safe to do so.

In their experiments, the team tested this idea on a small cluster of three computers running a Go-based prototype. They poked holes in the network and shut down computers to see what happened. The results were promising: when a computer failed, VICP managed to switch control to a backup in an average of 1,039.061 milliseconds (about 1 second). This was a massive improvement—roughly 50.54% faster—than a traditional "active-standby" setup, which took over 2,100.614 milliseconds to recover. Even more importantly, across 30 different tests where they simulated network splits, they detected zero instances where two computers tried to output commands at the same time. They also tested the system with real physical hardware, sending 4–20 mA electrical signals (the standard language of industrial sensors) through a "fencing gateway" that acted as a final security guard. The system kept the signals incredibly accurate, with a maximum error of just 0.02078 mA.

However, the authors are careful not to call this a magic bullet for every safety-critical situation. They explicitly state that their system is not a replacement for certified safety equipment or independent emergency shutdown logic. It's a way to make the control layer more flexible and available, but the final safety net still needs to be in place. They also note that their results are based on simulations and specific hardware setups (using virtual machines and specific I/O cards), so while the math and the logic hold up in their lab, real-world deployment would need even more rigorous testing. The paper suggests that by separating "thinking" (which can be copied everywhere) from "doing" (which needs a strict majority vote), we can build industrial systems that are both super flexible and incredibly safe, provided we respect the rules of the lease and the fencing. It's a step toward a future where our industrial infrastructure is as resilient as a flock of birds, where if one bird gets separated, the others keep flying in perfect sync without ever crashing into each other.

Technical Summary: VICP – A Majority-Lease Runtime for Highly Available Industrial Edge Clusters

1. Problem Statement

Industrial automation is increasingly migrating toward cloud-native architectures using commodity servers and containers to host advanced control functions (e.g., model-predictive control). However, standard cloud-native failure recovery mechanisms—such as process rescheduling or traffic redirection—address service availability but fail to address physical output safety.

In traditional Distributed Control Systems (DCS), field communication, execution state, and output authority are bound to dedicated hardware. In contrast, a virtualized environment allows multiple replicas of a controller to exist simultaneously. If a network partition occurs or replicas disagree, standard eventual consistency models may allow multiple nodes to issue irreversible physical commands (e.g., actuator movements) concurrently. This creates a critical safety hazard: while point values (sensor data) can be reconciled later, physical actions cannot be "recalled" once executed. The paper identifies the core systems question: How can a small industrial edge cluster retain local control capability during node failures while strictly preventing concurrent physical output from isolated replicas?

2. Methodology and System Design

The authors propose VICP (Virtual Industrial Control Platform), a runtime architecture that decouples reversible point-state replication from irreversible physical output authority.

2.1 Core Architecture

Local-First State: Control tasks run on local replicas using in-memory point tables. High-frequency control loops access local state without network round trips. Peer replicas are kept "warm" via asynchronous propagation.
Deterministic Convergence: Point updates are represented as tuples containing timestamps, priorities, source IDs, and sequence numbers. Replicas resolve conflicts deterministically using lexicographical comparison, ensuring all nodes converge on the same state values without requiring consensus for every read.
Majority-Lease Output Authority: Physical output is gated by a time-bounded lease.
- A node must hold an unexpired lease, backed by a majority quorum ( $Q = f+1$ ), to issue physical commands.
- The lease includes an epoch, holder identity, and expiry deadline.
- If a node loses connectivity to the majority, its lease expires, and it is forbidden from issuing output.
- A "single-survivor" mode is possible but requires explicit external authorization (e.g., a hardware arbiter or operator procedure), not just network observation.

2.2 Recovery and Isolation

Staged Recovery: A restarted node does not immediately rejoin the control loop. It progresses through a state machine: Starting → Discovering → Catching-Up → Validating → Pre-Serving → Serving. This ensures stale local updates do not override newer peer values.
Resource Isolation: Critical tasks (field communication, control loops, lease guards) are pinned to specific CPU cores and isolated from management tasks (logging, history, configuration). Non-critical tasks are degraded or paused under resource pressure.
Fencing Gateway: A persistent I/O gateway validates fencing tokens (lease epoch and holder) before forwarding commands to physical devices. It rejects commands with stale epochs, even if the runtime process resumes after a pause.

3. Key Contributions

The paper makes four primary contributions:

Split Correctness Model: It defines a model separating deterministic convergence for reversible point state from majority-lease requirements for irreversible physical output.
Local-First Runtime Architecture: It presents an architecture with explicit point ownership, deterministic conflict resolution, lease epochs, output fencing, and a staged recovery state machine.
Integrated Availability and Resource Management: It demonstrates how compute-group boundaries and CPU/storage isolation protect critical control paths from management-plane load.
Reproducible Prototype and Evaluation: It provides a Go-based prototype and a comprehensive evaluation covering failover, partition behavior, synchronization scale, resource interference, and bidirectional hardware-in-the-loop validation.

4. Experimental Results

The authors evaluated a three-node Go prototype running on openEuler with Docker containers.

4.1 Failover Performance

Interruption Time: VICP achieved a mean output interruption of 1039.061 ms (95% CI: 1024.492–1053.631 ms).
Comparison: This represents a 50.54% reduction compared to a configured active-standby baseline (2100.614 ms).
Safety: No cross-node execution overlap was detected in 30 failover runs.

4.2 Partition Behavior

In 30 partition runs (isolating one node from the other two), no duplicate output candidates were detected.
The isolated node executed 5–9 cycles before its local authority expired, while the majority side continued. The gap between the last isolated output and the first majority output averaged 944.081 ms.
Under a Bernoulli interpretation, the 0/30 event rate yields an exact one-sided 95% upper bound of 9.5% for the per-run event probability.

4.3 Synchronization and Scale

The system successfully synchronized 50,000 points with a mean throughput of ~18,363 points/s.
Mean synchronization latency was 8.192 ms for intra-group samples.

4.4 Resource Interference

CPU Isolation: CPU pressure on isolated cores had negligible effect on control cycle jitter. However, pressure on shared runtime cores increased P99 jitter to 4.981 ms.
Disk I/O: Synchronous disk I/O on the runtime host significantly increased P99 jitter to 28.542 ms, highlighting that container boundaries alone do not isolate disk interference.

4.5 Hardware-in-the-Loop (HIL) Validation

The system processed 1,200 physical 4–20 mA samples (600 analog input, 600 analog output) through a fenced Modbus/TCP gateway.
Accuracy: Maximum setpoint-mean bias was 0.01764 mA (AI) and 0.02078 mA (AO).
Linearity: $R^2$ values exceeded 0.999999.
Safety: No bad-quality or offline samples were recorded.

5. Significance and Claims

The paper positions VICP as a feasibility study and a reproducible prototype rather than a safety-certified product.

Scope: The authors explicitly state the prototype does not claim hard real-time guarantees, Byzantine fault tolerance, or compliance with safety integrity levels (e.g., SIL).
Primary Achievement: The work demonstrates that separating output authority from state replication is implementable on commodity infrastructure. It proves that a majority-backed lease can effectively gate irreversible physical output, reducing failover interruption time by roughly half compared to a standard active-standby configuration while preventing concurrent output during partitions.
Engineering Boundary: The paper emphasizes that safety depends on lease timing assumptions and the implementation of fencing at the physical I/O boundary. It argues that while the software mechanism is sound, production deployment requires certified hardware arbiters, authenticated messaging, and monitored clock synchronization.
Future Work: The authors note that further validation is required, including moving fencing to independent hardware, testing on ARM architectures, and conducting long-duration campaigns with diverse fault injections.

In summary, VICP offers a practical architectural pattern for industrial edge clusters that balances the flexibility of cloud-native computing with the strict safety requirements of physical process control, provided that specific engineering controls (fencing, resource isolation, and external authorization) are rigorously applied.