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.