No matter what you think of ISA-95, we can all agree on one thing: it is thorough. At 9 parts and over 1200 pages, the standard provides a comprehensive set of relations and definitions for the elements of any manufacturing operation. And given how varied the manufacturing domain can be, the standard’s length reflects the inherent complexity of its topic.
But this thoroughness can also be intimidating. For a beginner, the number of entities, sub-entities, relations, and cross-references is overwhelming. Many industry veterans also have an understandable distrust of the overly theoretical: who cares about the perfect model with so many urgent matters at hand? The standard itself is open-ended about how it is applied. People who decide to adopt it must ask themselves, how much do I need to model?
In short, you don’t need to model everything. You need only what’s enough for your use case. Start with the requirements, and focus on clarity and simplicity. As your automation matures, you will find more use cases to extend and deepen your models.
General guidelines: stick to requirements and reality
Successful modeling starts with a clear picture of a use case and its requirements. The ISA-95 model is highly generic and flexible. To navigate this flexibility, let your requirements determine your model’s focus and scope. For the structure of the model, stick to the physical reality of production.
The more tightly you can define the requirements and the more clearly you understand the plant’s essential processes, the better you can use the standard to devise the model that expresses the most with the least amount of parts.
Use the minimum number of parameters
The goal of a model is to serve a use case, not create a complete picture of reality. After you outline the entities, materials, and actions to represent, avoid over-complicating the model with unnecessary classes, parameters, and nested relationships.
Even the experienced can fall into this trap. The standard provides ways to be extremely abstract and extremely granular. However, just because a detailed level of modeling is possible does not mean that it’s useful.
In fact, unnecessary parameters can actively hurt project development. Too much upfront complication inevitably delays implementation. Every element of the model creates more information that stakeholders need to understand and more parameters that the MOM and all the downstream systems must account for. At the extreme end of this risk, an overly complex model may never get put to any practical use. And if it does, its complication will add a maintenance burden that exists as long as the system lasts.
Design to be flexible. Once you adopt the standard, it is far easier to extend a model later than it is to change something. While the temptation to use the full power of the model is understandable, the best course of action is to keep to current requirements, and avoid trying to anticipate future ones.
Don't Try to guess future requirements
It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive.
Along with the temptation to create overly granular models, also resist the temptation to create something that is overly generic. Engineers naturally want to make things that are future proof. But many systems have been built that never grow into the size of their abstractions. Besides, the future is uncertain; if you could really guess what future requirements are, they would likely be present requirements.
For example, all material can have a class. When adding material for a use case—say track and trace—it might seem prudent to add a class for each material category or even each material definition. However, if the use case doesn’t require a class, why add one? If the enterprise later decides that it needs to create reports based on material classes, you will be able to add precisely the classes that the new requirements demand.
The flexibility of your initial design and the flexibility of the model should already serve future cases. Good architectural decisions on the application level also make extension easier. For example, Rhize’s data model already has ISA-95 models built into its schema. If an application built on Rhize needed to add material classes, the developers could use the schema that already exists and apply it to the associated material. This would likely require only a single GraphQL operation.
Model reality, not ideals
Finally, always ground your models in the physical reality of production. While this might seem like obvious advice, it’s always possible to overestimate the capabilities of the plant to execute advanced MES functions.
For example, consider the activity of performance tracking. Theoretically, more data is better, right? If the MES can collect information about every detail related to production, analysts and algorithms have more data points to compare. And more data points should help uncover more places to optimize.
But data collection itself is not free, and the level of detail that an MES can reasonably capture depends on the plant’s relative digital maturity. For example, a waste calculation in a batch process might theoretically use careful mass and quality readings at every single checkpoint of material consumption and production. In a plant with a high degree of automatic weighing and quality analysis, such granularity might make sense in the model. In a plant without this maturity or in an operation that doesn’t require such detail, the model would only obstruct production (and annoy the operators who suddenly need to manually weigh a bunch of samples for no good reason).
Conclusion
Requirements and physical realities determine everything about how much you need to model. The ways to apply ISA-95 are many. But the principles of how to apply it are always the same.
Ultimately, the successful application of the ISA-95 standard is also an example of successful cross-team communication. When an organization has a clear, mutual understanding of its requirements, processes, and goals, it can more easily create a model that is flexible, minimal, and scalable. The process is also symbiotic. After successfully applying the standard to a novel MES solution, an organization has also adopted a standard model that can scale to other MES functions. Each useful MES also advances the organization’s level of digital maturity, opening the path for future automation.