Process Specification (was Demarcation (was: STL x Ladder))

B

Thread Starter

Bruce Durdle

My experience with getting contractors to write functional specs has been quite varied - from the small back-yard merchant who refused to put anything at all on paper because "he had put a lot of time and effort into getting it working and he wasn't going to give us all that information so we could use it on the next job", through a firm with acceptable but grammatically awful documents that could not be revised because it involved the whole company in a review process, to a guy would had never done one before but once we explained what was wanted produced a beautiful one in about 5 days.

The IEE has some material I have referenced in specifications - my copy of "Guidelines for the documentation of computer software for real time and interactive systems" ISBN 0 86341 233 5 dates from 1990. It can relatively easily be extended to cover hardware and field equipment as well. They also have a "Software quality assurance model procedures" ISBN 0 86341 230 0.

The operational words for a functional spec, according to the UK Health & Safety Executive, are "complete, concise, and unambiguous". I have used what I call an "operational cycle" approach to try and handle the "complete" part -

Define the various acceptable operational states of the system, starting from power down, and list all associated conditions of driven or activated
machinery.

Starting from power down, trace all the acceptable operational paths through the different states. For each transition from one state to another, define the events that will initiate the transition.

Look at each state and define the expected (or unexpected) faults - see earlier posting. Use this to decide how the faults can be detected and how they will be handled. Add the states arising during fault handling to the overall list.

Now comes the fun part. Starting at the beginning, trace every possible path through the various states that may occur in actual operation. This will involve complete loops from "Standby" or "Off" through start-up, operation, normal and abnormal shutdown, back to "Standby". Details of this actual sequence don't matter - the important thing is that the condition of the plant, considered as a whole, must be the same for any state regardless of how it is arrived at. So if a motor is started as part of the cycle, it must be stopped somewhere else: if an actuator is extended, it must be retracted.

Usually, the main route through the operational cycle is pretty well defined by what you want the plant to do, and will not give many problems. My experience has been that the fault handling parts of the system are poorly defined by the mechanical or process people, and have the most variation - after all there is usually only one way for the thing to work properly, but an infinite number of ways for it to go off the rails. The controls system designer usually has to come up with a lot of answers on the fault handling side.

Strangely enough, this starts to look remarkably like a Sequential Function Chart if you do it graphically!

It can help with developing the operator interface as well. Any operator actions will be defined as events that will initiate transitions between states, and each action must be based on relevant process information. Group all operator actions that are acceptable in a given state and all the required information needed for those actions, and you have a good guide as to what should be displayed on a screen page while the plant is in that state.

I've used this approach on a fairly complex GT cogeneration project where 2 GTs were feeding exhaust gas to a single auxiliary-fired Waste Heat Boiler. There were 16 possible states with each GT having its own bypass damper and stack, and associated dampers on the boiler. It greatly helped in the analysis process. I haven't had a lot to do with manufacturing processes, but what I have had would suggest that each element of a process train may possibly be treatable as a separate entity to try and keep the system simple.

One weapon I have used is to pick on any safety-related functions the machine may have, and use these as a tool to get the project management to take action. There is usually some (even if only peripheral) safety activity, and the threat of not complying with OSH requirements can work wonders if needed. We have a delightfully vague clause in the NZ Health & Safety in Employment Regulations to the effect that a designer is responsible for ensuring that the design is safe, and for providing all necessary documentation to manufacturers, suppliers and users so that it can be built, installed, commissioned, operated maintained, etc safely. Managers (especially of the project variety) may often not want to make a lot of fuss over what to them appears to be fairly insignificant, but the dreaded "S*$@&y" word usually gets things moving. IEC61508 is a bit too vague to give a useful handle, but IEC 61511 may be better, being more focused on process industries. I don't know how far it goes towards meeting the needs of the manufacturing automation industry.

Cheers,

Bruce.
 
Michael Griffin:
> As part of this, I have been hoping to find some sort of formal method
> which can been used to determine that the described behaviour of a
> machine is logically complete and consistent.

At first sight, no, because of Goedel's theorem, except in uninteresting systems - but what's uninteresting to a mathematician might still be very useful to an engineer.

(Historical note: at the turn of the previous century, someone noticed that *algebra* was inconsistent. Hence the search for stuff like the above, which ended with Goedel's theorem which says that you can't have one.)


It'd be a good idea to have a look at Goedel's theorem (Hofstadter's ``Goedel, Escher and Bach: an Eternal Golden Braid'' is a popular
explanation), so that you can see if you can dodge around it. You probably can, by putting enough restrictions in there.


The other thing is that once you have a formal description of the behaviour of a program, the work is done - with a bit of care, the writing of the actual program can be automatic (look up logic programming, eg Mercury).

> It involves using state diagrams (and possibly sequential function
> charts) to describe machine behaviour and associating operator controls
> and messages with various parts of the diagrams.

Sounds like a nice language if you can keep it elegant. If you get around to writing it, will you be contributing it to the MAT LinuxPLC?

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
V

Victor Zaltsman

There are several problems with "written word" in regards to process functional specification, when you are talking about classic
design method for control systems:
- the real system's "sequence of operation" is loosely coupled with it's werbal model- the "tightness" of this coupling is determined by the
person, who is writing the document.
- werbal documentation is usually created BEFORE and/or AFTER the "real" design process takes place and is not a part of the design process
itself. Therefore the werbal documentation is often seen as a unnecessary addition to the drawings, diagrams, etc.
- werbal documentation, even if exists, is "one-dimensional": it is written for one particular type of customers (one, who pushes harder).
Obviously, different customers require different level of details- that is different "views" of the same data.
This phenomena has been for a long time a pain for software engineers and a solution has been established as a conjunction of
object-oriented design, Unified Modeling Language (UML) and special software tools like Rational Rose, CASE SELECT, etc.
It seems, that the problem, you've raised, is complex enough to require a complex solution (there is no simple answers here), but all the
parts of the solution are already in place.
*-Following fragment of text contains some terms from ISA S-88.01-*
I believe, that in just a few years most of control systems in the world will be designed, using an object-oriented modeling and an
integrated development environment (IDE). IDE will allow to create a control system object library, which eventually replaces a good old
Master Design SPEC. This library will define P&ID typical objects, which will have correspondent SOO(Sequence of Operation=Process
Functional Specification ++) typical process units, equipment modules and control modules (where their control is precisely defined).
Object-oriented SOO model will define PLC code, which should be based on correspondent PLC user-defined data types/function block (which are
actually a library of PLC objects). Also SOO will define hardware (instrumentation + PLC I/O) and wiring templates (objects) and HMI
objects, so most of the control system's components comes from well-defined libraries almost automatically, as soon as SOO model is
created.
It looks like a science fiction, but actually all the components are in place already.
I'm using hardware and wiring templates during control system's design for years(implemented in CIMS software). All the reports and 90% of
drawings can be generated from CIMS database.
Our HMI (based on GE CIMPLICITY) application is based around object-oriented concept- there is the library for all the graphic objects, and
all the screens are based only on this library. CIMPLICITY configuration database is connected to CIMS database, so SCADA TAGs can be
generated from CIMS as soon as correspondent I/O (control module, which can be as simple as a flow switch or as complex as PID loop) are
added to the system.
VISIO 2002 can be used effectively to create a library for P&ID, while object's attributes will be used to connect the P&ID drawing to SOO
model.
And, at last, we've started to evaluate PFS software for computerized SOO. PFS is able to import P&ID drawing (provided, it is built, using
objects with attributes) and create a list of control modules. Since each P&ID object has a correspondent PFS object (actually we should say
'class' instead of object), it is not too difficult to built physical and procedural model, using PFS tools, like State Diagrams,
Sequential Flow Chart, Condition Editor^Å
Each control module class has a correspondent class in CIMS (with associated I/O and wiring), so hardware configuration is not a problem.
And finally, PFS software has a built-in sofisticated WORD "document generator", so you can generate a required "text view" (including
tables, datasheets,...) from the central database. This document always will be up to date, since it is generated from the "live" project database.
What is important here is not a particular implementation and software, but an approach.
As of methodology for control system's functional specification- I've found ISA S-88.01 terms and definitions as a good starting point. The standard's official scope is a "batch control" industry, but the approach seems to be suitable for other applications (with some
simplification).
Somebody already mentioned in this thread of discussion: "A language that doesn't affect the way you think about programming, is not worth
knowing". I don't want to know, "is it worth or not", but the methodology of control system's design does changes you way of thinking about
this system- and hopefully not just changes, but improves (yields better results).

Best regards,
Victor Zaltsman, control & software engineer.

Best regards,
Victor.
 
M

Michael Griffin

On January 19, 2002 03:37 pm, Bruce Durdle wrote:
<clip>
> The operational words for a functional spec, according to the UK Health &
> Safety Executive, are "complete, concise, and unambiguous". I have used
> what I call an "operational cycle" approach to try and handle the
> "complete" part -
>
> Define the various acceptable operational states of the system, starting
> from power down, and list all associated conditions of driven or activated
> machinery.

We've been trying to get people to define the operating "modes" of a machine, what functions each mode controls, and what the operator interface is for each mode. Most people seem to know how to describe the screens and
keys, but get stuck on what the machine *does* other than the normal operating sequence. I think if I had them start by listing the operating
modes and what each controls as the first thing they write down, then it would shift their point of view to where it belongs. This is a very good
first point.

> Starting from power down, trace all the acceptable operational paths
> through the different states. For each transition from one state to
> another, define the events that will initiate the transition.

I was thinking of using a state diagram for this part. It's fairly flexible when it comes to fitting it onto a page, and you can see the mode transfers clearly. This is a good next step though - now that the modes are defined, we
need to say how they are related. The weakest part of what we have been doing so far (whether using our own method or that of any of our suppliers) is that the various machine modes are discussed in isolation from each other without
enough thought as to how the transitions will occur.
Most of the mode changes would be due to someone pressing a button (e.g., select manual mode). In this event, I am thinking about how to tie these "button presses" back to diagrams of the actual screens and key layouts to make sure there is a button for each transition, and a transition for each button. Some mode changes (faults, welding tip changes, etc.) would be initiated by the machine, in which case we need to link these to particular operator messages.

> Look at each state and define the expected (or unexpected) faults - see
> earlier posting. Use this to decide how the faults can be detected and how
> they will be handled. Add the states arising during fault handling to the
> overall list.

Generally (actually, pretty well always), in the event of a fault the machine will stop where it is and wait to be told what to do. We normally transition from auto to manual or standby modes in the event of a fault. Someone can then take appropriate action before attempting to resume auto mode.
Most (but not all) assembly processes can be stopped and resumed again. This is a bit simpler than the situation in most continuous process applications. The main question is normally whether a fault can be recovered from by
resuming operation, or whether the operation has to be aborted. If you abort, then the question is how do you get out of the existing situation, and what do you do with the part.
This has to be shown in relationship to the operating modes since this involves a change between auto to manual and (hopefully) back again. I suppose we need to divide faults into "recoverable" (you can resume the operation and finish the cycle), and "non-recoverable" (you must abort the current cycle) faults. For example, if you have to re-home a servo axis,
there isn't much likelyhood of resuming the current cycle for most machines.

<clip>
> Usually, the main route through the operational cycle is pretty well
> defined by what you want the plant to do, and will not give many problems.
> My experience has been that the fault handling parts of the system are
> poorly defined by the mechanical or process people, and have the most
> variation - after all there is usually only one way for the thing to work
> properly, but an infinite number of ways for it to go off the rails. The
> controls system designer usually has to come up with a lot of answers on > the fault handling side.
>
> Strangely enough, this starts to look remarkably like a Sequential Function
> Chart if you do it graphically!

I find that an SFC seems to be very good at showing the normal operating sequence, particularly when you have operations occuring in parallel, or alternate paths.
Most faults we would have to deal with are ones for which you can resume the cycle from the current position (e.g., after clearing a jam). These I wouldn't show as the operating sequence is the same as in normal operation. A
typical fault involving a sensor on a pneumatic pick and place would fall into this class.
Another class would be faults for which the normal cycle cannot be resumed, and must be aborted, but under machine control. This I would show as there would normally only be certain points in the cycle from which the abort would occur, and a common point to which the sequence goes after aborting. In this case, you are really resuming the cycle, but not at the normal next
sequential step.
A third class of fault though would be a bit more difficult. This would be where you cannot resume the cycle at all. In other words, you must remove any parts manually, and manouver the machine under manual control (or even
turning off power and pushing it) to a point where you can start all over again from the beginning. If you had to re-start a robot, you would be in this situation. This is more or less the same position you are in on power-up or after a typical emergency stop. This sort of recovery could be specified by pointing back to where these modes are described.

> It can help with developing the operator interface as well. Any operator
> actions will be defined as events that will initiate transitions between
> states, and each action must be based on relevant process information.
> Group all operator actions that are acceptable in a given state and all the > required information needed for those actions, and you have a good guide as
> to what should be displayed on a screen page while the plant is in that
> state.
<clip>
The operator interface is where we have been doing best so far. The problem is that people have been getting *too* fixated on what the screens and keys look like, and not giving enough thought to what they control. The result is that some fundamental conceptual problems will get pushed back into the "programming" stage of the project when they should have been dealt with at the beginning.
Thank you for your advise. This has been very helpful to me for putting my thoughts in order. I am always looking for ways to do things better and this is an area which needs improvement.

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael Griffin

On January 20, 2002 03:56 am, Jiri Baum wrote:
<clip>
> > As part of this, I have been hoping to find some sort of formal method
> > which can been used to determine that the described behaviour of a
> > machine is logically complete and consistent.
>
> At first sight, no, because of Goedel's theorem, except in uninteresting
> systems - but what's uninteresting to a mathematician might still be very
> useful to an engineer.
<clip>
I wasn't looking for a mathematical proof - only reasonble grounds for confidence. I don't think a mathematical proof would be possible or useful because it doesn't account for whether the characteristics of the machine "as built" are correctly modelled.

> The other thing is that once you have a formal description of the behaviour
> of a program, the work is done - with a bit of care, the writing of the
> actual program can be automatic (look up logic programming, eg Mercury).
<clip>
> Sounds like a nice language if you can keep it elegant. If you get around
> to writing it, will you be contributing it to the MAT LinuxPLC?


I wasn't looking to go into that degree of detail as part of this. The objective isn't to write the program, it is to decide what the machine is supposed to do in enough detail that the person writing the program can implement it with reasonable confidence that it will work in a manner satisfactory to us.
The end result should be a (small) stack of paper which will give clear and unambiguous direction to someone writing a program. The present method of simply "writing it down" can be ambiguous or incomplete. This latter method is of course far better than nothing, but I looking to improve upon it.


--
************************
Michael Griffin
London, Ont. Canada
************************
 
G

Greg Goodman

> The end result should be a (small) stack of paper which will
> give clear and unambiguous direction to someone writing a program. The
> present method of simply "writing it down" can be ambiguous or
> incomplete. This latter method is of course far better than nothing,
> but I looking to improve upon it.

The systematic approach to software specification that I recommend for producing a complete and unambiguous description of the desired behavior of a machine is the Unified Modeling Language (UML).

From my perspective, the real advantage in UML lies in the different views its diagrams offer of the system. Our experience is that, in a control and automation environment, state diagrams, collaboration diagrams, and sequence diagrams offer a degree of clarity that textual software specifications, flowcharts, functional decompositions and entity relationship diagrams cannot match. In particular, they allow one to capture normal operating behavior, any potential abnormal behavior and the necessary remediation, timing constraints and dependencies, synchronous and asynchronous interactions, and concurrency issues.

There is much to be said about the pro's and con's of UML, especially in a real-time environment, and the effort required to develop competency in its use is significant. However, I (and some of my colleagues and clients) believe that the design approach, and the diagrammatic artifacts it produces, are worth the effort.

Regards,

Greg Goodman
Chiron Consulting
 
G

Greg Goodman

Considering how the UI looks and acts is an important part of the analysis/design process, but only a part. From a UML perspective, this
would fall under the heading of "use-case analysis"; that is, how the system is expected to interact with an "actor" (autonomous agent
outside the system itself). In many (perhaps most) use-cases, the actor is a user/operator.

However, use-cases are only one aspect of the system design. They should not be discounted, but neither should they be unduly emphasized.

Greg Goodman
Chiron Consulting
 
B

Bruce Durdle

I'd prefer to state "how the UI performs ... "rather than "how the UI looks
and acts..." I've seen some very pretty UI displays that are absolutely useless for operations - all the fancy graphics get in the way of the information transfer from electronics to brain.

Let's go back to basics. It is pretty well recognised, under the "protective layers" approach to safety systems, that the operator's response to process deviations and alarms is the second layer of protection against a disaster. First layer is the regulatory control system; third and fourth layers are the automatic shutdown systems and any last-ditch mechanical things. (It's often more complex than that but you get the idea.)

Now if you are working to IEC 61508 you should include all these other layers into the equation when deciding on the SIL for the safety-related electronics. So at least some systems must have a reference to the expected performance of the operator in response to an alarm or other notification of process upset.

Some good work has been done into putting numbers against the reliability to be expected of an operator taking the correct action in response to a fault, but to my knowledge none of this work has looked at the modern VDU with all its bells and whistles. The best performance you can expect is for a Probability of Failure on Demand of about 1%. This rises to around 5% if the operator is under mild stress, and probably about 25% if the operator has to select the most important one from a number of indications.

The point I am going to (finally) make is that the operator's role in the overall scheme of things is important. Every aspect of it needs to be given as much consideration as any other part of the system design - from ensuring operator comfort through correct ergonomics to making sure the required information is presented with the appropriate formats, and in a context that minimises confusion and distraction. Unfortunately, the bright young things who are writing HMI software often include "features" that can be over-used or mis-used, and end up severely detracting from the overall effectiveness of the system. I refer to such things as those nice little motor or fan graphics that revolve when the motor is running, belts that show boxes or bottles moving under normal conditions, or use fancy graphics rather than bare-bones schematics.

My approach is to ask "what is an operator going to do with this information?" If the answer is "nothing" , it doesn't go on the display. If a process engineer wants to record or log a point for engineering purposes, don't put it on the operator's display. Just as every function in a control system must be justified in a HAZOP or similar review, so must every element displayed.

Once the significance of the data points or control actions has been determined, then its relevance can be used to decide where to place it on the display. There is plenty of psychological reporting around that there is a well-defined sequence for scanning an area such as a VDU - centre first, then the middle of each side, and some parts are virtually ignored. So don't put the fancy company logo in the centre of the screen!

No-one would design an automatic control system(? - at least, I hope not) without a good idea of how the automatic controls are expected to work. The HMI is part of the manual control loop, and its performance is just as important. If nothing else, you need to be able to tell the operators what to do when THAT alarm THERE comes up.

So if someone protests that an indication is not symmetrical, or doesn't have all the lettering the same size, or the colours are not in harmony, or the latest fashion, or that Company X down the road has displays that fade in and out and include full-colour living CCTV pictures of the plant, ask them to justify what they want in terms of improved operator performance. Nothing else matters.

Unfortunately, we live in a world where, thanks to generations of "marketing" experts, everything is judged on appearance rather than suitability for function. I sometimes think there is a place for a dual set of displays - a fancy set with all the bells and whistles for the front office, and a plain vanilla variety for the operators. Just keep those bells and whistles off the operating systems.

A side issue is that, by automating all the normal operator actions, we break down the close relationship a good operator develops with the plant over time and make it more likely that mistakes will be made on the much rarer occasions an operator has to take charge. But that's another story ...

Bruce.
 
V

Víctor M. González

Hi everybody,

I see that you are very worried about how to develop secure control programs, so am I.

Have you heard about GEMMA (Guide d'Etude des Modes de Marche et d'Arrêt) proposed by l'Adepa the same French agency that developed GRAFCET?

GEMMA -Study Guide of the Starting and Stopping Modes (of an automated process)- is a guide that helps you thinking about all possible states an automated process can run through.

There is a French book that explains GEMMA very well, which I really suggest you. Besides, some guidelines about how to develop Secure Automated Processes are given in the second part of this book.

Title: "Le Gemma". Authors: S. Moreno and E. Peulot. ISBN: 2.7135.1752.4

I have looked thoroughly on the Internet for an English book about GEMMA but I wasn't able to find anyone.

I hope that this information is of any value for you.

Now one question. Maybe you can provide me with some sources of information.

I'm carrying out a survey amongst industry as a state of the art study for my PhD Thesis. I am asking consulting or engineering companies (e.g. Euromation, Semcon) and industries such as Volvo Cars Company or Electrolux, if they use any methodology, method, technique or architecture to analyse an automation problem and design the
control logic that will finally be implemented in the PLC that will control the given process.

The answer is always no! Mainly because they are not use to such real-time or obeject-oriented software engineering practices that could be used.
They just rely on the know-how of their electrical engineers.

From your experience and knowledge how are your companies dealing with this (analyse) stage of an automation project? Do you use any methodology?

Thank you very much in advance for your help.
__________________
Víctor M. González
University of Oviedo (Spain)
 
V

Vladimir E. Zyubin

Hello Victor,

The problem you are interested in is an actual one.

Just a couple of remarks:

1. "Real-time" is a buzz-word... too misconfusing to be used..
2. As to "OO software Engineering practice": Firstly, it needs to be shown that the method is aplicable for the control algorithms...

Have a nice day. Vladimir.

On Monday, April 29, 2002, 9:16:59 PM, List Manager <[email protected]> wrote:

LM> -------- Forwarded Message --------
LM> From: Víctor M. González <[email protected]>
LM> To: [email protected]
LM> Subject: Re: LANG: Process Specification (was Demarcation (was: STL x
LM> Ladder))

[...] LM> I'm carrying out a survey amongst industry as a state of the art study
LM> for my PhD Thesis. I am asking consulting or engineering companies (e.g.
LM> Euromation, Semcon) and industries such as Volvo Cars Company or
LM> Electrolux, if they use any methodology, method, technique or
LM> architecture to analyse an automation problem and design the control
LM> logic that will finally be implemented in the PLC that will control the
LM> given process.

LM> The answer is always no! Mainly because they are not use to such
LM> real-time or obeject-oriented software engineering practices that could
LM> be used. They just rely on the know-how of their electrical engineers.
 
M

Michael Griffin

Traditional written specifications are often very ambiguious when analysed rigorously. I have not seen any of our suppliers in the custom
machinery business use any formal methods. Some individuals will do so on an occasional basis, but only as a personal decision, not as an "official" company operating procedure.

However, I think that the analysis needs to include more than just the PLC logic. Hard wired logic and the physical characteristics of the devices controlled will often interact with the software in a complex manner. The machine needs to be viewed as a complete system, rather than just looking at the PLC logic in isolation. In addition, the needs of the operators (calibration, set-up, manual control, parameter adjustment, etc.) need to be accounted for in the design process, rather than just tacked on later.

************************
Michael Griffin
London, Ont. Canada
************************
 
Top