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.

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: 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.

S88 and Continuous plants

S88 Batch procedures carry out an ordered set of process operations on a finite quantity of stuff, batch by batch.

This ordered set is called by Part 1 a Recipe Procedure. It can be represented as a sequence of operations in time, typically by PFC/SFC logic .

A sequence of operations may take place in one place (or Unit) or different stages may take place in different units.

Note – this implies transfers, which S88 carefully does not attempt to explain.

Continuous production also carries out an ordered set of process operations, however the quantity of stuff is not finite, instead it grows in time, and more than that, most operations take place in Units that are specific for the operation, the chemistry happening as material flows through the unit.

Thus, the recipe procedure for a continuous process may well be represented as a process flow sheet - without the need for a PFC. And, actually the transfers are then implicitly described.

By the way, yes, PFC’s or SFC’s may be a good way to describe startup and shutdown and grade changes, that does not mean they are Recipe Procedures!

I have before suggested that Part 1 needs what I call a recipe equipment entity model, to underly the equipment requirements that are part of the (master) recipe.

I also suggest that the recipe equipment requirements are best described by a process flow sheet. This works with both batch and continuous.

The recipe view of the equipment should be generic, in terms of types of equipment, whereas the physical model must contain one or more of each of the types required by the recipe.

Where I seem to disagree with the work being done to “improve” Part 1 though (and this is compounded by the emerging Part 5) is that the procedural model is not a good model for actually controlling equipment. I think that State Based Control (check the tags on this blog) is a good example, it simply does not fit conventional S88.

There are ways in which Continuous process can be made to look like batch ones from the scheduling point of view, or even the broader point of view of an ERP or MES

In fact it is quite easy.

Automation objects and State Based Control

State based control is a method of defining the required states of some equipment and then driving the equipment to one of these states, typically where a Phase step sets the Equipment States.
It is an excellent way of describing the required behaviour of an Automation Object, or at least what I think of as an automation object. But I cannot relate it to Part 5 as it stands.
In essence designing a state controlled automation object involves in a large part determining all the required states that you need to set that object to. Please note that these States are not comparable to the Part 1 or 5 'Procedural States', they are things like Open, Closed, Ready to Fill, Filling, Reacting etc.
ControlDraw has long supported this method because it provides a very efficient method of representing functional requirements. And consequently over the 10+ years of designing systems with ControlDraw I now have designs for hundreds of these. You can read more here and here.
They range from basic control modules like motors and valves to highly intricate units, such as BioReactors, semi continuous sterilizers etc.
And looking at these, they have never needed to contain Resource Management. Yes they may have properties that relate to Resource Management, but always the actual Resource Manager is outside them. The lower level ones such as PID Controllers, are contained in Equipment Modules or Units, and the Resource Manager does not look at them, it only deals with the higher levels.
This is one reason for my objections to Part 5 as it stands. But please understand that I don't want to spend my time complaining about Part 5, I want to contribute positively.  

As it stands, I cannot. I think it should be completely re-started or abandoned.

Equipment Modules or Control Modules, which are cheaper?

I heard a good one today. I had emailed the State Based Control paper to a customer asking why parts of their plant model did not have Equipment Modules, perhaps on the lines of those in the SBC paper. I got a very good answer, part of which was that all the operational aspects in those areas are manual SOP guided. And that maybe some procedural control will be added when they understand better how to run the equipment.

But another aspect was that they get charged more for more equipment modules.

Now, I have been looking into the complexity of systems, and hence the time it should take to program them. And part of the point of using Em's is to reduce complexity.
So I suggested that as they do not have to run phases ( just like those in the SBC paper) call them Control Modules!

More on State Based Control

I spent a lot more time going through the ABB paper on the benefits of State Based Control

And in order to understand it better I have spent some time turning their example into a ControlDraw model. It was very interesting, first finding how easily the example can be modelled (using standard ControlDraw features such as Equipment State Matrices)  and how similar the ABB/Dow method is to the way ControlDraw can handle such requirements. One example (of many)  is that ControlDraw supports what you might call cascaded State matrices, where the state in a higher level matrix (for example a Unit State) sets the state in a lower level one such as an Equipment State. 

Please note - I do not mean the states like Starting, Holding etc in S88 Parts 1 and 5, I mean states like the ones the paper uses like Total Reflux, Empty etc. Well done ABB.

I also looked at some models in my archive where I found examples of Units that have 50 or more states and 20 or so equipment modules as compared with the 9 states and 6 EM's in the paper. Some of these date from 2001. So it really is not new. But nonetheless it is good approach, and as my examples show it is also highly scalable.

The paper says

"One last benefit of SBC is that it is an implementation of process control based on the principles outlined in ISA S88 Part 5"

I cannot see that at all. If anything the paper presents something better than Part 5 has offered, but it is really quite unrelated. I cannot either find any indication that ABB has been involved in Part 5 - I may be wrong, but if I am right, please ABB get involved, and don't make such statements for the sake it of it. 

One negative - a detailed review showed how poor the spreadsheet examples in the paper are.

The problem with using spreadsheets for this kind of application are numerous. Typical problems include:

1. Complex formatting, which while it may make table look pretty actually makes it very difficult to extract the data, for example to help with generating the application.
   
2. Multiple lines in the same cell are often a problem
3. If a tagname changes then there is a lot of work to correct the spreadsheet
4. You need a spreadsheet for each Unit, and there is nothing to handle higher levels like process cells

Of course these problems disappear if you use ControlDraw !

By the way, the same paper is now available from Automation.com, and you do not have to register.

State Based Control

There is a new White Paper on ControlGlobal.com called "The Benefits of State Based Control" written by David A. Huffman from ABB

Walt Boyes calls it a "very important white paper". It is quite good and I recommend readers, specially those working in the Continuous process industries, to download it. You have to register with ControlGlobal to get it, but that is worth doing anyway.

The paper does not claim that SBC is new, and indeed it is not. In fact SBC - or something very similar, has been the basis for a lot of ControlDraw models since CD was first introduced, in the mid 90's, and that itself was based on previous paper based ways of specifying State Based Control.

And in turn these models were often then implemented using SBC, and on a variety of systems.

The paper also suggest that implementing SBC is something that ABB with it's 800ax system has removed barriers to. That may be so, but the paper is short on details. Interestingly one of the systems that CD models have been used to specify (and frequently) is Sattline, now owned by ABB themselves. A little known fact is that 800ax is a direct descendant of Sattline, a system that can probably claim to have been the first object oriented DCS, it has been around since the 90's.

One thing the paper mentions is ISA S88 Part 5, but I cannot really relate the paper to anything in Part 5.