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.

S88 overkill?

An article in Food Engineering

Balancing Your Automation Standards - Cover Story - Food Engineering

One comment made in the article is

“I’m an ISA guy, but its S88 (for batch processes) and S95 (for continuous) standards are overkill,” asserts Rich DiBernardo, director of project engineering for Lecron Inc., Secaucus, NJ. “Projects that apply them never reach completion.”

Now, I think that is something of a misunderstanding of what ISA S88 is about, but it is understandable.

It is a misunderstanding because in fact the standard (part 1 at least) is only a guideline and does not say you must do all this, you can choose to exclude most of the possibilities in your own application.

But it is understandable because many 'S88' people push it too much, and furthermore they over complicate, seeming forgetting that the standard is supposed to make it easy for recipe designers.

What is your experience?

S88 for Continuous Processes

There is a new article on ControlGlobal

ISA-88 Works for Continuous Processes Too
Using ISA88 Principles to Address Procedural Operations in Industries Outside the Traditional Batch Realm

But it has no opportunity to make comments on it, so I will blog it.

S88 for continuous processes has been a topic for years.

This article says, "A procedural operation is a set of tasks conducted the same way time after time to achieve a certain goal"

Well, that is not actually the complete story - why? Because it misses out the batch.

And there is always a batch. Even in a continuous process.

I have commented on this before, look at the continuous tagged entries in this blog for more.

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.

Equipment Modules in Equipment Modules

As you all know S88 Part 1 supports Equipment Modules in Equipment Modules as indicated by this in the latest draft update.

I cannot at this moment think of one and nobody has ever shown me a real case that justifies it – if you know different Please Let Me Know. (You can comment here or email us.)

What I have seen is Equipment modules containing some sequential logic. But these are not phases that really perform Process Actions as phases should – I don’t rate sending a set point or prompting an operator as a Process Action by the way.

(I have also seen Common Resources implemented and Equipment modules and then containing equipment modules, but in those cases the Common resources were more like Units.)

Whenever I first review an S88 functional specification I look for this by the way. (If the functional specification is a ControlDraw model it takes about 10 seconds with Word it can take hours).

It is very rare, and always arguable.

Now, I think S88 would be greatly simplified and the implementations improved if the ability to have Equipment Modules in Equipment Modules was removed.

Of course you can do that yourselves when you do an S88 modularisation and without straying from the standard – and I highly recommend that you do.

S88 Part 1 Revised

As you may know from this, a new version of the ISA S88 Part 1 standard is out for vote. Will you be voting?

Now, speaking for myself, I would not like the revised version to be thrown away, there is useful stuff there. ButI would only like to see it published as a supplement to the original.

But please, don't make the Revised S88 Part 1 replace the original.

And of course it should be free, as should the original but that's another issue.

For me, the revised version adds little to the original, it does not make it simpler and it does not resolve some problems that have been evident since the guidelines were first published.

The revision has been prepared by a group of people that is smaller, less international and has a narrower perspective than the original team.

Much of the 3+ years spent revising the document have been spent re-arguing original issues and indeed re-learning what Part one really said.

I was to my delight accused of being an S88 purist at one point during the debate. I don’t think it was tended as a compliment, rather as a means of dismissing what I was saying as being eccentric.

The ‘standard’ is not a standard – it is about terminology and guidelines based on good, but not definitive models.

For me, the clarifications do not clarify, the diagrams are not improved and the models have only been restricted – that is not a good thing.

Most especially the revisions do not further the objective of making it easy to create recipes, and they do not help to improve control software.

Problems not resolved include:

What Recipe Equipment Requirements really are and how they relate to real equipment.

How Batches can be defined for Continuous and Discrete process

Actually I think all the problems are easily accommodated with the original, if you interpret it ‘Purely’. And avoid trying to use the procedural model in the physical domain.