One Click SCADA
Automatically setup Tags, Alarm Limits, Data Logging, Trending, Alarming, and HMI Smart Client in one step.
One Click HMI
Smart Client application that will display all data from any Open Automation Software data service.
Visit www.automatedhmi.com for a quick review of the Automated HMI feature.
Trend and Alarm Historian
How to use the Trend and Alarm Historian container. Pre-built application to run locally and remotely.
NOTE: If you want to visualize your data in a desktop or mobile browser with zero programming, you may be interested in the OAS Open UIEngine .
The UIEngine is a robust no-code web application and HMI builder for developing rich user interfaces in a browser-based development environment.
See the UIEngine Documentation to learn more.
You can view Trends and Alarms Dashboard video to review the steps of using this application.
The Trend Navigator Bar is used to add, modify, and delete Trend Windows that can be selected to be added to the current view configuration.
To view the list of Trends select the Trends button at the bottom of the Navigator Bar.
Select the Add button to add a Trend Window to the configuration. This will display the Trend Window setup form.
You can define a list of pens to be used with the trend on startup or use the Pen Groups feature and leave the list of Pens blank.
If you will be deploying the Trends and Alarms Dashboard configuration to remote PCs or using the application on a different PC than where the OAS Engine resides implement either Basic Networking syntax or Live Data Cloud Networking syntax by entering the IP Address or Network Node in the Network Node field and click Select or optionally select the Live Data Cloud node where the tags are hosted.
Local Tag
myGroup.myTag.Value
\\192.168.0.1\myGroup.myTag.Value
Live Data Cloud Networking from local OAS Engine
RemoteSCADAHosting.myLiveDataCloudNode.myGroup.myTag.Value
Live Data Cloud Networking though remote OAS Engine
\\192.168.0.1\RemoteSCADAHosting.myLiveDataCloudNode.myGroup.myTag.Value
Enter the desired Trend Window Name that will identify the Trend Window in the configuration. You must use a unique name that does not already exist.
Select OK to accept the changes or Cancel to abort the recent changes to the window.
Make sure to select File-Save if you add a Trend Window.
Select an existing Trend Window from the Trend List and then Modify button to modify the Trend Window. This will display the Trend Window setup form.
Select one or more existing Trend Windows from the Trend List and then the Remove button to remove the Trend Windows from the configuration.
Make sure to select File-Save if you remove a Trend Window.
Select a Trend Window from the Trend List and then the Activate Trend Window button or simply drag the Trend Window name into the main application to add the Trend Window to the view screen. You can add the same Trend Window more than once if you desire as you can make on-line modifications.
Once the Trend Window is activated the window can be left as free floating to any size or location or it can be docked within the main docking area.
Select File-Save after the Trend Window is docked or placed into the location you would like it to be.
The Pens Navigator Bar is used to add, modify, and delete Pen Groups that can define a list of pens to add to an existing Trend Window that is activated.
To view the list of Pen Groups select the Pens button at the bottom of the Navigator Bar or select Edit-Pens.
Select the Add button to add a Pen Group to the configuration. This will display the Pens setup form.
Enter the desired Pen Group Name that will identify the list of Pens in the configuration. You must use a unique name that does not already exist.
Select OK to accept the changes or Cancel to abort the recent changes to the Pen Group.
Make sure to select File-Save if you add a Pen Group.
Select an existing Pen Group from the Pens List and then Edit button to modify the Pen Group. This will display the Pens setup form.
You can use the Edit function to also clone an existing Pen Group to a new Pen Group simply by specifying a Pen Group name in the pens properties dialog.
Select OK to accept the changes or Cancel to abort the recent changes to the Pen Group.
Make sure to select File-Save if you modify the Pen Group.
Select an existing Group from the Pens List and then the Remove button to remove the Pen Group from the configuration.
Make sure to select File-Save if you delete a Pen Group.
Select an existing Pen Group from the Pens List and then drag the pen name to one of the trend windows that are currently activated.
Select File-Save after the Pens have been activated to a trend window.
The Alarm Navigator Bar is used to add, modify, and delete Alarm Windows that can be selected to be added to the current view configuration.
To view the list of Alarms select the Alarms button at the bottom of the Navigator Bar or select Edit-Alarms.
Select the Add button to add an Alarm Window to the configuration. This will display the Alarm Window setup form.
If you will be deploying the Trends and Alarms Dashboard configuration to remote PCs or using the application on a different PC than where the OAS Engine resides use the Networking tag to select all remote nodes where the alarms will be hosted from.
Enter the desired Alarm Window Name that will identify the Alarm Window in the configuration. You must use a unique name that does not already exist.
Select OK to accept the changes or Cancel to abort the recent changes to the window.
Make sure to select File-Save if you add an Alarm Window.
Select an existing Alarm Window from the Alarm List and then Edit button to modify the Alarm Window. This will display the Alarm Window setup form.
You can use the Edit function to also clone an existing alarm window to a new alarm window simply by specifying a new window name in the alarm properties dialog.
Select OK to accept the changes or Cancel to abort the recent changes to the window.
Make sure to select File-Save if you modify the Alarm Window.
Select an existing Alarm Window from the Alarm List and then the Remove button to remove the Alarm Window from the configuration.
Make sure to select File-Save if you delete an Alarm Window.
Select an existing Alarm Window from the Alarm List and then the Activate button to add the Alarm Window to the view screen. You can add the same Alarm Window more than once if you desire as you can make on-line modifications.
Once the Trend Window is activated the window can be left as free floating to any size or location or it can be docked within the main docking area.
Select File-Save after the Alarm Window is docked or placed into the location you would like it to be.
This application is used to view trend and alarm windows without creating an application with Visual Studio. It provides the ability to configure trend windows, alarm windows, and pen groups. The windows can be docked or be free floating and state of each window and the configurations can be saved to a file to be loaded on the same or different PC.
To launch the Trends and Alarms application select Trends and Alarms from the Program Group of Open Automation Software.
The following are more fully-featured applications and utilities available to assist with getting started more quickly with OAS. These applications serve a variety of functions, from rapidly starting up dashboards, demonstrating OAS Platform capabilities, and acting is simple administrative tools.
NOTE: If you want to visualize your data in a desktop or mobile browser with zero programming, you may be interested in the OAS Open UIEngine .
The UIEngine is a robust no-code web application and HMI builder for developing rich user interfaces in a browser-based development environment.
See the UIEngine Documentation to learn more.
You can setup OAS Data Logging and Alarm Logging to from multiple services to the same table. The following is a guideline of parameters to set to enable easy and reliable logging from multiple services to the same database table.
In the following example we will describe the steps to setup both double and triple redundancy when logging data from OPC Servers.
In Server A create two (2) Tags as follows, one to an OPC Item in the OPC Server that is the primary data source. For each OPC Server in Server A define one item.
In Server B create two (2) Tags as follows:
As an option you can enable a third Server C with the following tags:
Note: If you have multiple OPC Servers on each server PC you can create a master EnableLogging Tag that ANDs all of the .Quality parameters of each OPCServer##Quality Tag.
The safest implementation is to create separate groups of tags for each OPC Server and log the values from each OPC Server in their own separate Data Logging Groups.
So in same active states data logging from some OPC Server items will be logged from Server A, some from Server B, and if a tertiary is used possible the remaining in Server C.
In each Data Logging Group enable the property Activate Logging With Tag.
Set the Tag for Activate Logging to EnableLogging.Value.
Enable the property Do Not Buffer When Nulls Are Not Allowed In Database.
Enable the property Do Not Buffer On Primary Index Failure
Log the OPCServer01.Value Tag value in each Logging Group.
For each database table make sure there is a Primary Index on the DateAndTime field.
Set the field for the OPCServer01.Value Tag to not allow nulls in the database. Only this one field needs to be set this way along with the DateAndTime. All others can be left to allow nulls.
Make sure the enable Store Data Logging Buffer To Disk on each Server under Configure-Options-Data Buffer.
Open Automation Software Service Oriented Architecture supports any number of parallel servers and client systems. Following are some key attributes that help promote automatic switchover of one system to another. There multiple ways to implement redundancy for servers, data sources, databases, and applications.
Open Automation Software real-time service can have the same group and tag name structure running on parallel servers. The source of the tags can be the same or different. For the most reliable connection to the data source it is best to run the OAS Services with direct connection to the source.
Each .NET application can implement an automated or controlled switch to data servers.
For automated client switch from primary server to backup server on either a server failure or tag quality failure use the AddBackupNetworkNode method to add monitoring of a primary server and backup server. If the tag values from the primary server are bad quality the backup server data will be used with the same tag name. Or if the entire primary server is unreachable the tag values from the backup server will be used. This provides redundancy for sensor failure, controller failure, communications failure to the controller, server failure, or communications failure to the server.
Example: AddBackupNetworkNode(“localhost”,”192.168.1.1”)
See Client Application Failover for more details and a video of demonstration of this feature.
For manual switchover the logic to determine which is the master can be variable based on quality of individual points. As an example if there are 3 redundant servers and each as a tag called DataQuality you can use logic to monitor the Qualities array from the event for each tag.
If all Qualities are True you can decide which server to the client should switch to. If only one of the servers is good quality then the choice is easy.
Use the AddNetworkNodeAlias method of the OASData.NetworkNodes, OPCSystemsDataConnector.NetworkNodes, OPCControls.OPCControlsNetworkNodes or OPCWPFDashboard.OPCWPFNetworkNodes components to alias the original network node definition of all tags defined to the network node to a different network node.
Example: AddNetworkNodeAlias(“localhost”,”192.168.1.1”)
The AddNetworkNodeAlias method is demonstrated in the Form FormMain of the WinForm Example Code.
Also demonstrated in the following WPF application in detail:
WPF Redundancy Client Example – Demonstrates automated switch to data servers:
Download the Redundancy Client Example
For all trend controls programmatically define the pens of the trend to remote nodes. An example is demonstrated in the Form FormMain of the WinForm Example Code.
For all alarm controls use the AlarmNetworkNodes property to define what remote services the alarm window is connected to. An example is demonstrated in the Form FormMain of the WinForm Example Code.
Visual Basic WinForm Example Code for realtime data access and all configurations access:
Download the WinForm VB Example
C# WinForm Example Code for realtime data access and all configurations access:
Download the WinForm C# Example
In Open Automation Software create one or more tags to provide a status of it being a master is active mode or standby mode. These tags can be used by client applications for determine switchover logic and also for activate properties in data logging, alarm logging, alarm notification, report, and recipe configurations.
The data source for the tag can be a Calculation to automatically monitory other service tags with the Quality parameter or the value can be set from other remote applications like a .NET application, Microsoft Excel, OPC Clients, OPC Servers, or databases.
It best to include a heartbeat within a Calculation tag to verify that the remote service or application is still communicating to the service.
The logic to determine if a service is completely variable, but do not implement something that will prematurely put the service in a standby mode leaving no service as the master.
Things to consider if a service should be the master:
For each Tag value there is a Source When Bad property that can be set to another local or remote Tag when the data quality of the original source is bad. The Source When Bad property can be set to Set Sources To Tag Value and then alternate source can then be defined to another Tag.
Communications to a data source can be enabled or disabled with the property Enable by Tag.
When the Enable by Tag property is enabled a Boolean Tag can be defined to enable of disable the communications based on its value.
Under Configure-Options-Retain Values you can enable to store to disk the following information so when the service computer is restarted all of the latest values are retained.
Values and Alarm Limits for any Tag Value or Alarm Limit with a data source of Value.
Time and Counts for keeping track of times and counts for individual tag parameters with the feature Time On and Counts enabled.
Trends for real-time trend cache.
Alarms for all real-time alarms and the ability to retain when the alarm originally occurred.
To share values and alarm limits across multiple servers the Data Source of a Tag Value or Alarm Limit can be set to File Binary, File Text, or File XML. The path of the file that is shared is specified under Configure-Options-File Data Source.
This path can be set to a remote drive and directory that is accessible by all redundant services. For all tag names that are the same on each service with the Data Source of File all will be updated with the same value when one of the services receive a write from a client.
It does require that the remote file be able to be accessed in order to update the tag value on the multiple services.
Each Interface can optionally enable a failover connection if the primary connection fails. To enable the failover option use the driver interface property Enable Failover. This can be set for AB Classic, AB Logix, AWS IoT Gateway, Azure IoT, CANBus, Modbus, MQTT, MTConnect, OPC UA, and Siemens.
To define failover Classic OPC DA OPC Servers go to Configure-Options-OPC and define the list of primary OPC Servers and Backup OPC Servers.
See Driver Interface Failover – Communication Redundancy for detailed instructions for setup.
AddBackupNetworkNode for .NET applications is also applicable to resolve a data source failure.
Each configuration in Open Automation Software including data logging, alarm logging, alarm notification, reports, and recipes all have an Activate by Tag property under the Common tab of each configuration group to enable or disable the groups execution.
This can be assigned to a Boolean master tag that is true when the features should be enabled and false when disabled. You may need to use additional Calculation tags for each group if more than just an active master tag determines if the execution state of the configuration group.
Each service runs as a Windows Service and on network failure to remote clients all data is retained locally in the service. All trend, alarm, and data logging data is cached in the service at all times to be available for remote clients.
When performing data logging of data from a remote service data can be written to the local hard disk using the Data Buffering feature found under Configure-Options. The same is true for a database engine failure or a network loss to a remote database engine.
View the following video on data buffering to disk.
Data Buffering
How to setup data logging so there is no data loss on a network or database engine failure.
The same data logging configuration can be used on multiple services. If each service needs to log to a different database engine the property Override All Data Logging Database Server Names can be used to override all server names in all logging groups to point to only that database engine server.
Each data logging group has a property to enable a write of status to an Integer tag. The definition of each error code and assignment of error feedback tag is found under the Common tab of each data logging group.
The OAS Engine data logging and alarm logging groups can be enabled and disabled based on tag values. You can have as many logging groups on the same server or multiple servers which can automatically activate based on tag value or quality.
See Redundant Data Logging to the Same Table from Multiple Services for details of setup.
Each OAS service can support multiple client applications to monitor same or dissimilar tag lists. Data quality and timestamp is delivered from the data source to the final use of the data. If logging data or alarms to a database multiple OAS services can receive data from remote OAS services to log to the same or different database engines.
See Client Application Failover for automated switch from primary server to backup server when an application looses communications to a server or the tag quality from the data source is bad.