Fault-Tolerant SCADA Solutions

A fault-tolerant Iotellect SCADA/HMI system combines Iotellect platform-level high availability mechanisms with SCADA-specific redundancy logic.

Iotellect provides platform-level mechanisms, including active-passive server failover and active-active clustering, and supports database failover cluster configurations.

Iotellect SCADA/HMI solutions build on these mechanisms by adding a Iotellect SCADA/HMI tag model and SCADA-specific redundancy patterns. In this model, multiple redundant source values can be mapped to one digital twin tag, and the digital twin tag value can be calculated according to configured rules (pre-configured logic).

Redundancy can be applied at different levels, from field data acquisition to operator access. Depending on the implementation, redundant elements may include measurement sources, controllers, communication paths, communication servers or protocol gateways, platform servers, database or historian components, and operator workstations.

Fault-tolerant Iotellect SCADA/HMI architectures can use the following runtime patterns:

Pattern

Description

Active-Passive

One resource is active, while another resource is kept standby and becomes active after failover. The active resource performs runtime operations, such as reading data, calculating values, generating alerts, writing history, writing values to sources, or executing actions. The passive resource is ready to take over, but it does not perform these operations until failover occurs.

Active-Active

Multiple resources or server nodes are active at the same time. Resource ownership is defined by the system design and cluster configuration.
Active-Active does not always mean that every resource is active on every server. The system design defines which resources are active on each node.

These patterns can be combined in one Iotellect SCADA/HMI solution. For example, a system may use duplicated measurement sources, active-passive platform failover, and a database cluster for historical storage.

The final architecture is defined by the system design (and solution requirements). They specify where redundancy is required, which components are duplicated, which components are kept in standby, and which components remain non-redundant.

High Availability and Redundancy

Iotellect high availability mechanisms operate at the platform level. They help keep servers, services, and databases available when a node or component fails.

Iotellect SCADA/HMI adds application-level redundancy logic for process values, tags, visualization, alerts, and history. It defines how values are received, normalized, displayed, stored, and used by Iotellect SCADA/HMI applications.

A fault-tolerant Iotellect SCADA/HMI architecture may include redundancy at various layers:

Layer

Example

Measurement layer

One or more measurement sources for the same process value

Controller layer

One or more controllers / controller channels

Network layer

One or more communication paths

Communication layer

Direct communication or one or more communication servers / protocol gateways

Platform layer

One or more Iotellect Server nodes

Database / historian layer

Single database, database cluster, separate databases, or redundant historian nodes

Operator access layer

One or more browser-based operator workstations with server failover

Not every implementation requires all layers. A simple system may use one sensor and direct controller communication. A more complex system may use duplicate sensors, redundant controllers, two communication gateways, multiple Iotellect Server, database redundancy, and several operator workstations.

Iotellect SCADA/HMI Tags

In a fault-tolerant architecture, the same process value (such as temperature, pressure, level, flow rate, or rotation angle) may be available from multiple sources, such as measurement devices, controller channels, gateways, or platform nodes (via device tags). The Iotellect SCADA/HMI layer normalizes (binds) these source values into one digital twin tag, which is then used in operator screens, dashboards, alerts, charts, reports, and history.

The digital twin tag value can be calculated according to configured quality, availability, and priority rules. For details, see Iotellect SCADA/HMI Tags.

The same rules define where Iotellect SCADA/HMI writes values: a tag configured for writing sends the value to the device tag that is active at that moment.

If the active node fails while a tag write is in progress, the standby node does not send the value again after failover, and the commanded value is lost.

Database, Historian, and Operator Access

Digital twin tag values can be written to a database or historian.

The database design should match the server cluster mode. For example, in Active-Passive mode, only the active server may write history. In Active-Active mode, history writing may be split by resource ownership.

Operator workstations usually connect to Iotellect through a browser. A workstation can be configured with more than one server endpoint. If the current server becomes unavailable, the workstation can switch to another available server.

The operator should continue to see the same logical process tags after failover.

Values written to a tag do not survive a failover.

Architecture Example

The following figure demonstrates possible architecture. It illustrates common combinations of redundancy layers.

Active-Passive Cluster with Shared Database

Two Iotellect servers in an active-passive configuration. Server A is active and handles all runtime operations, including reading data and writing history. Server B is on standby and takes over if Server A fails. Both servers share a single database. Operator workstations switch to Server B on failover.

Was this page helpful?