I recently delivered a project where the goal was clear: keep an existing Siemens S7 environment running with hot failover while streaming alarm/events to a cloud analytics service — and do it without adding or swapping PLC hardware. Below I describe the pragmatic, production-proven approach I use when teams want high availability on the plant floor and modern cloud-based alarm analytics, but cannot change PLC hardware or introduce new PLC CPUs.

Design principles I followed

When you can’t add PLC hardware, the solution has to live in software and at the edge/network layer. My priorities were:

  • Non-intrusive — minimal or controlled changes to PLC code and no extra PLC chassis/CPUs.
  • Reliable failover — automatic detection of PLC controller failure and seamless continuation of alarm/event streaming.
  • Correctness — no lost alarms, no duplicate analytics artifacts, and maintain event ordering and provenance.
  • Secure and observable — TLS/secure telemetry to cloud, health metrics, and clear diagnostics for failover events.

    • Recommended architecture (edge-centric)

    The approach I typically implement is an edge gateway that performs dual-head collection and handles failover logic. High-level components:

  • Existing Siemens S7 PLCs (possible active/standby pair or single PLC with network redundancy).
  • An industrial edge gateway/server (on-prem VM or industrial PC) running:
  • - OPC UA/Siemens S7 client (or a vendor gateway like Kepware, Matrikon, Inductive Automation/Ignition) capable of connecting to multiple PLC endpoints simultaneously.
  • - A failover manager that watches PLC health, reconciles tags/alarms, and forwards a single canonical stream to the cloud.
  • - A cloud ingress using secure protocols (MQTT over TLS, AMQP, HTTPS) to your analytics platform (Azure IoT Hub + Time Series Insights, AWS IoT Core + Kinesis, Splunk/Datadog, or a custom pipeline).

    • In short: make the edge the authoritative bridge between PLCs and the cloud. The edge handles hot failover without changing PLC hardware.

    How it works, step by step

    Implementation steps I take on projects:

  • 1. Identify data model and alarm fuentes — Map PLC tags that represent alarms, blocks, severity, timestamps, and any sequence numbers. If PLC logic already sets DBs or flags for alarms, use those. If not, add minimal logic to generate structured alarm DBs (recommended but optional).
  • 2. Deploy a dual-connector edge — Configure the edge to open simultaneous connections to both the primary and secondary PLC endpoints (or to the PLC’s redundant IPs). Many industrial OPC UA clients or Siemens Sitop/Kepware drivers allow multiple endpoints/subscriptions.
  • 3. Implement failover arbitration — Write edge logic that chooses the canonical source of truth for each time window. Typical arbitration rules:
  • - Prefer the primary PLC while its health is OK.
  • - If primary misses heartbeats or returns connection errors, switch to secondary instantly.
  • - Maintain state on the edge to detect duplicates across switches (use sequence numbers or monotonic event counters where possible).
  • 4. Normalize model and enrich — Edge normalizes alarm payloads (tag, severity, timestamp, PLC_id, seqno) and enriches with asset metadata (line, shift, product) before forwarding.
  • 5. Forward to cloud with edge buffering — Use MQTT/AMQP with QoS and local persistency so transient network loss doesn’t drop alarms. Ensure messages are idempotent (include unique event IDs) so cloud deduplication is trivial.
  • 6. Provide diagnostics and reconciliation APIs — The edge should expose a small HTTP/API endpoint for health, last event IDs, and a reconciliation command (replay last N events) so cloud analysts can verify continuity after failover.

    • Practical implementation details

    Tools and concrete patterns that worked for me:

  • OPC UA as canonical northbound protocol — OPC UA provides secure transport, subscriptions, and industrial semantics. Use an OPC UA client/server that supports multiple endpoints. Kepware, Matrikon, and Ignition are robust choices.
  • Dual subscriptions — Create independent subscriptions for each PLC. The edge merges them using timestamp/seqno arbitration.
  • Message format example (JSON)

    • <pre>{"event_id":"lineA-PLC1-20260901T103010Z-000123","asset":"lineA","source":"PLC1","tag":"E_STOP","severity":"HIGH","status":"ACTIVE","timestamp":"2026-09-01T10:30:10Z","seq_no":123,"payload":{...}}</pre>

  • Cloud ingestion — Use MQTT with persistent sessions and QoS=1/2. In Azure/AWS, enable device twins or registry to keep edge identity and key rotation easy.

    • Handling duplicates and ordering

    Duplicates are the usual headache when you have two collectors. My tactics:

  • Require PLC to emit a monotonic sequence number per alarm (where possible). The edge stores last-seen seq per PLC and deduplicates.
  • If you can’t change PLC code, generate a deterministic event hash (based on tag+timestamp+value) and use that for dedupe.
  • Forward events with both PLC_id and edge-assigned event_id so cloud analytics can decide precedence.

    • Operational checks and KPIs

    Make sure you track these metrics from day one:

  • Edge-to-PLC latency (ms) and subscription drop rate.
  • Edge-to-cloud latency and queue depth (buffering backlog).
  • Failover events per week and time-to-recover.
  • Duplicate suppression rate and reconciliation operations.

    • Common pitfalls I’ve seen (and how I avoid them)

    PitfallMitigation
    Clock skew across PLCs causing ordering errorsUse NTP/PTP on edge and stamp events at the edge if PLC clocks are unreliable.
    Lost events during network blipsEnable edge persistence (disk), QoS in MQTT, and replay APIs.
    Ambiguous alarm ownership after failoverInclude source PLC id and seq numbers; reconcile with operator logs.
    Security gaps from edge to cloudUse TLS, certs, identity management, and minimal firewall openings.

    Why this avoids adding PLC hardware

    The edge gateway pattern lets you implement hot-read redundancy and failover arbitration entirely in software. You don’t need to add CPUs or modify the PLC chassis. The logic that provides “hot” continuity sits in the edge: it reads both PLCs, decides which to trust, merges streams, and provides a single, clean feed to the cloud. That gives you HA behavior for alarm analytics without adding PLC hardware.

    If you want, I can draft a specific design for your plant: list of PLC IPs, tags you care about, candidate edge software (Kepware vs Ignition vs custom Python + Snap7), and a simple MQTT topic schema you can drop into your cloud pipeline. Tell me your cloud provider and I’ll sketch the pipeline and QoS settings to use.