I’ve long been frustrated by vendor lock‑in when trying to implement high‑availability strategies across heterogeneous control systems. In practice you’ll often find a Siemens S7 island on one line and Rockwell ControlLogix on another, each with different tooling, licensing and runtime semantics. Building a vendor‑agnostic hot‑standby that works reliably across both families is possible — but it requires designing around the weakest common denominators: I/O determinism, state replication and failover orchestration. In this article I’ll walk you through an approach I’ve used in production pilots: using lightweight virtual machines to host soft PLCs and a small runtime layer that mirrors I/O and program state, while keeping a single, vendor‑neutral operational interface (OPC UA/IEC 60870/ MQTT) for SCADA and MES.

Why lightweight VMs?

Containers are great for many things, but when you need strict isolation for real‑time control logic and to run vendor soft‑PLCs or emulators that expect a full OS, lightweight VMs are the pragmatic choice. They provide:

  • hardware namespace isolation for driver and Ethernet stack parity;
  • fast boot and snapshot capabilities compared with full hypervisors;
  • the ability to run Windows‑based emulators (e.g., Siemens PLCSIM Advanced, Rockwell Emulate) alongside Linux soft‑PLC runtimes.

    • I typically use KVM with QEMU combined with a lightweight manager such as libvirt or firecracker for microVMs, depending on vendor emulator compatibility. For mixed OS workloads (Windows emulators and Linux runtimes) a small fleet of thin VMs is simpler than trying to shoehorn everything into containers.

    Core design principles

    Keep these principles front and center while designing:

  • Vendor abstraction: Never replicate vendor programming environments as the source of truth for failover decisions. Instead, rely on an independent state mirror and canonical I/O mapping.
  • Deterministic I/O mirroring: Mirror physical inputs and outputs at deterministic intervals (e.g., per PLC scan cycle or fixed sub‑cycle) so the standby VM sees the same I/O timeline.
  • Minimal downtime during failover: Aim for sub‑second switchover for critical loops; this often means pre‑arming the standby VM with recent snapshots and continuous state deltas.
  • Testability and observability: Build test harnesses that inject I/O faults and validate state convergence. Log every replication and failover event to an immutable audit trail.

    • High‑level architecture

    Here’s the architecture I use for a vendor‑agnostic hot‑standby:

  • Physical PLCs (Siemens S7, Rockwell ControlLogix) remain the authoritative controllers when they are healthy.
  • Soft‑PLC instances run inside lightweight VMs on a local edge server. Each physical PLC has a paired primary VM and a standby VM, or in some designs the VM pair mirrors multiple PLCs for density.
  • An I/O mirror service sits on the edge server and subscribes to physical PLC I/O via native drivers (S7 protocol, EtherNet/IP) or via an OPC UA gateway. The same service feeds I/O into the soft‑PLC VMs.
  • A state replication bus streams program variables, timers, and counters from the running PLCs into the standby VMs as deltas. On failover the standby applies the last known deltas and takes over I/O ownership.
  • Orchestration and health monitoring (lightweight control plane) manage heartbeats, perform integrity checks, and coordinate control handover.

    • Practical implementation steps

    Below is a distilled, practical sequence I follow.

  • Inventory and mapping: Document PLC models, critical I/O points, scan times, and program variables required for continuity (counters, accumulators, recipe tables).
  • Deploy edge VMs: Provision lightweight VMs on an industrial edge server. Use Windows VMs only when you need official emulators; otherwise prefer Linux‑based soft PLC runtimes (e.g., CODESYS, TwinCAT on Linux).
  • Implement I/O mirror: Build or deploy an I/O mirroring service. Options include Kepware or custom OPC UA servers that read native PLC protocols and expose canonical nodes. Ensure the mirror timestamps and sequences each sample.
  • State replication: For each essential program variable, stream updates over a reliable message bus (MQTT with QoS 2, AMQP, or a lightweight replication protocol over TCP). Compress and checkpoint periodically to minimize replay time.
  • Pre‑arm standby: Keep standby VMs running in a paused or ready state. Apply periodic snapshots of the soft PLC runtime and program code. Apply deltas continuously so standby state is within an acceptable delta of the primary.
  • Failover orchestration: Use a small control plane service (can be containerized) that monitors health checks (watchdog on CPU, scan time, I/O integrity). On primary failure, the orchestrator:
  • takes ownership of I/O addresses at the network gateway (most gateways support changing master addresses via API),
  • resumes the standby VM if paused,
  • applies final state deltas and moves the VM into active I/O mode
  • Integration with SCADA/MES: Present a single OPC UA endpoint for SCADA and MES; the orchestrator keeps the endpoint stable and rebinds it on failover to reduce integration complexity.

    • Dealing with vendor specifics

    Both Siemens and Rockwell have emulation and simulation tools (Siemens PLCSIM Advanced, Rockwell Emulate) — useful for development and testing but tricky for live use due to licensing and runtime guarantees. I generally avoid treating vendor emulators as the HA mechanism. Instead:

  • Use vendor protocols for I/O mirroring only; keep the state canonical in the replication bus.
  • For Siemens: leverage S7 protocol for I/O sampling and OPC UA companion specs where available.
  • For Rockwell: use EtherNet/IP adapters or OPC UA wrappers. Lean on ControlLogix tag read/write APIs for program variables if needed.

    • Safety, certification and operational concerns

    Hot standby for control systems touches safety and compliance. Address these:

  • Fail‑safe design: Ensure safety circuits remain independent of the hot‑standby mechanism. Safety PLCs should not be part of the mirrored domain unless certified.
  • Licensing and vendor support: Check vendor EULAs for running their emulators in production. Engage vendor support early — many vendors will not support incidents where unsupported emulation is in the control path.
  • Network determinism: Use separate VLANs and QoS for control traffic. Keep replication and orchestration traffic off the corporate LAN.
  • Testing regime: Run scheduled failover drills monthly and after any software change. Validate deterministic behaviour, not just connectivity.

    • Checklist for a first pilot

    Edge server with KVM/Firecracker✓
    Soft PLC runtime (Linux or Windows)✓
    I/O mirror (OPC UA / native protocol)✓
    State replication bus (MQTT/AMQP)✓
    Orchestrator and heartbeat monitor✓
    SCADA integration via single OPC UA endpoint✓
    Failover test plan and safety audit✓

    Implementing vendor‑agnostic hot‑standby is not a one‑size‑fits‑all exercise, but by isolating the replication and orchestration layers from vendor runtimes and using lightweight VMs to host standby logic, you can create a robust, testable solution that spans Siemens and Rockwell environments. I encourage you to start small — pick a single line, instrument the essential variables, and run failover drills until the timing and state convergence are predictable. If you want, I can share a sample repo layout, orchestration service blueprint, or an example OPC UA node model to accelerate a pilot on your site.