Blog
 

Correctness vs. Safety

One of the examples that we regularly use in our training material is the catastrophic loss of Lufthansa Flight 2904
on September 14, 1993 when it ran off the end of the runway in Warsaw Poland.  It is an interesting and very
useful teaching example because it illustrates some of the main themes of the training that we regularly provide
to clients on system/software safety. This accident is particularly effective as an introduction to the training
material because students quickly realize that we are not simply talking about defect prevention or quality assurance.

When an Airbus 320 lands, the crew relies on the combination of brakes, ground spoilers and reverse thrusters
to slow the aircraft.  However in the case of Flight 2904 the activation of all three of these critical systems was
delayed such that the aircraft reached the end of the runway at a speed of 72 knots and hit an embankment
resulting in 2 fatalities.

The official investigation concluded that the probable cause of the accident was incorrect decisions and actions
of the flight crew. However, the most interesting aspect of this accident is the effect of certain design features
of the software on the deployment of the brakes, ground spoilers and reverse thrusters.  For example, the ground
spoiler was designed to prevent deployment of the ground spoilers until there is a weight of over 12 tons on each
main landing gear strut.  For reasons described in more detailed accounts of this accident, the aircraft was
banked to the right upon landing and consequently, the weight on the left landing gear strut was less than
12 tons for the first 9 seconds after touchdown.   Similarly, deployment of the reverse thrusters and brakes was
inhibited because of a condition that requires the wheels to be turning faster than 72 knots.  It was a rainy day
in Warsaw on September 14, 2993 with an accumulation of water on the runway, and due to hydroplaning, this
condition was not initially satisfied. By the time that the grounds spoilers and reverse thrusters were deployed,
the aircraft had already gone more than halfway down the runway.

There always seems to be a flash of insight on the faces of students in our training courses when they realize
that there is no evidence of a software defect or lapse in quality assurance in spite of the fact that the decision
logic implemented by the software makes it impossible for the crew to slow the aircraft upon touchdown.  We
use this flash of insight by explaining how it illustrates a major theme of our training material on system/software
safety, namely, that sources of safety risk in software-intensive systems are not limited to software defects or
lapses in quality assurance.  A software-intensive system could be unsafe even if it is “defect free”.

Upon hearing our explanation that the “software in the aircraft behaved exactly as designed”, students in our
training courses usually ask why such restrictions on the deployment of brakes, ground spoilers and reverse
thrusters were included in the design of the software.  Simply put, these restrictions were intended to be safety
mitigations – that is, features of the software that were intended to improve the safety of the aircraft.   This must
sound as paradoxical to many readers as it does to most of the students in our training course. The explanation
of this paradox leads to a second major theme of our training material on system/software safety, namely, that
the addition of a mechanism to a system for the purpose of mitigating a particular hazard might simultaneously
become a new source of risk for a different hazard.  This theme will be taken up as a topic in a future addition
to this blog which continues a discussion of what other lessons about system/software safety can be learned
from Flight 2904.

 

Cyber-Security and Safety for Aircraft and Aircraft Systems: DO-326A guidance CSL has been an active member of the international committee, RTCA SC 216, charged with the responsibility of developing guidance material that will help ensure safe, secure and efficient operations amid the growing use of highly integrated electronic systems and network technologies used on-board aircraft, for CNS/ATM systems and air carrier operations and maintenance. Recent efforts of the committee have resulted in a revision of RTCA DO 326 “Airworthiness Security Process Specification” that was released on the RTCA web site in August 2014. The guidance of DO-326A is intended to augment current guidance for aircraft certification to handle the information security (i.e., cybersecurity) threat to aircraft safety. In a nutshell, this new document describes a security engineering process that includes generic activities with corresponding compliance objectives. The scope of DO-326A not only covers the...
EN ISO 14971 or not EN ISO 14971?
Friday, 06 September 2013
EN ISO 14971 or not EN ISO 14971?The European community recognised EN ISO 14971:2012 in July 2012. EN ISO 14971:2012 supersedes EN ISO 14971:2009 which was based on ISO 14971:2007 ‘Medical devices - Application of risk management to medical devices’.In general, the EC committee felt that the application of ISO14971:2007 did not meet the Essential Requirements described in the European Medical Device Directive 93/42/EEC. Therefore the EC group reviewed ISO14971 to identify these areas in the standard that are not compliant with the MDD and formally document these deviations.EN ISO 14971:2012 applies only to manufacturers with devices intended for the European market; for the rest of the world, ISO 14971:2007 remains the standard recommended for risk management purposes.Standard outlineThis standard published* in 2012 is somewhat unusual in its layout: it includes three annexes located at the beginning of the document and then includes a copy of the 2007 corrected version of ISO...
FAA Recognizes RTCA DO 178C
Friday, 26 July 2013
FAA recognizes RTCA DO-178C and associated technical supplements (July 2013)The FAA published AC20-115C on July 19, 2013. In this AC, the FAA recognizes RTCA DO-178C, three associated technical supplements and the 'Software Tool Qualification Considerations' document.The actual documents that are the subject of this AC are the following RTCA documents:- DO-178C, Software Considerations in Airborne Systems and Equipment Certification- DO-330, Software Tool Qualification Considerations, dated December 13, 2011.- DO-331, Model-Based Development and Verification Supplement to DO178C and DO-278A,- DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A- DO-333, Formal Methods Supplement to DO-178C and DO-278AIt has been a long awaited recognition since the release of RTCA DO-178C in December 2011. (In terms of comparison, RTCA DO-178B was endorsed by the FAA only one month after its publication).Similarly to the previous AC that it replaces, this new AC...
Correctness vs Safety
Tuesday, 16 July 2013
Correctness vs. SafetyOne of the examples that we regularly use in our training material is the catastrophic loss of Lufthansa Flight 2904 on September 14, 1993 when it ran off the end of the runway in Warsaw Poland.  It is an interesting and very useful teaching example because it illustrates some of the main themes of the training that we regularly provide to clients on system/software safety. This accident is particularly effective as an introduction to the training material because students quickly realize that we are not simply talking about defect prevention or quality assurance.When an Airbus 320 lands, the crew relies on the combination of brakes, ground spoilers and reverse thrusters to slow the aircraft.  However in the case of Flight 2904 the activation of all three of these critical systems was delayed such that the aircraft reached the end of the runway at a speed of 72 knots and hit an embankment resulting in 2 fatalities.The official investigation concluded that the...
Alarm Management
Wednesday, 22 May 2013
Alarm Management  Our clients appreciate the fact that we are involved in projects across a wide spectrum of industries becausewe bring insights from common challenges experienced by other industries that lead to innovative solutionsto their problems.  A good example is alarm management which is a consideration in the design of almostevery kind of critical system.  Although the details of alarm management may vary considerably betweentechnical domains, our approach to helping clients with alarm management is based on the same fundamentalconcepts and principles.Thanks to Hollywood and movies such as The China Syndrome (1979), most of us have a sense of theadrenaline fueled drama of a control room during an emergency with alarm bells ringing and lights flashing.  But helping a client develop a sound approach to alarm management goes well beyond thinking about therare moments of high drama.For example, an operator could eventually become desensitized to a spurious alarm that is repeatedly...