REST API Configuration

Programmatic Setup of OAS Configurations

OAS REST API Configuration

Open Automation Software now support all configuration properties through the OAS REST API.  This allows you to develop automated configuration of OAS servers using any language or platform. Configuration through the REST API is a free feature included in all OAS engines. Now you can read, write, and update individual configurations, or create bulk configurations in a single call. This includes Tag creation, Communication Drivers, Data Logging, Security, and more.

Visit http://restapi.openautomationsoftware.com to view syntax for all available configuration types under the Server Configuration folder.

  • Tags
  • Drivers
  • Data Logging
  • Alarm Logging
  • Alarm Notification
  • AE OPC Servers
  • Save and Load Configurations
  • Reports
  • Recipes
  • UDP Broadcast/Receive
  • Security and Users
  • Live Data Cloud
  • Global Server Options

View the Getting Started – REST API article in our knowledge base to view and easy to follow guide on how to get connected with OAS configurations and a video on what is REST API and how to access live data.

View the following video on how to interface with live data for both read and write access from data sources like Modbus, Allen Bradley, Siemens, MQTT, OPC UA, AWS IoT, and several other Industry 4.0 data sources.

What is SCADA?

What is SCADA
What is SCADA?

Supervisory control and data acquisition (SCADA) is a control system architecture that includes various software and hardware elements such as computers, data communications, peripheral devices, and controllers that interface with machinery.

The purpose of SCADA is to allow companies to control industrial and manufacturing processes locally or at remote locations. This effectively allows systems to be controlled and monitored from any location, and they can be stopped or started regardless of where you are. Real-time data is also generated by the different elements of the control system. This data can then be stored, gathered, and then compiled into actionable reports.

The flexibility of SCADA allows for individual components such as sensors, valves, motors, and other interfaces to be interacted with directly. These elements can be controlled remotely with software, and they can be programmed to activate or change dynamically based on a set of conditions that are managed by users. Everything is also recorded to a log, meaning that every action taken can be monitored and examined to ensure that systems are functioning correctly and configured properly.

What Does a SCADA System Look Like?

Most SCADA architecture consists of programmable logic computers (PLCs) or remote terminal units (RTUs). These are systems that can communicate with different objects within a factory or manufacturing plant. The information is then sent to computers with SCADA software which can then process and display the information. This can help operators understand the current state of the various manufacturing processes taking place and make important decisions should they need to.

Automated alerts and notifications can be set up to help operators identify potential issues. For example, a SCADA system can be configured to alert an operator if multiple sensors are failing or systems are acting outside a defined margin of error. The operator can remotely pause the processes involved and then use the SCADA system data to determine the cause of the issue. Once the operator has reviewed the data and discovered the issue, they can manually resolve the fault or reboot the system to fix any potential errors. By looking at the log file for that particular faulty component, the operator can get a better understanding of what caused the problem and how it can be fixed in the future.

By establishing systems like this, manufacturing and industrial plants can drastically improve performance, reduce the loss of product, and make it easier for operators to manage their plants with fewer employees.

The Components of a SCADA System

To gain a better understanding of SCADA, it helps to understand the individual components that make up a system.

Inputs and Sensors

SCADA: Inputs and Sensors

Inputs and sensors are the first component of a SCADA system and are integral to the overall functionality. These inputs and sensors are essentially used to pick up data that is sent to various other components of the SCADA system.

Sensors can generally be anything that needs to be monitored. For instance, sensors can be used to detect pressure within a pipe, they can be used to monitor temperatures, or they can even measure the direction of the wind.

Inputs involve anything that humans will touch or interact with. It can mean basic two-state on/off switches, a joystick that controls a robotic arm, or even adjust something more precisely such as the temperature of another device.

PLCs and RTUs

SCADA: PLC

PLCs and RTUs are used to collect data from inputs and sensors. They can then convert the data into information that is used by the SCADA system. It’s often translated into something much easier for operators to understand.

For example, a computer will only understand a switch as having two states; 0 and 1. PLCs and RTUs can be programmed to understand 0 as “Off” and 1 as “On”. This can then be used to display the state of a machine as on or off to the operator instead of 0 and 1, making it a bit easier to read. This is just a very simple example of how PLCs and RTUs translate data into something much easier to understand.

As another example, a rotating device could have hundreds of states depending on how much it has turned and its current position could be expressed as a number based on a relative angle. If that number increases, then it could indicate that the device is being rotated clockwise and the PLC can be programmed to display this to the operator as “Right” or “Clockwise”, and vice versa as “Left” or “Anti-Clockwise” if the value is decreasing. This could help operators understand if an exhaust fan is currently pushing or pulling air which would be useful for a ventilation system.

PLCs can also send commands to inputs. This can be automated, such as opening a relief valve if there is too much pressure in a system, or it can be sent manually by the user.

Alarms and Notifications

SCADA: Alarm Notifications

PLCs and RTUs can be programmed to automatically send notifications or raise alarms. For example, if the pressure built up in a tank or pipe is too much, then a notification will be sent to operators and the PLC will automatically send a command to a defined relief valve to automatically release pressure. However, if the relief valve cannot be opened and a disaster is imminent, then the system will raise alarms and start processes to help contain the potential damage and prevent accidents from occurring.

Notifications can also be used to get an overall idea of how a system is performing. Operators can set up SCADA notifications to give them a general idea of how the plant is performing at certain times of the day. This will help the operator check if the plant is performing well and will give them an idea of what areas to inspect if needed, or if they can focus on other tasks.

Human-Machine Interface (HMI)

SCADA: HMI

An HMI tends to be a display that can be interacted with using various inputs like a keyboard, house, or custom buttons. The information is often displayed as numbers, but it can also be programmed to interpret data graphically as well. It can also be connected to cameras that will display the device or component that the system is monitoring.

For instance, an HMI could display a picture of a tank in a facility that is storing some kind of liquid. The HMI could display graphs showing the current volume within the tank and also contain controls that could be used to empty the tank or prevent it from losing volume. In short, an HMI is typically used to analyze the information but it can also be used to make data-driven decisions to optimize the production process and prevent further loss of a product should an error occur.

Historian

The final component of a complete SCADA system would be the historian. A historian is responsible for storing and logging all of the data that the SCADA system collects. It also records logs for certain actions that take place within the system, such as activating certain machines or sending commands to inputs from an HMI.

The purpose of the historian is to log everything that happens with the system and also create historical data for certain processes, plants, and systems. Historian systems typically sync with an online system so that operators and even shareholders can access the data from anywhere. However, a historian can also be operated locally by running it from a server PC at the plant. This PC is connected to the SCADA network and records everything that happens within the plant.

The data can be used to create actionable reports by the operator, but it can also be used to create historical data that is given to shareholders to see the process of the plant and its overall effectiveness. Historical data can also be used to identify the cause of an accident that led to a loss of product or an employee injury.

Who Uses SCADA?

SCADA is mainly used by industrial organizations and manufacturing plants that use complicated and intricate machinery to produce a large number of products or perform multiple processing tasks at once. The purpose is to help maintain large and efficient systems by recording data from multiple sensors and devices that can be used to mitigate downtime.

SCADA systems work mainly in these scenarios, but their application can be modified to be used in a number of different industries. At its core, SCADA is just a system to monitor multiple PLCs and RTUs that are being fed with data from sensors and manual inputs. In that sense, SCADA can be applied to a variety of different industries and use cases as long as there is a need to collect, compile, and analyze large sets of data at once.

As of now, SCADA systems are critical in industries such as:

  • Energy
  • Food
  • Beverage
  • Manufacturing
  • Power
  • Recycling
  • Oil and gas
  • Transportation
  • Building management
  • Water and wastewater

These are major industries that make full use of SCADA by deploying hundreds or potentially thousands of sensors and manual input devices that provide data to PLCs and RTUs.

However, SCADA systems may also be present on a much lower scale as well.

For example, local supermarkets may use a small-scale SCADA system to manage refrigeration units. Sensors can be installed within refrigerators and freezers to monitor the temperature of the devices. This information can then be passed to a PLC or RTU which can control the power state of the unit. If the sensor reads a temperature that is well above a user-defined limit, it means that the refrigeration unit is no longer working or is faulty. This can trigger a notification to an operator who will then manually inspect the unit or send an engineer to examine it. Meanwhile, the system will automatically turn the refrigeration unit off and floor staff can manually remove the items and place them into another unit to keep the items inside properly refrigerated to prevent the loss of product.

SCADA systems can even be used inside your home to monitor and change temperatures. Sensors can be installed around the house or in different rooms to monitor the temperature. This data can feed into a system that has been pre-programmed to maintain a specific temperature. This can be connected to a heating and cooling system that automatically turns on when the temperature deviates from a user-programmed setting. This is a small-scale SCADA system that can be used to regulate the temperature inside a home and ensure it’s comfortable for everyone inside.

As you can see, SCADA systems have multiple applications on both a large industrial scale and a smaller home scale. However, its primary purpose is for use in large industrial and manufacturing operations.

SCADA Compatibility and Standards

A control system architecture is only as useful as the compatibility it offers. While the concept of SCADA is simple to understand, the components used to create one need to work in harmony.

Open Automation Software’s Universal Data Connector is a great example of a SCADA component that is essential for gaining unparalleled access to industrial operations and enterprise data. The OAS Platform supports data transport from any data source to any destination. It supports a wide variety of PLCs from reputable brands such as Allen Bradley and Siemens, and it can move data between popular cloud-based IoT services such as AWS, Azure, and MQTT brokers and clients.

For a SCADA system to be effective, flexible, and customizable, it needs to support multiple platforms, connectors, and tools. The core of any world-class SCADA system is in the connectivity between the different PLCs, RTUs, and databases. With effective automation solutions, you’ll find it much easier to manage your operations and optimize them as much as possible.

Contact Open Automation Software Today

The OAS Universal Data Connector gives operators complete access to industrial operations and data. Download the OAS Platform today or schedule a live interactive demo. Don’t hesitate to get in touch to learn more about the OAS Platform and how it can transform your SCADA system.

IoT Unidirectional Network Gateway

IoT Communication Diode

Secure your data with Communications Diodes

Communication diodes are used to protect data on a network to allow network traffic only one way.  This eliminates the threat of cyberattacks and access to intellectual property.  Customers rely on OAS to transfer selected real-time KPIs through communication diodes 

The OAS Unidirectional Network Gateway feature was designed and published in 2005 for our nuclear power customers to transfer OPC data from 20 different nuclear reactors for data collection and visualization.

Unidirectional Network Gateway

This unique network feature of OAS has been adopted by manufacturing and municipality organizations to protect their control systems from attack with data diodes in place to protect their assets.  All OAS data sources including Modbus devices, Allen Bradley PLCs, Siemens controllers, OPC UA, MQTT, and .NET applications can be shared to applications of the protected network securely.  The data that is received outside of the DMZ can be achieved, visualized in Web or .NET applications, generate alarm notifications, or transferred to third party cloud systems like AWS IoT Gateway and Azure IoT Data Hub.

Security and Flexibility

The broadcast server can be set to transfer all live values from the local system or be set to transfer a selected list tag variables from other OAS servers within the organizations DMZ.  Each broadcast server can target multiple receiving servers and each receiving server can process data from multiple broadcast servers providing a possible many to many network configuration.

More:

Other OAS Network Options

Getting Started – Unidirectional Network Gateway

Ten Common IIoT Points of Failure and Ways To Avoid Them

10 IIoT Failures

Industrial Internet of Things (IIoT) applications’ data accuracy and reliability are highly dependent on the uptime of several factors.  Many solutions work perfectly well under normal circumstances, but only those systems designed to anticipate and respond to failure are appropriate for industrial applications.

Failure is not fatal, but failure to change might be.
– John Wooden

Typical Industrial System Architecture

Deploying Open Automation Software as an Edge solution can help to avoid data loss and downtime due to communication breakdown, database failures, network loss, and application errors. First, let’s take a look at a typical end-to-end industrial application and all of the possible points of failure. In this example, the system consists of a data source, PLC, data server, database, and finally an application or HMI reading data from the data server. Each component and connection is a potential source of failures.

10 IIoT Points of Failure
(1)Data SourceIndustrial equipment generating data or being controlled
(3)PLCa logic controller collecting and tracking data from the source
(5)Data ServerSoftware used to monitor, log, and expose data to external applications
(8)Databasethe location of historical data logged by the Data Server
(10)Application or HMIAn interface intended to present the data to end-users for monitoring and control
(2)(4)(7)(9)CommunicationsAll communications channels between system components

Now, let’s explore all of the possible ways a system can fail and how using the OAS Platform as your Data Server can mitigate these failures. In most cases, OAS can even prevent data loss and increase availability of data to end-users.

Communications And Data Source Failures

Points of Failure

IIoT Communication Failure
Communication Failure

1 – Equipment

Equipment can be down due to scheduled maintenance or components of the physical systems can fail causing production to be stopped.

2 – Sensor Failure

In the case of instrumentation failure the sensor data will be in error and will be collected with bad quality flags, indicating the data is not reliable and should not be used.

3 – Controller Failure

PLCs and controllers can lose power without a backup power supply in place, or can be set in offline mode to update control programs.

4 – Controller Communications Failure

A failure in network communications to the controller or OPC server can cause a loss of data during production.

Solutions

IIoT Communication Redundancy
Communication Redundancy

1 – Automated Switchover

Open Automation Software (OAS) can disable and enable communications based on data quality or from other independent signals using the property Enable Communications from Tag.

2 – Switch Value Source from Quality 

To account for equipment or sensor failure redundant equipment should be in place as alternate data source.

OAS has the ability to automatically switch or override a data source with the property Source When Bad to one of the 4 following options.

  1. Report as Normal Bad Quality
  2. Hold Source to Last Good Quality
  3. Set Source to Default Value
  4. Set Source to Alternate Tag Value

3 – Driver Interface Failover

OAS has built into each driver interface the ability to define a failover IP address or url to account for failures in communications with Modbus devices, Siemens S-7 controllers, Allen Bradley PLCs, MQTT Brokers, AWS IoT Gateways, MTConnect data streams, OPC DA Servers, and OPC UA Servers.  Read more about Driver Interface Failover and how to easily setup automated communication backup.

4 – Buffer Data in Controller

The OAS data historian has built in handshaking support to obtain buffered data within the controller and pass back confirmation for data synchronization with the controller.  Read how to Log Buffered Data from a PLC or Controller which is also applicable for OPC DA and OPC UA Servers as well.

 

Data Server Failures

IIoT Server Failure
Server Failure

5 – Server or Network Failure

A server hardware or network failure can cause a data server to become unreachable.

6 – Offline Configuration

Some IIoT gateways do not permit online changes, possibly due to a custom application that needs to be compiled, or long delays can be caused during software updates.

IIoT Server Redundancy
Server Redundancy

5 – Redundant Servers

OAS can be deployed in parallel for as many redundant servers as desired, each having the same configurations with the ability to automatically enable or disable communications, archiving, and notification based on which server is the master.  Read more about OAS Redundancy.

6 – Online Configuration

OAS permits changes to all configuration attributes while a system is operational eliminating the need to take a system down.  OAS supports manual, CSV import, and programmatic updates via .NET or REST API.  OAS also has built Automated Update feature to upgrade OAS platform reducing downtime for a complete update.

 

Database Failures

IIoT Database Failure
Database Failure

7 – Database Engine or Network Failure

Uptime is critical in data archiving to build accurate data models, maintain faultless production data, and validate operations performance.  Logging data remotely can cause a loss in data if the data historian does not have data buffering to account for temporary loss in communications to the database engine.

8 – Database Performance

Valid IIoT data collection systems work on a first-in-first-logged order or processing, but can get behind when there is a burst of data to log, often leading to a loss in data.

IIoT Database Store and Forward
Database Store and Forward

7 – Store and Forward

OAS data logging and alarm logging have Store and Forward built into the buffer data to a local disk for as long as the database engine is not reachable.  See OAS Store and Forward in action in the 10 Things Your Data Historian Should Do video.

8 – Bulk Inserts and Parallel Processing

OAS implements the most efficient methods to insert records to a database providing database engines to run remotely being able to insert over 1,000,000 records per call.  See Data Historian Performance Benchmarks comparing SQL Server, Oracle, mySQL, MariaDB, PostgreSQL, MongoDB, and SQLite, MSSQL providing the best performance with OAS logging over 2,000,000 values per second.  OAS also support more than 10,000 logging groups per server each logging to a separate table.

 

Interface or HMI Failures

IIoT Application Failure
Application Failure

9 – Client Network Failure

During network failure between the client application and the server can leave operators and supporting applications operating without the information needed to make informed decisions.

10 – Client Application Failure

Client application failures can leave operations personnel and production managers void of the data needed to operate safely and reliably. 

IIoT Application Redundancy
Application Redundancy

9 – Client Application Failover

All OAS .NET assemblies for programmatic interface and visualization support Client Application Failover to automatically switch from primary server to backup server on network failure or signal failure.

10 – Unlimited Clients

OAS is deployed in Distributed Network Architecture to support unlimited client applications per server.  


Read more about OAS Platform features for system reliability:

OAS Performance

OAS Performance

Open Automation Software processes data with high efficiency and speed to maintain data accuracy and reliability.

OAS can run on multiple platforms with large scalability,  from 100,000 tags on Raspberry Pi 4 up to 1,000,000 tags on Windows or Linux server.  Deployed as an edge in a Distributed Network Architecture OAS can pre-process all incoming data and deliver to the final destination for unlimited number of tags to unlimited clients.

To emphasize the scalable performance of OAS the following video demonstrates 100,000 tags running on a Raspberry Pi 4 with all tag values changing each second and then logged to a SQL Server database.

Performance Variables

Open Automation Software addresses typical deadlocks, bottlenecks, and poor synchronization found in other applications that can cause data loss or system failure.

Factors Which May Impact Software Performance

Synchronous Processing

Synchronous or poorly-scaling architectures, forcing systems to block and limit throughput.

Single-Threaded Processing

Bottlenecks communicating with external sources, causing slow downs with additional endpoints.  Processing data inline from source to completion on a single thread can cause a complete system failure if there is a breakdown at any step.

Network Traffic Bandwidth

Large data packet size and overwhelming bandwidth can slow down or even cause backups in delivery of data.

Inefficient Encoding and Decoding

Slow, or inefficient data encryption, forcing a choice between security or speed.

Single Record Processing to Database

Poorly designed database record inserts can cause backup or failure of delivery.

Network or Database Failure

If the system is not deployed as an edge solution with store and forward implemented data will be dropped and not processed.  Important to cache this data properly to be able to process further incoming values continuously.

Limited Communication Channels

Most SCADA systems are limited to 200 or less channels and require separate instances to collect data from more than 200 devices.

Only Latest Value Update

Limiting what data is delivered learning engines can affect the data model.

Separate Data Source for Each Client 

The number of clients can be restricted otherwise causing undue stress in overwhelming communications to the data source. 

OAS Performance Features

Asynchronous Event Driven Processing

Asynchronous communications by subscription to data sources.  Routines only need to execute on data change or watchdog failure.

Multi-Threaded Processing

Multi-threaded data processing while retaining first-in-first-out handling.  Separate threads to receive, process, and deliver data in order it is received. 

Optimized Compression

High speed data compression algorithms for encoding and decoding data with reduced packet size in comparison of open standards.

Optimized Encryption

High speed encryption to retain security without sacrificing speed.  Always activated to maintain secure communications at all times.

Multi-Record Processing

Data logging and alarm logging routines perform bulk inserts to pass up to one million records per call.  Eliminates data backup due to delivery error.

Store and Forward

OAS is deployed as a edge solution being able to maintain connection to the data source and can store data to disk on network or database engine failure, freeing up memory resources for continuous processing.

Unlimited Drivers per OAS Engine

OAS can connect to unlimited number of devices per server instance, proven systems in production communicating to more than 1,300 Modbus devices from one server.

First In First Out Processing

OAS delivers all values it receives from end to end, not just the latest value maintaining 100% accuracy for learning engines and reports.  This makes it possible to use slower communication networks while still maintaining data accuracy up to 100 nanoseconds.

Centralized Data Namespace

Values received from each data source are centralized to OAS tag values, to be shared to unlimited number of client applications without impacting the communication rate from the data source.

More:

Data Accuracy

Why Use OAS

Raspberry Pi Installation

Automated Setup for Open Automation Software

A summary of methods used to automate setup and deployment of Open Automation Software

Open Automation Software offers programmatic and automated setup features for OEMs to define communication interfaces and platform configurations for their customers.  OAS also provides self-adapting user interfaces allowing integrators to deploy systems efficiently to customers with varying field configurations.

Automated Setup Benefits

Embracing automated setup when deploying systems has many benefits to OEMs and their customers.

Rapid Configuration

By eliminating the time required to manually define communication interfaces, alarm limits, and how data is to be archived and presented, deployment of each system can often be reduced to a few seconds compared to weeks or months of tiresome configuration.

Ensure Standards

Automated configuration ensures that systems adhere to defined standards and policies.  Automated setup guarantees that each system is deployed to follow specific rules for data monitoring and logging.

Eliminate Human Error

The setup of large systems can be overwhelming and tedious, and repetitive tasks can often lead to careless errors. Automating this process has a positive impact on data accuracy and system performance.

Deploy Changes Quickly

Automation allows both large-scale configuration changes and small changes to be implemented quickly and consistently.

Reduce Costs

No need to hire large numbers of automation specialists to carry out system setup.  Time required to verify and troubleshoot manual changes is eliminated.

One for All User Interface

A single user interface that is able to adapt across platforms, systems and users means one code base, greatly reducing development and debug time while increasing accuracy.

Adapt to Varying Equipment

Each customer of an OEM or system integrator may have different assets in the field, which requires modifications to how data is accessed.  OEMs can deploy applications based on one code set that can read asset allocation from their customer’s database, setup all data monitoring and provides a user interface that adapts to what data is available.

Open Automation Software Solutions

All interfaces to define configurations are included with the OAS Platform at no cost.

.NET Programmatic Interface

OAS features can be fully setup programmatically, providing developers complete flexibility how OAS systems can be deployed.  This supports all configurations including Tags, Driver Interfaces, Data Logging, Alarm Logging, Alarm Notification, Recipes, Reports, Security, and more.  Setup of OAS will take just a few seconds using this programmatic method.

With the OASConfig .NET Standard 2.0 assembly applications can run on both Windows and Linux to define properties of the OAS Platform locally or remotely, with optional security.  Refer to the .NET Programmatic Server Configuration article for an overview of OAS .NET assemblies for configuration.

View the Example Service Code article where to download projects for .NET Core / .NET 5 for cross platform deployment and for .NET Framework Windows Services in both C# and Visual Basic.  The code demonstrates defining tags using the Set and Get Tag Properties methods and reading and writing live values using the Data Access Programmatic methods.

REST API

The OAS Engine has a built-in REST API to make calls locally or remotely using a web interface.  View the Getting Started – REST API guide on how easy it is to setup tags and access live data through this interface.

Automated HMI

OAS .NET and web user interfaces can be created to self-adapt based on the tags defined in each OAS Engine.  This makes it possible for OEMS to deploy one application for all customers regardless if each site has varying numbers of devices or field instruments to connect to.

One Click Database

Data Logging Groups can be automatically setup by using the One Click Database feature that browses Open Automation Software Tags automatically and creates data logging groups based on the tags in a selected services.

CSV Import

OAS configurations can be setup using CSV files.  Use the Configure OAS application to export any of the configurations to a CSV file to obtain the header names used for each configuration property.  Then use Microsoft Excel or other CSV file editor or to add or modify rows to define the setup of OAS, then use the CSV Import.

Using the same CSV format tags can also be updated or added using the .NET Programmatic CSV Import or REST API.

See the Getting Started – Tags guide for a simple walk through of setting up Tags manually and using CSV Import, which is the same steps for all configurations.

One Click OPC

The One Click OPC feature can be used to browse classic OPC DA OPC Servers and automatically create Tags and setup communications for all OPC Items for a selected server or branch within the server.

One Click OPC UA

The One Click OPC UA feature can be used to browse OPC UA Servers and automatically create or update Tags and setup communications for all Nodes in a server or Nodes under a selected Node.

One Click Allen Bradley

Tags can be automatically setup by using the One Click Allen Bradley feature that reads all variables from a controller or program file and creates tags based on the variables and data types found.

Data Accuracy in IoT

High-Speed, Reliable Data Collection and Logging

Data accuracy is highly dependent on how IoT systems collect, transport and deliver data. It is critical that information systems receive data from data acquisition solutions that can run, on-premise, as an edge solution and can store and forward data on communication failures. Edge IoT systems like Open Automation Software eliminate the dependency on network reliability that cloud solutions require, and can deliver data with high precision and greater reliability.

Open Automation Software is deployed as an edge solution to collect and process data on-premise utilizing a first-in-first-out (FIFO) data method to deliver all samples of received data over the network to user interfaces, applications, remote OAS Engines, and databases.

Example solution gathering data in real time from a PLC to an edge or on-premise OAS instance, passing the data to a remote OAS instance which is logging data to an open database such as MS SQL Server. (click image to enlarge)
Watch the video to see how OAS transports 1,000,000 samples to a Raspberry Pi device, processes it at a rate of 100 nanoseconds per sample, and inserts 1,000,000 records into MS SQL Server in one database transaction.

By running as an edge computing solution Open Automation Software provides the reliability to retain the data in all possible failure scenarios. OAS is able to achieve the highest data accuracy possible through optimized communications with controllers and applications utilizing light network transport that is both secure and has a delivery confirmation, providing high throughput performance to databases with its store and forward capability.

Controller and Application Communications Failover

OAS supports buffered communications to controllers and applications to perform bulk polling of multiple samples in one call.  This provides a sampling speed matching the controller or application time cycle. It also provides store and forward capabilities directly on the controller so that there is zero data loss in the case of temporary communication failures.

OAS also supports communications redundancy failover to a backup controller providing an automated switch from primary to secondary controller or application.

OAS can also receive data from .NET applications and REST interfaces to update tag values.  See the Real Time Data Access WriteTags method to see how timestamps can be included with values to transfer multiple values in one simple call.

Upon failure to communicate with a data source, OAS can be configured to automatically fail over to a backup source or network address. (click image to enlarge)

Handling Remote Network Communications Failures

OAS runs as an edge solution collecting and processing data on-premise enabling it to reliably process all data in the event of a network failure. When data is transferred over the network, all value changes since the last successful transfer are transmitted, not just the latest value. This is important for building accurate data models from the data source. Network packets from client to server and server to server are encrypted and compressed to achieve the smallest packet size available.

The real-time trend and alarm information is processed locally and cached on the OAS Engine so when the remote user interfaces are able to reestablish a connection all trend and alarm data is provided to 100 nanosecond accuracy.   OAS also has client and server watchdogs to notify applications when there is a network failure.  If real-time access is critical, there can be an automated client switchover from primary to backup OAS Engine within the client application. Each OAS engine can also support multiple client interfaces.

Store and Forward functionally is also built in for data logging and alarm logging so the highest possible retention of data is available during temporary network failures.

Deployed as an edge solution, if remote systems cannot be reached, the edge instance of OAS will continue to capture source data, ensuring data integrity when communications are reestablished. (click image to enlarge)

Database Performance and Data Buffering

OAS has built in store and forward functionality to account for database engines failures as well.  In the event of a communications failure attempting to write data to a database, OAS can be buffer data to a local disk. When communication is reestablished, OAS will write all data out to the database, restored as first received first sent updates to the database in bulk calls.

The database engine can be located on the same system as the OAS Engine or on a remote system, as multiple records are inserted with just one call. This eliminates any possibility for data to be dropped or lag behind in update to the database. OAS can log up to 2,000,000 values per table to SQL Server.

In the event of a failure to log data to a database, OAS will buffer the data locally and write it back out when the database is back online with zero data loss. (click image to enlarge)

OAS Full Version on Raspberry Pi 4

We are happy to announce support for deploying the OAS Platform on Raspberry Pi 4 with 4GB or 8GB of memory. With the FULL OAS Platform running on an these devices, possibilities are created for inexpensively scaling your operations. Now you can take advantage of such features as reliable on-site data logging in remote locations with limited power or connectivity. This new addition means that OAS can now be run on virtually any platform in any form factor including the following, with all platforms able to seamlessly share data:

  • Windows PC/Server
  • Windows Embedded
  • Windows IoT
  • Linux Server
  • Virtual Machines (Win/Linux)
  • Raspberry Pi 4
  • Docker Containers (Win/Linux)

These systems can be networked together and share data creating endless network configuration possibilities. 

Now your Raspberry Pi 4 device can take full advantage of the OAS Platform, including:

  • High speed data logging to open formats on MS SQL Server, Oracle, mySQL, SQL Azure, PostgreSQL, Cassandra, MongoDB, MariaDB, SQLite, InfluxDB, and CSV files
  • Connectivity to Allen-Bradley, Siemens S7, Modbus, OPC UA devices and servers
  • Connectivity to IoT cloud services such as AWS IoT and Azure IoT
  • Built in high-speed MQTT Broker.
  • Alarm logging and notifications via SMS, email and voice
  • Host live and historical data for visualization HMIs or applications for .NET or Web environments
  • Fully customizable via SDKs in .NET, Web, and any language using the built-in REST API
  • Live Data Cloud networking and self hosting data servers.

If you are new to Raspberry Pi 4, it is an inexpensive (ranging in price from $55 to $75), mini, credit-card sized computer with the ability to output 4K video at 60 Hz or power dual monitors. Among other languages, it can be programmed using Python, Java, C and C++.  It is a full Linux computer with both ethernet and serial communications for connecting to external devices and its own set of I/O pins.

See Raspberry Pi 4 Specifications.

Here are just a few of the possibilities with OAS and Raspberry Pi:

  • With the Raspberry Pi’s low equipment cost OEMS and systems integrators can build software and hardware solutions using OAS and deploy them out to their customers all in one small form factor.
  • You could have thousands of Raspberry Pi devices out in the field all aggregating the data into a central OAS Engine or sharing data directly with each other.
  • The Raspberry pi 4 can be used in areas with limited power or internet access. You could hook it up to an external solid state 2tb hard drive and use the OAS Data Historian to collect data on it without internet access for years.
  • Deploy and run in remote locations with very low power usage powered by solar panels.
  • Replace legacy Remote Terminal Units with open architecture OAS.
  • Remote asset and personnel monitoring with on board data processing.

View the following video for easy to follow instructions to install OAS on a Raspberry Pi 4 device and see the Web HMI Dashboard hosted directly from the Raspberry Pi 4.

More:

Linux Installation

Raspberry Pi Installation

Open Database vs Proprietary Database

Open IoT Database

A comparison of logging Industry 4.0 data in an open format vs. a proprietary format

Logging industrial automation data in an open format provides users and automated systems the flexibility to utilize reporting tools, business analytics, and learning engines to harvest data with 100% transparency and accuracy.  An open format allows engineers to select the best tools to match the application requirements without being locked into proprietary systems to access their data.

Have you been locked out of data access due to proprietary formats and cumbersome development tools?

Open vs Proprietary

There are several features an open database format can support that are not achievable with a proprietary format.

Open Database

Easy Access

With an open format, data sets can be returned from simple SQL query statements like “SELECT * FROM myTable”.

Data for Learning Engines and Business Analytics

Data can be consumed by any learning engine or business analytics tool for maximum flexibility in processing data in meaningful way.  It is important to have all raw data including timestamps directly from the source for accurate data models. Using an open format, you control what gets logged and how it is stored.

No Cost To Access

No need to rely on one specific vendor to access your data.  Choose the best tools to meet the requirements. Whether it be off-the-shelf reporting tools or your own custom solution, you get to decide the best solution for your requirements.

Fastest Results

Data results are returned quickly without the need for post processing or need rely on one specific vendor to access your data.  No requirement for data processing components. You are even free to perform offline data transformations and optimizations.

Easy Management

Data archives can be backed up or mirrored in incremental steps.  Use standard database administration tools for easy management.

Update Existing Records

Updates to existing records can be performed easily.

Smaller Datasets

Return any number of records or columns of data that is needed.  This results in faster queries and lighter network traffic.

Smaller Memory Usage

By logging the raw value only, the native value in bytes is used for disk storage.

Insert Multiple Records in One Call

OAS can log up to one million records per network call, this eliminates the possibility of data getting backed up within the data flow.

Open Developer Support

All database developers and administrators can understand and work with an open format. Using an open format on industry standard databases, there is no need for database administrators to learn any specialized skills.

Third Party Reports

Use with any reporting tool to generate dynamic or automated reports.

Proprietary Database

Difficult Access

Data cannot be accessed and viewed directly.  Custom or proprietary tools must be used to access your data.

Inconsistent Number of Records

Proprietary systems sometimes use compression algorithms to overcome bloated data representation, leaving missing or uncertain data gaps within the data set.

Limited to Specific Platform

Data can often only be consumed by the originating platform.  Variable fees are sometimes charged in order to access the data. Why pay additional fees to see your own data?

Slow Response

Data that is obtained needs to be processed through additional routines, slowing down the history results.

Proprietary tools and user interfaces

In order to set up archiving routines or mirroring, the tools from the originating platform must be used, limiting the options for archiving.

Records Cannot be Updated

In some industries like pharmaceutical applications this is desired, but in manufacturing and material handing it is often beneficial to update existing records based on the step product creation or distribution.

Bloated Data

In order to log data in a proprietary format additional data needs to be recorded for indexing, status, quality, source of origin.

This results in larger data sets returned and larger disk capacity to archive the data.

Constrained Delivery

If the format of the data does not allow bulk inserts to the database, data can often get obstructed if the network or database engine is slow to process, which then results in either high memory usage or data loss.

Specialists Required for Support

Working with proprietary data will require specialized skills to work with datasets.  Selection of third party tools will be limited, and sometimes not able to process data results.  Time required to develop solutions to providing meaningful results can become costly.

Limited Reports

The choices of reporting tools is limited to what a vendor makes available to you, sometimes only available from the originating platform.

Open Automation Software Solution

Open Automation Software Performance

One challenge of logging data in an open format is data throughput.  OAS overcomes this by archiving data at a rate of over one million values per second, up to two million values using MS SQL Server.  Open Automation Software has worked directly with database providers Microsoft, Oracle, and others to achieve the best throughput to insert new records in a database while still maintaining a format that can be directly queried.  This is achieved by processing data in the OAS Engine with a first-in-first-out value processing, carrying the data quality and timestamp directly from the data source.

Data Historian Performance Benchmarks

Open Data Sources

The OAS Data Historian can log data from several sources, the most commonly used are Industry 4.0 like Modbus devices, Siemens S7 controllers, Allen Bradley PLCs, OPC and OPC UA Servers, MQTT, MTConnect, Azure IoT, and AWS IoT.  OAS also supports programmatic interfaces for .NET applications and REST API clients and custom driver support though the Universal Driver Interface, allowing you to log data from virtually any source including your own real time application.

Data Sources

High Scalability

Each OAS Engine instance can log to over 10,000 separate tables.  The design can be a narrow format, mapping each data point to one or more table, or wide format with all data points in one table.  OAS can log to multiple database engines of multiple providers at the same time.  Combined with the built in store-and-forward feature data can be mirrored easily from the data source to multiple destinations maintaining complete accuracy on redundant storage.

Secure Networking

OAS transports data from service to service securely using custom encryption with light-weight transport with compressed packets.

IIoT Networking

Reliability

With OAS, there is no fear of data loss since data even if the database engine cannot be reached. In the event of a network failure, database engine failure, or if communications is lost for any amount of time, the store-and-forward feature will queue data to disk. OAS can also log to multiple remote database engines reliably with the same bulk insert performance mentioned above for mirroring and backup.

Quick Setup

Configuration can be implemented in 4 possible ways, manually, CSV Import, automated setup, or programmatic setup.

If you’d like to learn more or try the OAS Data Historian please submit the form below to receive a fully-functional trial of the OAS Platform today.

The OAS Platform and Docker

OAS in Docker

Using Docker to containerize an application is an efficient and secure way to make your configurations portable as well as scaleable. If you are not familiar with what Docker is or how it can used to encapsulate your application infrastructure, see the online reference, What is a Container? on the Docker.com site.

Unlike virtualization where a host operating system runs multiple copies of an entire guest operating system, containers run as self-contained and isolated applications on the host OS itself. Multiple instances of the application can be spun up and shut down using the minimum of system resources.

With the latest release of the OAS Platform, we now fully support the deployment of an OAS server within a Docker container on both Windows and Linux platforms with the ability to centrally manage container licenses either directly on the host or remotely from a client PC. Each instance of the OAS Platform in a container is the full OAS runtime with all product features available, which can be used to independently move data from PLCs or other IoT devices, databases, and applications to any destination.

Comparison of OAS containers running self-contained and with shared configuration files on the host.

The OAS Platform in each container also supports full programmatic configuration and visualization APIs (both Windows and Web UIs as well as REST API support), so custom applications can target one or more container instances. And container instances can be networked together with Live Data Cloud for data aggregation or even failover.

With this new release, OAS extends its ability to be the ideal IoT solution for industrial automation, IoT Edge solutions, and IoT Gateway implementations. See our article on Getting Started with OAS in Docker for more technical information and instructions on how to configure your Docker installation.