ISA-95 Unplugged: How Will MOM and IIoT Merge?

Aug. 21, 2015
Detailing integration between enterprise and control systems, the ISA-95 standard offers a good starting point for an Industrial Internet of Things journey.

The Industrial Internet of Things (IIoT) is redefining the way people talk about manufacturing integration. Rather than a fixed architecture, we are moving toward a world of smart connected devices that provide information and services to other “things” in the network of networks.

ISA-95 was an advance on the Purdue model, taking as its basis a model of integration between enterprise and control systems that defined a multilevel detailed integration scenario. The six (and counting?) parts to the standard take a deep dive into business to manufacturing transactions with a detailed definition of the objects and messages required to implement such integration.

One of the goals of ISA-95 was to allow standard integration between manufacturing applications provided by different vendors. The messages that need to be passed between functional blocks are defined in the standards, and so in theory one could implement different applications from any source that followed ISA-95.

The reality of today’s manufacturing operations management (MOM) implementations is somewhat different. Most MOM systems use a database-centric architecture that allows the different applications to share information through the database. This is easy to implement and, more importantly from the software vendor’s view, pretty much ties you into a single-vendor solution.

However, ISA-95 offers a better starting point than this for a modern IIoT approach. IIoT offers the opportunity to bring together smart connected devices and assets and the data associated with them in an unlimited number of ways. If we imagine the ISA-95 functional blocks without their fixed connections to other blocks, we see that we have something very much like an IIoT architecture from the start. For example, a finite capacity scheduling application can be seen as a smart device that reads a plan from some other device (planning in the cloud perhaps, but for the sake of this argument, we don't particularly care) and delivers a production schedule to whomever wants it.

Of course the plant needs it, but so may some sales tool used by consultants who want to give customers up-to-date information on expected delivery of their order. It is not the job of the software designer to decide who will gain access, but rather to define what information may come out and in and what behavior is implemented. This is the public view of a smart connected asset (in this case a piece of software).

We can imagine everything that is currently in our control world as being an object—sometimes smart and sometimes connected. For manufacturing staff to start seeing the possibilities of IIoT, they can imagine all their current systems and devices as objects or things in the IIoT. They can then analyze how they could fit together and help each other in new and exciting ways. It is not necessary to start with everything neither smart nor connected, but it is useful to understand where connection and “smartness” would help to make the business run better.

Clearly, a little help in understanding how to split up your software systems to enable this type of thinking would be beneficial. This is where ISA-95 is your friend. ISA has gone to the enormous task of defining object models for just about anything that you can do at Level 3 (MOM) so you can conceptually break up your system using these pre-defined object classes (this is also extremely useful if you are considering implementing a new MOM layer, but that complex discussion is for another time).

You can also carry out the same exercise with systems at the control and enterprise levels and beyond. For example, you may have controllers in the field that are only accessible through a DCS or SCADA system. You can still imagine these as objects with behavior, inputs and outputs. A variable-speed motor might have outputs of actual speed, runtime and average speed, an input of set speed, and the behavior of being able to change the speed of the motor. Normally, these are used by the control system, but it is quite feasible to imagine a maintenance system directly accessing this data from the (future) smart device; or from a support engineer working for the motor supplier and gathering runtime information to improve maintenance across many sites and customers.

Now is the time to try your hand at IIoT. We suggest that a good starting point is ISA-95 unplugged: its objects, I/O and behaviors, and also control information about devices that you expect to be smart connected devices in your IIoT future.

>>Andrew Hughes, [email protected], is principal analyst at LNS Research, with a primary focus on research and analysis in the manufacturing operations management (MOM) practice. He has 30 years of experience in manufacturing IT, software research, sales and management across a broad spectrum of manufacturing industries.

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...

AVEVA™ System Platform: Smarter, Faster Operations for Enhanced Industrial Performance

AVEVA System Platform (formerly Wonderware) delivers a responsive, modern operations visualization framework designed to enhance performance across all devices with context-aware...