High Availability Ignition Architectures Part 2 – Improving Resiliency and Data Integrity at the Edge

A standard Ignition Architecture involves a single Ignition Gateway which handles all standard SCADA functionality.  To ensure functionality of the Ignition SCADA system the server must be available and all network connectivity to the PLCs, databases, and client sessions need to be available.

Part 1 of this blog series was aimed at addressing the risks of a server failure.  Even with fault tolerant and redundant servers, there is the potential impact of a network failure from the plant floor devices and/or HMI.  This impact becomes even more relevant when the SCADA servers are housed in offsite datacenters.  This post aims to help users specify an Ignition edge architecture to match the level of risk tolerance required by your use case.

Ignition Edge vs. Full Ignition Platform

Our experience is that most industrial networks and server infrastructure are very reliable – providing over 99% of availability; but it is inevitable that some downtime will occur.  Some manufacturers can withstand losing their SCADA system for a short period of time without much impact to their process.  For others, such as life science companies, losing process data would cause them to scrap the current batch or lot with an impact of thousands to millions of dollars of waste.

Ignition Edge Panel is a product which provides HMI functionality; however, it lacks many of the features Ignition users have become accustomed to with the full Ignition SCADA platform.  For the purposes of this blog post we’ll stick with the features we find most manufacturers are concerned with:

• Visualization and control of the equipment.
• Store and forward of tag history, alarm history, and audit logs to a centralized historian. These are features that are configured in the tag properties and stored utilizing the alarm journal or tag historian module.
• Store and forward of transactional data to a centralized SQL database such as work order transactions, event data, etc. These are features that require the use of the system.db script functions or SQL Bridge module.
• Ability to load SQL based recipes. In a standard architecture, these SQL recipes will reside in a centralized SQL Server.  If your process requires that you be able to load a recipe in the event of a network failure, the recipes must be accessible locally.

Inductive Automation has two versions of Ignition available for commercial use: Ignition and Ignition Edge.  The first two requirements can be addressed with Ignition Edge products; however, as soon as transactional data to a SQL database through system.db functions or the SQL Bridge module are required, a full Ignition platform is required.

IGNITION EDGE PRODUCT SELECTION

If database transactions (utilizing SQL Bridge or system.db functions) are not required, Ignition Edge is an option.  Local visualization and control requires Ignition Edge Panel.  Store and forward of tag and alarm history and audit logs requires Ignition Edge Sync Services.  While not required, EAM allows for centralized management of the edge gateway configuration and projects.  All Ignition Edge products require Ignition Edge Core.  The pricing and features of each option are:

• Ignition Edge Core – $200
  • Up to 2 device connections to all the native drivers
  • Up to 2 OPC UA connections
  • Ignition Designer
• Ignition Edge Panel – $1300
  • The choice of Vision or Perspective for visualization
  • Local trending of data for up to one week (This is local only storage – it does not include store and forward to a central database.)
• Ignition Edge Sync Services – $200
  • Store-and-Forward of up to one week of tag history, alarm history, and audit logs buffering to a central server
• EAM – $100
  • Centrally manage remote Ignition platforms

IGNITION MODULE SELECTION

If database transactions are required, the full Ignition platform must be used.  All Ignition gateways require the Ignition Platform.  From there depending what functionality you need the Ignition modules must be installed.  There are limited client versions of Vision and Perspective available to reduce the overall cost of this option:

• Ignition Edge Platform – $1000
  • Unlimited device connections to all the native drivers
  • Unlimited OPC UA connections
  • Unlimited database connections with native store and forward. This includes alarm history and audit logs.
  • Ignition Designer
• Perspective Module – 1 Client – $2585
  • Visualization and control in a pure-web experience
• Vision Module – 1 Client – $1785
  • Classic Ignition visualization for desktops
• Tag Historian – $2200
  • Unlimited SQL database tag history with native store and forward
• SQL Bridge – $2090
  • Integrate PLCs & SQL databases
• EAM – $1485
  • Centrally manage remote Ignition platforms

LOCALIZED SQL RECIPES

We often supply recipe systems which are stored on a centralized SQL database.  If your process requires the ability to load a recipe in the event of a network or server failure, those recipes will need to reside local to the equipment.  In that case we would recommend a local SQL instance which would synchronize to the central database on change or a scheduled basis.  We will explore this topic in more detail in a future blog post.

PROGRAMMING FOR DISTRIBUTED ARCHITECTURES

While we’ve spent quite a bit of time discussing architectures, we haven’t spent much time discussing the changes to the configuration and programming associated with them.  For instance, when moving to an edge solution all tags and IO are configured and programmed at the edge and then become a remote tag provider to the centralized system.  Depending on the authentication used (SQL, local) a synchronization scheme may be required as with localized SQL recipes.  Additionally, the Enterprise Administration Module (EAM) can help simplify some of the issues surrounding managing multiple gateways.  Stay tuned for future blog posts which will discuss these issues.

A server-based architecture simplifies the deployment and management of a SCADA system; however, it does add some risks.  If the server or network were to be compromised, the loss of visualization and control of the process or the loss of data may not be acceptable.  We’ve explored options to maintain optimum up time for your servers as well as a plethora of options for addressing risks at the edge.  Feel free to contact us if you have concerns that a server-based Ignition SCADA system can satisfy the stringent requirements of your applications.