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

AutomationML and ISA88 Part 5

According to Wikipedia, AutomationML (Automation Markup Language) is a neutral data format based onXML for the storage and exchange of plant engineering information, which is provided as open standard. Goal of AutomationML is to interconnect the heterogeneous tool landscape of modern engineering tools in their different disciplines, e.g. mechanical plant engineering, electrical design, HMI development, PLC, robot control.

Now, this looks to me to be covering much of the same areas as ISA88 Part 5 is attempting to deal with, in fact possible more. I suggest that the people involved in Part 5 should spend some time investigating AutomationML.

AutomationML is clearly coming from the European side of the pond (ok mostly Germany), whereas Part 5 is largely from the USA side.

I would really like to see something that explains how they relate to each other and whether there are synergies or indeed if they are competing.

DCS or PLC and Systems Integrators

As I mentioned in the last posting, there can be further reasons why a DCS solution may be better, for example the maintenance of the PLC/SCADA systems may be more involved because they all have different software architectural designs, no two SI's seem to do it the same.

Or the long term viability of an SI - and they are vulnerable - puts a client off compared with the stability of the DCS suppliers.

How can the SI's overcome these issues? At present they largely compete with each other.

What if all the SI's in the CSIA shared their designs?

and used identical documention systems?

and even shared their module libraries?

Then it would be easy for projects to be handed over to another SI if needed.

I think this would help the PLC/SCADA suppliers as a whole to compete with the large DCS suppliers, it could even put them at an advantage over the DCS suppliers.

Is this feasible?

I think it certainly is regarding the documentation systems - and I don't mean word processing, but by using object models, perhaps according to ISA S88 Part 5 - or of course ControlDraw models.

Now, the CSIA has developed some standards, such as CSIA’s “Best Practices & Benchmarks” Revision 3.0.1. This is an excellent document for both end users who want guidelines on selecting an SI and for SI's themselves to review their own business processes. But it is not a standard design.

And by the way, the CSIA is predominately American, few European SI's belong to it, so if you are looking for non US suppliers you need to look elsewhere. Your local PLC suppliers such as Rockwell, Siemens etc will be able to suggest a few.

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.

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.

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.

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.

S88 Working Draft 5 Version 4

This seems to be an incredibly complicated document with no explanation of the reasons for it, or the rationale behind the various concepts that it tries to present.
Why do Automation objects need to contain Functional Manager or a Resource Manager?
A PID controller (a good example of an automation object) is something that has been in existence for around about a century, and it never needed such things, what is the reasoning behind making it so complicated?

Will S88 improve - or should it?

Will ongoing developments of S88, specifically Parts 1 and 5, improve automation?
I am far from sure, in fact I think they will not.
I think it is arguable that even the original Part 1, for all the applause it has received, has actually had the effect of damaging the development of innovative automation products.
Why do I say that?
For a start, the ‘Procedural State Transition’ model given in the original Part 1 (which does not need updating imho) as an example is but one of many possible alternatives, and certainly not the ‘best’. And it may well have constrained product evolution. There are plenty of other similar issues, not least the handling of common resources that the same could apply to.
And now, in the Part 1 update and Part 5 the standards committee is further limiting opportunities for designers to come up with something much better, by refining that which did not need refining.
Standards have their place, we would hardly be able to function without standards such as the metric one for measuring, but S88 is not in that domain at all, there is no science behind it yet, and no sign of one emerging.

Common Resources

What are these Common Resources?

If more than one unit can acquire or request the services of a single resource, the resource is
designated as a common resource. Common resources are often present with complex batch
processes. Common resources are often implemented as either equipment modules or control
modules. A common resource may be either exclusive-use or shared-use.

That definition is pretty good for me, but there is still disagreement, and to a degree I think that they are the bits where the original S88 parties could not agree. For example, some give the example of Storage Tanks, but in an alternative perspective (not just mine) Storage Tanks are Units.

Another good example is transfer systems. Surely these are common resources?

Actually some of the best batch implementations I have seen treat them as units. They call them X units, but as far as controlling them they are exactly the same as 'normal' Units, including having Equipment Procedural Elements.
The viewpoint once described to me was that if contains even part of the batch it then it is a unit.

Something like steam supply or other utilities are for sure common resources aren't they?

Can a resource be a Unit and a Common Resource?
So, is there any prospect of the revised part 1 coming up with an improved wording that will stop the divergent interpretations, of things like storage tanks, transfer systems?

Of course, the definition that CR's may be made as equipment modules implies that they can have EPE's, and take part in recipes.
To be continued

S88 Control System Designs

I think that it is a very good idea to use the S88 part 1 models as a framework for a batch (and indeed other) control systems. If you have a reasonable Control System design then it should be possible to use S88.01 Models and Terms to write a fairly precise description of the design.
That does not mean that S88.01 is a design for a control system. And that is clearly stated in the original standard.
Part 5 as it stands appears to be attempting to go into areas (such as a generic model for equipment and control modules) that are explicitly excluded in the introduction to Part 1.
Most worryingly the Part 5 fans are now trying to change Part 1 by introducing their models into Part 1. It is bad idea that would undermine the beauty of Part 1.
Now, Part 5 fans, please understand that I do realise that you may have some very good Control System designs (tho mine may be better) but that is not the point, Part 1 is not at all about designs for Control Systems.
If the objective is have a standard design for re-usable Control System Objects, then it should have a major input from the suppliers just as the development of FieldBus and the like has had.
They are notable by their absense from the Part 5 - where are ABB, Emerson, Yokagawa, Siemens etc. Mostly they are lurking - they are on the mailing lists but rarely take part.

Sequences are not Recipes

Dave
I completely disagree with a heck of a lot of what you say part 5 blog.
The latest is
Is that a Sequence or is that a Recipe? The answer is - You say Yes
I say no, in fact I say do not even compare them. To do so undermines the great concept that S88 provides, - separation of Recipes and Equipment.
S88. 01 is not actually about Control, it is about how to describe recipes and the physical equipment they have to run with. The cookbook and the kitchen.
Chop with knife number 42, turn on the power for the cooker, rotate knob 3 to set the temperature on the oven, etc is in the equipment sequence.
Chop the carrots, put in preheated oven is in the recipe.
These are not the same, they interface but are not equivalent.
The formula in a packing machine, just like the temperature of the oven in the recipe and the set point for the mixing tank are local copies of the recipe formula - part of the control recipe and derived from the master recipe.
Your statements on this blog are potentially damaging to the value of S88 Part 1.
Part 1 by the way should be left unchanged, if I had a vote I would vote against the update and for the original.

S88 Part 5 - Standard Profits - ?

How will this help us? How will it deliver standard profits? Do you even want standard profits?
The part 5 ‘blog’ has a couple of new entries , will they help?

A Device is a Device is a Device; But what if it is not? Now, I was at an early S88 meeting where device were seriously being considered for inclusion as standard terms. There was much discussion and it was agreed that the more generic term Control Module handles them perfectly within the Batch domain of the standard.
Now can anyone explain this statement?
“In many other implementations outside of where the ISA88 standard is applied the term Device is used such that the Device also contains the control that in the ISA88 the Control Module contains.”
OK, a few typo’s maybe, but the rest of the post make little more sense, and then goes on to refer to the MaketoPack report, which in no way helps to define devices.

Then we have
Replace babble of Control Components with understandable language, OPC help Dave believes “that the babble of internal proprietary communications between control components will be replaced by a universal method of communication”. And I hope one day that telepathy will be the normal means of communication, not least because my ears are failing. (No, it was not the Rock concerts, see cookie bite!)

Do we really need this - us the control system designers, plc programmers, systems integrators, and even the automation project managers?
Dave also says
“Until then a way to translate to the world outside the language of the proprietary environment is necessary . ”

Hey Dave, we have had those since the first pneumatic controls 60 or so years ago, not so much the pneumatics as the diagrams. And those diagrams have succeeded representing control for example loops (pneumatic then electonic then DCS) , relay logic, sequences etc
The diagrams have developed and improved over the decades. But I have a dread that someone in Part 5 is driving the standard towards using Ugly, Mangled Logic, or UML as it is known here.

Control modules

And how great control modules are pure S88.
Control modules know nothing about the stuff you are making. They do not even know how stuff might be made. Part 1 is clear about that, as the recipe has no interface with control modules.
That does not mean that they cannot do a lot, in fact they are the bedrock of any application. The better they are, the easier the rest is.
'Primitive' Control Modules handle the Inputs and Outputs, from the plant and the operator and from higher levels in the system. They then make sense of it, setting and monitoring the state of the physical equipment that is connected the to IO and driving things like Faceplates.
Primitive Control Modules can be quite intricate, and supposedly simple things like motors can have a surprising number of states and parameters. They are little models in theselves.
Higher level Control Modules such as a PID loop or a one that handles a valve cluster also have states and parameters etc. They may even have sequences to move from one state to another or to perform a cyclic function. Some S88 practitioners choose to all these sequences 'Phases'.
I don't like to, but that is another story that I will return to.
I also use Control Modules for things like resource management - take a look at this Cyclic Request Handler . This is a small simple module to share a common resource among a number of users. These request the resource via a boolean flag, like holding your hand up in class.
They remove that flag when their demand no longer exists. The Module just looks at each in turn, and supplies if the 'hand is up'
The method guarantees First come at most Nth Served where N is the number of users. It is easy state control and avoids needing any form of queue and could easily be implemented in a PLC. Is it a Control Module? If not what is it? I hope Part 5 will find a space for it, and not a procedural one, as it does not need to know anything about making stuff!