ennl +31 88 52 25 000 Zandbreeweg 12, 7577 BZ Oldenzaal
Certified
PCS7, VMWare, Veeam, HPE
Best in class supplier and solutions expert
#1 Supplier in industrial automation and virtualization solutions

ISA 88 in Process Automation

ISA 88 in Process Automation

One of the most well know standard in process automation is the ISA88 standard. This standard defines a number of concepts and terms to allow for easier communication, programming and data exchange between software systems in a process control system. This standard is often used in Batch environments, but it allows control systems that do not have any batch control a very clear way of setting up software segmentation.

How does ISA 88 help me define software structures?

Because the ISA88 has a clear guide on how to setup an automation system and the software that goed with that, most automation systems follow this guide as part of the designed config. This clear guide of implementing an automation system starts with the physical structure of setting up an automation system. This physical structure define where equipment is on factory location, this location is named a site. On a site, you can have one or more production areas, and in these areas you can have one or multiple processing units. To start an automation system there must be at least 1 processing unit defined in the hardware, because if there is no processing unit, there is no need for automation. A unit is define as somewhere where the product undergoes a change, and so a process if applied to reform the input product to an output product.

To achieve this change in state, equipment is needed to create this change. For instance a mixer, heater or cooler, this equipment is called an equipment module, and is located in a unit. An equipment module, like a heater, is made up out of smaller, more simple, components. These components, like valves or pumps, are called control modules. When all these physical systems are engineered in the automation system, the engineer can think about the processing software to control them. 

The procedural model

To control a part of a factory we need some sort of description or idea on what it needs to do. The actions that something needs to do depends on the level it is in one the physical model. In case a describing the actions for a site, we can say it makes product A. But if we would then try to describe the action of the heater for the raw material intake tank, we could not describe it as making product A. So for each level of the physical model, we can define the action it does. This action is named according to the procedural model.

When talking about the most basic control we have in the automation system, it is the logic for the control modules. These control modules often have actions like Open/Close or Start/Stop. We call these actions Phases, and they are usually covered by internal logic of a function block in a control system. One level up, we are looking at the actions of an equipment module, these actions, like heat, cool, mix, are called operations. The operations are usually made in a sequence processing control function, and will control a number of control modules.

The third layer if the Unit operations layer, this is usually made in a batch control system, or can be made in a sequence control functions. The Unit Operation controls the product state change in a particular unit. To come to when a unit does something, a product descriptor is needed, this is often called a recipe or procedure. This procedure controls a process cell, and makes sure that Unit Operations are executed when they are required to run, to make the product that is created in this process cell.

ISA88 Physical model

ISA88 Procedural model

Grouping and design using ISA88

When implementing an ISA88 design it is often a good idea to mark up a P&ID. This will make sure that the whole engineering team knows what to refer to in meetings or engineering documents. Marking up a P&ID, and naming the Process Cell, Units and Equipment modules will define the hierarchy of controls and data sharing. But it doesn’t stop there, the tagging is also part of the ISA88 concept. Because, when we now have a clear overview of a hierarchial layout of the plant, from room to room, or unit to unit, we can easily come up with a tag coding system that follows the ISA88 design. Doing this will make it easy to see what Process cell, unit, equipment modules a control module  belongs to, and so, will make it easy to go straight to the correct control module in case of field work needing to be done.

Another thing that follows almost directly from these designs and grouping, is the layout of the control system and HMI. Because many control systems work with hiearchy folders for their automation software and HMI systems, the ISA88 structure can be used here as well. Creating the screens in the HMI based on Units or a couple of units in an overview screen and then being able to have an individual screen per unit, is ofter very useful. This is because of the function of a unit, being that it takes in a product and gives out a different product, it is always a good idea to have a screen for this for the operator to monitor this process. 

 

Instrumentation and utilities

A last thing to mention is a couple of exceptions in the design and structure of ISA88. The first one being that any instrument can be used by all equipment modules and is used as an information data point. Where for control modules it is so that only 1 equipment module should be able to use them. When a control module needs to be used by multiple equipment modules, we are talking about shared equipment or common equipment. This will usually lead to a utility based structure where one equipment module can claim a control modules, or one unit will claim an equipment module, and will be allow to use it. When the other associated equipment module will try to used the same control module, it will be put in a queue and only be allowed to use it once the original equipment module releases its claim. This way common or shared equipment can be designed safely, and there will not be any point in time where both equipment modules sent commands to the same control module.

About iAUTOMATON

iAUTOMATION is an automation specialist that focuses on industrial automation, IT and the links between these two fields. With many years of experience in the industrial automation and IT world, iAUTOMATION is a mature partner that will benefit you.

iAUTOMATION provides complete projects for the industrial automation world with a specialty in PCS 7 consultancy and engineering. But other systems are also known to us and can be implemented by iAUTOMATION.

With knowledge of virtualization, networks, domains and IT management, iAUTOMATION is also a very suitable partner for all your IT questions and projects. We will always assist you with great enthusiasm and knowledge in your projects, and try to relieve our customers by proactively and positively tackling your project.

About the author

Dennis is Technical Director at iAUTOMATION, where he is responsible for all the technical queries and technical solutions that iAUTOMATION provide. Dennis also helps customers and the iAUTOMATION consultants with the technical side of projects and designs. Dennis has a lot of experience with process control systems and IT infrastructure, this is why his experience is key in projects that include both these areas of expertise like MES, virtualization and process automation projects.

Leave a Reply