The world lost a vast treasure when the Library of Alexandra was destroyed. Founded in the 3rd century B.C., the library housed more than 400,000 scrolls describing everything from medicine to architecture to culture. This vast treasure trove of data, meticulously recorded by so many ancient scholars, is forever lost.

Today’s data is just as transitory. Data that is not collected, preserved, protected and utilized is at best an inconvenience and sometimes a debacle. That applies to everything from plant floor energy usage, tank levels and cycle counts to priceless scrolls.

Today, we have two competing methods for collecting, preserving and distributing factory floor data. Not just PLC data but diagnostic data from switches, energy data from drives, operational data from pneumatic and hydraulic systems, power quality and environmental data from a vast array of sensors.

Edge Gateways and Historians compete for this task. With similar features, deployment methods and results, it’s not always clear when to use one or the other. In fact, it’s easy to get this decision wrong. Use an Edge gateway, a Historian or a combination of the two? These devices do not play identical roles. The differences are crucial. Using them correctly unlocks productivity, insight, digital transformation and smart manufacturing.

Whether you use an Edge Gateway or a Historian, the data from the vast number of digital devices in your control systems must be preserved and accessible, unlike the lost scrolls from the library at Alexandria.

EDGE GATEWAYS: KEY FEATURES AND USE CASES

An Edge Gateway collects, normalizes and routes data from PLCs, HMIs, drives, and sensors to Enterprise and Cloud applications providing analytics, visibility, and decision-making capabilities at the edge. Edge Gateways prioritize uptime and speed over data retention. Most support store-and-forward operation, but that storage is limited, as data retention is not the primary purpose of an Edge Gateway.

Edge Gateways come with endless varieties of features. Some contain analytics engines to process data locally. Some are vendor-specific, designed to support a particular architecture (e.g., Siemens and Rockwell devices). Some provide scripting engines enabling users to customize how data is formatted and combined.

Six essential features should be in an Edge Gateway:

• Support for a Variety of Data Ingestion Sources: Nothing matters unless the Edge Gateway can collect the data needed by your quality team, analytics or certification systems. Multi-protocol ingestion, multiple PLC support, a variety of network interfaces and legacy device support expands the universe of potential applications.
• Flexible Local Preprocessing & Filtering: Factory floor systems are diverse, complex and often “mature” (old), meaning that Edge Gateways often encounter a variety of data types, formats, units and groupings. Raw data is seldom standardized, even from devices from the same vendor.
• Custom and Standardized Data Modeling: Once that data is collected, normalized and scaled, it must be packaged in a recognizable form. Modeling is not just about organizing and aggregating data from multiple sources in a standard form but also adding the metadata that makes it understandable to a receiver.
• Scalable Integration with Enterprise and Cloud Applications: Publishing data models to enterprise or cloud systems is another key feature. There are a variety of protocols, transports and media for this. The most common include MQTT, MQTT Sparkplug, REST, OPC UA and others. More flexible systems publish data directly to SQL databases, Unified NameSpaces (UNS) and often provide interfaces to well-known MES/ERP systems.
• Simple Deployment & Configuration: Fast deployment is a key feature of the more popular Edge Gateways. Rapid commissioning includes web-based or no-code configuration, plug-and-play device discovery and protocol auto-mapping, all designed to reduce engineering time from weeks to minutes, which is ideal for OEMs and system integrators.
• Cybersecurity: In today’s environment, cybersecurity is always a consideration. However, not all devices are cybersecure. There are various levels of security provided. Choosing an Edge Gateway with the correct level of security for your plant means understanding the threat vectors in the location where you will deploy the device. If deployed deep in a manufacturing system behind firewalls, no special security may be warranted. If deployed closer to IT systems connected to the Internet, you may want to choose a device with advanced firewalls and other protection features.

HISTORIANS: KEY FEATURES AND USE CASES

Historians satisfy a different need than Edge Gateways. Where an Edge Gateway collects and organizes data to publish it to other systems, Historians focus on collecting and retaining data in time-series databases for long-term analysis and reporting.

There are two key design considerations for Historian. One, how rapidly it can collect time-series data and, two, how much storage it has to retain that data. Unlike an Edge Gateway, Historians prioritize data collection and retention, with the exact requirements depending on the specific application. Collection requirements can vary from sub-milliseconds to the end of shift, job or month. Storage requirements can vary from kilobytes to terabytes.

The important features specified in the previous section, for Edge Gateways, also apply to Historians. In addition, there are four indispensable, additional features required of Historians:

• Ingestion Frequency – Rapid data ingestion is more essential to a Historian than an Edge Gateway. Historians are optimized for performance, timestamp accuracy and storage of large tag sets. This is distinctly different from Edge Gateways, which optimize data quality, semantic tagging and efficient transmission, not bulk storage or time-series fidelity.
• Compression – When an application requires massive storage of time-series data, the ability to automatically compress data is vital. Compression schemes and speeds vary. Know your application to choose a product that meets your requirements.
• Timestamping – Knowing the moment when time-scale data arrived is critical to data analytics. This requires the Historian to know the correct time. Some of the various mechanisms Historians use to maintain current time include Real-Time Clocks (RTC), the Network Time Protocol (NTP) and the Precision Time Protocol (PTP). Note that you must have the correct network servers for some of these options.
• Publishing – The ultimate destination for your data is a crucial consideration when selecting a Historian. In addition to supporting the publishing features of Edge Gateways, Historians should also support sending data to the common man’s analytics engine: Excel. Data is often captured in a CSV (Comma-Separated-Values) file over FTP or even in USB sticks. Another useful way some Historians publish data is by direct transfer to larger databases using the APIs of those databases.

Historian applications fall into two main categories: enterprise-level and cell-level. Enterprise-level historians are typically deployed in a VM (Virtual Machine) or Cloud and are designed for ingestion and organization of massive volumes of data. Cell-level historians are typically used for real-time process monitoring or performance optimization. These are a good fit for applications that don’t require the volume or speed of the enterprise-level historians.

About the Author