There are a number of software and hardware decisions we need to consider when building out a Unified Namespace architecture. In this post, we will discuss the most common items in a Unified Namespace architecture as spelled out in the following diagram:

Devices / Sensors

This portion of the diagram represents the lowest level of the ISA-95 model with instruments, field devices, and process equipment.

We will divide it into two sections specific to this portion of the diagram:

• Sensors and IIoT Devices

• OPC-UA, Modbus, and Other Protocols.

The Inputs/Outputs at the bottom of this section connected to PLCs and Remote I/O Devices will be handled separately as the communication considerations for those are slightly different than Sensors and IIoT Devices.

Sensors & IIoT Devices

Starting on the top left of the diagram are Devices and Sensors. Depending on the application and vendors, this can include instruments to measure different process variables, valves/pumps/motors and other process equipment—and based on the diagram, they could even be items communicating using protocols like OPC-UA and Modbus.

From an IIoT perspective, these devices are typically wired into a gateway capable of converting their signals into the topics and payloads we would send to the broker using MQTT. This gateway could be a vendor-implemented embedded device, a microcontroller, a computer running NodeRED, or a program capable of talking to the devices and the MQTT broker.

Depending on the vendors and the hardware they offer, you may or may not have a way to streamline the configuration of these systems. This will truly be a case by case basis type scenario.

Main Takeaway for IIoT Devices

When considering the architecture for IIoT devices, the main takeaway is to work with your vendors to build out the type of system you need. If you can find field devices capable of integration with industrial rated I/O modules or PLCs, we tend to use those over devices marketed for IIoT purposes which can sometimes run software you won't be able to modify if needed which means could have more vendor lock-in than with a PLC.

OPC-UA, Modbus, and Other Protocol Devices

By definition, OPC-UA, Modbus, and any other industrial protocol is not capable of directly communicating using Sparkplug B or MQTT. So, you will need a device or software conversion tool. In the case of Corso Systems, we built a tool called PySparkplugB to handle this for us. You could also choose other industrial conversion tools like High Byte Intelligence Hub, or you build your own using Python, C#, or even NodeRed.

Basically, you will need a tool to communicate with the industrial protocol of choice which will then convert the signals from the protocol to Sparkplug B topics and payloads. Since most industrial protocols use a polled communication model rather than report by exception, you will also need to set up parameters for deadband, or determine how much a numeric value needs to change before it will generate an exception to send a new payload.

These gateways are still necessary because is a lot of manufacturing technology is built on older platforms which have been installed for a long time. It can be extremely costly to upgrade and migrate these legacy systems to new technology. Adding ways to convert communications from an existing system to a new system is usually the easiest and cheapest way to integrate new technology.

In this architecture, the gateway is the node for handling this communication protocol conversion. It’s also a widely adopted and established methodology for incorporating non-MQTT or Sparkplug B enabled devices into this type of architecture.

In many instances—especially when using a SCADA platform like Ignition along with the MQTT Engine and Transmission modules from Cirrus Link—the SCADA platform can act as this gateway without the need for additional technology to connect your devices to the Unified Namespace. This is a great use case for Ignition's Edge Gateways. You can use Ignition Edge to communicate with the PLCs and using the Edge IIoT module to send data up to your Unified Namespace using MQTT.

Main Takeaway for OPC-UA, Modbus, and other Protocol Devices

You can easily integrate devices using non-MQTT protocols into this type of architecture by getting the data into the correct format for integrating with the Unified Namespace. While it’s not required to use MQTT for a Unified Namespace, MQTT inherently solves some of the problems for integrating many different systems together.

Edge of Network Nodes

I/O Devices and PLCs

The next level down is I/O Devices and PLCs. By I/O devices, we mean either remote I/O connected to PLCs via the network, and/or devices like Moxa's ioLogix hardware line. These allow you to wire in industrial signals from devices and sensors like discrete inputs and outputs, and analog inputs and outputs. Then they can communicate using a variety of protocols to higher level systems, and can be integrated with PLCs where necessary.

PLCs are a potentially more obvious use case in manufacturing facilities as they are commonly used to control equipment and process control systems. They take signals from field devices, run programmed logic to control the process based on the I/O signals and can turn on/off and adjust outputs to manage equipment on the plant floor.

Typically PLCs and I/O Devices will communicate with protocols like OPC-UA, Modbus, Ethernet IP, or others. Certain PLC vendors like Opto 22 with their groov series of hardware can communicate using MQTT and Sparkplug B directly.

In the cases where the PLC hardware can communicate directly with Sparkplug B or MQTT, it can connect directly to the broker as in the earlier example above. In most cases however, the PLC will need to first connect to a SCADA system like Ignition which will handle the MQTT communication to the broker.

Main Takeaway for I/O Devices and PLCs

Some PLCs and I/O Devices support MQTT and Sparkplug B out of the box and communicate to the broker directly. For those that don't, you will need to use an intermediary software package to handle the MQTT communication for you.

SCADA and IIoT Applications

Technically, SCADA can exist as an Edge of Network Node in some instances such as if you are using Ignition Edge to translate between field devices and PLCs to the Unified Namespace. SCADA can also bleed into the Application Nodes portion of the architecture.

Before Unified Namespaces, a SCADA system typically would be holding everything together. SCADA would communicate with PLCs, provide the user interface to control the process, act as the process historian, analytics package, and often times the MES package.

In a Unified Namespace, it still can connect many of the pieces, especially if the Unified Namespace is being built on top of an existing system. In this architecture, it is one level removed from the Unified Namespace conceptually, if not literally. This makes sense as the SCADA system is a domain-specific tool used to manage and control process conditions by operators. Much of the data required in a SCADA system is useful across the entire Unified Namespace stack—so integrating the SCADA system with the Unified Namespace makes a lot of sense.

In the case of using Ignition in a Unified Namespace Architecture, integrating the SCADA platform into the Unified Namespace is a relatively simple proposition with the Cirrus Link MQTT Modules. These modules allow you to build out a Unified Namespace integration using MQTT tags—with domain specific data populating the Ignition tag providers with reference tags.

IIoT specific applications provide a similar result. Examples include Particle.io, Arduino Cloud, or many other solutions on the market. Typically, these solutions might already be in place and a company wants to integrate them into the process control system through the Unified Namespace. Or, they may have logistical reasons to send data from devices and sensors up to a cloud-based IIoT platform directly instead of first passing it through the Unified Namespace.

Either way, once data is in an IIoT platform, it is available to integrate into the Unified Namespace similar to how you would integrate a SCADA system into the architecture.

Main Takeaway for SCADA and IIoT Applications

In a greenfield scenario, it may not make sense to run all of the data from the Unified Namespace through a SCADA or IIoT system, however you still can if you choose. In a brownfield scenario, you may save significant overall integration costs by leveraging existing data connectivity where possible, and running data through the SCADA system before it hits the Unified Namespace.

Your overall needs and architecture will determine the route you choose.

Application Nodes

The application nodes portion of the diagram is basically a catch-all for any systems you might be using to integrate additional functionality across the Unified Namespace. Typically, this includes process historians, MES systems, ERP systems, analytics packages, and maintenance tracking systems. These applications—especially in the case of MES—may also integrate with additional systems outside of the specific scope of the Unified Namespace to keep other business systems up to date. This is especially applicable in a brownfield scenario where not all of the tools are directly integrated into the Unified Namespace from the start.

Similar to devices and sensors, many of these applications may require a conversion between the Unified Namespace and the application itself. This is because most business software doesn't directly support MQTT. Instead it will typically use some form of API integration or direct database access for getting data to and from its destination. Similar to how PySparkplugB handles industrial communication protocols, it—and tools like High Byte's Intelligence Hub—can support these integrations. This will save you the time and hassle of building them from scratch.

Wrapping Up

Now you shold understand how to architect all of the nodes of a Unified Namespace based system across the entire manufacturing technology stack. Going back to the ISA-95 model, this shows you how to connect every single layer of the Enterprise->Site->Area->Line hierarchy including all of the various tools you would need to run an optimal manufacturing business.

In future posts we will demonstrate how to integrate each node with the Unified Namespace itself. If you have any questions or need any additional information on anything we covered here please reach out and let us know!