Process Historians and the Unified Namespace
A Process Historian collects data from a manufacturing process, stores the data in a database or in a proprietary file structure so that it is available for analytics, querying, and trending.
Many SCADA platforms have Process Historian functionality built-in, and there are a number of stand-alone process historians on the market. While most of the stand-alone products have on-premises hosting, many are now offering cloud-based hosting for a monthly subscription fee. It’s also important to note that dedicated Process Historians usually also include an analytics package for general reporting and trending needs.
By using a dedicated process historian instead of the one included with your SCADA system, you may have the advantages of larger data storage and faster data retrieval options with a dedicated historian’s proprietary data compression algorithms. In most cases, it’s also easier to integrate with third-party analytics packages since dedicated historians have a query engine or API you can use to retrieve data.
Additinally, if you aren't using a Unified Namespace in your overall manufacturing technology architecture, you can get the benefits of a Unified Namespace semantic hierarchy applied to your day by using a Process Historian. In many historians, you can organize your data so that it is easy to understand by building asset and production models of your process.
Historians Before Industry 4.0
Before Industry 4.0, there were only three options for Process Historians: use the one built into your SCADA platform, choose from a handful of standalone options, or use both. Many companies did and do choose to use both process historian options.
In the early 2000s, most companies used built-in process historians because dedicated process historians were costly and required a high level of network integration most companies didn't have on the plant floor. But, in the late 2000s, a big push to dedicated historians happened in conjunction with the release of the first major industrial analytics packages such as Wonderware's Historian Client and Incuity (now called FactoryTalk VantagePoint). These early analytics packages allowed users to perform more advanced calculations on their data than the built-in trending tools in SCADA platforms.
As companies began adopting dedicated historians, we shifted towards Industry 4.0. The dedicated historians took advantage of the increasingly connected nature of process automation at the time—which also made it possible for companies to collect and store massive amounts of data from nearly any device. The Industry 4.0 shift brought with it many more dedicated historian packages and IIoT focused products with built-in historian functionality. Now, there are now almost as many places to send your data as there are opinions for structuring your data in the first place!
Process Historians Today
The software referred to as “dedicated process historians” in the early 2000s are now full blown all-in-one software ecosystems which include historical data collection and storage, translation from tag structures into ISA-95 hierarchies and Unified Namespaces, and include incredibly powerful analytics packages.
With the advent of MQTT and Sparkplug B, it is easy to connect many different systems to your MQTT brokers—and reduce or eliminate data duplication. Without limitation, you can now choose the best tool for extracting value from your data. Additionally, you can leverage the power of AWS and Azure to build machine learning models to better understand your data. Then, with report by exception strategies, you can even drastically reduce the bandwidth your data requires.
The overall question has shifted from "why do I need a Process Historian, I already have a SCADA system?" To "how can I get the most value from my data, and what is the quickest possible ROI on this initiative?"
Process Historians and the Unified Namespace
Before Industry 4.0, historians were generally tied into the overall communication architecture alongside a SCADA system. Process Historians were connected to OPC servers or other PLC communication links and storing data from their connection, while the SCADA system used another direct connection to each device. Often, this led to duplicate data across systems, increased network bandwidth requirements, and made troubleshooting much more complicated since there were now multiple places to search.
Fortunately, using Process Historians in a Unified Namespace Architecture eliminates these issues.
Instead of connecting SCADA systems, historians, and other software that needs process data to PLCs over parallel connections, each system can now directly connect to the Unified Namespace for their data. This means data is not duplicated across systems since it comes from a single source of truth.
Using a Unified Namespace architecture also allows for any number of cloud historian and analytics integrations. With MQTT, IT departments no longer have to manage security and connections. Plus report by exception drastically reduces the required bandwidth compared to typical polled communication protocols.
Connecting Process Historians to a Unified Namespace
By viewing the details of the Historian Application Node from our overall Unified Namespace Architecture graphic, we can dig into the mapping between the Historian’s Domain Namespace and the overall Unified Namespace.
When we can use an ISA-95 compliant Asset Model (like with a Canary Labs Historian), we can replicate the Unified Namespace hierarchy in our Process Historian, to simplify data retrieval mapping. The actual historical data will come from the SparkPlug B Data Bus, and/or our MQTT brokers depending on the Process Historian’s capabilities.
If we can’t use an asset model at the Process Historian level, we will need to implement mapping within the Unified Namespace for retrieving data from the Process Historian. This will need to happen in a case-by-case basis, depending on the technology and tools used in a given scenario.
The importance of mapping the Process Historian Domain Namespace to the Unified Namespace is important since it will maintain a consistent user experience for folks interacting with all of the Unified Namespace integrations they are accustomed to using. This approach also opens up historical process data to any users in the organization who can access the Unified Namespace, enabling innovation and understanding through data analytics.
Wrapping Up
With the advent of MQTT, Sparkplug B, and Unified Namespace Architectures, Process Historians have become critical business tools for manufacturing companies. In addition to the industry-leading historians over the years, such as Canary Labs and OSI PI, new tools like Kafka and InfluxDB have been developed specifically to handle event driven and time-series data at scale. These technologies take advantage of MQTT’s built in pub/sub models and report by exception designs to streamline data collection and management. You can also easily integrate built-in Process Historians like the Ignition Tag Historian Module into your overall architecture.
Much like legacy industrial communication protocols such as Modbus, many Process Historians have been installed in facilities for many years and may contain hundreds or thousands of gigabytes worth of data. While it is possible to migrate to a new process historian without losing data, you may need to build data manipulation tools to get data from a legacy historian into a modern Unified Namespace Architecture. A common approach is to first implement a modern Process Historian and begin collecting data as part of the Unified Namespace implementation. Then once is configured and working, begin the process of migrating and backfilling data until you are using a single Process Historian across your organization.
If you have any questions on Process Historians, Unified Namespace Architectures, or how you can leverage them in your company, please reach out and let us know!
