Typical OAS Architectures

The Concentrator architecture relies on a single OAS instances for connecting to all of your data sources and also hosts all of your data destinations such as data logging and HMI integration. This architecture can be adjusted for redundancy by adding additional instances and exchanging data between them. This architecture works great when you have a simple network, all of your field devices connect directly to a central server and you do not have any requirements for data processing, logging or visualization at the edge.

The Edge architecture is commonly used when you have multiple remote sites, each on separate edge networks with multiple field devices at each site, and a centralized operations centre. Each edge location can be licensed for a different number of tags, products and drivers, or you can share features across all edge instances and distribute the tags using flex tag licensing. This means you can configure each edge for local requirements as well as facilitate remote data transfer to a centralized location using the OAS Basic Networking feature. Licenses are typically applied at the edge and the centralized OAS instance acts as a data gateway.

An important benefit of this architecture is that the edge OAS instances can be configured to store and forward data in case of loss of networking. This means not only is data encrypted and compressed in transit, there will also be zero data loss.

The Protocol Converter architecture is designed to allow you to move data between devices that use different protocols and to move data from a device directly into the Cloud. You can use any of the OAS supported protocols to read and write your data, such as Allen Bradley, Modbus, MTConnect, OPC UA/DA and Siemens. For Cloud connectivity, OAS supports AWS IoT, Azure IoT, Kafka and generic MQTT messaging.

This architecture uses the Data Route feature to move data from one set of tags to another or to publish data from a set of tags into the Cloud. The Data Route feature handles the data routing without writing any code. For more information see this article on IIot Data Transfer.

The IT/OT architecture is a typical 2-tier networking arrangement for segregation of OT and IT networks where the OAS instance in the OT network is deployed as a concentrator or edge deployment and an additional OAS instance is deployed in a DMZ to make data available to the IT network.

Depending on the security requirements, you can use a number of different configurations to achieve this architecture. If your DMZ OAS instance is simply acting as a data router, clients connecting to the DMZ OAS instance can use standard Basic Networking remote tag notation to reference the OT instance tag names. This way you only need to license the tags on your OT instance, but note that this does not support store-and-forward in case of networking loss.

If you want a copy of your data in the DMZ OAS instance, you will need to replicate the tags stored in the OT OAS instance. You can choose the method that suits you best:

• If you want the tags to be read-only in the DMZ then you can use the “Tag” Data Source (Basic Networking). Note that this does not support store-and-forward.
• If you want data to be read-write you can use a Proxy configuration (Live Data Cloud). Note that this does not support store-and-forward.
• If you want fine-tuned control over which data is copied and when it is copied you can use the Data Route feature on the OT instance to push the data to the DMZ.
• If you require a highly isolated OT network with no overlap, you can use the Unidirectional configuration (Unidirectional Network Gateway) to push data directly from the OT network into a DMZ or the IT network in a one-way data configuration.

The 3-Tier architecture is similar to the IT/OT architecture outlined above, except that it also introduces an IT DMZ with a third, public facing OAS instance. All of the details explained in the IT/OT architecture apply to this, but the 3-Tier architecture would be used if you require integration with external clients or third-party Cloud platforms (AWS IoT, Azure IoT and MQTT).

You can move data into your IT DMZ OAS instance using the same principles explained in the IT/OT architecture. Using the Proxy configuration (Live Data Cloud), you can create an alias that represents your OT DMZ instance and thus make the tag data available to external clients using the tag path notation shown in the Proxy architecture below.

Cloud IoT integrations can be achieved using the “Publish Tags” functionality to push messages to the Cloud. You do not have to replicate the tags license in the IT DMZ as it can remotely access the tag data via the OT DMZ OAS instance.

The Proxy architecture provides a hosted OAS instance, typically in a DMZ, that acts as a proxy between other networks, external networks or public clients and internal OAS instances. This architecture typically uses Live Data Cloud and can supplement other internal architectures such as Concentrator, Edge and IT/OT.

Using Basic Networking, the OAS instance acts as a data router allowing clients to request data from remote OAS instances without having to directly talk to a remote instance. This is very similar to the IT/OT architecture, but in this architecture only the instance in the DMZ is required to have a static IP. The internal instances can have dynamic IPs and will automatically register themselves with the OAS instance in the DMZ using an alias. Clients can use the alias of the instance they want to request data from as a prefix in the tag path as shown in the Live Data Cloud remote tag access documentation.

The Unidirectional architecture is designed to protect your vital, safety critical networks by only allowing data to flow in one direction. It works by using a broadcast style protocol called UDP to send data out of the vital network and into one or more non-vital networks based on a simple IP/host and port number configuration. Since UDP does not require acknowledgement, no traffic is required to flow back into the vital network.

This feature, called Unidirectional Network Gateway or UDP Broadcast, is specifically designed for highly critical systems such as nuclear power plants, military networks and other types of safety systems. The main aim of this architecture is to mitigate against network based attacks and remote configuration changes.

The Embedded architecture is used when OAS is hosted on a device that supports a Windows IoT or Linux operating system (such as Raspberry Pi) and provides on-board or locally connect I/O capabilities. This allows you to create an all-in-one IoT device powered by OAS and is typically used by OEMs.

This instantly gives you all of the features that OAS can provide including data logging and buffering, alarm management and notifications, REST API and an HMI using UIEngine. With private labelling and the OAS configuration API you can hide OAS and make the device your own product.