This page discusses redundant data production scenarios. If you wish to learn how data update and synchronise between ABB Ability™ History nodes, refer to High availability.

Overview

ABB Ability™ History is frequently used in redundant configurations for achieving high availability. When looking for a high-availability solution against any single point of failure, data production is typically made redundant. The following chapters discuss the various combinations of data production of a single and redundant History node.

First, we discuss the non-redundant setup, then by adding a redundant History node we will demonstrate both single active data producer and multiple active data producers configurations.

Next, we introduce a setup with redundant devices and a non-redundant History node, continue with deterministic data production, which is important when there are multiple devices measuring the same signal. Finally, we demonstrate both single active data producer and multiple active data producers configurations.

Single setup

The non-redundant/ single setup is used as the base to build redundant setups. We continue by adding a redundant History node. The picture below shows a single setup where we have a single device connected to a single History instance. The device measures an analogue signal, for example, temperature, and sampling this into a digital signal. This setup has no redundancy and therefore doesn't provide high availability.

Single active data producer - redundant History

This section adds a redundant History instance to the setup, and the History instances are called History A and History B.

In this setup, History A is an active data producer. This means that History A receives the data from the device. History B doesn't receive the data directly from the device. Instead, it receives the data from History A. All the incoming values are replicated by RTDB-CVMCServer between the History instances. To ensure full consistency, RTDB-ConsistencyController service monitors for potential differences in the database tables between the instances and fixes the found errors. The picture below shows the data flow in this setup.

If History A loses connection to the device, History B will become the active data producer. The instance that is the active data producer can change, but there can only be one active data producer at a time.

What History instance is working as the active data producer depends on the data production method. If the data production is with API, then the device or the History load balancer can decide which node is the active one. If the data production is handled by data collector link (master protocol), then typically the activity is controlled by a master token.

Single device - multiple active data producers

This section describes a setup where the data is simultaneously received from the device by both History instances. In other words, both instances are working as active data producers simultaneously, and they are basically competing which one is the fast producer and get the value stored first while the later value is discarded. If one data producer fails, the other one continues production like in the previous case.

Redundant device - Single data collector

In this section we're going to consider a case where a single signal is measured, or sampled, by two redundant devices. A single history instance receives the same data from both of these devices with same or different protocols. If devices are pushing the values with APIs, then they are competing with each other similarly as the active data producers in the previous section. If the data production is handled by data collection link such as OPC UA client, it is typically using one device connection at the time, and if it doesn't work, then it changes to the other one.

Deterministic data production

When there are two devices measuring the same signal, these devices won't produce exactly the same time-series. There can be measurement inaccuracies, the device clocks might not be perfectly synchronized, there might be a phase difference in sampling, etc. Therefore, if we just combine all the data points measured by both the devices, we can end up with double the amount of data we intended to collect. This kind of problem may be seen in a redundant History configuration where there are concurrently active redundant data producers.

To prevent a duplicate amount of from being collected, we need to ensure that both devices produce exactly the same measured data points. This is called deterministic data production. It requires that both the timestamps and the values of the corresponding data points are equal.

History itself doesn't offer solutions for achieving deterministic data production. Therefore, the devices themselves must be capable of communicating and ensuring that the generated data is deterministic. This requires a solution on the device-level.

To better understand the need for deterministic data production, we present a visualization. Consider the following analog signal:

Let's say that we have two identical devices measuring the above signal. Both of the devices are measuring a sample once a second. However, there's a phase difference in the devices' sampling. The first device (circles) is sampling on the seconds (0:01; 0:02; etc.) and the second device (diamonds) every half a second (0:01,5; 0:02,5; etc.).

The resulting time-series, even though a bit different, are almost identical for practical purposes. If we combine both of these time-series on the same plot, you can see how much they resemble each other:

Redundant device - single active data producer

In this section, we present a setup that contains two devices and two History instances, but just one active data production to eliminate the problem of non-deterministic data production. If History A goes down or loses network connection, History B becomes the active data producer. Likewise, if one of the devices has issues, the other device ensures that the data production continues without interruption.

Redundant device - multiple active data producers

The last example contains two devices, two data productions, and two History instances. If this setup is configured so that the data producers are simultaneously active and competing with each others, this configuration contains the most redundancy.