The Next WBF topic

I see that the next WBF is dedicated to “Expanding the horizons of manufacturing”.
That leaves plenty of scope in North Carolina I guess. I was going to suggest "Manufacturing models for a Sustainable future", maybe for the the next one. Or perhaps it fits in with expanding out horizons, so I hope those who are currently working on their presentations for the North Carolina conference will consider the issues in their papers.
I know that we are in a global economic crisis, for maybe a few years. Economic models have long process lags. But the process I am talking about when I refer to the future is much slower moving. And it is one of the areas where those involved in manufacturing can help, from minimising energy consumption to using sustainable resources. Even a control module, such as an agitator or pump can be controlled in ways that save energy, higher up the levels more can be done. I am sure that the forum can find many people with great things to say on the topic.

WBF Barcelona

The Barcelona WBF was good, it was well organised and of course in a lovely city and even the weather was fine. There were people from 23 countries there. I met many people that I have known for years from previous conferences and working with some of them and also made new friends.

And I was presented with the Guido Carlo-Stella Award, which I am very pleased about, thank you all. I remember Guido from the early years of the EBF.

Much of the conference was oriented toward the S95 domain and Manufacturing Excecution Systems. It is challenging to absorb so much information- 25 papers - in 2 days, so I am reviewing the papers again in my own time, and refreshing my knowledge of S95.

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 

WBF Barcelona

I case you are wondering, I shall indeed be going to this event, I am looking forward to it.

See you there I hope.

Alarms and Equipment States

How many reports on hazardous incidents have you read about where the alarms presented to the operators were excessive and the resulting confusion contributed to the incident.

I was reminded by this article

Why Is Safety so HARD?

The problem has been known and understood for decades, and now we all know that alarms should be suppressed when they are not relevant, and that when they are they should be prioritised.

But engineering a solution is time consuming and expensive.

The solution has to be specified, reviewed and approved, and maintained as operating experience is gained and the solution is modified, via an approved change process of course.

Typically these are described by text, cause and effect matrices and logic diagrams.  

Mostly the cause and effect matrices describe the responses to potential hazardous events, such as process upsets. The matrices do not often cover the alarms, although some do mention them typically in notes. Some control system actually support Cause and Effect matrix based design, and can translate them into control logic. For example Siemens has one

These are much more constrained than the typical excel version that people produce.

 

Using a state model provides a highly efficient way to define the enabling of alarms. The safety system, as a complete entity is defined in terms of possible states, a method that vastly reduces the number of states that have to be considered.

Then each possible alarm can be considered for it relevance in each state, producing an Alarm State Matrix. 

ISA–TR88.00.02

Dave Chappell's blog reports that "much anticipated Technical report from Make2Pack"  is now available, on the Part 5 blog and indeed subscribers were sent a copy, which I have been perusing. 

It is a good document, but not a lot to do with S88. 

I did much more than lurk on the postings, I spent many hours reading drafts and making comments about it, to try to align it with the real Part 1, and I took to using the phrase ~Save the Batch during the debate. It got quite intense, and at one point I was told "Better keep looking over your shoulder …the S88 police are coming!" 

Needless to say that did not deflect me. 

I think that I changed it in several respects - challenge is essential.

I objected initially to calling a machine a Unit as in most respects machines are little more than control modules, albeit complex ones (but only internally, not for the recipe). 

I accepted that they could be called Units because each machine in a filling line might be processing a different batch, thanks Dennis for reminding me of that and the parallel with continuous processes.

I did not accept that terms such a unit procedure or phases should be used in the report, as they were originally, and they are not there now.

S88 Graphics

I have seen many automation system HMI's. Often the process graphics have been produced based on the P&ID's. But P&ID's are not normally a good basis for graphics as they are not designed for operational purposes. Using the S88 Hierarchy can be much better.
There is at least one plant where the S88 Physical Hierarchy is used as the basic for the HMI graphics structure.
I believe this is a good structure, not only because it makes for simple uncluttered graphics but also because it exposes the S88 modules of a system to the operators.
Here is an example
The Plant overview shows a graphic that contains several Process Cells
Clicking on a Process Cell object opens the Process Cell diagram, which shows all the Units in the cell. Note - these can use colour and text to indicate the status of each Unit.
Clicking on a Unit object opens a Unit diagram
Note that this does not show all the valves etc in the Unit, it just shows simple objects for each equipment module but again with colour and text to highlight status of the equipment modules

Clicking on an equipment module object then opens an equipment module diagram where you can see the valves etc in the em.

From here you can also go to an Equipment Module Faceplate

Or of course a to Control Module Faceplate.

In this case, the automation for the plant was designed with ControlDraw, and the graphics correspond to relevant objects (diagrams) in the ControlDraw model.

Comments are as ever welcome.

Download S88 Part 1

Yes, you can download the entire ISA-88 (S88) Part 1 standard for free, the original and best version.

- note - this has now disappeared 
I mention this because it is one of the most common searches on the controldraw web. Of course it is not there, it is not supposed to be free - though I think it should be.
I did not put it there, but someone (not me) has put a link on the Wikipedia S88 section. I found it just 2 clicks from Jim Cahill's blog - which is worth reading by the way.
So get it while you can.
Updated May 2011
Some Chinese person has now posted the standard here
http://wendang.baidu.com/view/148a9bb91a37f111f1855be3.html

More on ISA S.5.06 Functional Requirements

I have spent some time delving into this standard, and the examples it provides.
Further than that, I have now created a ControlDraw model that captures basically everything that the standard shows. This is for me the best way of understanding a process.


One thing that amused me about the batch reactor example is that it has nowhere to send the batch it makes apart from down the drain! It calls dumping the product down the drain the Dump Phase, part of the Transfer operation, I suppose dump is appropriate, but Transfer? Maybe I missed something - here is the P&ID




S5.6 has this thing called a Sequence matrix. This is a condensed overview of the example process, but I suspect that it really would not be workable when scaled up to a real, and more complex process. Furthermore it conflates too much into too little, and if you are trying to do in in Excel demands lots of formatting. ( And the example manages to avoid the most complex issue, the transfer.)

So my model does not use that method - it is optional, you can also use Sequence charts - and instead uses those, in the form of SFC's and PFC's
Maybe a complex query could generate the matrix from the combination of the sequences and the equipment - it is possible but it would be a huge table compared to the example sequence matrix. Even without adding a real transfer!

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.

Part 1 update latest.

According to the latest Posting on the Part 5 blog, S88 part 1 has now been made 'Stronger' and has resolved all the outstanding comments except for one
The committee is alleged to be feeling confident it can be ready for the whole ISA88 committee before the year is out.
Apparently, the latest face2face had some of the original framers of the approved ISA88.00.01 standard present and the group worked well together in clarification of several contentious parts of the standard, creating what all felt was a greatly improved document that is easier to understand.
Sorry, but from this side of the Atlantic Ocean I beg to differ.
Why? Well, for a start my European contacts are far from sure that the new version improves on the old one. For a start it needs to be made simpler, not more complex.
Many comments were somehow removed from the commenting process, in meetings that were attended by just a few people.
The 'the original framers' were largely not present, some were but most (those from my side of the pond) were not. And let's face it, it all started in Europe, probably with Namur, in Germany.
The blog also states "While there are some in the community who claim the update work is diluting the batch standard to address other industries, I would challenge them to take a good look at the work and identify through constructive comments exactly how this is occurring. As I view the state of the work I only see a stronger “BATCH” standard that is now even more capable of being leveraged in other industries."
Well, In part I hope this blog actually does comment constructively.
I also have no problem and have not had for years in relating the 'batch' S88.01 to continuous and discrete production. There is always a batch, Save the Batch.
What do Y0u think?
PS I would like the Part 5 blog to link to my blog, as I do to theirs.

Equipment Heavy,Recipe 'Lite'

A friend commented privately about my blog that it is equipment heavy. 

I take that as a compliment, it is my hope that this blog, and my software will help to improve Equipment Control.

I think he also means that the blog is Recipe 'Lite', so it's time to talk more about how I view the Recipe and Procedural side of Control.

I am sure that good equipment control makes recipes simpler. And Recipes Can Be Simple (or Lite). 

And intrinsically I think they are and I think that the S88 originators (and it goes back long before S88) knew that.

A recipe describes how to make stuff given some equipment.

A recipe does not care how to control equipment, it does not even need to define the chemistry, which means that it can be described very easily. And as Part 1 says, a Procedure should be essentially an Ordered Set - or sequence.

It is the sort of thing that operators have done for many decades.

Please readers, when you see anything that claims S88 compliance or benefits or profits or whatever, remember that S88 is not about how to program a control system.

Show us your graphics

The next WBF meeting will be in Barcelona. That is a great place worth visiting even without the Meeting of Minds the forum promises. I have been to many WBF – and before that EBF meetings, and have always enjoyed them, sometimes too much. Perhaps I really should not have gone sampling all the strongest Belgian Trappist beers with the Irish and the Danes in Brussels. Making beer is of course something that S88 can describe perfectly, whether it is the largely manual processes used by small scale brewers or the highly automated ones used by the biggest. And how you make beer is interesting, but we don’t get paid for being interested. More to the point especially for a control engineer trying to justify a ‘WBF Jolly’ is to be able to learn how others automate making beer – or chemicals – or ice cream, or any manufactured product.
For control engineers the problems that are the same whatever you make are interesting - beer makers can learn from chemical makers how each solves the same problems.
Now, S88 did a good initial job of separating the product (the recipes) from the control of equipment . And it covers both.
So, looking at the agenda for the next WBF, where is the equipment control? (Apart from Part 5! )
I can’t see anyone on the agenda talking about how they control their plants. How do they handle their equipment - from simple things like agitators, to CIP and multi-purpose flexible plants. What standard objects do they use. How do their operators interact with the processes, their levels of manual control, and so on. How they deploy the great products that are available from the majors?

The WBF Charter says
WBF - The Forum for Automation and Manufacturing Professionals, is an association of end-users, vendors, consultants and academics with a strict, non-commercial agenda.
But is it really non-commercial?
I remember fondly the days of the European Batch Forum, it’s agenda was 50% commercial and 50% open. That is half of the presentation time was commercial suppliers demonstrating their wares, the other half was generally independent of the suppliers. The richer suppliers paid for (sponsored) most of it.
I found that this worked very well. There were for example many supplier presentations that were far more illuminating than most of non commercial ones. DCS and PLC suppliers and Systems Integrators could demonstrate how they had solved control problems - believe me you can learn far more from watching live demonstrations that you can from PowerPoint. But you are not allowed to do that at the WBF. It makes it much more boring. And yet even as it is the WBF is still used by most presenters as a marketing vessel and is actually highly commercial in it’s dealings – it now uses sponsorship in different ways. Fair enough, a different model. But where is the Control?

Hacking Safety Systems

I don't normally comment on this area, but I do track what is going on.
Walt Boyes has written on his 'blog' about a demonstration of compromised Safety System, read it all here
I have resp0nded, not least because many year ago I was delegated the job of checking out alarming reports about Y2K faults that might blow by up refineries. I had a free hand to investigate the truth about such tales, and invariably I found bad science.
The dialog so far follows.

Walt,
When you say things like “blow up a refinery” it suggests that some software fault (eg caused by some hacker) might have the capability of doing that. But as you know the ultimate protection, and a great deal of effort goes into it, is at the lowest physical level possible, relief valves for example. And hard wired logic, high integrity safety systems etc. I had this argument over Y2K many years ago. Don’t you think you may be feeding the trolls? Francis www.controldraw.co.uk
Comment by FrancisL Posted on August 12, 2008 @ 11:26 am

No, I am not feeding trolls. Francis, I saw a live demonstration of a hack against an SIS system last week. It took 26 seconds to cause the valves to fail open. The danger is in fact real.
Comment by waltboyes Posted on August 12, 2008 @ 12:01 pm

More details please Walt. My mind boggles that anyone could engineer an SIS to permit such a hack, and how such an SIS could be even called a safety system. And does the situation not imply that a failure in the SIS (hacked or not) could open the valves? So how can it be called an SIS? Francis
Comment by FrancisL Posted on August 13, 2008 @ 11:47 am

Your guess is as good as mine. Fact remains, this product is being sold as a SIS. I do not know the vendor. Anytime a SIS is connected to the plant network, it becomes open to an attack. Nearly all PLCs, including safety PLCs are vulnerable to DoS attacks unless properly firewalled. I have not much more information, because the demonstrator was unwilling to share too many.

More on Common Resources

Good old Anonymous has made some good comments about Common Resources.
Anonymous people are founts of infinite wisdom, if only you could meet them over a pint!
Read the whole comment - at the end Anon says
By your definition, these EMs would be common resources. I am not sure I agree with that, as their primary function is with the parent unit (Reactor), plus all the problems which would be associated with P&IDs, tagging etc.What about the concept of expanding and shrinking Units? How would this fit in with the concepts of common resources?
Great point, but what are these Units that expand and Contract? The comment explains it well, We do need expanding and contracting Units, for example after a mixing vessel has been filled and closed the inlet valve, what happens on the other side of that valve no longer matters. So long of course as it does not fail but that's another story.
One way of handling this is to have 'Virtual Units'. These are Units that the recipe can see, in it's view of the physical model, but that do not exist in the physical plant. These can expand and contract. (Also you can use them to point to selected equipment so the recipe does nto care wich equipment it is using - more later)
Good PLC and DCS programmers can easily construct them by the way, provided that they are prepared to use indexing and a little logic. It might help to have that rare thing, an object oriented PCS, so for example the equipment could inherit the current batch formula.

Another solution may be to eliminate Units and Equipment Modules completely and just have
Equipment Procedural Entities - EPE's. Then the recipes that are running (for example several batches and several cleans running simultaneously) can acquire the equipment that is required dynamically, using only the EPE's needed at any one point.
You can call the EPE's Units, EM's or Common Resources if you like, I don't care. The EPE's can be very small or quite large, it just depends on equipment the batch occupies.

Now, where all this gets hard is the fact that equipment control has to be fast and safe, and can be complex. Of course the safety aspect can normally be handling by simple logic that is close to the IO. The fast aspect is also easy - but not with a transaction based batch manager running on a busy PC on a busy network- this sort of performance needs controller software.

Australia

I am going to Australia again. I first went at the age of 1, in 1951, but returned to England in 1955. I think my mum found it particularly hard there.
Back then it was somewhat behind the times for a woman, especially one who considered herself (as she is) equal to men. But it may also have been something to do with the weather, and pining for the English countryside. And having small children.
My dad was a teacher and engineer, sadly he has gone, 10 years ago, at the age of 84, Mum is still fine, at the age of 94. Let me know if you would like her email address, she is still totally with it, but hates spam. I have not got her into blogging yet!
Anyway, I arrived back in England at the age of 5 , and ever since then I wanted to return. I did it 4 years ago for 3 weeks or so. I saw more than my mum did in her 4 years there! But 3 weeks is not enough, so I am coming back for 6 weeks.
Wherever I go I like to meet the engineers, so if you are in Australia and working with process automation, please contact me, to chat or for a fee I can do a great S88 tutorial.
I look forward to meeting you Oz

Back on the Tea - off topic

As I was talking about cups of tea, here is The Tea Rap on YouTube

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

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.

Equipment Procedural Entity

There have been discussions in the S88.01 Update meetings about Equipment Procedural Entiies (EPE's)

This is how I view EPE's -

They are objects such as Phases that can be executed under the command of a Recipe - for example an SOP, or a Production batch, a Batch manager Control or MES Recipe - but which are contained in - and controlled by - the equipment controllers.

The Equipment Controller might be an Operator who runs the equipment manually or if the equipment is automated, the Process Controller - PLC/DCS, Relays or whatever - that is connected to the physical equipment. (Most times it is a mix of the two)

EPE's are part of equipment control.

In Object oriented terms they are like the Methods of Objects
The Equipment that contains the EPE is a Unit or an Equipment module depending whether the Recipe-Equipment Interface is at the Unit or EM level.
Note, the S88 standard says that Control modules cannot have EPE's. But this is no problem - if you must control one CM from the recipe, create an EM to contain it. There is no law against it.


The EPE's can be Phases, Operations or Unit Procedures.

Now, the standard does not say this, but what follows is I think consistent with the models. It is also a configurable aspect of ControlDraw.
Equipment that contains EPE's must also be Acquirable, which mean that the Control Recipe takes control of the Equipment when it needs to carry out some processing in it. And to take control of it means preventing others from controlling it. Which to me implies Acquiring the equipment.

There is a direct correlation between the Equipment Requirements of the Master Recipe and the Equipment that contains EPE's .

That means that the Recipe Equipment Requirement maps to the physical equipment.


This can be one for one in cases where the recipe must use specific equipment or one to many in cases where the Recipe can use different (but similar) equipment.
For example a Recipes' Equipment Requirements might have a Reactor and a Filter but the plant has several Reactors and Filters. The Acquire process involves reserving the equipment for the current batch.

The last draft has a diagram, "Figure 18 – Referencing equipment entities at different levels within a control recipe procedure."

See also
Think of batch standard as design philosophy
Much more to come !

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.

Equipment for Making the Tea

The Turks do it another way

But that is for a completely different type of Tea.
So let us look at the Boil Water step in our English Tea Recipe.
Disregarding for the moment that this is probably control in a Common Resource, the typical English Kettle has a switch that once you have put water in it will boil the water and then stop.
The Recipe to make tea hands over to the kettle for that process action.
While the kettle is boiling it is executing the Boil Water part of the Control Recipe for your cup of tea.
Of course you do not Have to have an Electric kettle, you could use a pan on a gas ring, or a camp fire, just for example.

A Batch Recipe

Header
Name : A cup of tea:
Version: Typical English
Equipment Requirements
Teapot
Process Inputs:
Dried Tea Leaves (optionally in 'Bags')
Water
Energy for Heating
Parameters
2g of leaves per cup
Procedure:
Pre-heat teapot by using a short flush with nearly boiling water.
Put tea in Hot Teapot, then Add boiling water to a teapot.
Stir (optional).
Wait 3* minutes for tea to brew. (*time is a operational/user choice)
Put Milk in Cup - This can be done while the tea is brewing.
Please note - the milk Must be added to the cup Before the Tea!, (This is a Critical Recipe Parameter).
Pour tea into cup.

Slurp it up

Good things found in Vista:
Windows Key the type the name of the application - :
Bingo!

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.

MS Vista

I make and sell software for Control Engineers to design their systems with. Of course it is Microsoft based, sorry you open source people out there, but MS is so much more productive for me.
I have wondered whether, or even when, it will be feasible to convert ControlDraw to a web served application, like those that Google does. Maybe I could stuff it full of adverts and retire on the revenue, but that is not my intention yet.
My customers, at least those who work sometimes from their new gleaming home PC's are buying Vista machines these days, and I found that some of them could not run CD
So, ControlDraw Ltd bought me a new Laptop with Vista, and in a day the problem was fixed.
However, I have just had 3 black screens in succession, after installing Vista SP1 and Visual Studio 2008. It took a Safe Start then another reboot to get the machine running properly again.
I thought Vista was not supposed to to that. I guess Vista is still Beta- but in reality so is all software. And Standards. They have flaws that get fixed over time. (unlike S88, but that is not fair as S88 is not like that, it does not need fixing)
Vista is nice, but another big flaw is that I cannot get VB6 Service packs to install.
That looks to me like MS forcing up their revenues, I cannot find an excuse for it. I should be able to use my existing development setup, that I have paid them for.
Notwithstanding, I am now playing with the latest and greatest development tools from MS

Recipe Control

I see that Dave has blogged about Recipe Control

"No where that I can find does the ISA88 standard deal with “Recipe Control” as it does with “Equipment Control.” it says. My jaw dropped when I read this so I posted a fairly mocking response, but as usual it takes days before comments on that 'blog' appears if at all.

I think that the post indicates that the most fundamental purpose and meaning of Part 1 is not understood by the poster. Let me explain why I say that.

The entire Original Part 1 is all about Recipes and how to make stuff according to a Recipe.
And keeping the Recipes independent from the equipment and yet being able to run the recipes in the available equipment. The Equipment gets Controlled Yes. The Recipe provides the Set Points and the Procedural Sequence, but the Equipment Does the Control!

Part 1 quite rightly strictly excludes defining how to program either recipes or the control of equipment. Part 1 as it is does a very valuable job of providing a framework in terms of the words that can be used, and models that can provide a structure where those words can be used to describe the required Recipes and the Equipment Control.

Recipe Control is a meaningless term - unless we are talking about how to manage the Recipes themselves. Such as making sure that they are kept safely, version management, ensuring that a Recipe is up to date and approved for use etc.

When thinking about Recipes, it always helps to use the cooking analogy. So what do the cook books say about Controlling a Recipe. Try Searching for Cooking Control. Did that help?

By the way, Dave's 'blog' is not really a blog, but never mind. If you comment on this one it will appear - immediately, please feel free.

The History of Diagrams

After my comments about diagrams and UML I checked out the history of diagrams.
I found a very nice presentation on the topic here, it follows them from the earliest - Maps, Geometrics etc on - thanks Nottingham university and Thannasis.
It happens to be also a very good introduction to UML. Now, my types of diagram such as those for Unit and, Equipment Modules, Operations and Phases etc are not really part of the classic UML set, but it is quite easy to see how they could be part of a Control Modeling Language that conforms with much of the UML rules.
Maybe if I get time I will write it up. Or introduce the idea to S88 Part 5.

WBF 2008 USA Conference

No, I am not there, but it is good to see Walt Boyes reporting at Sound Off in near real time from the latest WBF conference.
Walt has kindly summarised several papers - those that can be put into words - perhaps not the flashy graphics ones.
Nothing new that I could see there, but it all stands repeating.
One paper about the Zen of Project Management makes plenty of good points, slow down to speed up, improve the equirements analysis and so on. Really not new but totally valid. But here we go again, UML. Sorry but no, we do not need UML for process control, and believe me I have tried, years ago. Control Engineers have had better diagrams than UML provides (for our stuff) for decades. And the software tools too.

Lynn Craig Webcast

This should be worth hearing, Lynn usually is:
WBF Web Sem: Using ISA88 - Approaches, Opinions & Caution
There is unfortunately a charge of $95. Which will greatly reduce the audience, a great shame. It should be free and on YouTube. And Part 1 should be a free download.

Part 1 update gets sensible

One of the issues that I have been on about is that Equipment Phases are only phases if they directly relate to the Recipe Phases. I always believed that the original Part 1 says as much, and more than that that the people who wrote it meant it that way.

Somehow over the years some people seem to have not understood that, but I am very pleased to hear that the update commitee has re-affirmed it. Here it is:

General Discussion – What makes an EM different than a CM?

The entire call was spent discussing the equipment module / control module clarification. Key agreement was that an equipment module could have two forms of procedural control logic. First, it is clearly stated in the standard that EMs are the lowest part of the physical hierarchy that can perform procedural control and thus have an equipment phase. By definition, this type of procedural control logic is intended to be directed by a recipe phase and that association should exist. It was also agreed that there may be another type of procedural logic which may be performed by an EM which is not directed by a recipe phase. In this case, such logic should not be called an equipment phase, but some other name (possibly “equipment task”). This non-phase related procedural logic may be commanded by operator interface or by another (possibly superior) EM. The key difference then from a control module to an equipment module is this capability and existence of procedural control logic. Control modules do not perform procedural control. An equipment module is used to support the lowest level execution of procedural control, either as directed by a recipe phase (causing an equipment phase to process), or as directed by a non-phase entity (causing some currently un-named procedural logic to process).

Personally I would have gone further and reserved the word procedural as belonging to the recipe as well, and found another name (perhaps sequential) for the second type of equipment control. But it is better than it was looking a few weeks ago.

Documentation Standards

There is a new standard, ANSI/ISA-5.06.01-2007 Functional Requirements Documentation for Control Software Applications.
It reminded me of an older one from Norsok, that I came across while researching control systems diagrams. I would be very interested to hear from people who are actually using this standard.

I am of course very interested in such standards, as much as I am in S88, because this is my livelyhood, as well as an abiding interest. I look at these standards to see if they have any bright ideas, such as new diagram types or models that might be added to ControlDraw.

I-005 System Control Diagram, (Rev 2 2005) - includes:

Present extensive use of computerised systems and 3D modeling provide efficient tools for specifying and handling of physical equipment in a standardised manner. However, the development of methods and tools to specify functional relationships has not reached a corresponding level.
During the plant development the process engineers specify the process through the development of the P&IDs. Throughout this work process the process engineers acquire a thorough understanding of the total plant behavior. However, the P&IDs provide limited facilities for documentation of the overall functionality as well as operational aspects of the plant.

The SCD approach has been developed with a view to industrial processes controlled by state-of-the-art process control systems, but as it provides a general process oriented approach for development of thedocuments, no field of application are explicitly excluded.

It says a lot more (Search like this)



And the ISA standard (also known as S5.6) says

Learning and configuring today's control software packages is easier than ever before. Documentation, however, is not such an easy task. With the increased capabilities of software packages to handle more process and operator interfaces, the complexity of defining and documenting these requirements increases. This standard directly addresses this documentation issue.


I have no idea whether the ISA looked at the Norsok standard when they were developing S5.6, I wish they had though. It even covers much of what S88 Part 5 is aspiring to, such as Modes and States (in some depth and with precise meanings and State Charts, templates.

Part 1 update

There is a new version of S88.01 being developed.
The development is being conducted by means of draft copies and comment forms being distributed via a mailing list, periodic meetings, and some dialog on the mailing list. It has to be said that in these days of Social Networking, Wiki’s, Blogs and excellent help groups such sites as eng-tips.com and plctalk.net/qanda, that the ISA and WBF are truly archaic. Although they do use internet online meetings, which is good.

I remember an esteemed WBF member at an EBF meeting in the mid 90’s at about the time the WBF started up speaking of one day ‘Surfing the Batch Web’. Niels I don’t think we are there yet!

Notwithstanding I have been following the Part 1 update process and occasionally throwing in a comment. It is clear that even now there are still big conflicts about what Part 1 actually says.
I used to think that all it needed was some examples and the problems could be resolved.
But now, I realise that it is unlikely because the disagreements are at present too entrenched.

These differences are greatest in the use of procedural models in equipment control. To me, and some others, it seems that some want to use the procedural terminology for parts of control software and even push the models as architecture for the real time control in the PLC’s and DCS’s. That is not what they are for, and they do not always fit.

Some just want to agree and follow whatever it becomes, but that is not the answer, since if it gets it wrong the result will be all of us having to be inefficient. And, no doubt, some good designs being rejected because they do not fit the standard.

S88 Part 5 Resource Managment

Part 5 has it seems started on a path that includes recource management in some way, tho I have yet to undertand what way.

Part 1 has no model for Resource Management so Part 5 has not got a chance of having anything worth saying in that context.

First, Part 1 should refine resources

Standard Control System Objects

One thing that Part 5 seems to be aspiring to is to provide frameword for a common set of objects. By this I mean Devices, (primitives) and perhaps higher levels in the recipe independant physical model.

Yep that is possible, in fact there are already for example ISA templates for at least one aspect of that, Instrument Specifications.

And they are indeed useful. So why not extend them to other parts of the Physical model? Or to the functional aspects of these instruments? If you like, from the Object Oriented viewpoint, the ISA instrument specs define standard properties of Instrument Objects, can we extend them to cover their methods? Further, can we define a set of ISA classes for the physical model?

To a degree, this is what users have been doing with ControlDraw model classes - I think has given me some insight. One thing that is showing up is the difference between system specific classes and those that are just about the generic objects.

It seems though that the Part 5 writers have not understood yet.

OMAC and Part 5

I see that the part 5 ‘blog’ has attracted another blog comment
OMAC should maintain a simple focus on packaging
Note the statement OMAC should proceed with extreme caution!

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.

WBF S88 Papers

I am browsing through my large collection of papers presented at WBF conferences over the years. Google Desktop is a wonderful thing as it make it so easy to search them.

There are various types, many are very interesting, and would apply regardless of S88. Great, the WBF is not just S88.

There are also many that claim business benefits as a result of S88. As an engineer, that seems unexciting. For me it is a given that good engineering benefits business!
The most boring are those that claim X% saving here and Y% there, invariably with no evidence that would stand up to the kind of review that scientific work has to.

Some do extend our understanding in ways that are true S88.

But rare are papers that have anything other than positives to say the standard.

S88 did not come out of the blue - many successful systems had been designed according to what we now think of as S88 long before the standard was even in its early drafts. The German NE33 Standard was one of the feeds into S88 Part 1.

And some real problems occurred in the early stages of the standard, you only have to read the paper on CIP that was contributed to the (ancient) EBF - for demonstration imaginary plants, which incidentally, preceded the Part 5 Best Glue Plant by 10 years.

Most of the papers are written by - or at least presented by - people in managerial positions.

But I would really love to hear from people with experience from the Process Controller end - the programmers. So, if you are out there I would love to hear from you and about your experiences with S88 from the control code end.

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!

Save the Batch

Or how to be an S88 Purist and how it will improve your controls, be it batch, discrete or continuous.
Often when analysing a process people start by dividing the process into Units and Equipment modules, but without thinking where are the Batches?
It greatly helps if you start by looking for the batches. And Everything can have a batch, even storage tanks.
Once everything has a batch, you can use S88 terms through all your application without confusing the recipe with the equipment.
An important thing about the batches in a plant is that they are not often one for one. For example a pallette of chocolate bars, a tanker full of milk, a delivery of hazel nuts can all be seen as batches.
Drawing a Batch relationship diagram is a good way to crystallise your ideas.
Once that is done you can find the units and the recipes, and decompose them.
Then you can match the procedures to your elemental basic control. Which you can get straight from the equipment for example a P&ID.
Adding higher levels level control modules in Basic Control can makes this far easier.
I will try to extend this in time, but for the present take a look at "Is a storage tank a Unit?" which shows how to run a control recipe in a storage tank just like any other batch control recipe .

On ISA Part 5

The ISA part 5 developments appear to me to be trying to take Part 1 concepts into areas it was never designed for, such as the inside of machines.
In the process of doing this they are inventing new meanings for those Part 1 concepts such as Control Recipe and Procedural Control. This will only confuse, especially the use of terms like Operation and Unit Procedure. They think that an Equipment prefix means that they are not the same thing. I cannot find anywhere in Part 1 that says that - the Equipment prefix adds the ability to direct basic control, but does not remove the Recipe meanings.