[SystemSafety] At least PBL is now talking to me again ...

Olwen Morgan olwen at phaedsys.com
Fri Jul 10 23:04:06 CEST 2020


OK. I suspect that we probably have differences of perspective rather 
than hard technical disagreements on matters of important substance. I'm 
still honestly puzzled by some of the things you are saying but at least 
we're not trying to knock eight bells out of each other on what seeks to 
be a civilised list. ... :-))


On 10/07/2020 20:20, Peter Bernard Ladkin wrote:
<snip>

> You are way off the usual aeronautical safety ball.
Sod the "aeronautical" safety ball. I believe, with due respect, that 
I'm not actually way off the common-or-garden safety ball.

<snip>

> ... they go wrong in specific ways. ...

Individual things go wrong in specific ways but often disasters are a 
chain of events whose sequential occurrence was never envisaged by 
system designers. By analogy with Michael J's "long span" requirements, 
one might call such things "long-span" failures.

<snip>

"Stress testing" SW is not going to get you away from that fundamental 
situation.

<snip>

I beg to differ. One of the advantages of stress testing, at least in 
the way I have understood and used it, is that it's an opportunity to 
simulate low-probability/high-consequence chains of failures. If you 
start designing stress tests from the question, "What could possibly go 
wrong?" and are focussing on chains of events, you give yourself at 
least a sporting chance of detecting circumstances in which your 
short-span assumptions link together to engender a long-span failure and 
consequent disaster.

And common system safety practices show you where to start on designing 
stress tests. You simply aggregate fault trees and cause-consequence 
graphs and traverse them systematically applying a stressing 
boundary-value test derivation rationale. (I have actually used this 
approach, based on graphs of internal signal processing paths, to test 
an ADAHRS instrument for a light aircraft. After giving it a hefty 
caning - far beyond the normal functional testing - I was unable to 
induce long-span failure in the signal processing algorithms, which, 
AFAI could see, were very robust - probably owing to well-designed 
signal level and rate clipping and smoothing.)

It might not be what most aviation safety practitioners currently do - 
but it's not rocket science.


Olwen




More information about the systemsafety mailing list