With ICC 2023 recently behind us, Ignition Cloud Edition has become an ever-present topic of discussion in the manufacturing world. At Corso Systems, we have recently been answering many questions about how best to architect a cloud-based SCADA system. While the easy answer is always “it depends”, that answer also requires us to ask at least 900 more questions about everything you need to consider.

What is the Best Ignition Cloud Architecture?

The specifics of each situation will lead to a different list of risks and rewards. We’ve found most cloud-based Ignition SCADA systems fall into a a few categories. Knowing about these categories can simplify the overall decision making process as well as spark discussion about what will work best for your needs.

The main takeaway from this article will be a clear understanding of when you should use the cloud for the supervisory and data acquisition portion of SCADA along with how to put the C (Control) back into SCADA with a robust Cloud-based Ignition system.

Low IT Requirements Can Drive Cloud Adoption

The simplest example of a cloud-based system using Ignition is commonly referred to SCADA as a Service. This type of setup is most common in the water/wastewater sector, or might be provided by an OEM for their service technicians to troubleshoot/manage operations—while giving their customers access to their information without having to use an on-prem SCADA solution.

For example, a company can host an Ignition Gateway in the cloud, typically on AWS, with customer sites connected to the gateway for PLC communications, HMI operation, and data acquisition.

Diagram: Moving On-Prem Ignition to the cloud. PLCs on the left side, Cloud-Based Ignition Gateway in the center, Clients on various devices on the right side

A big benefit to this approach is the user has a lower total cost of ownership compared to buying an individual Ignition license, and low IT requirements since the service provider will usually manage setup and maintenance.

However, a big risk is that if your connection to the cloud fails, you will also lose access to local control of your process until it comes back online. Fortunately you can mitigate this risk by using Ignition as a service as sort of a “mini” enterprise architecture.

Enterprise Data in the Cloud

By far, the the cloud-based SCADA approach we’re most frequently asked about is the practice of using an on-prem Ignition Gateway to control the process, and a cloud-based gateway as a central data repository for analysis, process engineering, and dashboards. We think of this strategy as ScADA in the cloud.

Reasons to choose this approach include managing overall licensing fees, non-plant floor employees can easily access data—along with access to integration between process data and more advanced analytics tools.

This approach can also have a number of configurations. Here are just a few examples:

Local Ignition Edge gateways sending data from on site to a connect cloud instance of Ignition
Local Standalone Ignition gateways sending data from the site to a cloud instance of Ignition
Multiple Gateways at the site level, divided by functionality to send data to the cloud
Cloud connected IIoT devices or other devices with Ignition Edge gateways outside the facility

In all of these these configurations, the choice to not use the cloud gateway for process control is what differentiates them from more “standard” Ignition installations. This architecture is an excellent use case for Ignition Cloud Edition, especially since it does not provide access to any PLC communication drivers.

However, the main use case for Ignition Cloud Edition in this architecture is making the data accessible to anyone in the company who needs it, such as higher level managers who want to see performance dashboards from many different plants without having to a separate client for each facility.

Enterprise Cloud Architectures also allow process engineers to compare and contrast data across multiple facilities. They can also easily integrate the data already in the cloud with advanced tools like machine learning technology to gain more insight into their operation.

It’s important to note that this is also inherently the least risky Cloud-based system. You won’t lose any functionality at the plant level if your internet connection or cloud provider goes down or becomes inaccessible. Your plant floor systems will keep data on a store and forward loop, and will backfill when everything comes back online.

This architecture can unite multiple sites into one system to simplifying comparisons between each. It can streamline overall business system integrations by reducing the number of databases you need to interact with as well.

Enterprise with High Availability for Local Control

If you really want to move all of your operations to use Ignition to the Cloud, you need to consider process control as part of the equation. Essentially, this keeps the “C” (control) in SCADA in the cloud.

Using the cloud for process control of your local assets is inherently more risky than using on-prem Ignition gateways. If all your communication is through the Cloud, then if the Cloud provider itself goes down (or your internet connection fails) you will not be able to run your process.

Corso Systems can mitigate this risk, and we’ve used a specific strategy on many projects—even when they have on-prem Ignition gateways. Essentially, in any situation where a network can go down for any reason, we can set up a “Local Client Fallback” as it’s known in the Ignition documentation. Basically, you can run Ignition gateway(s) as close to your process as you feel comfortable. In many cases, we’ve deployed multiple Ignition Edge gateways running in machine control panels—all in a single facility. Another option is to use an on-prem Ignition gateway running your whole facility.

Diagram of a high availability enterprise system with mutliple sites running Ignition Edge and local failover at the equipment level on the left. A cloud-based Ignition gateway in the middle, and then clients on various devices on the right

In this example the gateways are set up to feed the higher level gateway in the cloud. If the connection to the higher level gateway ever drops for any reason, the clients shift to the local gateway—this allows you to keep in full control of your system using the local gateways. Once the connection to the cloud is restored, store and forward will send data up to the cloud.

This approach does have additional cost compared to the previous architecture, both in the cloud using a full-blown Ignition license and at the local level for enough licenses to support your risk tolerance.

Typically we would use the Enterprise Data in the Cloud architecture for end users who want to take advantage of everything the cloud has to offer while minimizing their overall risks.

Data Storage In the Cloud

Many companies opt to use the cloud for database storage while running Ignition on-prem. This has become more popular with the introduction of Snowflake as an Ignition Alliance Partner. This approach gives you the best of all worlds by getting your data closer to data analytics tools, and doesn’t add risk from a control perspective. This use case is well supported and reasonably common.

In addition to the Enterprise with High Availability architecture, you can take a similar approach to an entirely on-prem system. Ignition Edge gateways will run at the machine level and connect to a main Ignition gateway at the site level. This architecture lets your plant can run even in the midst of an on-site network outage! While this approach isn’t necessary for most situations, it does provide valuable peace of mind to many of our customers. They know that they will never lose data while their equipment is running.

Testing the limits of the possible—into somewhat bizarre territory—you could use Ignition in the Cloud for control, paired with an on-prem gateway acting as your redundant server in a redundancy pair. We’re not saying you should do this, simply that you could do it to test the limits!

Wrapping Up

While the specifics of any Ignition implementation will usually be unique, we can help you find the right architecture with very little information.

When someone asks us about a Cloud SCADA architecture, the first thing we want to know is why they want to use the Cloud. We want to understand the value that you want to get from the cloud and from any related relevant tools. From there, we can quickly help you narrow down the correct architecture choices for your needs.

Once you know the overall architecture you need, we’re able to fill in the details with you fairly quickly. We’ll help determine the Ignition modules you need, the data you want to access, and the security to set up around it all. We then can apply the best practices and tools we have developed over the last 15 years of our Ignition development experience to implement the exact system you need for now and as it grows with you into the future!