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.