Smart Manufacturing Using ISA95, MQTT Sparkplug and the Unified Namespace

Introduction

First expounded in the book, Future Perfect by Stanley M. Davis in 1989, the concept of integrating an entire organisation’s value chain to the point of achieving lot size one manufacturing capabilities at costs similar to those of mass-produced products was put forward as being the holy grail of most manufacturing enterprises.

Since then, there have been numerous efforts to move closer to that goal, including the standardisation of models of data exchange between different aspects of manufacturing enterprises with the introduction of the IEC 62264/ISA95 standard in the year 2000, to the more recent developments such as the Sparkplug specification for implementing consistent models of industrial information exchange, and the Unified Namespace concept for architecting smart manufacturing systems.

In this article, I’m going to define these aforementioned concepts as they are central to the idea of building smart manufacturing systems today. Further, I’ll describe how they relate to each other, and also provide implementation techniques in manufacturing facilities. In particular, I’ll describe how an MQTT Broker can be used as a centralised server for coordinating the exchange of ISA95 models implemented using Sparkplug, in a Unified Namespace architecture.

Why A Unified Namespace Architecture Matters for Smart Manufacturing

In a traditional manufacturing system architecture, you’d typically have your control applications running on devices and machines connected to a controls network. And then you’d have higher-level applications such as SCADA connected directly to these devices. And in most cases, the type of communication that is used between these devices and applications is a point-to-point protocol. What this means is that there is always a client and server communicating directly with each other, as shown in the diagram below.

Furthermore, this client-server architecture is in most cases implemented using proprietary application interfaces only known to and provided by device vendors, this means that applications become dependent on a particular device they control. In essence, you cannot remove a device and replace it with one from a different vendor without providing protocol implementation details. And of course, you cannot access the device data from, say, cloud-based IT systems that have no knowledge of industrial communication protocols.

Clearly, such an architectural approach is not suitable for building smart manufacturing systems because it results in systems that are hard to manage, tightly coupled, and, more importantly, unscalable.

However, what would be a more suitable smart manufacturing architecture is a hub and spoke model, whereby the participants of the network never contact each other directly. Instead, they publish information about themselves to a central repository of information, in this case, a Unified Namespace. Other participants can then go on to pull the information that they are interested in from the Unified Namespace. All direct communication is totally removed, thus making it easy to merge control systems with IT systems without them knowing about each other’s implementation details.

In fact, in a Unified Namespace architecture, you can replace a device from vendor A with a device from Vendor B and other network participants would not even know it, provided that the new device publishes to the same topic namespace. Further, using a Unified Namespace allows your smart manufacturing system to scale without limitations.

Essentially, a Unified Namespace is a middleware solution that allows you to collect data from various industrial systems, add context to it, and transform it into a format that other systems can understand. And one of the ways that a Unified namespace could be implemented is to use an Sparkplug-based network architecture. We shall explore that in detail later in this article.

But here’s the kicker, traditional manufacturing systems were built based on a hierarchical client-server architecture because that’s one of the ways to implement the IEC 62264 /ISA 95 standard, which is a functional modeling standard used to define the interface between control functions and other enterprise functions. However, ISA 95 does not impose a pyramidal network-and-system architectural approach for its implementation, as it is purely a functional modeling standard, not an inter-networking one.

As it turns out, the Unified Namespace architecture and ISA 95 are actually complementary to each other. Meaning that you could design your smart manufacturing system based on a Unified Namespace architecture and then use ISA 95 standard for modeling the data objects that get pushed to your Unified Namespace. And the benefit here is that you get to use an innovative and modern way of organising components of your manufacturing system in conjunction with a tried and tested functional modeling standard that’s already in widespread use, globally.

Again, we are going to explore this symbiosis in detail later, for now, let me give you a brief description of ISA 95 in order to set the context.

Introduction to ISA95

As Industrial Engineers, we all know what goes on the factory floor to produce the desired goods. We understand why things like SCADA, DCS, and PLCs exist and how they exchange information in order to keep the factory running. Similarly, manufacturing business executives understand how business systems on the top-floor work, they understand how logistic systems work to make sure that raw materials are delivered to the factory, how to create orders and make sure that things are paid for, and that there are trucks needed to take the finished product away for delivery.

Now, understanding that to get closer to the manufacturing holy-grail, the Factory-Floor and Top-Floor systems need to work in conjunction with each other. But yet, there is a whole set of activities that go on in the middle, between Top-Floor and Shop-Floor, that are not as clear-cut. These are activities that go on inside a manufacturing site that actually coordinate the personnel, the equipment, and the materials to get the job done. They take requests from the manufacturing business executives to say, here are the things you’re supposed to make and go on make them and report back to the business on what was actually made.

Traditionally, this had been left to what is called a Manufacturing Execution System (MES), but the scope of activities is much bigger than what can be achieved using MES. Hence, a team of experts back in the 90s decided to define something that was gonna provide a real solid interface between operations systems such as Distributed Control Systems (DCS), and business systems. And the ISA95 specification was born.

Now, ISA95 is a large specification with many parts developed over many years, and therefore I’m not going to attempt to explain everything about it in this article. So in short, the idea of ISA95 was to look at the activities highlighted above and try to identify common patterns in different manufacturing industries so as to develop, first, a standard and consistent terminology, and then from that foundation, create a model for exchanging information between operations technology and business systems. A model that can essentially be used in any manufacturing facility, making it much easier for the wide variety of hardware, software, and networking technologies to work together. You see, back then and even today, a lot of manufacturing systems provide industry-specific solutions and are incapable of exchanging information using a consistent format, both internally and externally.

Now, what the patterns revealed was that those activities or processes that go on inside a manufacturing facility can be grouped into different levels based on how much time it takes for a process to complete. This resulted in the famous diagram below.

Level 0 is the physical production process, for example, this could be a chemical reaction. And Level 1 consists of those systems that you put in place to sense and manipulate the process, these include Fieldbus devices, pumps, motors e.t.c.

Next, the systems at Level 2 are ones that use the information from level 1 to actually perform the control, which could be PID type control, or ON/OFF logic type control.

And then systems at Level 3 are the ones that drive workflows or recipes that cause the system to do exactly what it is you want it to do, which could be switching over to a new product, or directing plant personnel to take certain actions.

Lastly, there are Level 4 systems. These are called business systems and are responsible for taking orders and determining what product is to be made, what and how much raw materials are to be used, how much goods are to be produced, and so forth.

However, it’s important to mention here that, with changes in technology over the years, there’s no longer a clear line of demarcation between the levels in the above diagram. Instead, there are a lot of overlaps and the boundaries keep getting fuzzier.

Okay, now that we have a clear picture of what ISA95 is all about, I’ll go on to define what Sparkplug is and how it complements the above tried and tested model.

What is Sparkplug and How Does it Fit?

Now, before we go on to define what Sparkplug is and how to use it for a Unified Namespace architecture in complement to the ISA95 Framework, I’d like to hone in on Level 3 briefly, as this is the source of ambiguity that the ISA95 seeks to address.

So, a lot of the information that is required to operate a manufacturing facility is handled at this level. This could be through the use of tools like sophisticated MES systems, simple Spreadsheets, Warehouse Management Systems, custom software programs, Maintenance systems, etc. Now, with all those systems in place, there is obviously a lot of communication and integration which has to go on. And what ISA95 does is define these as activity models, for example, Production Tracking, Dispatching, and Execution.

Furthermore, ISA95 defines data objects that are to be exchanged between these activities, and more importantly for Sparkplug, data objects defined by ISA95 are implementation-independent.

Simply stated, ISA95 is an abstract specification. It doesn’t describe data types or information models that can be used to create these objects. Also, it doesn’t specify what transportation mechanism is to be used to move these objects around. It simply defines a standard terminology for what these activities are and uses UML representation for the data objects.

So, this is where Sparkplug comes in, and in case you are not familiar with Sparkplug, here’s a brief description of what it is and why it exists.

Technically, the biggest hindrance to the advancement of Smart Manufacturing is that Industrial systems have traditionally been, and to a large extent still are, closed and proprietary. Meaning that without interoperability, no meaningful information can be shared among hardware and software components of a manufacturing facility, especially from different vendors.

While standards like OPC UA were developed to solve that problem, its complexity has kept it out of the reach of most developers and software architects. What is required is a standard that provides manufacturing facilities with the simplicity of communication. It is with this in mind that the inventors of the MQTT protocol decided to come up with a specification for industry-wide interoperability that runs on top of MQTT, and called it Sparkplug.

Sparkplug is an open-source software specification that provides MQTT clients the framework to seamlessly integrate data from their applications, sensors, devices, and gateways within the MQTT infrastructure in a bi-directional and interoperable way.

Furthermore, and in alignment with a Unified Namespace architectural approach, Sparkplug allows for IIoT deployments to decouple the data between the hardware and software data sources. New data sources can become immediately discoverable to other system components and these data sources can become a single source of truth. And more importantly for industrial infrastructures, Sparkplug is fully secured, requiring no open ports for new devices and requiring TLS for all data transport.

Sparkplug Unified Namespace Implementation Using ISA95 Models

Now, how does Sparkplug help implement a Unified Namespace that uses ISA 95 for modeling data exchange objects?

First of all, Sparkplug uses MQTT as a publish/subscribe architecture for the underlying application transport layer and decouples producers and consumers of data in a Unified Namespace architectural fashion. Also, MQTT is based on push communication, which means data is distributed instantly to business-level systems, production, and a myriad of systems within manufacturing that are subscribed to that Unified Namespace.

Further, the Sparkplug specification helps to implement ISA95 specified data objects for exchanging information between these systems as it is, essentially, an exchange mechanism. It can take data from one system, put it into ISA95 format, push it to a Unified Namespace, and then the other systems can pull it out in an equivalent format.

This is all possible because Sparkplug has the capability of defining actual data and what the data looks like, whether it’s a Float, a structured value, or a complex piece of information. What’s more, Sparkplug allows you to build a generic data model, then an asset, and then populate the asset.

Case in point, for their Smart Manufacturing Framework’s Common Data Structures, the University of Sheffield adapted information models that have already been defined for OPC UA, by inheriting the data structure and simplifying for Sparkplug.

In addition, Sparkplug defines a standard format for MQTT topic paths, creating a Unified Namespace for all Sparkplug clients on the network. Below, is the structure of a Sparkplug topic path:

spBv1.0/<Group ID>/<MESSAGE TYPE>/<Edge Node ID>/<Device ID>

Whereby Group ID is a logical identifier for a group of MQTT nodes, MESSAGE TYPE indicates whether the message contains state information, data, or a command and whether it pertains to a node, device, or the primary application, Edge Node ID identifies a specific MQTT node and Device ID identifies a device attached physically or logically to a node.

Using Sparkplug to Map ISA 95 Enterprise Structure in a UNS Architecture

As you might be aware, physical components in a manufacturing facility are usually confined to a specific area, for example, a PLC controlling a specific Cell or a Supervisory Control and Data Acquisition System (SCADA) on a specific site. And if you have hundreds or thousands of components from different manufacturing sites, areas, and cells, all pushing data to a Unified Namespace, it can quickly become difficult to organise this information accordingly on the backend. As it turns out, ISA 95 provides a convenient way of structuring data sources in relation to their position within a manufacturing enterprise, hierarchically. ISA 95 recommends following the Enterprise=>Site=>Area=>Line=>Cell format.

Sparkplug payload definition allows you to readily apply this well understood and standardised format, for organising ISA 95 data objects that are being pushed to your Unified Namespace.

Below is an example of a Sparkplug payload with a hierarchical metric name reflecting this.

Furthermore, in cases where, as a manufacturer, you have multiple sites in different geographical locations that you’d want to gain total visibility, then a Unified Namespace architectural approach can be used implemented by having an Edge-Based HiveMQ MQTT Broker act as a local unified namespace at each site while connected to a central cloud-based HiveMQ MQTT broker through an MQTT bridge as shown below. This is to ensure that data exchanges that are local to a site are not affected by latency issues introduced by sending data to and from the cloud.

Conclusion

In conclusion, a Sparkplug compliant broker such as HiveMQ MQTT Broker can be used as a Unified Namespace for ISA95 based Sparkplug data objects that can be consumed or published by industrial hardware or software systems when needed for a specific action. In short, the Unified Namespace Architectural Approach, ISA95 Standard, Sparkplug Specification have a mutually beneficial relationship that could be used as a basis for building smart manufacturing systems.

For more information on Sparkplug, you can check out our Sparkplug Essentials series.