Scalable SCADA: Deploying Ignition in Any Architecture

One of the most basic principles of architecture is that a structure can only be strong if it is built on a solid foundation. Today’s enterprises face the added challenge of building technology infrastructures that are not only strong but flexible.

The Internet continues to transform the way business is done, industries are in transition, new markets are opening, and consumer habits are shifting. Even if your architecture is working well for you now, is it scalable enough to adapt to unpredictable changes?

Many industrial organizations are asking themselves that question, and a growing number are switching to Ignition by Inductive Automation® as their industrial automation platform. Ignition is a uniquely scalable SCADA software that can be deployed in many different types of architectures because it is modular.

Building on a Modular Platform

If modular SCADA software sounds like an odd concept, it simply means that the user builds and customizes the Ignition platform by adding software modules to it. Just think of the way that apps add specific functionalities to a smartphone or that programs add functionalities to a PC; similarly, the modules that you add to the Ignition platform define what you can do with it.

The Ignition platform itself is a web-based industrial application server that provides a number of important features.

It comes with a built-in designer application. It provides connectivity to databases, as well as OPC connectivity that allows it to communicate with thousands of different devices. It comes with a store-and-forward feature, and alarming, security, and redundancy features. It also has a real-time tag database, an application program interface (API), and other powerful features.

While the platform of Ignition has many capabilities, most of the things that industrial organizations do with Ignition are accomplished by using modules. You can use the Ignition platform to connect with PLCs and databases, but if you want to capture and display the information from those connections, and make it accessible on different devices in different places, or do other useful things with it, you will need to add certain modules.

Each of the Ignition modules performs a different, specialized function, and they all work seamlessly with the platform and with other Ignition modules. Every Ignition module is configured on the same designer application. When you install a module onto an Ignition server, the functionality of that module resides on that specific server.

Because Ignition supports an unlimited number of modules, you can build nearly any kind of architecture with it. You can deploy Ignition effectively at one site, at multiple sites, or host it in the Cloud. This is a major reason why Ignition is being adopted by organizations of all sizes in many industries.

Logging and Visualizing Your Data

Of the many modules that users can add to their Ignition platform, there are two core modules which are particularly important to its ability to build different SCADA architectures: the SQL Bridge Module and the Vision Module.
 

The SQL Bridge Module has many uses, the most important of which is providing connectivity between OPC data and SQL databases. The module accomplishes this through its high-performance historian which logs historical data into a database, and its transaction groups which move data bi-directionally between a PLC and a database.

If you ran an Ignition server that only had the SQL Bridge Module installed on its own, you’d have an excellent historian and data-logging solution but you wouldn’t have any way to see the data.

The Vision Module brings visualization to the Ignition platform. It provides web-launched clients, displays historical data; and it provides windows, components, templates, and design tools that enable you to build projects.

Even on its own, the Vision Module provides a lot of tools to work with. You could use it to make a frontend application to a database that has no PLC interactions, or make a real-time status control screen that interfaces with devices. It can also make graphs, charts, and more. However, if your Ignition platform only has the Vision Module and not the SQL Bridge Module, you’d have the ability to display data but no way to log it.

When you have both the SQL Bridge Module and the Vision Module installed on the same server, Ignition performs the functions of both, which means that you can log data and visualize it all in one place. This provides you with many powerful options for building a customized architecture.

With a basic understanding of the platform of Ignition and some of its core modules, we can now look at some of the different ways that Ignition is commonly deployed. No matter what you need to build now or how you may need to scale it out in the future, Ignition offers a practical and cohesive way to do it.

Deploying a Single Ignition Server

The standard Ignition architecture is a single Ignition server installed at a single site. This single-server/ single-site deployment, in which Ignition and all components are all installed on a single machine, is the one that most Ignition users begin with.

The modules typically used in the standard architecture are Vision, SQL Bridge, Reporting, Symbol Factory, and Alarm Notification.* With that platform, the user can connect to all of their PLCs and databases, do realtime status control, alarming, use pre-made vector graphics, create professional reports, display optimized HMI screens, and more – all on the same machine.

It’s a beautifully simple setup: for the price of one server license, the user has one place for all of their SCADA installation, configuration, and backup, for an entire facility. If you have one site, then one server can provide all the functionality you need.

However, with only one server there is a single point of failure. It’s best to set up a redundant pair of servers so that if the master server fails, the backup server will take over. Doing this will make your system fault-tolerant.

A single Ignition server can also be used for multiple sites. For example, if your organization installed Ignition at its central site and then wanted to view and control two remote sites in other parts of the country, you could connect all three sites through a corporate wide-area network (WAN). With one Ignition server connected to the PLCs at the remote sites over the WAN, you could collect information from all PLCs to one database at the central site. This is quite attractive from a cost perspective because you could collect data from three sites on one license.

However, there is a drawback to using one Ignition server for multiple sites: if the corporate WAN goes down and causes the central server to lose connection to the remote sites, the remote sites will lose historical data and visualization. So if access to historical data and visualization at the remote sites has to be maintained at all times, it is recommended that you use an architecture with more than one Ignition server.

When to Deploy Multiple Ignition Servers

Ignition Standard Architecture: Multiple Sites

As you expand your system, you can explore other Ignition architectures. If your organization wants to use Ignition at more than one site, it is best to install an Ignition server at each of your locations.

The main advantage of having a server at each site is that your remote sites will be able to continue performing essential functions even when communication to the central server is lost. Using multiple servers also offers a wide degree of flexibility. Depending on the modules you select, each Ignition server in the network can perform the exact same functions or they can each perform different functions. Your organization gets to pick and choose which modules to run at which sites in order to make the whole system the most effective it can be.

You could deploy a variety of Ignition architectures that use multiple servers at multiple sites. The most basic of these is the Wide-Area SCADA architecture. An organization using Wide-Area SCADA at three sites would have one Ignition server at each site: all three servers would be connected through a corporate WAN, and all three would have the same modules installed so that the full functionality of the Ignition application would be available at each site.

From the perspective of an operator, Ignition would appear as if it were a single, cohesive application even though it is actually distributed across three sites. Through a method called client retargeting, the operator could quickly switch from a project on an Ignition server to another project on another Ignition server. This would make managing different projects at geographically dispersed sites much simpler than it used to be.

Wide-Area SCADA

But what if at some point your organization decided it should start analyzing data across sites? That would require that data be logged not only locally but centrally. In this case, you’d be advised to use a variation of the Wide-Area SCADA architecture that includes a central database where all three Ignition servers could log data. Data can be logged to both central and local databases by adding the Tag History Splitter Module. This setup would give you the ability to get more insight from your data by comparing sites to each other on the same trend, or aggregating the data from all of the databases into one report.

Wide Area SCADA-Central Database

Hub-and-Spoke: Connecting Many Remote Sites to a Central Site

Organizations that have a very large number of remote sites, such as oil-and-gas companies that operate hundreds of rigs out in the field, need a reliable and economical means of logging their remote data. Hub-and-spoke is a type of multiple-server architecture that is ideal for organizations with hundreds or thousands of remote sites, because it allows them to collect historical information from many remote sites to a central location, while keeping costs down by using a minimal number of modules at each site.

The hub in the hub-and-spoke architecture is the central site with an Ignition server that has the Vision and Reporting modules. The spokes are the remote sites, which each have a data-logging computer with Ignition and only the SQL Bridge and OPC-UA modules. That way, the remote site connects to the PLC locally so that data will not be lost when the connection to the central hub goes down. The Ignition store-and-forward feature on the embedded data-logging computers ensures that data is recorded at the remote sites when the connection to the hub goes down, and it forwards the remote data to the central hub once the connection is restored.

Data can be logged locally and remotely in a hub-and-spoke architecture by installing a local database and the Tag History Splitter Module at each site.

Hub & Spoke: Reliable Local & Remote Data Logging

Although the remote data will be saved when the Internet connection goes down, the hub won’t be able to see the remote site when that happens. If your organization needs to maintain visibility to your projects when the connection goes down, you can add a local Ignition client with a limited version of the Vision Module at the remote sites. That way, the remote clients can fall back to their local client and keep the project visible when the connection to the hub is lost. For water districts or oil-and-gas companies with remote sites that need to function when the connection to the hub is down, this hub-and-spoke architecture with local client fallbacks and local and remote logging is ideal.

Organizations can continue strengthening the spokes in their architecture by adding alarming to them. This can be accomplished by adding the Alarm Notification Module to each of the remote sites.

With hub-and-spoke architectures, you can keep your remote sites fairly limited or make them more independent by adding more modules and local clients to them. You have the option of simply logging data from many sites centrally, or of setting up remote sites that are able to keep performing many critical functions on their own.

Hub & Spoke with Vision & Alarming

Hosting Ignition in the Cloud

Hosted Ignition Server

Ignition can also be used in a hosted environment using the Cloud. This software-as-a-service (SaaS) approach is becoming more popular among end users and system integrators. Cloud-based systems offer several appealing benefits including simple scalability, easy data access via the Internet, and lower IT costs.

So how does a Cloud-based Ignition architecture work? The general strategy is for the integrator to host Ignition on their own servers or through a Cloud-computing service (such as Amazon Web Services, Microsoft Azure, or Rackspace) to provide runtime clients for their customers. The integrator would set up two redundant Ignition servers in the Cloud along with a firewall and a public IP address. The customer’s information would be collected in the Cloud, and then the customer could open up a runtime client and log in from almost anywhere to see their screens, reports, trends, and any other features that are being provided on the Ignition Cloud server.

In order to host the customer’s information, the integrator needs to collect it from the customer’s PLCs. A smart way to do this is to install Ignition with the SQL Bridge Module at each of the customer sites, so that their data can be logged to the database in the central location hosted by the integrator. The other way to collect the information would be to connect the Cloud server directly to the PLCs through a cell tower, a satellite, a secure VPN, or by polling or round-robin-type polling, although this method could cause security concerns for some customers.

Cloud computing is possible with Ignition, but those who deploy such an architecture should be careful about what they put in the Cloud. It is best not to handle control in the Cloud, so that you do not create the possibility that someone to could turn parts of your system on and off from the Internet.

Build Any Architecture You Need

In any architecture – whether it’s Cloud-based, hub-and-spoke, or wide-area SCADA – the modules installed on the Ignition server should be selected according to the customer’s needs. End users and integrators should thoughtfully determine whether a given site needs to have real-time values, where it needs to log historical data, where redundancy is most critical, and so forth.

Every organization has unique needs, and Ignition allows them to build any architecture, from a simple data logger to a SCADA network that stretches across thousands of geographically dispersed sites, and almost anything in between. By leveraging the modular Ignition platform, every organization can find the sweet spot between scalability, affordability, functionality, and security.