Where should the boundary be between Procedural Control and Basic Control?

The intent of the standard is to at least in part to alleviate human error by automating the manual procedures that are common today, and of course to do so with a recognised framework so that there is not a proliferation of individualist solutions, and all systems and end users are able to communicate consistently.
A current question is "Where should the boundary be between Procedural Control and Basic Control?"
I think we should start from an operational viewpoint and consider where the Operator interacts with Procedures.
Clearly, when a procedure is being run by an operator it would be unfriendly to say the least if the system had no tolerance of delays in the operators response
Now, that to me implies that the Process should be in a stable state whenever an operator input is requested.
And I think it should apply even if the Procedure is running automatically, in effect replacing the operator.

So I propose that the following apply
Procedures steps that interface with Equipment should do so by via Persistent Process States - Where a Persistent Process State:
    Is a State that is set entirely by Basic Control and that can be maintained without operator intervention
    Can persist for a time, for example longer than the slowest operator response or until some resource runs out

When procedure steps request equipment to do something they can do so by sending a State Request
A State Request is much like a control loop's Set Point. The PID controller (a type of Basic Control) then adjusts control valves etc to keep a Measurement at the Set Point, or within some limits.
With higher levels such as Equipment Modules or Units, Basic Control Loops and Logic can run to move  the process in the desired state and then keep it there, indicating so via an interface back to the procedure.

Procedures could set State Request in peer or lower level physical model entities
So, a Unit level Procedure may set the state of the Unit
Or it may set the state of Equipment in the Unit or of Control Modules in the Unit
They should never set the state of higher level entities
So a Unit level procedure should never set a Plant Area State or set the State of another Unit or an EM or CM that is outside the unit.

And for designing the Procedures it would provide a simple view without the complexity of showing the Module Logic

This shows how a procedure might look as a PFC

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.

ISA 106 - a Simple Hierarchy diagram

Just an initial proposal!

Suggestion for ISA 106 - The Production Run

This ISA 106 Production Run overview diagram shows a suggested high level state model for a Production Run
A Production Run is a suggested new Term that covers the operation of a Unit or Process Cell from shutdown through Starting, Producing to Stopping and back to ShutdownThe Production Run
Click the diagram to see it full size

ISA106 - What is a continuous process anyway?

You can read about the new ISA106 committee here. It is intended to develop standards, recommended practices, and technical reports on the design and implementation of procedures for automating continuous process operations.
One question this raises is what a continuous process really is! So let's look at a couple of real processes.


The first example is from the biotech world, the second from petrochemicals

Fermentation - there are some very large processes with fermentation at their core. Some use entirely batch whereby the fermentation is done and then the fermentation product is transferred downstream as a single batch. But there are others that run the fermenter continuously for as long as they can (many weeks) whilst periodically taking fermentation product out. Is this batch or continuous? They most certainly have recipes. And either way they spend a lot of time in a single controlled state that is essentially governed by control loops. I know of many such processes and both types use S88 oriented implementations.

The Unipol process. (A nice animation, note the batches appearing in step 6)
Much like the continuous version of the fermentation process this runs with a continuous feed but product is taken from the reactor in batches. Different grades of product can be made by changing the set points (recipe formula!) without shutting down. Is this batch or continuous?   This process too spends much of it's time in a single controlled state that is essentially governed by control loops.

It is not really important. but ff the two, the fermentation processes I have seen are more complex, but in part this is due to CIP complexities. On the other hand the Unipol process has more complex control loops and higher level optimisation systems.

I suspect the petrochemical industry is right up 106's street and the biotech industry is not

So what will distinguish the sort of process (or is it industries?) that 106 is to be aimed at?
This is a key point that must be resolved at the meeting

Finally a note -  there used to be a link to the Official ISA Part 5 Blog 

But this is presently unavailable as controlengineering.com has closed. Supposedly it will return.

ISA106: Procedural Automation for Continuous Process Operations

A new standard is being proposed, called ISA106: Procedural Automation for Continuous Process Operations
The WBF website provides a description of the forthcoming effort.

In the very early days of S88 Part 1, in October 1995 I presented a paper at the EBF in Dublin titled “Extending SP88 into continuous and semi-continuous processes.”

One point I made was that the Recipe operations for a continuous process are distributed in Space rather than time. So the sequence of process operations to make stuff happens continuously in a stream of equipment.

The essence of this is exactly the same as defined in part 1 for batch, so a continuous operation still carries out a process operation - A major processing activity that usually results in a chemical or physical change in the material being processed .

And in a continuous plant the ‘sequence’ is achieved continuously as the material passes through the equipment, whereas a batch plant carries out the sequence of actions batch by batch and may carry out many of the sequence of operations in the same equipment.



Since then I have further developed my understanding this to encompass how to make continuous processes (or discrete ones) exactly the same as batch..

The essence here is that the procedures needed to make a quantity of stuff or things as from the operation viewpoint can be identical for both batch and continuous.

This is predicated on the idea that the procedural operation of plants, whether batch, continuous or discrete can be the same. And that these procedures do not need to work real time – or at least in the time domain needed to control equipment.

Unfortunately (from an s88 purist’s point of view like mine) the procedural aspects of part 1 have been taken by many to prescribe a means of controlling equipment.

Now the concept of combining sequential control with state orientated control is a very powerful one, capable of controlling highly complex processes. But in my view these equipment sequences are not the same as the procedural level that puts together product independent equipment control to make stuff.

And I have never agreed that the procedural level as described in the original Part 1 was intended for equipment control. It was intended to provide the means to map equipment control to the operational procedures needed to make stuff. And no more.

But practise has not been that, and what we now have is a lot of systems which use recipe managers to perform equipment control - and I am convinced that this has been detrimental to many projects.

Now, referring to the Dow/ABB State based Control architecture I know it very well and I have in fact worked with Dow and Yahya to develop ControlDraw to support it even better than it used to.

But I do not believe that it is really S88 based, apart from the division of units into equipment modules (which by the way are not recipe aware) and control modules. The entire procedural level in the examples of this approach is missing, yes there are sequences to start up and shut down the equipment, but they are not in my opinion even phases as they do not perform process actions. For example, a sequence to start a distillation column is not a phase because it does not perform a process action, it just sets the column into the state where it can perform the distil process.

There is much more to say, for example about equipment requirements and routing etc. But I do ask that the ISA106 group consider what I am saying about the procedural level being an operational level rather than a control level.