The One Way Networking feature provides communications of tag values from the local server and remote server within the same DMZ to receiving servers through communication networks that only allow one direction through a communication diode. The receiving server need to have a fixed IP address. The data source servers can be fixed or dynamic.
Each data source server can broadcast to multiple receiving servers. Each receiving service can receive values from multiple data source servers.
The Network Forwarding feature makes it possible for client devices to reach data servers live data through multiple redirect servers, as many as you like, to bridge multiple networks together end to end. If the data servers do not need a fixed IP address it can be used in combination with the Live Data Cloud feature.
In order to use Network Forwarding you just need to install Open Automation Software on each redirect server. If you plan to use different TCP port numbers through the forwarding use Configure-Options-Networking to set the source TCP Port Number and Configure-Options-Remote Services to set the client TCP Port Number.
.NET Tag Access
Using the Tag Browse dialog from any .NET, Excel, or service client enter the IP Address, Network Node Name, or registered domain name in the Network Node field and click on Select.
Then using the Forwarding button define as many redirect servers as you like, each one having Open Automation Software installed and running.
You can optionally specify a Live Data Cloud data server as well if that is the final data server. Of leave the Live Data Cloud data server blank if it has a fixed IP address.
You can then browse for the Tag name and property (most common is Value) to return the following.
In the following example 192.168.249.128 is the first redirect server that forwards communications onto www.opcsystems.com, and then finally the Live Data Cloud server OAS_SONY.
In the following example 192.168.249.128 is the first redirect server that forwards communications onto www.opcsystems.com were the tag resides.
Without a Live Data Cloud Node
\\192.168.249.128\RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED.TagName.Value
There is additional syntax to note when using Network Forwarding.
The network nodes following RemoteSCADAHosting use <dot> in replace of any period. For example and IP address would be represented as 192<dot>168<dot>0<dot>1 instead of 192.168.0.1
All redirect servers are separated by _SUBNODE_
The last server must either be a Live Data Cloud data server or the words LIVE DATA CLOUD NOT USED.
Note: If you are using Calculation Tags, Data Logging, or other service to service communications where the Live Data Cloud server is performing data functions on remote data from data servers you do not need to specify the first server IP address.
RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED.TagName.Value
.NET Tag access is applicable for the following
WPF HMI .NET
WinForm HMI .NET
Cross-Platform HMI
Trend .NET
.NET Data Connector
PCL iOS and Android HMI
Microsoft Excel
Data Logging
Recipe
Calculation Tags
Tunnel Target Tags
Web Tag Access
In the web page specify the IP Address, Network Node Name, or registered domain name that has the HTML HMI registered over your desired port in the serverURL config property.
serverURL: 'http://www.192.168.249.128.com:58725'
Specify the tag names in the HTML code as RemoteSCADAHosting tags without the first network node portion as the Live Data Cloud server is already reached through the serverURL.
RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED.TagName.Value
The web browser can be run locally or remotely, it will communicate to the server specified in the serverURL as a relative path for the tag values.
Web Tag access is applicable for the following
Web HMI
Web Trend
HTTP API for Tag data
HTTP API for Trend data
.NET Alarm Access
Using the Network Node Browse dialog from Alarm Logging, Alarm Notification, or Alarm .NET control enter the IP Address, Network Node Name, or registered domain name in the Network Node field and click on Select.
Then using the Forwarding button define as many redirect servers as you like, each one having Open Automation Software installed and running.
You can specify multiple network nodes in the AlarmNetworkNodes.
\\192.168.249.128\RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED
.NET Alarm access is applicable for the following
Alarm .NET
Alarm Logging
Alarm Notification
Web Alarm Access
In the web page specify the IP Address, Network Node Name, or registered domain name that has the HTML HMI registered over your desired port in the serverURL config property.
serverURL: 'http:// 192.168.249.128:58725'
In the alarm_bindings specify the networkNodes property with RemoteSCADAHosting.
RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED
Web Alarm access is applicable for the following
Web Alarm
HTTP API for Alarm data
OPCSystems.NET OPC Server Access
When providing Tag access to remote third party OPC Clients install OAS setup on each OPC Client PC to install the OPCSystems.NET OPC Server. You can use a Custom installation to install only OPCClient.NET if you prefer not to install everything on the OPC Client PC.
Modify the file NetworkNodes.txt with Notepad or other text editor to add the IP Addresses, Network Nodes Name, or registered domain names that have the OAS server tags running. The file will be in C:\Program Files\Open Automation Software\OAS\.
You can then browse for the Tag name and property (most common is Value) directly in the OPC Client in the Network folder to return the following to the OPC Client as and OPC Item.
OPCSystems.NET OPC Server access is applicable for the following
OPC Client Connector
.NET Configuration Access
The OPCSystems component provides free access to all configuration settings of a service including Tags, Data Logging, Alarm Logging, Alarm Notification, Security, etc.
Each method of the OPCSystems component has an optional NetworkNode parameter and RemoteSCADAHosting parameter. When you specify these parameters it will perform the configuration access to the remote service specified by IP address, network node name, or registered domain name through the Live Data Cloud server to the Live Data Cloud data server.
ResultString = OPCSystemsComponent1.TagCSVImport(CSVStrings, "192.168.249.128", ErrorString, "RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED")
ResultString = OPCSystemsComponent1.TagCSVImport(CSVStrings, "192.168.249.128", ErrorString, "RemoteSCADAHosting.www<dot>opcsystems.com<dot>com_SUBNODE_LIVE DATA CLOUD NOT USED");
.NET Configuration access is applicable for the following
OPCSystems .NET component (free to use)
Web Configuration Access
View the REST API documentation on how to access configuration information via web interface.
The Live Data Cloud feature makes it possible to expose your private OAS instances to external clients and networks via a dedicated OAS hosting instance. You can think of this like a data proxy that sits within a public facing network, such as a DMZ, and routes data from your private OAS instances to external clients. This allows you to make your data available outside of your private networks without exposing your internal network and OAS instances.
The architecture of this feature ensures that your private OAS instance servers do not need a fixed IP address. Each private OAS instance will automatically register themselves with the hosting instance using a unique well-known alias. All your external clients need to know is the domain or IP address of the hosting instance, the alias of the internal server they want to talk to and the Tag path where the data is stored.
With the Live Data Cloud feature you can also pipe data between disparate private networks via a central hosting instance acting as a data gateway. As long as each private network can see the network where the hosting instance is stored and they know the alias of the private instance they want to read data from, the hosting instance will handle the data routing.
Licensing
The Live Data Cloud feature is provided as part of the Distributed Network Architecture feature, which must be enabled in your license on the private OAS instances. In the Configure OAS license screen this is displayed as Networking Enabled.
The OAS hosting instance does not need a license and you can have as many hosting instances as you need. Clients can read Tag data from multiple difference hosting instances.
Security
The credentials that you use to access an OAS instance using Configure OAS or any of the APIs and SDKs also apply to the Live Data Cloud architecture. When you connect to a private instance via the hosting instance, you will need to provide the same credentials that you would if you were connecting to the private instance directly. The same security features apply and you can restrict the allowed operations using a security group configuration.
The connection between the client, the hosting instance and the private instance is encrypted and compressed.
Live Data Cloud Configuration
Every Live Data Cloud architecture needs at least one OAS private instance and one OAS hosting instance. The private instance can be installed in a private network, but it must be able to see the hosting instance network. The hosting instance network can be a private network or a public network as long as it is reachable from the private network and from any networks where the clients will be connecting from.
The OAS instances will use port 58727 as the primary secure communication channel. If this port is not available, it will attempt to connect on port 58737. Please ensure that these ports are permitted through any firewalls that may be present.
Configure the Hosting Instance
On the hosting instance server install the OAS platform. You can use an on-prem server, a virtual machine or a public hosted service provider.
The Live Data Cloud hosting service is now active.
By default, any private instance can now register themselves with the hosting instance. If you would like to limit which instances are allowed to register themselves with the Live Data Cloud hosting instance, see the Restricting Live Data Cloud Registration section below.
Configure the Private Instance
This section assumes that you have one or more private OAS instances already installed and running. You will need the hostname or IP address of the hosting instance you wish to connect to.
Use the Configure OAS application to connect to your private instance.
Select the Configure > Live Data Cloud menu to open the Live Data Cloud screen.
Tick the Enable Hosting checkbox.
Click on the Browse button to bring up the Network Node Editor window.
Enter the IP or hostname of the hosting instance in the Network Node text field and click on the Add button.
This will attempt to communicate with the remote instance to validate the connection. If the connection is not successful you will see an error message.
If you want to skip the validation you can untick Validate when adding checkbox. Select the node and click OK.
Provide a Hosting Name, which is an alias that you will use to access Tag data on this instance. For example: OAS_OT_1
Click on the Add LDC button to add this configuration.
Save your configuration using the Save button.
Your Live Data Cloud configuration is now active.
Restricting Live Data Cloud Registration
By default, any OAS instance that can reach the hosting instance network will be able to register with the hosting instance.
You can make this more restrictive by configuring the allowed Live Data Cloud instances on the hosting instance.
Use the Configure OAS application to connect to your hosting instance.
Select the Configure > Options menu to open the Options screen.
Select the Live Data Cloud tab.
Tick the Disable Live Data Cloud checkbox.
Click on the Edit button.
You will see a list of instances in the Available Nodes list. Double click on the node that you wish to allow. It will appear on the right hand side list box.
Click the OK button.
Your allowed list should now contain the allowed node alias.
Click on Apply Changes to save the configuration.
Connecting to an Instance using Live Data Cloud
To connect to a private instance from an external network you will need to know the hosting instance IP address or host name and it must be accessible from your network.
You can connect to a private instance using any of the connection methods such as Configure OAS, REST API, .NET Data Connector or OAS products that can reference remote tags such as UIEngine, HMI, trend or alarm components, calculations, data logging, recipes, data route, OPC UA client and Excel.
This section provides examples of each type of connection as the method might differ slightly for each case.
Remote Tag Access
You can access Tag data remotely by specifying the Tag name the remote tag notation. In the following example, you are connecting to the 111.122.133.144 IP address, which represents the hosting instance, followed by the RemoteSCADAHosting key word, followed by the private instance hosting name (alias), followed by the Tag path of the Tag you want to read.
This method allows you to read and write Tag data on private instances via the Live Data Cloud hosting instance. It applies to JavaScript applications that use the OAS client libraries for communicating with an OAS engine. In your client code specify the IP Address, Network Node Name, or registered domain name of the hosting instance using the serverURL configuration property.
serverURL: 'http://111.122.133.144:58725'
You can then specify the Tag paths using the RemoteSCADAHosting key word, followed by the private instance hosting name (alias), followed by the Tag path.
An external OAS instance can be configured to perform Alarm Logging and Alarm Notifications by using the Nodes filer provided by these features. Normally, when a local instance is configured for alarm logging or alarm notifications, the Network Nodes filter is set to localhost. However, you can also log and notify based on alarm data sourced from private instances via your Live Data Cloud hosting instance.
Using the Configure OAS application, connect to a local OAS instance where you want to configure alarm notifications or logging.
In the Nodes tab of the Alarm Logging or Alarm Notification screen, click on the Edit button.
Provide the IP or host name of the Live Data Cloud hosting server and click SELECT. In the Live Data Cloud drop-down list, select the private instance hosting name (alias) and click the second ADD button. You will see the node added to the list. Click OK to accept this change. The network node will be listed with the following notation:
Configure the remaining parts of the Alarm Logging or Alarm Notification settings and then add and save your configuration. The instance you just configured will now listen to alarms coming from the private instance but routed via the Live Data Cloud hosting instance.
This method allows you to read alarm information from private instances via the Live Data Cloud hosting instance. It applies to JavaScript applications that use the OAS client libraries for communicating with an OAS engine. In your client code specify the IP Address, Network Node Name, or registered domain name of the hosting instance using the serverURL configuration property.
serverURL: 'http://111.122.133.144:58725'
You can then specify the network nodes using the RemoteSCADAHosting key word, followed by the hosting instance IP or hostname, followed by RemoteSCADAHosting key word, followed by hosting name (alias).
The OAS Engine has the Open Automation Software OPC UA Server included. Connect to server url opc.tcp://localhost:58728 if OPC UA Client is on same PC, or opc.tcp://<NetworkNode or IP Address>:58728.
opc.tcp://192.168.0.1:58728'
Use Remote Tag Access syntax listed above for Live Data Cloud networking. The OPC UA Client will be able to browse for RemoteSCADAHosting under Local or Network as a folder to browse to remote OAS Tags.
When providing Tag access to remote third party Classic OPC Clients install OAS setup on each OPC Client PC to install the OPCSystems.NET OPC Server. You can use a Custom installation to install only OPCClient.NET if you prefer not to install everything on the OPC Client PC.
Modify the file NetworkNodes.txt with Notepad or other text editor to add the IP Addresses, Network Nodes Name, or registered domain names that have the OAS server tags running. The file will be in C:\Program Files\Open Automation Software\OAS\.
You can then browse for the Tag name and property (most common is Value) directly in the OPC Client in the Network folder to return the following to the OPC Client as and OPC Item.
OPCSystems.NET OPC Server access is applicable for the following
OPC Client Connector
.NET Configuration Access
The OASConfig component provides free access to all configuration settings of a service including Tags, Data Logging, Alarm Logging, Alarm Notification, Security, etc.
Each method of the OASConfig component has an optional NetworkNode parameter and RemoteSCADAHosting parameter. When you specify these parameters it will perform the configuration access to the remote service specified by IP address, network node name, or registered domain name through the Live Data Cloud server to the Live Data Cloud data server.
Basic Networking is at the core of every OAS Engine instance and OAS component based client. It provides the networking foundations and connectivity that allows you to create different types of network architectures and move your data in a secure, efficient and reliable manner between different hosts and across private and public network boundaries.
In this guide we will explore the different use cases for Basic Networking including remote configuration, remote tag access and we’ll explore a few different example architectures that can be implemented using the networking functionality of OAS.
👉 For standard configuration, information about ports and licensing see the Getting Started – Networking 🔗 page.
Remote Tag Access
Using the Tag Browse dialog from any .NET, Excel, or service client enter the IP Address, Network Node Name, or registered domain name in the Network Node field and click on Select.
You can then browse for the Tag name and Variable (most common is Value). See Tag Variables for a complete list of all variables possible.
In the web page set the serverURL to the IP Address, Network Node Name, or registered domain name of the Linux or Windows devices where the OAS Engine located.
serverURL: 'http://192.168.0.1:58725'
Specify the tag names in the HTML code as local tags. The web browser can be run locally or remotely, it will communicate to the server specified in the serverURL as a relative path for the tag values. In this example the tags would be running on the same server as 192.168.0.1.
TagName.Value
If the tag is located on a different system than the serverURL or you want to host data from multiple OAS Engines use the Remote Tag Access syntax.
Using the Network Node Browse dialog from Alarm Logging, Alarm Notification, or Alarm .NET control enter the IP Address, Network Node Name, or registered domain name in the Network Node field and click on Select.
You can specify multiple network nodes in the AlarmNetworkNodes.
In the web page specify the IP Address, Network Node Name, or registered domain name that has the HTML HMI registered over your desired port in the serverURL config property.
serverURL: 'http://192.168.0.1:58725'
To host remote OAS alarms from different nodes than the serverURL specify the NetworkNodes: property in the Alarm Bindings.
The OAS Engine has the Open Automation Software OPC UA Server included. Connect to server url opc.tcp://localhost:58728 if OPC UA Client is on same PC, or opc.tcp://<NetworkNode or IP Address>:58728.
opc.tcp://192.168.0.1:58725'
Use Remote Tag Access syntax listed above for Basic networking. The OPC UA Client will be able to browse for Network as a folder to browse to remote OAS Tags.
When providing Tag access to remote third party Classic OPC Clients install OAS setup on each OPC Client PC to install the OPCSystems.NET OPC Server. You can use a Custom installation to install only OPCClient.NET if you prefer not to install everything on the OPC Client PC.
Modify the file NetworkNodes.txt with Notepad or other text editor to add the IP Addresses, Network Nodes Name, or registered domain names that have the OAS server tags running. The file will be in C:\Program Files\Open Automation Software\OAS\.
You can then browse for the Tag name and property (most common is Value) directly in the OPC Client in the Network folder to return the following to the OPC Client as and OPC Item.
Network.192.168.0.1.TagName.Value
OPCSystems.NET OPC Server access is applicable for the following
OPC Client Connector
.NET Configuration Access
The OASConfig component provides free access to all configuration settings of a service including Tags, Data Logging, Alarm Logging, Alarm Notification, Security, etc.
Each method of the OASConfig component has an optional NetworkNode parameter. When you specify this parameter it will perform the configuration access to the remote service specified by IP address, network node name, or registered domain name.
As outlined on the Networking Overview page, the Unidirectional Network Gateway can be used to pass data from one OAS engine to another in a way that ensures data can only flow from the source to the destination and never the other way around. Normally, when an OAS engine uses Basic Networking or Live Data Cloud, one OAS engine can both read and write remote tags on another OAS engine. This type of communication is often used with remote data logging and Data Route. Whilst it is possible to use permissions to prevent reading and witing tags, this level of isolation is not sufficient for some use cases. The Unidirectional Network Gateway aims to solve this problem using a lower level isolation approach.
The Unidirectional Network Gateway is in fact also known as UDP Broadcast and UDP Receive, because it makes use of UDP – User Datagram Protocol – to create unidirectional data streams. By using UDP instead of TCP, the data can be sent from the source engine to a destination engine UDP port, which ensures data can only flow from the source to the destination OAS engine and not the other way around.
In the source OAS engine, you will specify the destination IP or host and port number on the UDP Broadcast screen. One destination OAS engine on the other hand, you will specify a port on which to listen for tag changes. These two port numbers must match. The following diagram shows an example:
The feature is included for free in all OAS systems.
See the following video for more practical information.
The feature supports broadcasting data from any tag variable from a the local server or remote servers within a local network to unlimited number of receiving servers. Each receiving server can be setup to receive data from multiple broadcast servers providing many to many data transfer.
Use the following steps to setup servers to broadcast data and receiving services to update local and remote tag variables from the broadcasting nodes.
The receiving nodes need to have a fixed IP address, registered domain name, or network node name. The broadcasting nodes do not need to have a fixed IP address.
Step 1
Start Configure OAS application.
Step 2
From the data source service select Configure-UDP Broadcast.
Step 3
Select the Local OAS Service by selecting the Select button next to the Network Node drop down.
Step 4
Click the Checkbox to Enable UDP Broadcast and enter the Server Port number and Broadcast Rate which is the rate all values from this service will be broadcast to the receiving clients.
Click on Apply Changes.
Click the Add Button and enter each receiving client IP Address and Port Number in the popup window and click OK.
Step 5
Choose to send all tag values from the local service on each broadcast or uncheck the property Send All Local Tags to define a list of tags from the local system, remote systems, and all variables.
By defining which tags to broadcast has the following benefits over Send All Local Tags.
Reduced network packet size on the broadcast if the number of tags sent is less then the number of local tags.
Can broadcast any Tag Variable, not just the Value.
Can broadcast tag values from other remote nodes within the DMZ.
Step 6
Select the Save button on the toolbar at the top.
Step 7
Save the file myUDPBroadcastServer.UDPBroadcast in the directory of your choice.
You can specify for this configuration to load automatically when the Service starts using Configure-Options to specify this default UDP Broadcast file.
Step 8
From the receiving service select Configure-UDP Receive.
Step 9
Select the Local OAS Service by selecting the Select button next to the Network Node drop down.
Step 10
Click the CheckBox to Enable UDP Receive and enter the desired watchdog rate. The watchdog rate is the amount of time it will wait before setting the receiving tags quality to bad without receiving a broadcast.
Click on Apply Changes.
Click the Add Button to add a Port Number to listen on and select OK. You can enter multiple receiving port numbers.
Step 11
Select the Save button on the toolbar at the top.
Step 12
Save the file myUDPBroadcastClient.UDPReceive in the directory of your choice.
You can specify for this configuration to load automatically when the Service starts using Configure-Options to specify this default UDP Receive file.
Step 13
In the receiving node select Configure-Tags. Add Tag’s with the Data Source of UDPClientTag and enter the Tag name of the broadcasting node you want to receive the value from.
Keep in mind you may not be able to browse for the tag name from the broadcast node, so you may have to manually enter it or use Tag CSV Import or programmatic tag setup using .NET or REST API to setup multiple tags.
The Tag defined must match the broadcast tag name defined in Step 5.
Examples:
Ramp.Value
Ramp.HighAlarmActive
\\192.168.0.1\Ramp.Value
Save the Tag Configuration file and specify it to load automatically under Configure-Options-Default Files.
The OAS Service must be started to be accessed by a local or remote OPC client component or application. Use the OAS Service Control application to Start the Service.
If you are using a Firewall make sure to open up TCP port 58727 for both inbound and outbound traffic. You can find what port number is used under Configure-Options-Networking in the service, 58727 is the current default port number.
You can check if the TCP port is open using the Windows Command Prompt with the following command on the same computer as the OAS Service.
netstat -an | find “58727”
If the service is not started or the port is not open then the command will just return without any results.
To check a remote computer port use PortQry from Microsoft.
Run PortQryV2.exe to extract to desired directory.
Use the Windows Command Prompt from the PortQryV2 directory with the following command. Replace 127.0.0.1 with the IP address of the remote system where the OAS Engine is running.
portqry -n 127.0.0.1 -e 58727
If this test fails check the network connection to the remote system and open the TCP port for incoming and outbound traffic in the firewall and antivirus software.
How can I define IP Addresses when browsing for network nodes?
Use the Configure-Options-Networking in the Configure OAS application to define a list of IP addresses in the Network Nodes field as shown in Networking OPC Data.
How can I change the default WCF Port Number to use in the OAS Service and Client applications?
Go to Configure-Options Networking and set the WCF Port Number.
View the following video for adjusting the client applications and how to adjust WCF port number in the realtime service and all client applications:
How can I host my OAS Service on the Internet without a fixed IP Address or registered domain name?
Use the Live Data Cloud feature that is free to use.
How to host data from any Windows PC with a standard Internet connection. No fixed IP Address or registered domain name required.
Do I need to make a web application in order to access data over the Internet?
No, all Open Automation Software client applications and services support Internet communications in Open Automation Software by default. You can deploy them as Smart Clients.
When trying to connect to a local or remote OAS Service an error occurs and access is denied.
View the Remove OAS Service Access section is this file.
When I select localhost I receive an error
Try 127.0.0.1. If it works you can correct your hosts file where is shows localhost.
Data packet size is limited on Windows XP and Windows Server 2003 for UDP Broadcasts
If you setup a large number of tags to be transferred via UDP Broadcast sent from or received on XP or Windows Server 2003 and the data is not transferred, but is with a small number of tags download and install the following Hotfix.
https://support.microsoft.com/en-us/kb/824838
Edge network platform for IIoT communications. Host data directly at the source.
Basic Networking
How to network all products to central service using a fixed IP Address or registered domain name for the Internet.
Unidirectional Gateway
How to transfer data through networks with one way communication data diodes.
Live Data Cloud
How to host data from any Windows PC with a standard Internet connection. No fixed IP Address or registered domain name required.
Adjustable WCF Port Number
How to adjust WCF port number in the realtime service and all client applications.
Modern OAS now uses TCP Port Number with default value of 58727 which is also adjustable with the same methods.
Excel with Live Data Cloud
How to use OPCExcel.NET with data service being hosted with free Live Data Cloud feature over the Internet.
Data Log with Live Data Cloud
How to use Data Logging with data service being hosted with free Live Data Cloud feature over the Internet.
OPC Client with Live Data Cloud
How to use OPCClient.NET with data service being hosted with free Live Data Cloud feature over the Internet.
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.
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:
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.
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:
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.
