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.

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.

ControlGlobal's Process Automation Usability Project

Recently ControlGlobal.com has created the Process Automation Usability Project, it is an interesting read, with ongoing discussions on Planning, Design, Implementation, Operations, Maintenance, and Security.

It is well worth reading or better still taking part in, so I have added it to the Automation Links on this blog.

Part 1 update - what has changed

Marcus Tennant has produced an excellent summary of the changes between the latest draft of the updated S88 Part 1 standard and the original.

It must have taken him a lot of time and I have no problem with it.

I do however have a problem with the proposed update itself.

Here is a small example, it shows the proposed changes to the physical model.

Now as far as I am comcerned, the original version, on the left, is elegant and clear whilst the update is frankly a mess.

And the value added is zero.

How do standards evolve?

I was thinking again about the S88 standard and how it is developing, and the results that we are seeing. That led me to wonder, how do standards evolve?

So I thought that some research was needed. And I have searched a lot, and one noticeable thing about the results on various search engines is the association of standards with law.

Things like metric and imperial, Whitworth and so on are measurement systems and physical and science based. Even if they started with the distance between Napoleon's nose and his finger tip, allegedly. And so De facto standards arrived. Eventually they became consistent, via such thing as the System International (Three nations have not officially adopted the International System of Units as their primary or sole system of measurement: Liberia, Burma and the United States.)

Others like ASCII and perhaps html are language interpretations.

What about Fieldbus or, say Betamax versus VHS ?

Here, competitive companies produced competing standards, and the result became De facto standard.

Some such as XML, maybe UML are somewhere between De Facto and Science based - or at least they involve a lot of meetings.

When we come to Automation is it apparent that the ISA (For me still the Instrument Society of America) that now appears to be the leader in setting the standard.

But I actually think that it is missing the competitive element. I could argue that they should leave the domain alone until a De facto standard arrives!

What's in a Process Cell

There is currently much discussion about what a Process Cell is as you can see on the Part 5 blog.

As I view it, a Process Cell:

1- is the domain within which batches can be made according to a recipe.

2- contains the collection of equipment (units, and equipment modules) that meet the equipment requirements of the recipes that can be produced in the cell

That is I believe what S88.01 says, but in different words:

S88 (original and latest draft) says

A logical grouping of equipment that includes the equipment required for production of one or more batches. It defines the span of logical control of one set of process equipment within an area.

NOTE - This term applies to both the physical equipment and the equipment entity.

But this really does not define the boundaries of a Cell in the way that we like to put boundaries around Units for example. Why not make an entire plant a process cell? Of course, a cell lives 'in an area' .

So might be that the boundaries of a Process Cell are arbitrary provided they meet the definition.

I have seen several large plants where there are dozens of Units in the Process Cells, and have worked on projects where there were only a few. Why? Because of repetition - if you have many similar units it makes sense to put them into the same process cell because they can run the same recipes. And Recipes execute in Process Cells.

But as Part 1 also says Logical Control

Is that Logical as in mathematics? Or as in intuition?

From the Intuition point of view, it just makes sense to have say solvents handing in a different process cell to reaction doesn't it? Is that enough?

But how about Logical Control? Are we talking about basic control logic - or Procedural Logic?

I think we can forget basic control here so can we somehow make a logical choice based on the Recipes? And one that generally agrees with the intuitive one? I think so.

It depends on finding the Batches, Equipment Requirements and the Routes.

Start by asking where are the batches? If a batch comes out of one unit, and then joins with other batches so that the downstream units are working with bigger batches, or conversely where batches are split up so the downstream units are working on smaller batches then I would have two process cells. In the case of say a plant with feed storage vessels then bioreactor units then intermediate storage then filtration units then product storage I would have something like Feed storage process cell bioreactor process cell intermediate storage process cell filtration process cell product storage process cell And by the way I would call the storage vessels Units.

As for the connectivity, what I mean is that all the euipment in a single Process Cell should permit the transfer connections needed to assemble the instances of required equipment for the Cell's Recipes.

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.

DCS or PLC?

This is a topic that has been discussed endlessly over the years ever since there were DCS’s and PLC’s with SCADA on top.

Back in November I noted a great article, do PLCs Eliminate Need for a DCS? on Automation.com that sums up the differences well. It does so from the point of view of the pro DCS Camp, not surprisingly because it is essentially a Honeywell interview.

Refreshingly though, it does not promote Honeywell over other DCS’s and just presents many of the core arguments that all DCS suppliers present. They are well presented good points

DCS's have succeeded for a good reason. They were the first to encapsulate things like PID control, and emulations of control panels. And the PLC people encapsulated relays and won the discrete market.

It would be good to see the other side of the argument presented equally impartially, no one has done so in response to that article, so I am having a little go. It may be because the suppliers of PLC/SCADA systems are more numerous but smaller, and none has the time to present the argument. Perhaps this is something the CSIA (Control Systems Integrators Association) should address.

So, lets looks at the core issues
"Today with open technologies, DCS systems are competitively priced with PLCs."
Maybe – but it is not my experience for the Hardware. This may well be true if the engineering is less, but that is another topic – the next one.

"Simply taking a PLC and adding an HMI and database on top of it requires a great deal more engineering to accomplish integrated control..."
I am one of those who has in the past been responsible for such engineering, and I don't quite agree with the term 'more engineering'. Better maybe, more is dependant on the application. Sure DCS’s are still far and away easiest for plants that have control loops and little else, such as refineries and the continuous chemical industries. And you would never use a DCS controller for fast machine control.
But it is that huge area in-between that the paper suggests is now DCS territory. But there are many case where PLC/SCADA still prevails. The food and beverage industries such as brewing and diaries are good examples.

And I am well aware of projects in the past where the engineering has taken far more that expected, even where a DCS was being used.

Why is configuration better than programming?
First it is highly a debatable point. Much of a SCADA is configured rather than programmed, and no configuration system exists in DCS's for complex sequential control for example.

Also, programming is not actually a bad thing, provided they are designed well, systems with programmed rather than configured applications can be better. This is because there is much more flexibility of design resulting in much less compromising of the functional requirements to fit the standard system.

Other points include:

Future growth

This is disputable as probably the largest (by IO Count) systems in the world are PLC based.

For example many food manufacturers have huge systems.

Need to make changes frequently

Of course if the application is well engineered such changes should be rare. New recipes should not require program changes for example

Integration requirements

Again, at least in the past it has long been easier to interface to other systems.

Even now DCS interfaces are often implemented with ModBus, and where did that start? PLC's!

Fault Tolerance

I think PLC's may have caught up here

The PLC vendors still seem to be struggling with trying to get all the parts and pieces to work together seamlessly.

Really? This may be true from the point of view of a small PLC/SCADA Systems Integrator competing with a large DCS supplier to win a project. But I think this is not a technical issue, rather one of the nature of those two types of supplier

I am convinced that the results using a well designed PLC/SCADA can be far better than using DCS canned functions. Not only in the result, but in the time it takes to write the software, the user interface, the scan time for the program to execute, and the hardware cost.

I could add further reasons that a DCS may be better, for example the maintenance of the PLC/SCADA systems may be more involved as they all have different software architectural designs, no two SI's seem to do it the same. But I will cover that in another blog soon

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.

Equipment Modules or Control Modules, which are cheaper?

I heard a good one today. I had emailed the State Based Control paper to a customer asking why parts of their plant model did not have Equipment Modules, perhaps on the lines of those in the SBC paper. I got a very good answer, part of which was that all the operational aspects in those areas are manual SOP guided. And that maybe some procedural control will be added when they understand better how to run the equipment.

But another aspect was that they get charged more for more equipment modules.

Now, I have been looking into the complexity of systems, and hence the time it should take to program them. And part of the point of using Em's is to reduce complexity.
So I suggested that as they do not have to run phases ( just like those in the SBC paper) call them Control Modules!

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

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?

Some internet travelling experiences

I know this blog has been silent for too long, I have been travelling, in fact I still am, this comes from New Zealand, where the connection is excellent. I thought I would share some internet travelling experiences:
The Motel in Brisbane that advertises Free internet.
On arrival the person in reception asks for your laptop and then types in the password, taking care to prevent the password being saved. When you close your laptop lid and it shuts down or hibernates the password is required again when you restart.
Reception closes at 8pm (I immediately cancelled my reservation and moved out when I found this, fortunately before 8pm)
The Hotel in Sydney that charges $30 (AU) per day
The hotel that has a third party that provides WIFI. The signal is strong, but the performance is unusable, the third party, (Jimojo.com), said that there was no problem with their systems. Ha !
And finally using the internet with a mobile phone connected to a laptop via Bluetooth. I can tell you that at least with VodafoneAustralia it works well. But can you believe £10 per Megabyte. That means it can cost about £1000 per hour. At the same time you can get 5Gbyte per month for about £20 if you have a local account. Legalised robbery