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.

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.

Who needs the Transient Procedural States

I always work on the principle that the recipe controller (that handles the control recipe) is a transaction based sequencing and data handling system. It can tolerate short delays. It is in effect the process operator; it cares little about the equipment provided it can do what the recipe asks of it. It can request the equipment to do some process action, then wait until it has.

 Basic control that drives the equipment is real time and cannot tolerate such delays.

The original Part 1 provides a lot of suggestions and some basic models that help to specify both the recipe and the basic control. And it shows how they can meet, via Procedural Entities.

 To interface the control recipe with the equipment, there must be EPE’s (Equipment Procedural Entities), typically phases, that actually execute the process action.

 But think about this – why should the recipe control have any real time capability other than being fast enough to avoid introducing significant delays?

If something happens that requires a quick response then it should not have to require data to propagate up and down the procedural levels of the Control Recipe, that will be slow  (and I have seen this cause problems,) and anyway it complicates the recipe procedure.

So, this leads me to my first objection to the Procedural State Transitions, and their extension in the Part 1 update and in Part 5.

Yes the Control Recipe may need to know whether an Equipment phase is running or complete but why does it need to know about Pausing, Starting etc?

Why do these transient states need to be exposed to the recipe?

 For example if we are running an equipment phase, as far as the world outside that equipment is concerned it is surely not of any value to know whether the equipment phase is Pausing or Paused. Once it is pausing or paused that is all the control recipe needs to know until it is running again. What the control recipe is supposed to do with that information is not defined – propagating modes to other objects maybe, but that should be only what is reasonable in Recipe Control – the real time stuff should be down in basic control. 

And I suspect that the transient states are really about the real time world.

PLC is 40 years old!

The PLC is 40 years old, time flies, I first saw one when they were maybe 5. In fact I learned much of my Batch control by programming PLC's. That is where control happens, in the controllers, surprisingly enough. 

While I may have complained that the WBF does not have enough about Control I had not looked though all the papers presented at this years USA Conference. (It is worth joining the WBF for this alone by the way, some are gems) and found one on implementing recipes in a PLC, by Igor Steiner, Janez Tancek, Marko Svetina at INEA d.o.o.

I hope they won’t mind me quoting a bit from their paper

This is about PC based recipe managers versus writing your own in a PLC

Pros:

High level of abstraction for complexity management

High flexibility&reusability

Rich functionality

Cons:

Unsatisfactory reliability of the PC platform

Poor adjustment to small and medium projects

Unsatisfactory time behaviour of the PC platform

Too low expressive power of phase behaviour mode

An interesting comparison, I generally agree. The Too low expressive power point is one that I think might be based on an over optimistic view of what a Recipe Phase has to do, for me there is very little it has to do apart from starting and monitoring the execution of an equipment phase, via a phase logic interface. I don’t even believe the ****ing states (such as Pausing!) should exist in the PLI, why does a recipe care about that?

The programming of the equipment phase itself of course can be done in the process controller, PLC in this case, and there you can do what you want using the power of PLC instruction sets, which have high expressive power.

The paper also describes the Concept of Tabular Recipes on a PLC, nothing new, to my knowledge something similar was done in Wigan in the mid 80’s using Siemens S5 PLC’s, but worthy all the same. There is by the way a popular misconception that S88.01 revolutionised batch control, I think that makes the point that it did not. It helped to specify it though, I agree with that, and it raised understanding of the issues.

PS - in fact Tabular recipes have existed in ControlDraw for many years 

Unit State Model

Latest on Part 5 developments
What is a Base State Model?
It says. The Base State Model defines a complete fixed set of defined unit states, unit state commands, and unit state transitions. Each Equipment Unit Procedure will comprise a subset of the same base sta...

This dates back to 1996, it works well. It integrates exception handling with Unit Control in ways that the conventional S88 Procedural States do not.