<html><head></head><body><div class="ydp45c15bbyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div dir="ltr" data-setdir="false">At the risk of dumbing things down, I have found that complex multi-disciplinary systems (e.g. operator-electro-mechanical-software-chemical...) tend to be unpredictable - even when each of the components were thoroughly vetted, certified, calibrated - by experts in their prime. It can be as simple as a decision to use angles instead of quaterions (singularites), un-realistic design assumptions, delta retirements analysis instead of global requirements analysis (requirements conflicts), failure to optimize globally across multiple dimensions - mass, energy, momentum, time, jitter, sample frequency, changing physical systems without updating models & transforms, silent bill of materials <span>changes</span>, last minute cables/geometries <span>changes</span>, silent depot changes, pressure to say yes/pressure to say no, bit error/upset, etc. It's well and good to say the "O ring" was within spec and that the problem was else where - in a crisis the question becomes: is / was the system in spec? This is where devices like flight data recorder and flight reporting can prove useful - providing they are used constructively & responsibly. It the very least, perhaps you could use the data to determine the failure power law of the fielded system - or the fleet of systems.<br></div>
</div><div id="yahoo_quoted_4987999941" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday, July 10, 2020, 5:04:23 p.m. EDT, Olwen Morgan <olwen@phaedsys.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr"><br clear="none">OK. I suspect that we probably have differences of perspective rather <br clear="none">than hard technical disagreements on matters of important substance. I'm <br clear="none">still honestly puzzled by some of the things you are saying but at least <br clear="none">we're not trying to knock eight bells out of each other on what seeks to <br clear="none">be a civilised list. ... :-))<br clear="none"><br clear="none"><br clear="none">On 10/07/2020 20:20, Peter Bernard Ladkin wrote:<br clear="none"><snip><br clear="none"><br clear="none">> You are way off the usual aeronautical safety ball.<br clear="none">Sod the "aeronautical" safety ball. I believe, with due respect, that <br clear="none">I'm not actually way off the common-or-garden safety ball.<br clear="none"><br clear="none"><snip><br clear="none"><br clear="none">> ... they go wrong in specific ways. ...<br clear="none"><br clear="none">Individual things go wrong in specific ways but often disasters are a <br clear="none">chain of events whose sequential occurrence was never envisaged by <br clear="none">system designers. By analogy with Michael J's "long span" requirements, <br clear="none">one might call such things "long-span" failures.<br clear="none"><br clear="none"><snip><br clear="none"><br clear="none">"Stress testing" SW is not going to get you away from that fundamental <br clear="none">situation.<br clear="none"><br clear="none"><snip><br clear="none"><br clear="none">I beg to differ. One of the advantages of stress testing, at least in <br clear="none">the way I have understood and used it, is that it's an opportunity to <br clear="none">simulate low-probability/high-consequence chains of failures. If you <br clear="none">start designing stress tests from the question, "What could possibly go <br clear="none">wrong?" and are focussing on chains of events, you give yourself at <br clear="none">least a sporting chance of detecting circumstances in which your <br clear="none">short-span assumptions link together to engender a long-span failure and <br clear="none">consequent disaster.<br clear="none"><br clear="none">And common system safety practices show you where to start on designing <br clear="none">stress tests. You simply aggregate fault trees and cause-consequence <br clear="none">graphs and traverse them systematically applying a stressing <br clear="none">boundary-value test derivation rationale. (I have actually used this <br clear="none">approach, based on graphs of internal signal processing paths, to test <br clear="none">an ADAHRS instrument for a light aircraft. After giving it a hefty <br clear="none">caning - far beyond the normal functional testing - I was unable to <br clear="none">induce long-span failure in the signal processing algorithms, which, <br clear="none">AFAI could see, were very robust - probably owing to well-designed <br clear="none">signal level and rate clipping and smoothing.)<br clear="none"><br clear="none">It might not be what most aviation safety practitioners currently do - <br clear="none">but it's not rocket science.<div class="yqt5146750433" id="yqtfd17925"><br clear="none"><br clear="none"><br clear="none">Olwen<br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">The System Safety Mailing List<br clear="none"><a shape="rect" ymailto="mailto:systemsafety@TechFak.Uni-Bielefeld.DE" href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE">systemsafety@TechFak.Uni-Bielefeld.DE</a><br clear="none">Manage your subscription: <a shape="rect" href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety" target="_blank">https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a><br clear="none"></div></div></div>
</div>
</div></body></html>