New Sparkplug B MQTT collector for Factry Historian: all you need to know
Why we built a Sparkplug B MQTT collector for Factry Historian, and what’s in it for your business.
Jeroen Coussement on , updated
In the slipstream of the Factry Historian v5 update, we are currently adding a series of minor product features. First in line: automated collector failover. Find out what it’s all about, and how it brings you more peace of mind.
While failover is not the same as redundancy, it is strongly related to it. Redundancy means there are extra components readily available whenever a component fails. Failover is the mechanism that switches the workload between redundant components in case one of them fails.
Industrial historians typically collect data in real time from control systems such as SCADA, which run either on virtual or physical machines. These machines can fail, while they also need occasional maintenance or updates.
The historian’s collector failover feature eliminates the data collector as a single point of failure, ensuring the data captation process automatically continues in case the main data source becomes unavailable due to hardware failures or system updates.
As such, it prevents irreversible loss of process data, no matter how small, and adds value to your company’s risk strategy.
The collector failover feature was built for companies for which extreme data continuity is essential to investigate and document their processes. It was specifically requested by some of our clients, and therefore prioritised by us.
It is especially valuable in industries in which traceability is crucial, although it can add value to any industrial company that leverages the historian’s datasets for deep analysis, and requires them to be as complete as possible.
To ensure the continuity of the data collection process, many companies have duplicated the SCADA on the control layer. A second system continuously checks in to see if the master is still operating, and takes over in case it isn’t.
In case the SCADA system went down, operations could continue as the second SCADA takes over. The historian, however, was still trying to get data from the first system, until someone manually switched to a second collector.
As the historian instantly sends an alert in case of issues, this could often be quickly resolved. However, this would leave at least a small data gap between the moment the data stopped flowing, and someone jumped in to fix the issue.
The failover feature works in a similar way as the SCADA duplication, yet on the level of the collector. As soon as the second collector notices that the first one is down, it switches to the second collector, all in a matter of seconds. As such, it offers extreme data continuity and additional peace of mind.
On top of that, building your own failover mechanism is a substantial investment. Think licence fees, hardware and maintenance costs.
With this new feature, you get a hassle-free and more cost-effective solution.
Following the recent v5 update, we are again planning major updates to Factry Historian in 2023. Along with other exciting stuff, we will be focusing on making our IIoT platform even more useful for various roles in the company.
Meanwhile, we will continue to add some minor features and other improvements. Keep an eye on our blog for new historian updates!
Or while you’re here: why not schedule a free demo of Factry Historian?