Combining the Power of ISA-95 and Sparkplug B
If you’re in the automation world, chances are you’ve heard of ISA-95. While the ISA-95 standard can describe many different things, unfortunately many people are not always using it correctly. If you are unfamiliar with ISA-95, or need to learn more about it from a modern automation perspective, please read our detailed post: Everything You Need to Know About ISA-95.
Additionally, if you've heard about ISA-95, you’ve also likely at least heard of:
Industry 4.0
IIoT (Industrial Internet of Things)
MQTT
Sparkplug B
When people say ISA-95 and Sparkplug B in the same sentence, they are usually talking about how Sparkplug B enables the use of a UNS or Unified Namespace. Using a Unified Namespace along with ISA-95 for some of your overall structure is a great way to get valuable information about the entirety of your business with modern manufacturing technology and software.
Part 1 of the ISA-95 standard focuses on this approach to the problem, where the overall concepts of modeling your business and process control systems are defined. Parts 2-8 of the standard discuss concepts that can be applied to technology like MQTT and Sparkplug B. We think that tying MQTT topics to the equipment model is doing everyone a disservice.
That said, in this post we will explain how to approach ISA-95 combined with MQTT and Sparkplug B correctly to maximize their value.
ISA-95: Business and Equipment Model
The main takeaway for most people from ISA-95 is the idea of the Equipment Model. This allows you to model your process as a hierarchy. This concept allows you to easily capture data for individual pieces of equipment, production lines, multiple production lines in an area, or even an entire facility.
The equipment model is an abstraction—a way to generalize how you think about your production processes by capturing only the most important details.
With the equipment model, you can focus on how everything is operating and see data in usable chunks.
However, it also means you may run into some issues with complex processes. A tree-based approach can't handle some process flow scenarios very well. While solving that problem is well beyond the scope of this post, it is something we debate a lot internally and with customers when we need to create a better abstraction for a complex process than the equipment model.
Sparkplug B Topics
For a review of MQTT and Sparkplug B, please check out our post MQTT and Sparkplug B Simplified.
The format for a Sparkplug B topic is:
spBv1.0/Group ID/Message Type/Edge Node ID/Device ID
spBv1.0 and Message Type are handled by the engine sending data to the MQTT broker, and you define the Group ID, Edge Node ID and Device ID.
Sparkplug B also defines a payload format for the actual data values, or metrics, you will send to the broker.
{
"timestamp": 1486144502122,
"metrics": [{
"name": "My Metric",
"alias": 1,
"timestamp": 1479123452194,
"dataType": "String",
"value": "Test"
}],
"seq": 2
}
This allows you to send any number of metrics to the broker and they will be populated for each topic. If example, if you are sending data to Ignition, the data will be created as tags under the MQTT Engine tag provider as seen in the screenshot.
In this example our topic is spBv1.0/My MQTT Group/Message Type/Edge Node 909b82/PLC1 and the metric is "Example Tag". When we send data to this topic from our Sparkplug B enabled device the value of Example Tag will update accordingly.
Sparkplug B Group ID/Edge Node ID/Device ID DOES NOT EQUAL ISA-95's Site/Area/Line
This post is talking only about OT data, we are not considering business systems like ERP, WMS, Quality, or Shipping/Receiving where you would need to write your own translation tools to MQTT regardless of using Sparkplug B or vanilla MQTT.
It is a common misconception you should map the ISA-95 equipment model to your Sparkplug B Topic.
***Editor’s Note***
After this post was originally published, we had a number of discussions based on a post on the MQTT Sparkplug Roadmap forum where user JeremyTheocharis explained the limitations of the Sparkplug B topic format in comparison to ISA-95:
Our response when asked our thoughts on the above post were as follows:
We 100% agree with Jeremy. Sparkplug B is designed for IoT devices out in the field, it immediately breaks once you bring it into a factory where the standard hierarchy convention is ISA-95.
Group Id/Edge Node/Device doesn’t support Enterprise/Site/Area/Line/Cell/etc.
You CAN use the (in our opinion very cumbersome) Parris or Schultz methods to put delimiters in the topic, but you would need to break those apart at the broker level and turn your Sparkplug B data into a standard MQTT topic.
For example:
Group ID: Enterprise:Site
Edge Node Id: Area:Line
Device Id: Cell:/etc
Then you’d have:
SpB/Enteprise:Site/Area:Line/Cell:Etc.
You can instead do things like pass in PLC specific data:
Facility Name/Line Name/PLC Name, which would give you all the data you want and where it is coming from, but zero context about the data so you’d either have to be cute with tag-naming conventions for the data in the payload, or send over a lot of metadata as part of the payload to provide the context.
Sparkplug B would be much better for the industry if it were not a fixed topic format and was instead “use this format for IoT data, and if you are doing OT data inside factory walls use whatever you need”.
For the record it is a hard sell for most people team to even consider MQTT inside a single factory, it adds a lot of configuration overhead and another moving piece to troubleshoot if it breaks. People would generally prefer to just use the regular comms protocols to SCADA systems.
***End Editor’s Note***
While you certainly CAN map things this way, it adds too many layers of abstraction to the process data and can get confusing very quickly. Using the example from above, this would look like mapping Packaging/Line 1/PLC to the topic, along with any metrics:
spBv1.0/Packaging/Message Type/Line 1/PLC
First, Sparkplug B does not have enough layers in the topic definition to PROPERLY map everything to the equipment model as you would want:
spBv1.0/Enterprise/Site 1/Packaging/Message Type/Line 1/PLC
And indeed, we know about Parris and Schultz and how they try to solve this problem. We will discuss those approaches later in this post.
How Sparkplug B ACTUALLY Works with ISA-95
If we take into consideration ISA-95 Part 7 (the section focused on handling naming conventions) we can demonstrate how applying the concepts outlined in Parts 1-5 to Sparkplug B can be problematic in the long run—and will eventually require refactoring as we scale the system.
For purposes of this discussion, we will assume application A is our SCADA application, and application B is an MES application tracking downtime. We will also assume that the data for application A includes device level tags from a PLC.
On the diagram above from ISA-95 Part 7, we see the overall data flow from a specific application or device level out to the broker and to any other devices or applications who will use this data.
ISA-95 Part 2 shows how to structure your global data format. Where applicable, include a reference to a specific location in the equipment model for a value. For the most part, this information is descriptors and values along with metadata like units. It is focused on individual values and uses references to information like equipment models so you can understand where the data needs to be applied. This is very useful when considering OEE (as one example) for a particular line or piece of equipment. Obviously, you’ll want to know the production count and downtime on that machine.
For applications like a SCADA system which will be focused on the data coming from the PLC, the equipment model isn't necessarily relevant to how the SCADA system and the PLC interact. You don't always need to manage the equipment model in this application like you do in the MES application where the object model has a direct impact on your data.
Even in this basic example, thinking through the ramifications of applying the equipment model at the SCADA level will create additional overhead without benefit. Instead, if you simplify at the SCADA level and just deal with the level of abstraction you need, then you can minimize the technical debt from managing the equipment model in multiple places. Then, when you need to interact with the equipment model (such as in the MES for tracking OEE, you can layer it in when converting from the global namespace to the local namespace—and put all the relevant data in the correct place). A corollary would be that the MES application does not need to be aware of all of the tags in the PLC. By filtering down only the information you need in the format you need it, you can reduce the amount of work included in the MES scope.
Here’s an example for a particular data point.
Let's say we have the following equipment model:
Corso Systems (Enterprise)
HQ (Site)
Production Area A (Area)
Line 1 (Line)
Bottling Line (Cell)
Product Tanks (Line)
Product Tanks 1-12
The bottling line is controlled from a PLC called PLC-BTL-1, and it has a number of values including:
Bottled Count Downtime Status Associated Downtime Reason Code Fill Level Fill Pressure Product Tank Level in Tanks 1-12
If we want to send data to the operator running the bottling line through the SCADA system, they will need to understand how many bottles the machine is filling, if the machine is down (and why), plus we need to have an alarm if the machine is down. The operator will need to set the fill level and pressure, and they will want to know the level in the product tanks so they can keep the bottling line moving as much as possible.
At first, the Plant Manager and Process Engineers using the MES application won’t necessarily care about the levels in the tanks, or the particular settings for this run. They will want to know how many bottles are being filled and how much downtime the machine has so they can see OEE. After the process has been running for a while, they start to notice that the tanks are draining faster than expected based on the bottle production. Since thye suspect that there’s a leak in the system, they will now want to investigate where the liquid is going.
As you'll notice, our equipment model has two production lines each with a number of cells below them, but our PLC-BTL-1 has data from multiple production lines contained within it.
Here’s what the Sparkplug B topic would look like if it was for all the data coming out of PLC-BTL-1:
spBv1.0/Product Area A/Message Type/Line 1/Bottling Line
While will be getting data for the bottling line with that topic with no problem, we will also be seeing data from the tanks in the wrong place in the equipment model.
This approach will add a layer of additional effort when we want to analyze the tank levels in the MES system. We will need to go to the Bottling Line topic, grab the data for the tank levels, then translate it into the correct place in the MES application. This adds steps that people in the future will need to know about and account for as a small form of technical debt.
While that might be easily solved, let's create a second topic:
spBv1.0/Product Area A/Message Type/Line 1/Bottling Line spBv1.0/Product Area A/Message Type/Product Tanks/Tank X
While this is another approach you can take, it also creates yet another layer of effort for the SCADA team who will need to manage splitting data up in their system to go from one PLC to multiple topics to ensure the equipment model is met. Again, not a deal breaker at a small scale, however it is a piece of technical debt that staff will need to know about and keep documented forever.
You might say, "Wait a second, have you heard of Parris or Schultz?" And, the answer would be yes, we have.
Here’s an example of these two topics now based on Parris:
spBv1.0/Corso Systems:HQ:Product Area A/Message Type/Line 1:Bottling Line/PLC-BTL-1 spBv1.0/Corso Systems:HQ:Product Area A/Message Type/Product Tanks:Product Tank 1/PLC-BTL-1
Schultz would ultimately look similar, although we would need to add more MQTT brokers to the mix to build up the topics across the entire architecture.
Both of those approaches are needlessly complicated, and would require people to separate the different delimited values in each topic to use the data—for EVERY integration to the Unified Namespace. It might not be the end of the world if everyone is aware of and using the equipment model, but for systems that don't care about the equipment model it creates a lot of technical debt to pay for simply using the data.
How Do We Avoid This Technical Debt?
By entirely removing the equipment model level of abstraction from the Sparkplug B data we can avoid these headaches. This is also where the real work of defining your communications and Unified Namespace comes into play. The process will be different for every company, as there are many ways to manage the flow of data and topic naming to best meet your needs.
Ideally we would use Sparkplug B to send data across the wire to take advantage of its compression capabilities, then before it hits the Unified Namespace, convert it into vanilla MQTT topics so we don’t lose any of our ability to map data to our semantic hierarchy. There are plugins available for HiveMQ to do this, and you can also build this type of functionality into other MQTT Brokers. This is the same approach the Cirrus Link MQTT Engine takes when integrating with Ignition. It parses out all of your Sparkplug B payloads into individual Ignition tags. This approach is covered by the box in the earlier diagram for ISA-95 Part 7.
You might also see this approach and think that it creates a little more work for everyone across the board—and we totally agree with you.
The major difference is that the extra work will ensure consistency across the board. Even if everyone needs to aware of how to structure the data, it will be structured consistently across all environments. At the same time, you will significantly reduce or eliminate the technical debt incurred by any one group from translating data across layers of abstraction for specific cases.
If for some reason you don’t want to take this approach and do want to use Sparkplug B, we recommend a couple of approaches below, then rely on the domain specific namespaces to map the values from the Sparkplug B payloads to the individual datapoints in whatever tool happens to be looking at the data.
While this breaks down the traditional idea of the Edge a little bit, overall it’s a good thing since we are removing abstractions. You could also say that we are looking at business functions as our network topology and defining the areas of focus and device types as our "edge". This also assumes that we are in a factory and not going outside the building—or that we don't have true edge devices pushing data to our brokers. This exposes some of the limitations of MQTT which was originally developed for an oil and gas company with remote well sites as a common occurrence (as compared to a traditional manufacturing process).
One approach is to consider functional areas of the business for our group ID, types of devices for the Edge Node ID, and then specific devices for the Device ID.
spBv1.0/Controls/Message Type/PLCs/PLC-BTL-1
We could expand this approach to other functional areas very easily:
spBv1.0/Controls/Message Type/Robots/Robot A spBv1.0/Machining/Message Type/CNCs/VMC-101 spBv1.0/Warehouse Management/Message Type/Shipping/Palletizer
Our individual data points will be sent across as Metrics within these topics, and then the systems that need the data (such as our OEE engine) could ingest the data and map it to their models very easily.
Obviously this is a basic example, however we can see where confusion begins to creep in when mapping this data to Sparkplug B using the concept of the topic as a representation of the equipment model.
Walk Before You Run
The views we present in this post could be considered fairly contrarian: building a topic namespace and avoiding ISA-95's equipment model as part of our topic definitions.
Our goal was not to be contrarian, our approach is simply a result of going through many iterations of these types of implementations at massive scales and finding where they break. If you have very few users or systems interacting with your data, and you are not using large quantities of metrics, the equipment model approach can work well.
You will likely have to educate people on the equipment model if they are not using it in their day to day life—which can create friction as you scale up.
If instead you have many users of your data, and are building systems on top of your Unified Namespace, you might spend a lot of time educating people how to parse complicated topic names with delimiters before they can get the data they need. Especially if they aren’t using the equipment model for their mental picture of your business. For example a maintenance tech might not be thinking of a particular instrument as part of the Enterprise->Site->Area->Line model, they are thinking about it as an input to PLC-BTL-1.
As you scale, it is important to keep the namespace as simple and as uncluttered as possible. Give people the ability to find information based on where they will go looking for it—and once they find it, don't make them jump through a ton of hoops to use the data!
Wrapping Up
As the length of this post demonstrates, implementing Unified Namespaces is a complicated endeavor! There are a lot of things to consider before you begin, and there are a lot of places where you can easily—and unknowingly—cause yourself a lot of hassle later on.
Having gone through the process of learning these lessons over the course of many years and many projects, our hope is that you can learn from our experience and find an easier and faster path to success.
While we still have a lot to learn about many things, we like to learn in the open and welcome any feedback you may have. Is your experience with Unified Namespaces different? Did we miss anything? Do you need more detail on something? If so, please reach out and let us know!
