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.