The Industrial Internet of Things (IIoT) is redefining the way that people talk about manufacturing integration. Rather than a fixed architecture we are moving to a world of smart connected devices that provide information and services to other 'things' in the network of networks.
Following on from my colleague Dan Miklovic’s blog post recently about the loss of relevance of the Purdue model in manufacturing integration, I am pleased to report that rumours about the death of ISA-95 are exaggerated. ISA-95 was an advance on the Purdue model as it took as its basis a model of integration between enterprise and control systems that defined a multi-level 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 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, IAS-95 offers a better starting point than this for a modern IIoT approach. The 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 argumnent, 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. In order for manufacturing staff to start to see the possibilities of the IIoT, he or she 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 helpful. 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 to implement a new MOM layer, but that complex discussion is for another blog post).
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 indeed a support engineer from the supplier of the motor gathering runtime information to use to improve maintenance across many sites and customers.
Now is the time to play at IIoT. We suggest that a good starting point is ISA-95 unplugged: its objects, IO and behaviors, and also control information about devices that you expect to be smart connected devices in your future IIoT journey.
Gain a year of free access to new research in our IoT Research Library by completing a survey.
