The short answer to this question is no, Ignition is not a Unified Namespace. And the answer would be the same if you were to ask it of MQTT, Sparkplug B, or just about any other individual technology tool on the market.

While you can build a Unified Namespace using only Ignition, the power of a Unified Namespace comes from the advantages you gain from integrating multiple systems together using the Unified Namespace as the central data bus for communications.

Ignition can however be the starting lineup for implementing a Unified Namespace at your company, even if it is the first and only thing you are integrating on your Digital Transformation journey. Let’s dig into how!

What is Ignition?

Ignition at its core is a SCADA platform. It connects to PLCs and other software platforms to consolidate data across a manufacturing business, stores historical data in databases for reporting and dashboard purposes, and can even act as the centralized technology platform to run an entire business.

It can connect ERP systems to collect and manage production schedules. This schedule can be used by the plant floor operators to make necessary changes to meet customer demands. Productivity data can be integrated throughout the process to notify customer service and production scheduling staff of any delays. Any alarms or abnormal process conditions can be brought to operators attention to resolve them quickly.

Then, you can send data from Ignition to machine learning or artificial intelligence systems for advanced analytics—and many different analytics platforms process engineers use to ensure optimal process conditions.

Ignition is built to connect different systems together, including data from PLCs with archaic naming conventions, which will help anyone who interacts with the system understand data points, or tags. It makes data available to an entire organization, connects them to the Ignition server where they can use the data to figure out anything they may need.

Ignition (while not being a Unified Namespace itself) allows you to easily build a Unified Namespace across your entire technology stack, and ultimately your entire business.

What is a Unified Namespace?

As we described in our Unified Namespace 101 post, a Unified Namespace is the result of planning the naming convention for all of your data across your business in a clear and easy to understand way. This will allow you to easily integrate all of your technology and devices together through a centralized data hub, otherwise known as a Unified Namespace.

Assuming you define and enforce your Unified Namespace’s naming convention, you can easily build a Unified Namespace with Ignition. One of the benefits of using Ignition is that you can build a unified namespace using only the Ignition tag engine. Obviously, to get the most power from a Unified Namespace, you need to integrate other systems and use the Cirrus Link MQTT Modules to bring the data from Ignition into the Unified Namespace.

By starting with Ignition and plant floor devices, you can learn how to use a Unified Namespace. This can help you get more value from your system as it grows and your data needs scale.

How Does Ignition Support a Unified Namespace?

If you are integrating with an MQTT broker and/or Sparkplug B, Ignition will function like any other node in the system. It will send important information to the Unified Namespace and use the data it requires in Ignition to perform its configured tasks.

But, if you are using Ignition in a more traditional environment without MQTT/Sparkplug B, you can still reap many benefits of a Unified Namespace with the standard Ignition infrastructure built on Tag Providers.

With this very simplified architecture, Ignition will connect to PLCs through an Ignition Tag Provider. To enable the concept of a Unified Namespace, we need to map the tag names in the Tag Provider to our Unified Namespace hierarchy. Then, the tags can use the relevant OPC Tag Paths to get data from each PLC.

So, if we have a mixture of PLC brands—including some from Opto 22 where we can use a variety of communication protocols, some from Schneider Electric where we need to use Modbus TCP, and some from Allen Bradley where we can use the built-in PLC drivers on the Ignition Gateway—all the tags can exist in the same namespace even though they come from entirely different systems.

In Ignition, we could either use User Defined Types (UDTs) to build customized tag structures, which is useful if we have a number of identical devices in the field. Or we could simply use a basic folder structure. For the examples in this post, we will just use a basic folder structure. For a more detailed breakdown of UDTs in Ignition please check out our How to Program Lead/Lag Pumping in Ignition post.

Using the example below we have a pump, a valve, and a tank, each with a single tag configured in Ignition. We will bring each tag across from a different PLC and set them up in a coherent, Unified Namespace style architecture. If we were using MQTT/Sparkplug B, these would use reference tags in Ignition instead of OPC tags. We would update the path to MQTT Engine tags instead of PLC device level tags. Likewise, if instead we wanted to send this data from Ignition to our MQTT broker, we would use the Cirrus Link MQTT Transmission Module.

This approach allows us to build out a small portion of our system with the larger Unified Namespace in mind—without needing to have the complete Unified Namespace infrastructure in place.

The important takeaway is that the power of a Unified Namespace begins with our naming convention. We explore this concept in our MQTT and Sparkplug B Simplified post.

Wrapping Up

You can build your system from the ground up with the Unified Namespace in mind, even if you don’t have the entire architecture set up on day one. If you consider integrating the parts of your overall system in this way, you can begin to make the necessary culture shift at your company to get the most value from all your future Digital Transformation projects. Then, you can easily add an MQTT-based Unified Namespace onto the architecture above with no data loss or changes to your tag structure.

As you integrate more and more pieces of your system, think through the overall Unified Namespace layout and build it in as part of your overall project requirements. As new systems come online—even if they weren’t originally part of the overall Unified Namespace itself—you can easily add them in the future and without the extra work of refactoring and renaming along the way.