[SystemSafety] Functional safety and safety functions

Olwen Morgan olwen.morgan at btinternet.com
Mon Sep 17 18:42:58 CEST 2018


Here's an attempt to clarify some issues around functional safety, 
safety functions, reliability and safety. I'll give examples from the 
field of machine safety because they are perhaps easier to grasp.

Consider a CNC lathe that is part of a robotic production line. A robot 
puts a metal rod into the lathe's chuck, whereafter the lathe makes the 
turned component and the robot removes it before putting in the next 
rod. Typically these things have Lexan guards on them so that a machine 
supervisor can see what is going on but is shielded from swarf and the 
danger of getting caught in the rotating shaft. The lathe is 
software-controlled but we can distinguish two types of software:

1.    the s/w that controls the operation of the lathe to make the 
required parts, and

2.    the s/w that monitors whether the Lexan guard is open or not.

For a given turned part made of a given metal, the rotary speed of the 
lathe and the rate at which it feeds the cutting tool along the bar must 
be very closely controlled. If speed and feed are not kept within 
prescribed limits, various undesirable things can happen, one of which 
is that a long line of jagged swarf can snake out of the machine and 
cause injury to bystanders. OK, there is the Lexan guard, but the normal 
control of the lathe must be such as to avoid swarf-snakes  because they 
pose other kinds of danger too. Hence the lathe control software 
performs safety-related functions. In this case we may speak of 
functional safety to refer to safety considerations in the working of 
normal control functions.

At this point we can introduce the concept of control envelopes. An 
control envelope is a subset of the system's phase space such that 
control functions seek to keep the machine within that subset. We can 
immediately identify different kinds of control envelope;

1.    The safety control envelope is an envelope such that no hazards 
arise when the system is kept within that envelope.

2.    The proactive safety control envelope is a subset of the safety 
control envelope such that by keeping the system within that envelope, 
the controller can ensure that the system never has time to cross 
outside the safety control envelop between successive demands on the 
controller for feedback control.

Now it may happen that the system is subjected to a perturbation from an 
external source such that the normal control mechanism cannot guarantee 
to keep the system within the safety control envelope. In this case, an 
unsafe system state may arise. The way to deal with this is to define:

3.    The reactive safety control envelope, which is defined to be a 
subset of the phase space such that when excursion from it is detected, 
a reactive safety function cuts in so as to ensure that the system 
returns to within the proactive safety control enveloped within a 
specified time.

In the lathe control example, the lathe feed and speed controller seeks 
to keep the feed and speed within the proactive safety control envelope 
but if it fails to do this, e.g. when a worker opens the Lexan guard, 
the unsafe state has occurred without the normal functional control 
having any way of knowing about it. Hence the use of a PLC connected to 
a sensor that detects when the guard is open. When the open-guard state 
is detected, the lathe is powered down (and if necessary braked) so that 
the shaft stops moving before the person who opened the guard gets close 
to the shaft itself. (A simplified example, I admit, but not entirely 
unrealistic.)

By using the notion of safety envelopes to describe this situation, we 
have a useful way to distinguish between safety-related aspects of 
normal, proactive control, and safety-related aspects of reactive 
control that cuts in when exceptional conditions are detected.

For *reactive* controllers in this sense, safety entails reliability. On 
the other hand a *proactive* controller can be as reliable as you like 
but cannot guarantee safety because it is not designed to respond to the 
exceptional conditions that are dealt with by a reactive controller 
(because typically a normal controller will be using a three-term linear 
control scheme).

I don't advance this as some deep theory about safety and reliability 
but it does offer a way to distinguish cases in which safety entails 
reliability and when it does not. This way of looking at things has 
proved helpful in one project on which I worked, largely in enabling 
people to think in useful kinds of categories about reliability and safety.


Hope it helps,

Olwen



More information about the systemsafety mailing list