Dedicated to improving your control systems with Process Control System models
About Control
What's new
Our Clients
About Diagrams
Automation Models
Online manual
Free Software
Other Downloads

S88 Exception Handling

This document proposes some basic principles for exception handling in an S88 framework. 

S88 Part 1, Section 3.21 exception handling definition:
"Those functions that deal with plant or process contingencies and other events which occur outside the normal or desired behavior of batch control.
The components of exception handling are Event Detection, which is concerned with determining that an exception has occurred, and Actions to take in that event."

In general the Principle is to 
    Keep it simple
    Follow Generic rules as far as possible.
    Put the exception handling in Basic Control, not in phase logic.
    When a fault occurs drive the process to a sustainable quiescent state.
    In most cases Rely on operators to decide what action to take after exceptions occur.
    Design the procedural logic so that it can wait during exceptions

The authors believe that in general exception handling should NOT be handled by Recipe procedural logic. This means not in a Unit Procedure, an Operation or a phase. Note -  this is quite different to what will be found in many real life systems!
The recipe describes what Should happen, not what to do when something goes wrong.
If an exception should occur during the course of running a recipe procedure then the problem should, if possible (and generally it is,) be handled in such as way as to permit the procedure to continue from where it was. 
Whilst the fault is being handled the affected parts of the recipe procedure should wait.

Recipe Exceptions
This paper concentrates on exception handling by basic control. However there is a type of 'exception' that can happen in recipe procedures. An example is when a process analysis result is not 'normal' (a process event) and the execution of the recipe procedure is modified as a result, say by re-running a phase. 
The procedure for handling such events (as S88 says a process contingency) should be within the recipe procedure, or if the event has not been programmed for, by operators. In S88 terms this is a modification of the Control Recipe- ie the recipe procedure is changed at run time.

Event Detection

The author believes that good handling of exceptions at the detectable physical level can greatly reduce the incidence of process exceptions. This also requires that the physical faults are clearly distinguishable from the unpredictable process events. (So put limit switches on your valves)

We can easily detect failures in the physical system. For example:

Control System Failures
  These are detected by the diagnostics in the PCS and include failures of  IO Cards, Processors, Communications etc

Control Module Feedback Discrepancies
 These are detected by the Control Module software and indicate when the state of a device as indicated by it's feedback signals are in disagreement with the state that the device has been commanded to. Examples are
Valve Failures,Agitator Failures,Pump failures etc

Process Deviations
These cover cases where the process instrumentation detects an undesirable condition exists. This includes:
Control Loop deviations, Loss of Cooling, CIP - Process Contamination ,Loss of Sterility due to a temperature falling etc
Now, whilst most of these have a physical cause, it may be necessary to have procedural control to recover, but even this does not need to be part of the recipe.

Operational Events
There may simply be a need to suspend the execution of the recipe.

Actions to Take
When an exception occurs it require some action. 
This could be:
Just Raise an alarm
Drive the process to a sustainable hold state. Ideally one in which the process is quiescent and the recipe procedure can just wait. (you have weighed the cocoa and measured the milk into the saucepan, started the heat and the phone rings, causing an operational hold. You turn off the hob.)

How can a Procedure wait during exceptions?
in the following:
Operations = Procedural Entity - ie Phase or Operation
PE = Physical Entity - ie Equipment or Module/Unit

If the basic control is as described above, then nearly all failures will be detected by basic control.
When an equipment module has failed the Operation that is running on the module should suspend due to the module being held. Each Operation should have a "Too Slow" alarm. Generally these alarms should NOT cause the PE to go to hold. The basic principle is that when the PE is in a hold state then the running operation is inherently suspended. This happens because the PE is not doing any processing. Since operations generally wait for some process event before moving to the next step, the hold state will prevent the process event from happening.

This article is a short summary of a much more extensive document that ControlDraw has, please email if you would like more details. Examples are also provided in the ControlDraw sample models.

Copyright ControlDraw Ltd. All rights reserved.