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