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.
| (1) | Data Source | Industrial equipment generating data or being controlled |
| (3) | PLC | a logic controller collecting and tracking data from the source |
| (5) | Data Server | Software used to monitor, log, and expose data to external applications |
| (8) | Database | the location of historical data logged by the Data Server |
| (10) | Application or HMI | An interface intended to present the data to end-users for monitoring and control |
| (2)(4)(7)(9) | Communications | All 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
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
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.
- Report as Normal Bad Quality
- Hold Source to Last Good Quality
- Set Source to Default Value
- 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
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.
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
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.
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
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.
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 Redundancy
- OAS Performance
- OAS Networking
- Driver Interface Failover
- Client Application Failover
- Data Accuracy
- Why Use OAS