7 myths about ISA-95

ISA-95 gets a lot of critique. People say the standard is outdated, complicated, impossibly abstract, rigid, inflexible, and applicable only to narrow problems in niche industries. These opinions are so well known that you don’t even need to read the standard to hold them!

But such critiques seem strange when we consider Rhize’s customers, a diverse, forward-thinking crowd. All have proven histories of solving hard problems with great success. All are pushing the state-of-the-art in manufacturing and data analysis. But they also come from wildly different industries and use data for wildely different use cases. When it comes to their manufacturing operations, they have only one thing in common: ISA-95 as a data foundation.

How could this be? Is it possible that people on LinkedIn are misinformed about ISA-95? In truth, many stock critiques of ISA-95 originate with people who’ve never meaningfully applied the standard. And their misconceptions get repeated by people with perhaps even less firsthand experience.

Let’s dispel some of the biggest myths.

ISA-95 = equipment

Arrows pointing to equipment — Equipment, just a part of a much bigger picture

The equipment model is just a tiny fraction of the standard. But somehow many think that ISA-95 is the equipment model. The popularity of the UNS has probably unintentionally contributed to this misconception. People apply an Area/Center/Unit structure to their MQTT topic structure and call that ISA-95, no matter whether they’ve read the standard or not.

It is true that ISA-95 provides a way to organize equipment in levels: that’s the role-based equipment hierarchy. But in ISA-95, equipment is only meaningful when it is a resource to perform some function―hence the phrase role-based.

Many use cases do not even need an equipment model. For example:

A genealogy use case might need only material models
A QA procedure might need only material and testing specifications
Some processes may not involve equipment at all

Besides, the entire concept of separating equipment into levels is not even ISA-95. This layout is the Purdue model: which leads to the next misconception.

ISA-95 forces a system architecture

Another common misconception is that ISA-95 forces a certain type of system architecture or network topology. This claim is also common in UNS-adjacent circles. Typically the argument goes that ISA-95 represents “old-fashioned” architecture, unfit for the “modern” cloud world. What “old-fashioned” means exactly changes: sometimes it means a monolithic application, sometimes on-premises deployment, other times a hierarchical, point-to-point network topology. No matter what the claim, here’s the truth: your application stack is not the domain of ISA-95.

While ISA-95 does talk about what activities apply to different functions of the system, it is agnostic about where these functions live in your application architecture. Perhaps the misconception comes from the many diagrams that mislabel the automation stack pyramid as ISA-95. People see the pyramid and can’t help but imagine rigid hierarchies.

To reiterate: ISA-95 supports all types of patterns: hub-and-spoke, distributed, point-to-point, or any hybrid. Rhize itself is an event-driven, distributed architecture that uses ISA-95 as its semantic layer (we have various examples of Rhize transforming and ingesting data from external MQTT clients, OPCUA servers, and REST APIs).

In fact, using ISA-95 as an integration layer promotes integration across systems, regardless of the integration pattern.

ISA-95 forces a way to manufacture

Periodic table of elements — A useful model can apply to many cases. The periodic table, for instance, applies to all known atoms in the universe.

Another popular misconception is that ISA-95 works only for some narrow type of manufacturing. A related misconception is that some processes are too unique to be modeled as ISA-95, and the standard would represent a kind of procrustean bed that mangles processes into a certain shape. These notions are false. ISA-95 is not opinionated about what manufacturing looks like.

ISA-95 describes how processes are; it does not prescribe how processes should be. The only thing the standard “forces” you to do is to think with a higher level of clarity about an operation and its interrelations. But that’s the beauty of all precise technical vocabularies: they remove ambiguity about how to describe complex domains.

But the standard never says what is a correct process; it only provides the entities and relationships to describe any manufacturing operation. To say it “forces” a type of manufacturing is like saying the names in the periodic table of elements “force” a type of molecular behavior.

The standard is too heavyweight to be practical

Indeed, it would take a long time to model every single entity and behavior in a plant. But trying to model too much is a bad practice. You should start by modeling exactly as much as your use case and no more. Many use cases require just a few entities.

What its thoroughness does enable is a diverse range of use cases for any task that requires definitions, scheduling, execution, or performance analysis. It also scales across sites and vertically across organizational levels.

The standard is impossible to learn

Rhize regularly trains university graduates who have no experience in manufacturing or software. Amazingly, they all get the hang of this “impossible” standard in 4-6 months. Compare that with the traditional 20-year path to becoming an MES expert.

In fact, because the standard is so logical, it also helps people build an intuition about the necessary components of some use cases. And its carefully considered relations minimize the chance of making modeling mistakes.

However, we won’t deny that the language of the ISA-95 standard can be difficult or that its diagrams can seem perplexing at first glance. This is a trait of many technical standards, which have to be both abstract enough to apply to many cases and precise enough to remove all unnecessary ambiguities. To make the curve a bit gentler, we’re building beginner’s guides to different entities. I invite you to read them and judge their difficulty for yourself.

It’s just as well to build a custom model

Good luck! Modeling is hard, and manufacturing is full of edge cases. A custom model is probably fine for a small operation, but as you scale, it’s hard to compete with the thoroughness of ISA-95.

Beyond that, learning ISA-95 hugely reduces start-up time. Once you learn how to map different data to a standard model, you don’t have to spend any more time inventing bespoke models for each use case. What’s more, you can start with the assurance that your ad-hoc schema won’t require painful changes and migrations every time a new requirement comes around.

Useful for only MES-ERP integration.

This misconception is understandable, as the standard itself emphasizes this use case. But, as it turns out, building a data model to describe all elements of an operation has far wider applicability.

Through a well-crafted model of entities and relations, ISA-95 provides a graph to relate all components of the manufacturing system. This semantic layer joins all disparate systems that make up inventory, quality, maintenance, and, of course, production. But it is not only a data model, but an ontology, providing a way for all stakeholders to communicate about requirements and implementations.

In fact, while the original focus may have been L3-L4 interop, we’d say that that’s a relatively minor use case compared to its vast potential for data modellng, cross-team collaboration, and data governance.

Think bigger: ISA-95 as the domain language

Let’s think bigger about ISA-95. It’s not about equipment hierarchies and it’s not about interfaces for enterprise resource planning. Those are part of the standard, but the real value is that it provides a complete ontology to describe every aspect of a manufacturing operation.