ISA106 procedures

Thoughts on the emerging ISA106 standard. And S88 phases.

What can a step in an ISA106 procedure do?

Ask the operator to do something, from setting up equipment to entering data to confirming that a manual or paper procedure has been completed

Request equipment to do something for example run an equipment procedure or set equipment to a state

Set up something such as set points for control loops

Record some data

By the way that looks like just the sort of thing an S88 batch manager recipe procedure step can do - but of course ISA 106 people don't seem to like S88's' batchness'  Comment please.

Let’s look at the second, asking equipment do something and setting equipment states.

What is the difference? If you ask equipment to do something then the equipment might do numerous things and then say Done.

If you set equipment to a state the equipment might still do several things in the process before it says State Established.

There really is no difference in terms of interfacing a procedure with equipment control, but the first of these may run a longer and more process oriented sequence - and in turn set the equipment to states.

Let’s call the 'Do something please' equipment step a phase (following S88 terms).

Because it is run in the equipment - ie by the BPCS (Basic Process Control System ) that controls the equipment , let’s call it an Equipment phase (or if you like an Equipment Procedural Entity) The Equipment phase itself runs a sequence of setting equipment states with transitions (cf feedback) to direct the steps and confirm that the process actions are achieved. 

The Phase could of course set all the individual devices one by one (a common practise). Or it could set a state in a higher level physical entity, provided that entity can in turn set the lower levels devices.

That is what Equipment State Matrices are about – they are deployed in the  Dow/ABB State Based Control paper (see Tables 1 and 2) and by most ControlDraw users - and they are highly advantageous. Why?

If you don’t know what they are you can look for them on google 

They provide logic where all requested states are known easily. And as many states may be used more than once by different steps and even different by procedures they are more efficient. Alarms can be enabled according to the state matrix, Control loops modes set and so on.

In fact part of the Dow/ABB State Based Control paper is about this, and as I blogged before nothing to do with the S88 model where a recipe (cf procedure) speaks to the equipment. And I do mean Speak, since the objective of part 1 was in part to ensure that chemists (and their recipes) could speak to control engineers (and their equipment controls)

I feel that so far S106 is neglecting State Based Control.

Equipment Procedure or Recipe Procedure?

I see that the latest draft of the updated part 1 spends a lot of words on Equipment Procedural Entities (Phases, Operations, Unit Procedures)

I think that this results from the idea that the recipe to equipment boundary is the same as the boundary between a recipe manager and an equipment controller.

My take on this is that if the 'equipment controller' has the capability of containing higher level procedures such as operations that do no more than sequence lower level ones such as phases then this means that the  controller is actually performing some part of the recipe control. And as such this is not equipment control.

If this concept were adopted, then the entire standard could be greatly simplified, and I think without losing any value.

I propose that the only function that an Equipment Procedural entity can perform is one that actually directly controls(or directs) equipment, for example a phase that sends commands and responds to to basic control.

For a bit of background on this, when I first had ControlDraw working properly, soon after the introduction of Version 2 and the object structure that exists to this day I dithered about whether there should be a separate Class for Equipment phases and Recipe Phases. 

I decided not to, as I found that the only difference was in their owners (in ControlDraw that is the Parent object that links to the Phase diagram.)

So, if you have a phase in a Recipe procedure that is not also in an Equipment item then it must be purely a  procedural phase, if it does exist in the equipment then it is an equipment phase. If in both then it is still an equipment phase, but is referenced by the corresponding Recipe Procedure phase.

There are Simultaneous Equipment and Recipe procedural elements

This was recently stated on the Part 5 Blog
"In some cases it may be sufficient to allow the recipe phase to directly control the equipment modules. In other systems where complex equipment modules exist, it may be necessary to implement some level of state model based procedural control in the equipment between the recipe phase and equipment modules in order to better deal with the underlying equipment complexity. Again, it’s an implementation decision left to the developer and thus does not restrict creative efforts."

I don't agree. The Equipment Phase must exist 'in' the equipment. Allowing "the recipe phase to directly control the equipment modules" is not a concept I can subscribe to.

I am assuming in the following a phase level interface for simplicity, but it could be Operations or higher.

The Recipe Phase is that procedural control that speaks to the Equipment Phase, it may just be one step in an operation, which interfaces with the Equipment Phase but does not actually control the equipment module (or Unit) - that is the job of the Equipment Phase. But in my view (and others) both the recipe phase and it's corresponding Equipment phase exist

To further illustrate, suppose we have a PC based batch manager executing the Recipe Procedure (so the PC is the recipe controller) and it speaks to the equipment controller (eg PLC or DCS controller) then the Operation and its steps and Transitions are coded PC, whilst the steps and transitions in the Equipment Phase are coded in the Controller.
These corresponding phases speak to each other via a Phase Logic interface and some data transfer such as recipe parameters

Now, it may be that there are applications of PC Batch managers where some of the equipment control steps and transitions are coded in the PC. That just means that the recipe and equipment control are not nicely separated in the implementation, but they still both exist.
And the S88 standards are not supposed to be about actual implementations, just the concepts and models.

Equipment Procedural Entity

There have been discussions in the S88.01 Update meetings about Equipment Procedural Entiies (EPE's)

This is how I view EPE's -

They are objects such as Phases that can be executed under the command of a Recipe - for example an SOP, or a Production batch, a Batch manager Control or MES Recipe - but which are contained in - and controlled by - the equipment controllers.

The Equipment Controller might be an Operator who runs the equipment manually or if the equipment is automated, the Process Controller - PLC/DCS, Relays or whatever - that is connected to the physical equipment. (Most times it is a mix of the two)

EPE's are part of equipment control.

In Object oriented terms they are like the Methods of Objects
The Equipment that contains the EPE is a Unit or an Equipment module depending whether the Recipe-Equipment Interface is at the Unit or EM level.
Note, the S88 standard says that Control modules cannot have EPE's. But this is no problem - if you must control one CM from the recipe, create an EM to contain it. There is no law against it.


The EPE's can be Phases, Operations or Unit Procedures.

Now, the standard does not say this, but what follows is I think consistent with the models. It is also a configurable aspect of ControlDraw.
Equipment that contains EPE's must also be Acquirable, which mean that the Control Recipe takes control of the Equipment when it needs to carry out some processing in it. And to take control of it means preventing others from controlling it. Which to me implies Acquiring the equipment.

There is a direct correlation between the Equipment Requirements of the Master Recipe and the Equipment that contains EPE's .

That means that the Recipe Equipment Requirement maps to the physical equipment.


This can be one for one in cases where the recipe must use specific equipment or one to many in cases where the Recipe can use different (but similar) equipment.
For example a Recipes' Equipment Requirements might have a Reactor and a Filter but the plant has several Reactors and Filters. The Acquire process involves reserving the equipment for the current batch.

The last draft has a diagram, "Figure 18 – Referencing equipment entities at different levels within a control recipe procedure."

See also
Think of batch standard as design philosophy
Much more to come !