Functional Safety, and a Trope (was Re: <sp> )



Functional Safety, and a Trope (was Re: <sp> )

From: Peter Bernard Ladkin <ladkin_at_xxxxxx>
Date: Mon, 23 May 2011 09:25:13 +0200
Message-ID: <4DDA0BD9.3080706@xxxxxx>
On 5/22/11 5:52 PM, Nancy Leveson wrote:
> .. Software is not safe or unsafe by itself. It is only safe or unsafe depending on the
> context or system in which it is operating.

Indeed so.

> ...Safety is an emergent property of any system, it
> is not a component property (unless the component can be dangerous all by
> itself, for example, it has sharp edges and could cut someone if they get
> near it).

Yes, safety is an emergent property of a system that may not be simply assessed through composing 
properties of components.

Your mention of "sharp edges" led me to the following. I think it is useful to make a distinction 
between functional safety and non-functional safety. If software commands behavior which constitutes 
a dangerous system failure, that is an issue of functional safety. If heavy use of a processor by SW 
causes it to give off fumes which make people in its immediate environment ill, that is a 
non-functional safety issue.

Let me propose a thesis: that all safety issues concerning software are functional. Is this right?

Functional safety turns out to be controversial for some poor reasons, below.

> The SIL levels applied to the software imply that there is some "number" or
> "level" of safety that can be applied to software in a vacuum and it will
> apply no matter in what system you run that software.

That characterisation of software SIL does not apply to the concept in IEC 61508 (although it might 
in other standards). A system function ("safety function", generally implemented in HW+SW) gets a 
SIL and the software which functionally controls the behavior of that function inherits a SIL from 
that function. A SIL is not assigned to SW "in a vacuum".

However (and this is a big however), some evaluation organisations are willing to say of certain 
software tools that they are suitable for SIL X software development, and said producers of the 
tools advertise their wares as "certified to SIL 3 under IEC 61508". Similarly, producers of certain 
HW+SW components say their components are certified for use in SIL X systems. Some of us consider 
this an abuse of the 61508 conception of a SIL as specific to a safety function in a specific system.

> Sorry, but that is
> simply untrue, however convenient it would be if it were.

Yes, it sure is untrue.

> Pairing the word "safety" with "integrity," where integrity is defined as
> "dependability" or reliability, as Felix suggests, makes no sense to me at
> all.

I prefer the notions of integrity which I and John McD proposed. I think they make consummate sense.

> In system safety, the term that has always been used is "hazard level" which
> talking about levels of safety or hazards. When using qualitative
> categories, various numbers of categories can be used.

I agree in general with John McD that there is a problem with terminology. I think this illustrates 
it. I know what is meant by safety integrity and its various levels, and can say. It is (manifestly, 
to me) not the same as classifying the function according to the hazards it can encounter. Both 
notions have their uses.

Use of the term "system safety" raises another set of issues around the set of terms "X safety", as 
in "functional safety", "non-functional safety", "system safety", "electrical safety", "fire 
safety", ....., which I would illustrate as follows.

In Germany, we have a standardisation effort specifically concerned with electric vehicles. It is 
called "E-Mobility", a good old German word :-) . It occurred to one of the E-Mobility committees 
(AG10) that there are some issues about recharging. Electricity-network providers are concerned 
about the behavior of high-potential-energy equipment (electric cars) when connected to their 
networks, and what they might do to the network. Providers of recharging stations want some 
assurance that their products are deemed fit for purpose, presumably inter alia to protect 
themselves against random lawsuits because everyone else who is larger will say "not our fault" when 
something bad happens (which it will) and has the larger army of lawyers to promote that claim.

I said: when an electric vehicle is being recharged, what is the system and where is the system 
boundary? Ask that question, and it becomes clear that the behavioral influences include electricity 
network (home, or commercial on-the-street), charging station, cable, electric vehicle, as well as 
all their interfaces. It becomes equally apparent to those who search that there exists no document 
which treats the hazards of this "system", whatever the system should turn out to be.

It is standard when designing a system with safety-relevant properties that a preliminary hazard 
analysis (PHA) be performed. Everybody here agree?

So I said: not only has nobody yet defined the system and its boundary, but there exists no PHA as 
far as anybody can put their finger on one. So let's define the system boundary for recharging 
activities and do one. It's standard procedure. AG10 agreed.

Pretty straightforward stuff, one might think. But companies in one market segment appear to be 
quite contra. Let me air one of the tropes.

"Functional safety should not be confused with electrical safety. Electrical safety is guaranteed 
through the existing standards of such-and-such for networks and such-and-such for vehicles and 
such-and-such per UN agreement. It is thereby assured. Functional safety has no application here."

Try to parse that. It seems to me to be a category mistake. Functional safety can be usefully 
opposed to non-functional safety. Electrical safety can be usefully considered as well as dynamic 
safety, steering safety, braking safety, collision safety, fire safety as one of the aspects of 
safety considerations of, say, a vehicle and its environment: one is dividing up by component 
subsystem and common characteristics (electrical as contrasted with mechanical, say).

However, the argument seems to be that "we do electrical safety; we don't need functional safety as 
well", as if functional safety was another similar type of safety. But it isn't. However, I am told 
that "functional safety" is very controversial in standards circles as if it were, and tropes such 
as the above appear a lot.

The term functional safety can only be compared/contrasted with non-functional safety. If one wants 
to say "electrical safety is assured", one is thereby making a claim that functional safety 
integrity, indeed likely also non-functional safety attributes, which concern electrical subsystems 
is/are assured. And either there is proof of that or there isn't. If there is proof, let's see it. 
If there isn't, let's provide it. And when we've done it for electrical aspects, let's do it for 
other aspects of functional safety.

Here is where I think the term "system safety" can come in very useful. System safety is a way of 
thinking about engineered purposeful (I say "teleological") systems in which the main preliminary 
activity is to delimit the system boundary and its interfaces with the environment, and the second 
activity is to conduct a preliminary hazard analysis. I hadn't thought that any of this was at all 
controversial, but it is. As I have illustrated above.

Wouldn't it be useful to have a standard which says that functional system safety assurance consists in:

1. a. Delimit the system boundary
    b. Describe the system environment (that part of the world which interacts with the system
        but which does not lie within the boundary
    c. Describe the interface(s) between system and environment
    d. Write down the results of 1a, 1b, 1c.

2. a. Conduct a preliminary hazard analysis (PHA) on the basis of the results of Step 1.
    b. Write down the results of 2a.

3. Perform these actions recursively for subsystems of the system.

Anyone up for a project to define an international standard for System Safety, which consists of the 
three steps above, plus applicable definitions, plus boilerplate?

(Somebody will surely be first to say "but this is all covered in IEC 61508". If you feel tempted, 
please cite specific clauses and proof, that is, the connecting argument. And then explain how one 
argues that a "functional safety" standard also embraces "electrical safety" to someone who thinks 
it is different. I will be eternally grateful - I promise!)

PBL

Peter Bernard Ladkin, Professor of Computer Networks and Distributed Systems,
Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de
Received on Mon 23 May 2011 - 08:25:22 BST