Not “collapse” as in demise, but as in collapsing the levels used in the model. Isn’t it time to give the ISA95 model a little overhaul? The ISA95 team built a framework for modeling business processes with 4 levels of systems in an enterprise and placed Manufacturing Operations Management (MOM) applications on Level 3 of the model. Levels 1 and 2 were left for ISA88 to explain direct machine and recipe management, and Level 4 was supposed to be where “applications we don’t care about at the plant floor” go, applications like ERP. Manufacturing systems feed Level 4 applications in the background, but hopefully, at the shop floor, we do not have to look at those Level 4 apps or our eyes will burn : )
The concept that information has to flow up in the model before it moves out of the organization is a little outdated given that 50% of a product is usually now manufactured outside the company walls. In today’s manufacturing world, MOM systems do much more than just manage the plant, they also manage critical communications and transactions with suppliers of material, parts and specialized external processes like paint, chemical processes, testing, etc. That means that MOM systems are not just doing application-2-application (A2A) communications, they are also doing business-2-business (B2B) communications which (in theory) were supposed to be the job of Layer 4. These communications might need some coordination with the procurement function, but do not necessarily need to go through it.
When I take a business process management (BPM) view of manufacturing processes across multiple disciplines, I don’t really see “levels” as in ISA95. Business processes need to orchestrate communications and transactions with objects, applications and people in different disciplines and all appear to be at the same level. The level of data detail required (for example, seconds versus days) might be different for different applications or transactions, but precision requirements can be viewed as attributes of each transaction and not necessarily derived from a made up theoretical “level” for an application.
Can the “levels” in ISA95 become a constraint for manufacturing systems development and architecture if they are taken literally? If you look at the Purdue CIM model as a predecessor to the ISA95 model, the levels were closely tied to levels of management. Data would be rolling up and aggregated from lower level transactions similar to rolling up facts in a data warehouse to higher level metrics and scoring for executive management. The levels were not intended to represent walls for applications or systems. A reference model, like the Purdue model, is a good reference to have around and help us understand how functions in our own organization could be wired, but innovation can happen when we rewire the organization differently.
We are now witnessing the evolution of the Internet of Things (IoT) along with standards and protocols to facilitate machine-2-machine (M2M) and machine-2-application (M2A) communications. For manufacturing, the IoT means that industrial machines will be smarter with internal computers and internet connectivity, practically acting as any other computer, laptop or phone on the network. When a new piece of equipment is installed, it will present itself to the control system along with its operational constraints and energy profiles. The control system then can incorporate these to form a control strategy for that machine. As a result, the machine becomes part of an intelligent, machine-led optimization engine, where resource availability, product demand and energy costs can be easily viewed and weighed to provide the best production schedule. Do we still consider these smart machines and their built-in applications to be at Levels 1 or 2? Or do we see work happening at different levels within those machines?
The German government calls this next generation of manufacturing machines, robots and systems, Industry 4.0. But to make Industry 4.0 a reality, manufacturers will need to embed intelligence and communication capabilities into their products and we will need broadly accepted standards for communicating and collecting the data.
I am putting the idea out here to see if there is interest. I think it is time to start thinking of newer models for manufacturing systems that span across B2B, A2A, M2M, M2A types of communications with a BPM flavor of communications in mind facilitating implementation of Lean Manufacturing concepts, autonomous yet coordinated work cells, and aggregation of real-time manufacturing intelligence.
Please share your thoughts on this topic and any ongoing initiatives you have that relate to this topic.
1.5 years afterwards, LNS Research is discussing this concept : ) http://blog.lnsresearch.com/x-questions-from-yesterdays-agile-mes-webinar
Posted by: Conrad | March 01, 2016 at 01:33 PM
I think this is a very good observation, but I do not fully agree. What I often see, working with ISA-95, is that people mix up the Functional hierarchy with the applications. We have so many times seen the "Automation pyramid" presented to us. In this there is an assumption that there is a one-to-one relationship between functionality (process), application, and often also the device the software run on.
For me, the functional hierarchy is an abstraction, helping us to sort out thing. OK, many time the border between level 4 and 3 often also will be the border between applications, but as ISA-95 points out, it does not necessarily have to be like that. And this pose some problems, of course, for COTS suppliers.
I usually try to leverage the thinking of TOGAF, dividing the solution in Process, Application and Technology layers. The (business/work) processes are what we would like to have performed. The applications are our helpers in realizing this, and the technology layer is the physical realization. Here, virtualization is a big deal today.
In an industrial, shop-floor context, the Role-based equipment hierarchy becomes very relevant. This we must relate to the ideas of Cyber-Physical Systems. The whole factory is such CPS, and so is each work center and work unit. These are containers of functionality. A line controller is a good example of something that is not MES, but is still level 3 - even if it is implemented in a PLC.
My interpretation of role-based equipment is that they are applications in TOGAF terms. Each such equipment (not asset) is represented by some kind of control system. And a control system is not a PLC. The control system software can equally well be run on a PC, server, PLC or why not distributed.
Yes, there is a relationship between ISA-95 functional hierarchy levels and implementations, but we need to try to break free from thinking there is a one-to-one relationship between applications and levels. Then we can come up with even better implementations.
Conny Jakobsson
Industrial Enterprise Architect
Posted by: Conny Jakobsson | July 14, 2020 at 12:03 AM