Getting Started – Networking

Networking functionality is a core feature of Open Automation Software and is also known as the Distributed Network Architecture (DNA) feature. As outlined in the Networking Overview, there are three main communication types that OAS provides for transferring tag data between OAS Engines and clients depending on what networking architecture is required:

These methods can be used in isolation or together to achieve different types of networking architectures and allow you to move you data from your data sources to your data destinations.

Within the context of OAS Networking discussed here, a client could be defined as another OAS Engine or one of the OAS .NET connectors or .NET HMI or Web HMI components used for reading and writing tag data. Whilst features such as the REST API, MQTT and Cloud based connectors are also used to transfer tag data, these are not considered core features of OAS but rather considered separate drivers with independent configuration options.

When is Networking used?

The Networking functionality of OAS is used whenever you move data between two or more OAS Engines or between an OAS Engine and one or more OAS clients. More specifically, when we are talking about data, we are actually talking about Tag data. A Tag is the fundamental representation of a unit of data in OAS and consists of a value, a timestamp and a quality state. The tags you define and organize in OAS represent your data model – be it a business process, a monitoring processes or some other logical representation of a physical state.

Using the configurable features of OAS, you can move tag data between engines and between engines and clients without having to do the heavy lifting of implementing any communications protocols yourself. Your own custom solutions and applications can leverage existing OAS libraries to read and write data – all you need to know is the tag path, name and parameter name you wish to read or write. The power of OAS Networking becomes more apparent with an understanding of Remote Tag Access.

When a tag is referenced locally to a particular OAS Engine (for example, by setting a tag’s data source to Tag and pointing to another tag) or from a client connected to a particular instance, it can be simply referenced by the path, name and parameter, as mentioned previously. This looks something like this:

MyTag.Value

Let’s now look at how you might reference a tag on a remote OAS Engine. In other words, an OAS Engine or client referencing a tag that is not on the same OAS Engine or the OAS Engine that the client is connected to. This is where the Basic Networking communication comes in. When you want to reference a tag on a different OAS Engine it is as easy as adding the remote node’s IP address, host name or domain name.

\\Instance1\MyTag.Value

OAS will handle all of the engine to engine data transfer automatically and you do not need to do anything differently in your clients. In the diagram above, you can see that the client is connected to Instance2, but the tag reference is a remote tag reference. Instance2 will automatically route the request to Instance1 and retrieve the data. Depending on if you are using a .NET or a Web client (see next section) the remote tag access will be configured slightly differently.

👉 More information about Basic Networking 🔗

The second remote tag access method is the Live Data Cloud method. This is where tag data is routed through an intermediate OAS Engine and is designed to allow separation of networks. In this type of communication, tags are referenced using the alias name of the Live Data Cloud host node. For example:

\\www.opcsystems.com\RemoteSCADAHosting.Instance1.MyTag.Value

In this case the domain www.opcsystems.com represents the Live Data Cloud host node and Instance1 is the alias for one of your internal OAS Engine instances. The RemoteSCADAHosting prefix let’s OAS know that this special format is being used. The remainder of the tag path is the same as a standard tag reference.

👉 More information about Live Data Cloud 🔗

.NET vs Web Clients

Clients within the context of OAS can be divided into two general categories – .NET clients and web clients.

.NET clients include the OAS Configuration Tool and any custom application that uses the .NET OAS components such as:

These components will natively communicate with an OAS Engine using the core TCP networking functionality provided by OAS as explained in the Networking Overview.

The web clients on the other hand use HTTP based protocols to communicate with the OAS Engine. These components include:

Licensing

Networking functionality is enabled with the DNA feature enabled in your license. You can check your license in the OAS Configuration tool by going to the Configure > License screen and checking that you can see the phrase Networking is Enabled.

There are some architectures that do not require networking, such as hosting services on one server

The Live Data Cloud hosting server does not need a license as its only purpose is to route traffic between data source servers and clients. Your OAS Engine at the data source will typically be licensed for the features and drivers that you require.

Configuration

For OAS Engine configuration changes you have the option to use the OAS Configuration tool or to use the .NET OAS Configuration SDK or the Server Configuration REST API. From this point on this guide will only mention the OAS Configuration tool in order to minimize duplication.

Limits

➡️ Each OAS Engine can support up to 10,000 simultaneous client connections.

➡️ Each client application can support connections with up to 10,000 independent OAS Engines.

➡️ The resources of your hosting server or environment as well as the networking bandwidth and connection quality may play a role in the overall performance of the system. It is important to monitor the CPU, memory, storage and network throughput of your environment to ensure OAS is performing as expected.

Polling Rate

Clients will request tag data from an OAS Engine at a regular interval. The first poll will send all requested tag data and any subsequent poll will only send data changes.

The default polling rate for clients is 30 milliseconds. This can be configured using the OAS Configuration tool on the Networking tab of the Configure > Options screen.

Recommended polling intervals for larger number of client connections:

  • > 100 client connections — 100ms
  • > 1,000 client connections — 1,000ms

⚠️ The OAS Engine will need to be restarted for the change to take effect.

Listening Ports

OAS uses a number of standard ports for communication between OAS Engines and clients depending on the technology that is used.

OAS Engine and .NET client OAS components

For OAS Engine to OAS Engine and for OAS Engine to non-web client OAS component communications two ports are exposed on the OAS Engine. These are called the primary and backup ports. These ports provide a bidirectional, compressed and encrypted data stream.

  • Port 58727 – Primary Port Number
  • Port 58737 – Backup Port Number

The backup port is used to listen for incoming client connections should there be a problem with the primary port. The OAS Engine will automatically attempt to use the backup port if the primary port is not available. The following diagram illustrates OAS Engine to OAS Engine communications.

The following diagram illustrates OAS Engine to non-web clients where the OAS Dotnet libraries are used for OAS Engine communications. This allows OAS components and HMIs to use the same benefits of compression and encryption. Note that all of the non-web clients will use the primary port, except the OAS Configuration Tool which will use the backup port if the primary port is not available.

Web clients

Web based clients and REST API clients use a different port to the primary and backup port exposed by the OAS Engine. This is because the web-based components do not use the same TCP stream based data transfer, but instead require a HTTP style communication API.

  • Port 58725 – Web and REST API Port Number

The Web API port is used for web-based clients such as the Web HMI JavaScript based features and controls. It is also used by the REST API and UIEngine.

Legacy Ports

There are two legacy port numbers used for communicating with old versions of OAS using the WCF or the .NET Remoting frameworks.

  • Port 58724 – Legacy WCF Port Number for OAS version 11 or older
  • Port 58723 – Legacy .NET Remoting Port Number for OAS version 4 or older

These port numbers are not configurable and are not available on Linux. To enable communication with a legacy OAS version using .NET Remoting, you can enable this feature by ticking the Enable Classic TCP (Unsecure) checkbox.

Port Configuration

The primary, backup and web ports listed in previous sections are configurable using the OAS Configuration tool on the Networking tab of the Configure > Options screen. Note that if you make changes to these ports there may be other applications that need to be updated. For example, the OAS Configuration tool and the OAS Service manager application will need to use the updated primary port to function correctly. Similarly, any OAS Engines or clients will need to be updated – for more details see the Change Network Port Numbers page.

Remote Services Ports

An OAS Engine (local engine) can communicate with a remote OAS Engine (remote engine) using the default port configurations as listed in the previous section. However, if you choose to change the listening ports on the remote engine and the local engine needs to communicate with the remote engine, then you will need to configure the Client Ports on the local engine to match the ports used by the remote engine.

You can configure the client port settings in the OAS Configuration tool on the Remote Services tab of the Configure > Options screen.

⚠️ Note that this setting will apply to all client communication initiated by the local engine. In other words, all remote engines that the local engine needs to connect to must have the same primary port numbers and the same backup port numbers. You cannot have a local engine that connects to two different primary port numbers or two different backup port numbers.

The Client Watchdog Rate parameter allows you to set a communication retry timeout on the local engine. If no communication is detected for the given number of seconds, the connection will be reset and a new reconnection attempt will be made.

Security

Access to reading and writing tag values is managed using OAS Security features. This includes creating user accounts with specific permissions that OAS Engines and clients will use to authenticate as well as mechanisms to manage permissions for reading and writing at the tag level.

👉 More information about Security 🔗

👉 More information about Restricting Tag Access 🔗