dataPARC Historian Architecture Best Practices
  • 25 Jan 2024
  • PDF

dataPARC Historian Architecture Best Practices

  • PDF

Article summary

HeaderImage12

Many architecture options exist when building a process data historian system. The best configuration depends on a variety of factors specific to each site, but some overall guiding principles are helpful to start the architecture design process. This document will outline basic best-practices when deploying the dataPARC Historian in three common scenarios:

Single Site Historian

A data historian solution installed on-premises at a single physical plant site typically requires the simplest architecture. However, several concerns such as security, reliability, and cost must be considered.

Standard Single-Firewall

The example diagram below shows a typical system with a single firewall. One or more Data Collector PCs are installed on the Process Control Network (a.k.a. O.T. Network) to allow direct, fast data streaming from automation devices and other real-time data sources. The Data Collector buffers and packages this data to be sent to the dataPARC Historian server. Data Collectors typically do not need to be high-performance PCs, and can often be combined for several data sources if fitted with proper network connectivity.

Typically only two ports must be opened through the firewall between the Process Control Network and the Business Network (a.k.a. IT Network), minimizing security concerns. Data is transmitted from the Data Collector to the dataPARC Historian server via the GRPC protocol.

The dataPARC Application server may be a separate machine, or it may be shared with the dataPARC Historian server, depending on the site’s size and expected data loading. Communication between the Historian and Application servers is also by GRPC protocol. The dataPARC Application server may also exchange data via a variety of protocols with other sources on the Business Network. The diagram below shows several examples, but many others are possible.

dataPARC Client workstations, also on the Business Network, communicate with the Application server via OPCUA. This yields high client performance since all communications to and from the Application server occur on the same network.

DMZ Implementation

If a greater level of separation between the Business Network and the Process Control Network is desired for security purposes, a single site may opt to set up a DMZ where the dataPARC Historian server will reside. Note that in this case, the Historian server will also require SQL (can be SQL Express or PostgreSQL) example of this option is shown below:

Enterprise-Wide Historian

Companies with more than one physical plant site also have options when building-out a fully-connected historian solution. Each site’s architecture is typically similar to the examples above, although there may be some variation between sites within one organization.

Multi-Location “Mesh”

dataPARC provides the ability to interconnect multiple “Locations” to build a mesh-style network of plant-site data historians. In this way, users at each site may view data from any other site within the company, provided all sites reside on the same Wide-Area-Network (WAN), and each Application Server’s PARCsecurity settings are configured to allow connections to/from other servers. If sharing of pre-configured displays across sites is also desired, links to other sites’ PARCview displays share directory may be added to each Application Server’s displays directory, and appropriate file permissions must be configured.

Centralized Corporate Historian

If inter-site data access loads are expected to be high, overall system performance can be improved by implementing a centralized Corporate Historian and Application Server. This server can mirror the historians of all site locations, and can also host client connections from all sites who wish to view data from outside their own location. Each site Application Server only needs to serve its own local clients, instead of also serving clients from multiple other sites, reducing load on each server. The Corporate Application Server serves all Corporate clients as well as inter-site client connections, improving performance for inter-site data access.

Cloud-Based Historian

The dataPARC Historian and Server Applications are compatible with installation on both Amazon AWS and Microsoft Azure cloud platforms. Cloud historian architecture offers the advantage of a highly scalable system with geographically-independent connectivity and no hardware purchase or maintenance requirement. However, cloud hosting can lead to significant ongoing costs, and data streaming performance at the client will be dependent on web connection speed/reliability. Additionally, extra cybersecurity precautions may be needed due to the transmission of all collected data across the web to the cloud server.

The diagram below shows an example in which the Historian and Application Server are all hosted in an Azure Cloud Environment. Note that the firewall between the Process Control network and the Business network is still in place.


Was this article helpful?