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.

S88 Part 1 update progress

The Update to Part 1 is apparently late, it has taken so far 3 years when it should have been done in 2, and there is still a lot of disagreement.

S88 defines hierarchical recipe management and process segmentation frameworks, which separate products from the equipment that they are made in, we all know that don't we?

But I am starting to wonder if the people working on the new version actually understand what that means.

Why do I say this? Well they are persisting with  their extension of the Procedural Model into the Equipment, so now they propose, for example, that the Recipe Procedure and Equipment Requirements can be passed to the equipment and that the equipment can contain the procedural hierarchy. 

In my opinion this is completely the wrong approach, and it will ruin Part 1.

 I really believe that they are confusing Controllers such as PLC's in packages with Equipment. And I can understand that, but I think there is a way round it.

I know that the team has been working hard to improve part 1 and there are no doubt some good things they have done. But that will all be undermined if they continue to follow their present path.

I got some good background from Lynn who was the one who managed to get the original Part 1 published, I won't quote all that he said, but here are a couple of points

I think the basic mistake we made in “part one – the original” was that we drew the diagrams that show interaction of the recipe with equipment control at multiple levels wrong.  We took the correct base case (recipe phase references equipment phase) and simply expanded it without coming to grips with what those things we offhandedly labeled “equipment operation” or “equipment unit procedure” above the equipment phase really are.  Once we all accepted the flawed diagrams we were stuck with that mode of thought and have been trying to explain how that works conceptually – and when we really try to do that it seem we really can’t. 

How did we get into this twisted solution?  It was pretty easy.  We knew we had a master recipe and that it needed to turn into a control recipe to make a batch.  So far, so good.  

We also knew that the master recipe needed to be able to direct the equipment at more than one level.  

Why?  Well there are two pretty good reasons why this flexibility could be needed.  First it is possible that someone has invented an operation or a unit procedure that doesn’t subdivide as Paul has pointed out. Secondly, we may just want to create the master recipe based on higher level procedural elements even though the equipment procedural elements the control recipe needs to address is an equipment phase.

 Lynn has much more to say, such as

 we were so taken with the genius of our hierarchy (it really is pretty neat) that we thought everyone should really use all levels of the model if they want to do the job right.  In most cases that is still not a bad idea.  But forgive us, we couldn’t stop there.  We – in our zeal – had to indicate to folks building packaged equipment that they really need to build these things in a modular way even if we don’t need to actually see anything below the operation or unit procedure level.  Thence cometh the diagram that shows the control recipe interacting with the procedural control of an equipment entity at the unit procedure level (or whatever) and – again in our zeal – we included the lower level parts of the hierarchy that we really thought people ought to know we thought they ought to build in

.And 

The huge mistake we all bought into and that has affected our thinking ever since is  that the diagram showed the control recipe connecting to an EPE at the unit procedure (or other) level when it was the master recipe that was really our concern

So it looks to me like like the update is just compounding rather than fixing a mistake.

I think they should make it absolutely clear that Equipment Control involves only the logic etc that actually connects to equipment. This of course means basic control but also the phase(+) logic that directly speaks to basic control.

As ever comments are welcome.

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.

Equipment Procedure or Recipe Procedure?

I see that the latest draft of the updated part 1 spends a lot of words on Equipment Procedural Entities (Phases, Operations, Unit Procedures)

I think that this results from the idea that the recipe to equipment boundary is the same as the boundary between a recipe manager and an equipment controller.

My take on this is that if the 'equipment controller' has the capability of containing higher level procedures such as operations that do no more than sequence lower level ones such as phases then this means that the  controller is actually performing some part of the recipe control. And as such this is not equipment control.

If this concept were adopted, then the entire standard could be greatly simplified, and I think without losing any value.

I propose that the only function that an Equipment Procedural entity can perform is one that actually directly controls(or directs) equipment, for example a phase that sends commands and responds to to basic control.

For a bit of background on this, when I first had ControlDraw working properly, soon after the introduction of Version 2 and the object structure that exists to this day I dithered about whether there should be a separate Class for Equipment phases and Recipe Phases. 

I decided not to, as I found that the only difference was in their owners (in ControlDraw that is the Parent object that links to the Phase diagram.)

So, if you have a phase in a Recipe procedure that is not also in an Equipment item then it must be purely a  procedural phase, if it does exist in the equipment then it is an equipment phase. If in both then it is still an equipment phase, but is referenced by the corresponding Recipe Procedure phase.

Why the procedural hierarchy in Equipment?

There seems to be an assumption that equipment procedures must themselves preserve the procedural hierarchy, so if you have an equipment Unit Procedure, that must itself be made up of phases. However I submit that this is not a reasonable assumption, because it makes the recipe have to dive into equipment control when there is no need for it, at least if we are going to preserve equipment - recipe independence.

If you can code a unit procedure in your controller that looks to the recipe like a unit procedure then that is all you have to do, S88 is not a standard for writing control software and should not try to be, that is stated in the standard.

If on the other hand you really want Recipes to reference Unit Procedures or Operations that are designed in your recipe procedure but implemented in the equipment, then I say that this means that you have a recipe controller in your equipment. This contradicts the concept of product independent equipment – I think it is part of the misunderstanding (or at least an alternative understanding to mine) of the original part 1 that the update is now perpetuating

Yes, I can see the need for being able to pass equipment requirements down the levels in a Recipe, but not to pass them across to equipment control.

And I can agree that equipment phase+ control might benefit from structuring into levels, to improve controller code. But hey, real time PLC and DCS control – the sort of thing you use IEC1131/3 languages for is not like recipe control.

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.

A word cloud from the original Part 1

I pasted most of the part 1 text into Wordle to generate this