emerging methods for safety assessment of software

EMERGING METHODS FOR SAFETY
ASSESSMENT OF SOFTWARE
Kristina Forsberg, Saab AB
3rd Scandinavian Conference on SYSTEM & SOFTWARE SAFETY
KTH, Stockholm 24 March 2015
OUTLINE
INTRODUCTION
•
•
•
Aircraft safety
Development assurance
Safety assessment process
SAFETY ASSESSMENT
METHODS
•
•
•
Safety assessment overview
FTA
FMEA
EXAMPLE: SW prevent braking
PAGE 2
AIRCRAFT SAFETY
AIRWORTHINESS STANDARDS are based on,
and incorporate, the objectives and principles or
techniques of the fail-safe design concept, which
considers the effects of failures and combinations
of failures in defining a safe design.
FAULT TOLERANT DESIGN
Aircraft-level functions are implemented using
diverse and redundant system architectures and
capabilities as mitigation techniques to achieve an
acceptable level of safety at the aircraft level
DEVELOPMENT ASSURANCE
All those planned and systematic actions used
to substantiate, to an adequate level of
confidence, that development errors have
been identified and corrected such that the
system satisfies the applicable certification
basis.
DEVELOPMENT ASSURANCE LEVEL (DAL)
Top-Level Failure Condition
Severity Classification
Associated System
Development
Assurance Level
Catastrophic
A
Hazardous / Severe Major
B
Major
C
Minor
D
No safety effect
E
The system development assurance level is assigned based on the most
severe failure condition classification associated with the applicable aircraftlevel function(s)
FAILURE CONDITION SEVERITY AS RELATED TO
PROBABILITY OBJECTIVES AND ASSURANCE LEVELS
Probability
(Quantitative)
Probability
(Descriptive)
Failure Condition
Severity
Classification
1.0
Per flight hour
1.0E-5
Improbable
FAA
Probable
JAA
Frequent
FAA
Minor
Major
1.0E-9
Extremely
Improbable
Extremely Remote
Extremely
Improbable
Severe Major
Catastrophic
JAA
Minor
Major
Hazardous
Catastrophic
- slight reduction in safety margins
- slight increase in crew workload
- some inconvenience to
occupants
- significant
reduction in
safety margins or
functional
capabilities
- significant
increase in crew
workload or in
conditions
impairing crew
efficiency
- some discomfort
to occupants
Level C
- large reduction in
safety margins or
functional
capabilities
- higher workload or
physical distress
such that the crew
could not be relied
upon to perform
tasks accurately or
completely
- adverse effects
upon occupants
Level B
- all failure
conditions which
prevent continued
safe flight and
landing
Failure Condition
Effect
FAA
JAA
&
Development
Assurance Level
ARP 4754
1.0E-3
Level D
Reasonably
Probable
1.0E-7
Remote
Level A
Note: A “No Safety Effect” Development Assurance Level E exists which may span
any probability range.
PAGE 6
Source ARP 4761
KEY DOCUMENTS
ARP 4754A
•
EASA, FAA Certification
requirements and regulations
CS25, PART25 (large airplanes)
Guidelines for Development of Civil
Aircraft and Systems
ARP 4761
•
Guidelines and Methods for conducting
the Safety Assessment Process on Civil
Airborne Systems and Equipment
RTCA/DO-178C
•
Software considerations in airborne
systems and equipment certification
RTCA/DO-254
•
Design assurance guidance for
airborne electronic hardware
RTCA/DO-160G
•
Environmental conditions and test
procedures for airborne equipment
Aircraft & System
Development
Process
ARP-4754/ED-79
Safety Assessment
ARP-4761
Electronic HW
Software Development
Development Process
Process
DO-254/ED-80
DO-178/ED-12
SYSTEM SAFETY PROCESS
Functional Hazard Assessment (FHA)
•
examines aircraft and system functions to
identify potential functional failures and classifies
the hazards associated with specific failure
conditions.
Preliminary System Safety Assessment
(PSSA)
•
establishes safety requirements and provides
preliminary indication that the anticipated system
architecture can meet those safety
requirements.
System Safety Assessment (SSA)
•
collects, analyzes, and documents verification
that the system, as implemented, meets the
system safety requirements established by the
FHA and the PSSA.
Common Cause Analysis (CCA)
•
establishes and validates physical and functional
separation and isolation requirements.
Source ARP 4754A
SAFETY ASSESSMENT METHODS
ARP 4761 – Guidelines and methods
for conducting the safety assessment
process on civil airborne systems and
equipment
Safety Assessment Overview
The safety assessment process includes
requirements generation and verification which
supports the aircraft development activities. This
process provides a methodology to evaluate
aircraft functions and the design of systems
performing these functions to determine that the
associated hazards have been properly
addressed. The safety assessment process is
qualitative and can be quantitative.
ARP 4761 includes:
Fault Tree Analysis (FTA)
Dependence Diagram (DD), Markov Analysis (MA)
Failure Modes and Effects Analysis (FMEA)
Failure Modes and Effects Summary (FMES)
Common Cause Analysis (CCA)
•
•
•
Zonal Safety Analysis (performed on each zone of the aircraft )
Particular Risks Analysis (events or influences which are outside the
systems and items)
Common Mode Analysis (to verify that ANDed events in the FTA/DD
and MA are independent in the actual implementation)
System Safety Assessment includes:
System description
List of failure conditions (FHA, PSSA)
Failure condition classification (FHA, PSSA)
Qualitative analyses for failure conditions (FTA, DD, FMES)
Quantitative analyses for failure conditions (FTA, DD, MA, FMES,
etc.)
Common Cause Analyses
Safety related tasks and intervals (FTA, DD, MA, FMES, etc.)
Development Assurance Levels for hardware and software
(PSSA)
Verification that safety requirements from the PSSA are
incorporated into the design and/or testing process
The results of the nonanalytic verification process (i.e., test,
demonstration and inspection activities)
EXAMPLE: SW prevent braking
RUNWAY OVERRUN
Flight DLH 2904, Frankfurt to Warsaw – cleared to land
Warsaw tower informed about ”Severe Windshears”
First contact with runway by it’s right landing gear at the
distance of 770 meters from RWY 11 threshold
Pilot attempted to use wheel brakes, failed to work
Left landing gear touched runway 9 seconds later
Heavy rain and a layer of water on the runway
Details about the design features of
the aircraft
To ensure that the thrust-reverse system and the spoilers
are only activated in a landing situation, the software has
to be sure the airplane is on the ground even if the
systems are selected mid-air.
The spoilers are only activated if at least one of the
following two conditions is true:
•
•
there must be weight of at least 6.3 tons on each main landing gear
strut
the wheels of the plane must be turning faster than 72 knots
(133 km/h)
The thrust reversers are only activated if the first condition
is true. There is no way for the pilots to override the
software decision and activate either system manually.
Causes of this accident
The main cause of the accident was incorrect decisions
and actions of the flight crew. Some of the incorrect decisions
were taken when information about windshear was received by the
crew. The windshear was produced by the front passing over the
airport; accompanied by intensive variation of wind parameters as
well as by heavy rain on the runway itself.
One additional cause was the lack of current wind
information at the tower. For that reason no up-to-date wind
information could be transmitted to the crew.
Further additional causes were certain design features of the
aircraft. Computer logics prevented the activation of both ground
spoilers and thrust reversers until a minimum compression load of
12600 kg was sensed at the shock absorbers, thus preventing the
crew from achieving any braking action by the two systems before
this condition is met.
As a result of the accident, Airbus Industrie changed the
required compression value from 6.3 tons to just 2 tons per
main landing gear.
Identified Failure Conditions
(ARP 4761)
For the function “Decelerate Aircraft on the Ground”
Functional Failure Conditions
•
•
•
•
•
Loss of all deceleration capability
Reduced deceleration capability
Inadvertent deceleration
Loss of all auto stopping features
Asymmetrical Deceleration
Environmental and Emergency Configurations and
Conditions
•
•
•
•
•
Runway Conditions (Wet, icy, etc.)
Runway Length
Tail/Cross Wind
Engine Out
J.
Severe weather condition assessment
Could extended software assessment methods
capture the software design more accurate?
•
•
E.g. extend FTA to identify combination of failures, faults and
events
Software items which appear in the minimal cutset of each
tree should be assessed with detailed FMEA
Design philosophy J which functions should be
overridable?
The software’s operation, its safety
requirements, its relationship with hardware ,
and its interaction with the operator must be
known and understood under all conditions.
[email protected]
[email protected]