[SystemSafety] WG: words you cannot use at GM

[Peter Bernard Ladkin]

> On 23 May 2014, at 05:27, Matthew Squair <mattsquair at gmail.com> wrote:
> 
> From a systems engineering perspective the word 'acceptable' is a subjective qualifier,

(The word "acceptable" is not a qualifier. It's an adjective, denoting a property. The word "acceptably" is a qualifier, aka an adverb). 

> meaning the requirement for something to be 'acceptably safe' is unverifiable as it introduces subjective and potentially different interpretations. 

It doesn't follow that because a phrase "acceptably safe" is not objective it is not verifiable. 
All that is needed is a decision procedure. Any such decision procedure might well involve some arbitrariness; but all that is needed is that the results of the decision procedure are objectively verifiable.

When safety properties of a system are known, you could ask stakeholders to vote on their acceptability, and have a rigorous criterion for a vote to succeed or fail. There is no philosophy which equates "acceptably safe" with such-and-such a proportion of "yes" votes amongst some designation of stakeholders - also who is a stakeholder is not predetermined - nevertheless we can recognise some such procedure as appropriate even while quibbling over the proportions and participants. 

That is in principle what is done in IEC 61508, except that the decision procedure is not specified. We can take it that it is regarded as outside the scope of the safety engineering itself. 

And I think that is right. Or, at least, as right as it gets.

Further, I would challenge anyone to produce an objective (in this sense) definition of "safe". I don't think you can look at a system, and simply in virtue of its objectively determinable properties determine the value of the property "safe". There is inevitably a social selection involved. Adding the obviously-social indicator "acceptably" is only making this explicit.

> I also tend to the school of thought that if you can't verify a requirement in any credible sense it's not a technical requirement, ergo such concepts as SFAIRP or ALARP on their own are not true requirements,  nor should they be introduced into specifications. 

I don't follow this at all. Social judgements make their way into engineering specifications all the time. A bridge must be designed and built such-and-such a way because of its social impact. In the US, power cables are strung from poles; in Europe in towns they are generally buried. The specifications for an urban distribution power cable will include that it shall be underground. And even the guidelines for underground cable laying will include items that have been determined over years of experience to be broadly acceptable to some group of people (how deep to bury it, requirements for accessibility, and so on). When you build a car, its properties will largely have been determined by how the manufacturer thinks it can sell it to people. 

I don't see any general problem in introducing matters into engineering specifications that must be decided outside of pure engineering considerations. And to the contrary, I see plenty of problems if you couldn't. 

PBL

Prof. Peter Bernard Ladkin, University of Bielefeld and Causalis Limited