dataPARC Corporate Architecture Best Practices

dataPARC not only provides powerful data visualization and analytics features within a single site or location, but can also connect data across multiple plant sites and corporate offices to ensure that the entire organization has quick access to all data and information needed for optimum decision-making.  The overall system architecture can be configured in multiple ways, with the best design depending on a number of customer-specific factors.  This article discusses these considerations relative to the following corporate architecture types:

• Single Centralized Corporate Server

• Distributed Servers

• Distributed Servers with Dedicated Corporate Server

Note:  For more details specific to historian architecture, please refer to this article:  dataPARC Historian Architecture Best Practices

Single Centralized Corporate Server

A corporate dataPARC architecture built around a single, central server is often the simplest and most economical choice.  In this scheme, the dataPARC application server resides in one central location, often the corporate headquarters.  Data sources from all remote operation sites are connected to the application server via the corporate wide area network (WAN).  Clients at all remote sites also connect to the application server via the WAN.

Considerations

A single, centralized dataPARC application server offers the advantage of requiring less actual or virtual hardware and overhead to maintain, as well as consolidating all sites’ data into a single point.  However, it requires connections to raw data sources over a WAN, which may involve long physical distance.  Depending on the WAN speed and the volume of data to be transferred, some performance limitations may be encountered.

Similarly, any dataPARC client connecting to the central server from a location other than the server site must communicate via the WAN.  Again, depending on the nature of the data visualization or analysis required, client performance may be slower than if the server connection were physically local.

Typical Use Case

Industries with a large number of small, widely distributed operating sites may benefit the most from a single, centralized application server architecture.  In these cases, the overall data load may be high, but each individual site typically provides a relatively small number of tags.  Similarly, each site may only have a few dataPARC client users, while a greater number of users are located at the corporate headquarters.  Thus, it may be impractical to deploy a dataPARC application server at each site due to the large number of them, and the client load at each site may be low, meaning that performance reduction for remote clients is not too severe.

Distributed Servers

A distributed server architecture places a dataPARC application server at each of a company’s operating sites.  Data source connections are made locally, and local user clients communicate with the application server via the Local Area Network (LAN).  Each site’s application server is configured to connect to the other locations via dataPARC’s “Location” settings, allowing client access to data from other sites.  This architecture is also known as a server “mesh”.  User clients at corporate headquarters or other non-operation sites must connect to one of the application servers via the WAN.

Considerations

A distributed server architecture offers the advantage of fast and robust connectivity to the local data sources at each site.  It also allows user clients at operating sites to connect to a local application server that contains most of the data they need since it is connected to the local data sources.  This means that the vast majority of data access is fast and reliable.

However, since application servers at various sites are connected via the WAN, inter-site data access is still subject to any speed limitations of the longer-distance network.  Additionally, corporate user clients must connect to one of the site application servers, which may result in slower performance than experienced by those local to the site.  The choice of which application server to connect to is typically dictated by physical distance and/or the need to distribute client load among the sites.

Typical Use Case

Companies with a small number of complex operating sites, each containing a large quantity of data often choose a distributed server architecture.  This architecture is a good choice if local user clients’ fast, reliable access to data at their particular site is a priority.  These companies often have a much smaller number of corporate or other non-operation site users, so any data access speed penalties for those clients are minimized. Inter-site data exchange is still provided via the WAN as well, but this is typically not the primary goal of the system.

Distributed Servers with Dedicated Corporate Server

This architecture is the same as distributed servers above, but adds one additional application server at the corporate or other centralized location.  Data source and client connections at each site remain local, but corporate client users are able to connect to their own application server.  The centralized corporate server is connected to each site’s application server via dataPARC’s “Location” settings.  If the application servers include historians, the historian data can optionally be mirrored on the central corporate server.

Considerations

This architecture type offers all the advantages of distributed application servers, but also improves client performance for users at the corporate location, since they are also able to connect to a local server.  Site application server loads are reduced as well, since the corporate clients are not all individually connecting - they must only maintain a single connection to the corporate server in addition to the local site clients.  If the site servers include historians, and the historian data is mirrored on the central corporate server, this provides even further performance improvement as well as an always-current data backup.

Of course, this additional server comes at a cost, both in terms of hardware/software and maintenance overhead, adding another level of complexity to the system.

Typical Use Case

The choice to add a centralized corporate server is typically driven by the number of corporate users and the volume of their data access needs.  If a large number of corporate clients need to access data across all operating sites, addition of a centralized server is often worth the extra expense and maintenance overhead.  In some cases, companies may also choose a “hybrid” architecture, where major operation sites have distributed servers while a centralized application server is also connected to its own data sources coming in from several smaller remote operation facilities that aren’t large enough to warrant their own application server.