What are all these Recipe Defer Functions for?

If you are programming a Batch Manager, such as DeltaV batch or RSBatch, you will find yourself having to define the Defer Levels of Recipe parameters.

What is all this about?

Well, you can see some explanation on the DeltaV Books Online web site. And by the way Emerson, thank you for that excellent resource. And the explanation of the paints project shows well how to build a recipe in DeltaV.  

The basic principle is that the value of a recipe formula parameter used in a phase can be set by a higher level, so that you can ultimately create a master recipe formula containing the settings and define a path through the procedural hierarchy that sets the required value in the phase and hence in the equipment control.
Now, there may be many, perhaps hundreds or more, parameters that are used in the entire collection of phases that are run for a batch, but the actual master recipe formula need only have a small portion of them.
A design rule might be to only defer parameters that have to change for different recipes.

Deferring a Recipe to the Recipe Procedure

Deferring a Recipe to the Unit Procedure

The actual process of defining the paths looks rather tedious, because (as I understand)  you have to go through each level of the hierarchy, bottom up, deciding whether a parameter must be deferred, and furthermore if a parameter has to pass though multiple levels, then each level needs to contain the parameter - shown as Pass Thru parameters in the above diagrams. I can't help thinking that there must be a better way.
ControlDraw by the way allows you to link the top level parameters to the bottom level ones and then automatically work out all these Pass Thru parameters. Whether DeltaV would allow you to import these I do not know.

Where is the Batch?

Continuous and discrete processes can be used to make batches of stuff or things. That is the key to using S88 outside of batch processes! There is always a batch!

Is this the most misunderstood aspect of S88? It is not hard to understand at all:

A Continuous process can make a batch by running for a period of time with a set of recipe parameters such an Flow, Pressure, Temperature etc

A Discrete process can also make a batch - in this case a quantity of the items it makes - by running for a period of time.

Information flow from general recipe to equipment entity

The latest version of S88 has this diagram in it.

It is a nice little explanation of how a recipe maps to equipment. It really does not say anything that the original standard does not, but it does provide a different viewpoint.

There was an surprsingly long debate about how the Equipment Procedural Elements should be shown, should they have Start and End elements just like the Recipe Procedural Elements or not. The thinking was that the start and end implied that the bit in-between might be taking part in a sequence in the equipment, when really it is not.

I liked the idea, but also accepted that the EPE must have a start and end.

Furthermore there is a meaning to these icons, differentiating between where they exist.

So I have played a bit with the diagram - click to show full size.

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 Heavy,Recipe 'Lite'

A friend commented privately about my blog that it is equipment heavy. 

I take that as a compliment, it is my hope that this blog, and my software will help to improve Equipment Control.

I think he also means that the blog is Recipe 'Lite', so it's time to talk more about how I view the Recipe and Procedural side of Control.

I am sure that good equipment control makes recipes simpler. And Recipes Can Be Simple (or Lite). 

And intrinsically I think they are and I think that the S88 originators (and it goes back long before S88) knew that.

A recipe describes how to make stuff given some equipment.

A recipe does not care how to control equipment, it does not even need to define the chemistry, which means that it can be described very easily. And as Part 1 says, a Procedure should be essentially an Ordered Set - or sequence.

It is the sort of thing that operators have done for many decades.

Please readers, when you see anything that claims S88 compliance or benefits or profits or whatever, remember that S88 is not about how to program a control system.

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 !

Equipment for Making the Tea

The Turks do it another way

But that is for a completely different type of Tea.
So let us look at the Boil Water step in our English Tea Recipe.
Disregarding for the moment that this is probably control in a Common Resource, the typical English Kettle has a switch that once you have put water in it will boil the water and then stop.
The Recipe to make tea hands over to the kettle for that process action.
While the kettle is boiling it is executing the Boil Water part of the Control Recipe for your cup of tea.
Of course you do not Have to have an Electric kettle, you could use a pan on a gas ring, or a camp fire, just for example.

A Batch Recipe

Header
Name : A cup of tea:
Version: Typical English
Equipment Requirements
Teapot
Process Inputs:
Dried Tea Leaves (optionally in 'Bags')
Water
Energy for Heating
Parameters
2g of leaves per cup
Procedure:
Pre-heat teapot by using a short flush with nearly boiling water.
Put tea in Hot Teapot, then Add boiling water to a teapot.
Stir (optional).
Wait 3* minutes for tea to brew. (*time is a operational/user choice)
Put Milk in Cup - This can be done while the tea is brewing.
Please note - the milk Must be added to the cup Before the Tea!, (This is a Critical Recipe Parameter).
Pour tea into cup.

Slurp it up

Good things found in Vista:
Windows Key the type the name of the application - :
Bingo!