Top 5 system engineers omissions that make safety engineer s lives harder Colin Brain SE Validation Limited INCOSE President s Award Winners 2004, 2007 and 2008 INCOSE Gold Circle Award Winners 2003-2009
1. Safety Requirements Don t define any safety requirements its easier to simply quote a standard Similarly with CONOPS/ CONEMP/ CONUSE 2
Requirement? 3
No Safety Requirements - Impact Most safety engineers seldom see real safety requirements Acceptance then depends on demonstrating process compliance during design, rather than through-life safety in operation System safety is about freedom from harm during operations, without CONOPS etc. safety team have to: Guess how the system will be used and misused Ask potential users, who may have to guess 4
2. Safety Architecture Don t define any safety architecture, i.e. no defined system safety boundaries no defined safety interfaces with neighbouring systems no documentation of cross-interface safety assumptions no allocation of safety requirements to sub-systems Simply flow down standards required 5
Lack of Safety Architecture - Impact Without an architecture it is difficult to record safety reliance on sub-systems... Without interface information the safety team can only try to communicate their assumptions We produce safety requirements reports saying what we have done, but system engineers rarely know what to do with them Radio therapy machine 6
3. Test & Analysis Don t make provision for safety tests or analyses This is easier if you don t bring in safety specialists until the documentation phase (safety case) If you don t define safety requirements or specifications then no satisfaction evidence is required for these 7
Lack of Test & Analysis - Impact You cannot test something to prove that it is safe, but; tests can show it to be unsafe you can test for satisfaction of derived safety requirements Analysis can be effective, but always depends on the validity of the analysis models chosen Titanic Effect: The severity with which a system fails is proportional to the designer s belief that it cannot fail 8
4. Safety in Design Don t fix safety problems in design, leave them to be fixed in operation Leave it to the human factor folk to provide guidance and training If necessary provide personal protective equipment Don t worry about producing a safe design just produce a safety case 9
Lack of Safety in Design - Impact If you can eliminate a hazard, get rid of it If you cannot eliminate it, reduce its probability of causing an accident When you can t do anything else, mitigate the severity of the accident Managing safety in operation is never as satisfactory as managing it by design, however well intentioned However, beware the assumption that automation eliminates human error it doesn t 10
5. Safety Modifications Don t consult the safety engineer when making modifications to fix identified safety defects 11
No Safety Mod Consultation - Impact Modification may make the problem worse, not better...may be true of other mods...especially without an architecture! Significant defects should also trigger process and competence reviews 12
Conclusion: 5 Top Omissions 1. Safety requirements 2. Safety architectures 3. Safety test & analysis 4. Safety in design 5. Consulting on safety modifications I look forward to the discussion!!! 13