[SystemSafety] Functional hazard analysis, does it work?

Wed Jan 20 14:42:34 CET 2016

Thank you Drew, this is consistent with my experience. The only thing I would add is that a significant element of the improvement comes through not leaving out the details. Recording the safety Derived Requirements (or trackable issues) is really important. So is ensuring that you close them all – whether through justification/analysis or through design change.

This is immediately useful to prevent issues being brushed under the table. It is also long-term useful because the safety oriented design changes (e.g. design so loss of X leads to the safe state by default) are explained to the next generation of developers. Otherwise they might alter them unknowingly in the name of product improvement or manufacturing simplification or something.

Cheers,
            Alvery

* these opinions are my own, not necessarily those of my employer.

Matthew,
I mean the real world and our understanding of it don't stand still. Take for example, your FFA. It would have a higher immediate fidelity if you performed it including modes than without including modes –
[] …
Hints for achieving parsimony of analysis:
 1) Be viscious about pruning the initial set of functions, and getting them neatly and consistently worded. If the system can't be described  in less than 20 functions, you're analysing at a level inappropriate for something as informal as FFA.
 2) Make sure the explicitly stated goal of the analysis is to identify ways to improve the system. That's the deliverable, not the FFA tables. Make sure everyone understands that the tables don't demonstrate anything, so there's no point in making them elaborate, or worrying about whether something gets recorded as an "omission" or an "incorrect", or whether it's okay to combine mode 7 and mode 8 because the wording is exactly the same, or any of the countless details and petty arguments that distract from finding ways to make the system better.
3) Do it in pairs, and mandate that each pair must contain someone response for actual design of the bit being analysed. (This is for psychological and political reasons as well as technical - if key design team members are burning time, there's immediate pressure to make it relevant to the design and get it finished).

[] …

<html><head></head><body><font color="black" face="arial" size="2">
This email and its attachments may contain confidential and/or privileged information.  If you have received them in error you must not use, copy or disclose their content to any person.  Please notify the sender immediately and then delete this email from your system.  This e-mail has been scanned for viruses, but it is the responsibility of the recipient to conduct their own security measures. Airbus Operations Limited is not liable for any loss or damage arising from the receipt or use of this e-mail. 

Airbus Operations Limited, a company registered in England and Wales, registration number, 3468788.  Registered office:  Pegasus House, Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.
</font>
</body>
</html> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160120/ff63b596/attachment-0001.html>