System Software Safety
Chapter 10System Software Safety
10.0 SYSTEM SOFTWARE SAFETY.......................................................................................................2
10.1 INTRODUCTION ...........................................................................................................................2
10.2 THE IMPORTANCE OF SYSTEM SAFETY................................................................................3
10.3 SOFTWARE SAFETY DEVELOPMENT PROCESS...................................................................5
10.4 SYSTEM SAFETY ASSESSMENT REPORT (SSAR) .................................................................14
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-2
10.0 SYSTEM SOFTWARE SAFETY
10.1 Introduction
Much of the information in this chapter has been extracted from the JSSSC Software System Safety
Handbook, December, 1999, and concepts from DO-178B, Software Considerations in Airborne Systems
and Equipment Certification, December 1, 1992.
Since the introduction of the digital computer, system safety practitioners have been concerned with the
implications of computers performing safety-critical or safety-significant functions. In earlier years, software
engineers and programmers constrained software from performing in high risk or hazardous operations
where human intervention was deemed both essential and prudent from a safety perspective. Today,
however, computers often autonomously control safety critical functions and operations. This is due
primarily to the capability of computers to perform at speeds unmatched by its human operator counterpart.
The logic of the software also allows for decisions to be implemented unemotionally and precisely. In fact,
some current operations no longer include a human operator.
Software that controls safety-critical functions introduce risks that must be thoroughly addressed (assessed
and mitigated?) during the program by both management and design , software , and system safety
engineering. In previous years, much has been written pertaining to "Software Safety" and the problems
faced by the engineering community. However, little guidance was provided to the safety practitioner that
was logical, practical, or economical. This chapter introduces an approach with engineering evidence that
software can be analyzed within the context of both the systems and system safety engineering principles.
The approach ensures that the safety risk associated with software performing safety-significant functions is
identified, documented, and mitigated while supporting design-engineering objectives along the critical path
of the system acquisition life cycle.
The concepts of risk associated with software performing safety-critical functions were introduced in the
1970's. At that time, the safety community believed that traditional safety engineering methods and
techniques were no longer appropriate for software safety engineering analysis. This put most safety
engineers in the position of “wait and see.” Useful tools, techniques, and methods for safety risk
management were not available in the 1970's even though software was becoming more prevalent in system
designs.
In the following two decades, it became clear that traditional safety engineering methods were indeed
partially effective in performing software safety analysis by employing traditional approaches to the
problem. This situation does not imply, however, that some modified techniques are not warranted. Several
facts must be realized before a specific software safety approach is introduced. These basic facts must be
considered by the design engineering community to successfully implement a system safety methodology
that addresses the software implications.
· Software safety is a systems issue, not a software-specific issue. The hazards caused by
software must be analyzed and solved within the context of good systems engineering
principles.
· An isolated safety engineer may not be able to produce effective solutions to potential
software-caused hazardous conditions without the assistance of supplemental expertise.
The software safety "team" should consist of the safety engineer, software engineer,
system engineer, software quality engineer, appropriate "ility" engineers (configuration
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-3
management, test & evaluation, verification & validation, reliability, and human
factors), and the subsystem domain engineer.
· Today's system-level hazards, in most instances, contain multiple contributing factors
from hardware, software, human error, and/or combinations of each, and,
· Finally, software safety engineering cannot be performed effectively outside the
umbrella of the total system safety engineering effort. There must be an identified link
between software faults, conditions, contributing factors, specific hazards and/or
hazardous conditions of the system.
The safety engineer must also never lose sight of the basic, fundamental concepts of system safety
engineering. The product of the system safety effort is not to produce a hazard analysis report, but to
influence the design of the system to ensure that it is safe when it enters the production phase of the
acquisition life cycle. This can be accomplished effectively if the following process tasks are performed:
· Identify the safety critical functions of the system.
· Identify the system and subsystem hazards/risks.
· Determine the effects of the risk occurrence.
· Analyze the risk to determine all contributing factors (i.e.. hardware, software, human
error, and combinations of each.)
· Categorize the risk in terms of severity and likelihood of occurrence.
· Determine requirements for each contributing factor to eliminate, mitigate, and/or
control the risk to acceptable levels. Employ the safety order of design precedence
Chapter 3, Table 3-7, for hazard control.
· Determine testing requirements to prove the successful implementation of design
requirements where the hazard risk index warrants.
· Determine and communicate residual safety risk after all other safety efforts are
complete to the design team and program management.
10.2 The Importance of System Safety
Before an engineer (safety, software, or systems) can logically address the safety requirements for software,
a basic understanding of how software “fails” is necessary. Although the following list may not completely
address every scenario, it provides the most common failure mechanisms that should be evaluated during the
safety analysis process.
· Failure of the software to perform a required function, i.e., either the function is never
executed or no answer is produced.
· The software performs a function that is not required, i.e., getting the wrong answer,
issuing the wrong control instruction, or doing the right action but under inappropriate
conditions.
· The software possesses timing and/or sequencing problems, i.e., failing to ensure that
two things happen at the same time, at different times, or in a particular order.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-4
· The software failed to recognize that a hazardous condition occurred requiring corrective
action.
· The software failed to recognize a safety-critical function and failed to initiate the
appropriate fault tolerant response.
· The software produced the intended but inappropriate response to a hazardous condition.
· The specific causes most commonly associated with the software failure mechanisms
listed above are:
· Specification Errors: Specification errors include omitted, improperly stated,
misunderstood, and/or incorrect specifications and requirements. Software may be
developed "correctly" with regard to the specification, but wrong from a systems
perspective. This is probably the single largest cause of software failures and/or errors.
· Design and Coding Errors: These errors are usually introduced by the programmer and
can result from specification errors, usually the direct result of poor structured
programming techniques. These errors can consist of incomplete interfaces, timing
errors, incorrect interfaces, incorrect algorithms, logic errors, lack of self-tests, overload
faults, endless loops, and syntax errors. This is especially true for fault tolerant
algorithms and parameters.
· Hardware/Computer Induced Errors: Although not as common as other errors, then can
exist. Possibilities include random power supply transients, computer functions that
transform one or more bits in a computer word that unintentionally change the meaning
of the software instruction, and hardware failure modes that are not identified and/or
corrected by the software to revert the system to a safe state.
· Documentation Errors: Poor documentation can be the cause of software errors through
miscommunication. Miscommunication can introduce the software errors mentioned
above. This includes inaccurate documentation pertaining to system specifications,
design requirements, test requirements, source code and software architecture documents
including data flow and functional flow diagrams.
· Debugging/Software Change Induced Hazards: These errors are basically selfexplanatory. The cause of these errors can be traced back to programming and coding
errors, poor structured programming techniques, poor documentation, and poor
specification requirements. Software change induced errors help validate the necessity
for software configuration.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-5
10.3 Software Safety Development Process
The process outlined below is briefly explained in this Handbook. Further guidance and specific instructions
can be obtained through a careful examination of the JSSSC Software System Safety Handbook, Dec. 1999
and DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Dec. 1, 1992 at a
minimum.
10.3.1 Software Safety Planning and Management
Software system safety planning precedes all other phases of the software systems safety program. It is
perhaps the single most important step and should impose provisions for accommodating safety well before
each of the software life cycle phases: requirements, design, coding, and testing starts in the cycle. Detailed
planning ensures that critical program interfaces and support are identified and formal lines of
communication are established between disciplines and among engineering functions. The software aspects
of systems safety tend to be more problematic in this area since the risks associated with the software are
often ignored or not well understood until late in the system design.
Planning Provisions
The software system safety plan should contain provisions assuring that:
· Software safety organization is properly chartered and a safety team is commissioned at
the beginning of the life cycle.
· Acceptable levels of software risk are defined consistently with risks defined for the
entire system.
· Interfaces between software and the rest of the system’s functions are clearly delineated
and understood.
· Software application concepts are examined to identify hazards/risks within safetycritical software functions.
· Requirements and specifications are examined for hazards (e.g. identification of
hazardous commands, processing limits, sequence of events, timing constraints, failure
tolerance, etc.)
· Design and implementation is properly incorporated into the software safety
requirements.
Planning
And
Management
10.3.1
Assign
Software
Criticality
10.3.2
Safety-Critical
Requirements
Derivation
10.3.3
Design
And
Analyses
10.3.4
Testing
10.3.5
Software Safety
Process Steps
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-6
· Appropriate verification and validation requirements are established to assure proper
implementation of software system safety requirements.
· Test plans and procedures can achieve the intent of the software safety verification
requirements.
· Results of software safety verification efforts are satisfactory.
Software Safety Team
Software safety planning also calls for creating a software safety team. Team size and shape depends
commensurately on mission size and importance (see Figure 10-1). To be effective, the team should consist
of analytical individuals with sufficient system engineering background. Chapter 5 of this handbook
provides a comprehensive matrix of minimum qualifications for key system safety personnel. It applies to
software system safety provided professional backgrounds include sufficient experience with software
development (software requirements, design, coding, testing, etc.)
Figure 10-1: Example Membership of Software System Safety Team
Several typical activities expected of the team range from identifying software-based hazards to tracing
safety requirements, from identifying limitations in the actual code to developing software safety test plans
and ultimately reviewing test results for their compliance with safety requirements.
Management
Software System Safety program management begins as soon as the System Safety Program (SSP) is
established and continues throughout the system development. Management of the effort requires a variety
of tasks or processes from establishing the Software Safety Working Group (SwSWG) to preparing the
System Safety Assessment Report (SSAR). Even after a system is placed into service, management of the
software system safety effort continues to address modifications and enhancements to the software and the
system. Often, changes in the use or application of a system necessitate a re-assessment of the safety of the
software in the new application. Effective management of the safety program is essential to the effective
reduction of the system risk. Initial efforts parallel portions of the planning process since many of the
required efforts need to begin very early in the safety program. Safety management pertaining to software
generally ends with the completion of the program and its associated testing; whether it is a single phase of
the development process or continues throughout the development, production, deployment and maintenance
phases. Management efforts end when the last safety deliverable is completed and is accepted by the FAA.
Management efforts may then revert to a “caretaker” status in which the safety manager monitors the use of
Software Safety Team
Software Engineer
Software Quality Assurance
· Software Test Engineer
· Domain & Systems Design
System Safety Program Manager
System Safety Engineer
· Software Safety Lead
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-7
the system in the field and identifies potential safety deficiencies based on user reports and accident/incidents
reports. Even if the developer has no responsibility for the system after deployment, the safety program
manager can develop a valuable database of lessons learned for future systems by identifying these safety
deficiencies.
Establishing a software safety program includes establishing a SwSWG. This is normally a sub-group of the
SSWG and chaired by the safety manager. The SwSWG has overall responsibility for the following:
· Monitoring and control of the software safety program
· Identifying and resolving risks with software contributory factors
· Interfacing with the other IPTs, and
· Performing final safety assessment of the system (software) design.
10.3.2 Assign Software Criticality
The ability to prioritize and categorize hazards is essential for the allocation of resources to the functional
area possessing the highest risk potential. System safety programs have historically used the Hazard Risk
Index (HRI) to categorize hazards. However, the methodology to accurately categorize hazards using this
traditional HRI matrix for hazards possessing software causal factors is insufficient. The ability to use the
original (hardware oriented) HRI matrix was predicated on the probability of hazard occurrence and the
ability to obtain component reliability information from engineering sources. The current technologies
associated with the ability to accurately predict software error occurrence, and quantify its probability, is still
in its development infancy. This is due to the nature of software as opposed to hardware. Statistical data
may be used for hardware to predict failure probabilities. However, software does not fail in the same
manner as hardware (it does not wear out, break, or have increasing tolerances). Software errors are
generally requirements errors (failure to anticipate a set of conditions that lead to a hazard, or influence of an
external component failure on the software) or implementation errors (coding errors, incorrect interpretation
of design requirements). Therefore, assessing the risk associated with software is somewhat more complex.
Without the ability to accurately predict a software error occurrence, supplemental methods of hazard
categorization must be available when the hazard possesses software causal factors. This section of the
handbook presents a method of categorizing hazards that possess software influence or causal factors.
Risk Severity
Regardless of the contributory factors (hardware, software, human error, and software influenced human
error) the severity of the risk could remain constant. This is to say that the consequence of risk remains the
same regardless of what actually caused the hazard to propagate within the context of the system. As the
severity is the same, the severity tables presented in Chapter 3 remain applicable criteria for the
determination of risk severity for those hazards possessing software causal factors.
Risk Probability
With the difficulty of assigning accurate probabilities to faults or errors within software modules of code, a
supplemental method of determining risk probability is required when software causal factors exist. Figure
10-2 demonstrates that in order to determine a risk probability, software contributory factors must be
assessed in conjunction with the contributors from hardware and human error. The determination of
hardware and human error contributor probabilities remain constant in terms of historical “best” practices.
However, the likelihood of the software aspect of the risk's cumulative causes must be addressed.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-8
Contributory
HAZARD
Software Hardware
Human
Error
Likelihood
of Occurrence
Base Upon
Component
Failures
1 X 10
-4
Likelihood
of Occurrence
Base Upon
Trained
Individuals
1 X 10
-3
Likelihood
of Occurrence
Base Upon
Software
Faults/Error
s ? X 10
-?
Figure 10-2: Likelihood of Occurrence Example
There have been numerous methods of determining the software’s influence on system-level risks. Two of
the most popular software listings are presented in MIL-STD 882C and RTCA DO-178B (see Figure 10-3).
These do not specifically determine software-caused risk probabilities, but instead assesses the software’s
“control capability” within the context of the software contributors . In doing so, each software contributors
can be labeled with a software control category for the purpose of helping to determine the degree of
autonomy that the software has on the hazardous event. The software safety team must review these lists and
tailor them to meet the objectives of the system safety and software development programs.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-9
(I) Software exercises autonomous control over potentially hazardous
hardware systems, subsystems or components without the possibility of
intervention to preclude the occurrence of a hazard. Failure of the software
or a failure to prevent an event leads directly to a hazards occurrence.
(IIa) Software exercises control over potentially hazardous hardware
systems, subsystems, or components allowing time for intervention by
independent safety systems to mitigate the hazard. However, these
systems by themselves are not considered adequate.
(IIb) Software item displays information requiring immediate operator
action to mitigate a hazard. Software failure will allow or fail to prevent
the hazard’ s occurrence.
(IIIa) Software items issues commands over potentially hazardous
hardware systems, subsystem, or components requiring human action to
complete the control function. There are several, redundant, independent
safety measures for each hazardous event.
(IIIb) Software generates information of a safety critical nature used to make
safety critical decisions. There are several, redundant, independent safety
measures for each hazardous event.
(IV) Software does not control safety critical hardware systems, subsystems,
or components and does not provide safety critical information.
MIL-STD 882C RTCA-DO-178B
(A) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure
of system function resulting in a catastrophic failure condition for
the aircraft.
(B) Software whose anomalous behavior, as shown by the System
Safety assessment process, would cause or contribure to a failure
of system function resulting in a hazardous/severe-major failure
condition of the aircraft.
(C) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure
of system function resulting in a major failure condition for the
the aircraft.
(D) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure of
system function resulting in a minor failure condition for the
aircraft.
(E) Software whose anomalous behavior, as shown by the system
safety assessment process, would cause or contribute to a failure of
function with no effect on aircraft operational capability or pilot
workload. Once software has been confirmed as level E by the
certification authority, no further guidelines of this document apply.
Figure 10-3: Examples of Software Control Capabilities
Once again, the concept of labeling software contributors with control capabilities is foreign to most software
developers and programmers. They must be convinced that this activity has utility in the identification and
prioritization of software entities that possesses safety implication. In most instances, the software
development community desires the list to be as simplistic and short as possible. The most important aspect
of the activity must not be lost, that is, the ability to categorize software causal factors for the determining of
both risk likelihood, and the design, code, and test activities required to mitigate the potential software cause.
Autonomous software with functional links to catastrophic risks demand more coverage than software that
influences low-severity risks.
Software Hazard Criticality Matrix
The Software Hazard Criticality Matrix (SHCM) (see Figure 10-4 for an example matrix) assists the software
safety engineering team and the subsystem and system designers in allocating the software safety
requirements between software modules and resources, and across temporal boundaries (or into separate
architectures). The software control measure of the SHCM also assists in the prioritization of software
design and programming tasks.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-10
Software Hazard Criticality Matrix
For Example Purposes Only
High Risk - Significant Analyses and Testing Resources
Medium Risk - Requirements and Design Analysis and Depth Testing Required
Moderate Risk - High Levels of Analysis and Testing Acceptable With Managing Activity Approval
Severity
Control Category Catastrophic Critical M arginal Negligible
(I) Software exercises autonomous control over potentially hazardous
hardware systems, subsystems or components without the possibility of
intervention to preclude the occurrence of a hazard. Failure of the software
or a failure to prevent an event leads directly to a hazards occurrence.
(IIa) Software exercises control over potentially hazardous hardware
systems, subsystems, or components allowing time for intervention by
independent safety systems to mitigate the hazard. However, these
systems by themselves are not considered adequate.
(IIb) Software item displays information requiring immediate operator
action to mitigate a hazard. Software failure will allow or fail to prevent
the hazard’ s occurrence.
(IIIa) Software items issues commands over potentially hazardous
hardware systems, subsystem, or components requiring human action to
complete the control function. There are several, redundant, independent
safety measures for each hazardous event.
(IIIb) Software generates information of a safety critical nature used to make
safety critical decisions. There are several, redundant, independent safety
measures for each hazardous event.
(IV) Software does not control safety critical hardware systems, subsystems,
or components and does not provide safety critical information.
1 1 3 5
1 2 4 5
1 2 4 5
2 3 5 5
2 3 5 5
3 4 5 5
Extracted from Mil-Std 882C
Moderate Risk - High Levels of Analysis and Testing Acceptable With Managing Activity Approval
Low Risk - Acceptable
Figure 10-4: Software Hazard Criticality Matrix
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-11
10.3.3 Derivation of System Safety-Critical Software Requirements
Safety-critical software requirements are derived from known safety-critical functions, tailored generic
software safety requirements and inverted contributory factors determined from previous activities. Safety
requirement specifications identify the specifics and the decisions made, based upon the level of risk, desired
level of safety assurance, and the visibility of software safety within the developer organization. Methods for
doing so are dependent upon the quality, breadth and depth of initial hazard and failure mode analyses and on
lessons-learned derived from similar systems. The generic list of requirements and guidelines establish the
beginning point that initiates the system-specific requirements identification process. System-specific
software safety requirements require a flow-down of hazard controls into requirements for the subsystems
which provide a trace (audit trail) between the requirement, its associated risk and to the module(s) of code
that are affected. Once this is achieved as a core set of requirements, design decisions are identified,
assessed, implemented, and included in the hazard record database. Relationships to other risks or
requirements are also determined. The identification of system-specific requirements (see Figure 10-5) is the
direct result of a complete hazard analysis methodology.
PRELIMINARY HAZARD LIST (PHL)
PRELIMINARY HAZARD ANALYSIS (PHA)
Develop Generic Safety Critical
Software Guidelines & Requirements
Derive Functional Safety-
Critical Requirements
ð Obtain Generic Software Safety Requirements Lists
ð Tailor Generic Software Safety Requirement and
Guidelines List for the Specific System and/or
Subsystem
ð Develop Safety-Critical Functions List
ð Develop Potential Functional Hazard List
ð Categorize and Prioritize Generic Software
Requirements and Guidelines
ð Categorize and Prioritize System Functional Hazards
ð Determine System Level HW/SW and HF Causal Factors
ð Execute System Level Trade Study
ð Analyze and Identify All Software Specific Causal
Factors
ð Execute Detail Design Trade Study
SAFETY REQUIREMENTS CRITERIA ANALYSIS (SRCA)
Derive System-Specific Software Safety-Critical Requirements
SUBSYSTEM (SSHA) & SYSTEM (SHA) HAZARD ANALYSIS
Tracing Safety-Critical Requirements to Test
ð Tag Safety-Critical Software Requirements
ð Establish Methods for Tracing Software Safety Requirements to Test
ð Provide Evidence for Each Functional Hazard Mitigated by Comparing to Requirements
ð Implement Software Safety Requirements into Design and Code
ð Provide Evidence of Each Functional Hazard Mitigated by Comparing to Design
ð Verify Safety Requirement Implementation Through Test
ð Execute Residual Risk Assessment
ð Verify Software Developed in Accordance with Applicable Standards and Criteria
SOFTWARE SAFETY ASSESSMENT REPORT (SAR)
Software Requirements Derivation for
Safety-Critical Software Systems
Figure 10-5: Software Safety Requirements Derivation
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-12
Preliminary Software Safety Requirements
The first “cut” at system-specific software safety requirements are derived from the PHA analyses performed
in the early life cycle phase of the development program. As previously discussed, the PHL/PHA hazards
are a product of the information reviewed pertaining to systems specifications, lessons learned, analyses from
similar systems, common sense, and preliminary design activities. Hazards that are identified during the
PHA phase are analyzed and preliminary design considerations are identified to design engineering to
mitigate the risk. These design considerations represent the preliminary safety requirements of the system,
subsystems, and their interfaces (if known). These preliminary requirements must be accurately defined in
the hazard record database for extraction when reporting of requirements to the design engineering team.
Matured Software Safety Requirements
As the system and subsystem design mature, the requirements unique to each subsystem also matures via the
Subsystem Hazard Analysis (SSHA). The safety engineer, during this life cycle phase of the program,
attends the necessary design reviews and spends many hours with the subsystem designers for the purpose of
accurately defining the subsystem hazards. Hazards/risks identified are documented in the hazard database
and the hazard “causes” (hardware, software, human error, and software-influenced human error) identified
and analyzed. When fault trees are used as the functional hazard analysis methodology, the contributors
leading to the risk determine the derived safety-critical functional requirements. It is at this point in the
design that preliminary design considerations are either formalized and defined into specific requirements, or
eliminated if they no longer apply with the current design concepts. The maturation of safety requirements is
accomplished by analyzing the design architecture to connect the risk to the contributors. The causal factors
are analyzed to the lowest level necessary for ease of mitigation. The lower into the design the analysis
progresses, the more simplistic (usually) and cost effective the mitigation requirements tend to become. The
PHA phase of the program should define causes to at least the Computer Software Configuration Item
(CSCI) level, whereas the SSHA and System Hazard Analysis (SHA) phases of safety analyses should
analyze the causes to the algorithm level where appropriate.
10.3.4 Design and Analyses
The identification of subsystem and system hazards and failure modes inherent in the system under
developed is essential to the success of a credible software safety program. The primary method of reducing
the safety risk of software performing safety-significant functions is to first identify the system hazards and
failure modes, and then determine which hazards and failure modes are caused by or influenced by software
or lack of software. This determination includes scenarios where information produced by software could
potentially influence the operator into a wrong decision resulting in a hazardous condition (design-induced
human error). Moving from hazards to software contributors (and consequently design requirements to
either eliminate or control the risk) is very practical, logical, and adds utility to the software development
process. It can also be performed in a timelier manner as much of the analysis is accomplished to influence
preliminary design activities.
The specifics of how to perform either a subsystem or system hazard analysis are briefly described in
Chapters 8 and 9. The fundamental basis and foundation of a system safety (or software safety) program is a
systematic and complete hazard analysis process.
One of the most helpful steps within a credible software safety program is to categorize the specific causes of
the hazards and software inputs in each of the analyses (PHA, SSHA, SHA, and Operating & Support Hazard
Analysis (O&SHA)). Hazard causes can be identified as those caused by; hardware, and/or hardware
components; software inputs or lack of software input; human error; and/or software influenced human error
or hardware or human errors propagating through the software. Hazards may result from one specific cause
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-13
or any combination of causes. As an example, “loss of thrust” on an aircraft may have causal factors in any
of the four below listed categories.
· Hardware: foreign object ingestion,
· Software: software commands engine shutdown in the wrong operational scenario,
· Human error: pilot inadvertently commands engine shutdown, and,
· Software influence pilot error: computer provides incorrect information, insufficient or
incomplete data to the pilot causing the pilot to execute a shutdown.
The safety engineer must identify and define the hazard control considerations (PHA phase) and
requirements (SSHA, SHA, and O&SHA phases) for the design and development engineers. Hardware
causes are communicated to the appropriate hardware design engineers; and software related causes to the
software development and design team. All requirements should be reported to the systems engineering
group for their understanding and necessary tracking and/or disposition.
The preliminary software design SSHA begins upon the identification of the software subsystem and uses the
derived system specific safety-critical software requirements. The purpose is to analyze the system, software
architecture and preliminary CSCI design. At this point, all generic and functional Software Safety
Requirements (SSRs) should have been identified and it is time to begin allocating them to the identified
safety-critical functions and tracing them to the design.
The allocation of the SSRs to the identified hazards can be accomplished through the development of SSR
verification trees that links safety critical and safety significant SSRs to each Safety-Critical Function (SCF).
The SCFs in turn are already identified and linked to each hazard. By verifying the nodes through analysis,
(code/interface, logic, functional flow, algorithm and timing analysis) and/or testing (identification of
specific test procedures to verify the requirement), the Software Safety Engineer (SwSE) is essentially
verifying that the design requirements have been implemented successfully. The choice of analysis and/or
testing to verify the SSRs is up to the individual Safety Engineer whose decision is based on the criticality of
the requirement to the overall safety of the system and the nature of the SSR. Whenever possible, the Safety
Engineer should use testing for verification.
Numerous methods and analytical techniques are available to plan, identify, trace and track safety-critical
CSCIs and Computer Software Units (CSUs). Guidance material is available from the Institute of Electrical
and Electronic Engineering (IEEE) (Standard for Software Safety Plans), the Department of Defense (DOD)
Defense Standard 00-55-Annex B, DOD-STD-2167, NASA-STD-2100.91, MIL-STD-1629, the JSSSC
Software System Safety Handbook and DO-178B.
10.3.5 Testing
Two sets of analyses should be performed during the testing phase:
· Analyses before the fact to ensure validity of tests
· Analyses of the test results
Tests are devised to verify all safety requirements where testing has been selected as appropriate verification
method. This is not considered here as analysis. Analysis before the fact should, as a minimum, consider
test coverage for safety critical Must-Work-Functions.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-14
Test Coverage
For small pieces of code it is sometimes possible to achieve 100% test coverage (i.e., to exercise every
possible state and path of the code). However, it is often not possible to achieve 100 % test coverage due to
the enormous number of permutations of states in a computer program execution, versus the time it would
take to exercise all those possible states. Also there is often a large indeterminate number of environmental
variables, too many to completely simulate.
Some analysis is advisable to assess the optimum test coverage as part of the test planning process. There is
a body of theory that attempts to calculate the probability that a system with a certain failure probability will
pass a given number of tests.
“White box” testing can be performed at the modular level. Statistical methods such as Monte Carlo
simulations can be useful in planning "worst case" credible scenarios to be tested.
Test Results Analysis
Test results are analyzed to verify that all safety requirements have been satisfied. The analysis also verifies
that all identified risks have been either eliminated or controlled to an acceptable level of risk. The results of
the test safety analysis are provided to the ongoing system safety analysis activity.
All test discrepancies of safety critical software should be evaluated and corrected in an appropriate manner.
Independent Verification and Validation (IV&V)
For high value systems with high risk software, an IV&V organization is usually involved to oversee the
software development. The IV&V organization should fully participate as an independent group in the
validation of test analysis.
10.4 System Safety Assessment Report (SSAR)
The System Safety Assessment Report (SSAR) is generally a CDRL item for the safety analysis performed
on a given system. The purpose of the report is to provide management an overall assessment of the risk
associated with the system including the software executing within the system context of an operational
environment. This is accomplished by providing detailed analysis and testing evidence that the software
related hazards have been identified to the best of their ability and have been either eliminated or
mitigated/controlled to levels acceptable to the FAA. It is paramount that this assessment report be
developed as an encapsulation of all the analyses preformed. The SSAR shall contain a summary of the
analyses performed and their results, the tests conducted and their results, and the compliance assessment.
Paragraphs within the SAR need to encompass the following items:
· The safety criteria and methodology used to classify and rank software related hazards
(causal factors). This includes any assumptions made from which the criteria and
methodologies were derived,
· The results of the analyses and testing performed,
· The hazards that have an identified residual risk and the assessment of that risk,
· The list of significant hazards and the specific safety recommendations or precautions
required to reduce their safety risk; and
· A discussion of the engineering decisions made that affect the residual risk at a system
level.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-15
The final section of the SSAR should be a statement by the program safety lead engineer describing the
overall risk associated with the software in the system context and their acceptance of that risk.
页:
[1]