Week6b

Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems: 

Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems Presenter: Raffi P. Tikidjian Date: Tuesday, September 26, 2006

Presentation Outline: 

Presentation Outline Summary of the paper Introduction Methodology Analysis of Safety-Related Software Errors Recommendations Strengths of the approach Weaknesses of the approach Relevance to embedded software F-18 ISHM Experiment

Introduction: 

Introduction This paper examines (387) software errors uncovered during integration and system testing of two spacecraft: Voyager Galileo Failure classifications Negligible Significant Catastrophic Purpose of the paper Identify the extent and ways in which the cause/effect relationships differ in safety-related vs. non-safety-related software. Goal of the paper “Improve system safety by understanding and, where possible, removing, the prevalent sources of safety-related software errors.”

Introduction – Cont.: 

Introduction – Cont. Spacecraft software is safety critical Monitors and controls components that can involve in hazardous system behavior. Complexities of the spacecraft systems Highly interactive message-passing among components Timing issues among parts of the system Real-time monitoring of hardware and environment Distributed embedded software on several different flight computers Lines of Source Code Voyager: 18,000 Galileo: 22,000 Potentially significant or catastrophic effects classified as safety-related Voyager: 87 software errors Galileo: 122 software errors

Methodology: 

Methodology Classification scheme that analyzes three points in the path from a software error backwards to its sources. Allows classification of: Documented software error (program fault) Human error (the root cause) Process flaws (likelihood of the error’s occurrence) Leads backwards in time from the evident software error to an analysis of the root cause, to an analysis of the software development process.

Methodology – Cont.: 

Methodology – Cont. Program Faults (Documented Software Errors) Internal Faults Syntax Interface Faults Interactions with other system components Transfer of data or control Functional Faults Operational Omission or unnecessary operations Conditional Incorrect condition or limit values Behavioral Incorrect behavior, not conforming to requirements

Methodology – Cont.: 

Methodology – Cont. Human Errors (Root Causes) Coding or Editing Errors Communication Errors Within a Team Communication Errors Between Teams Errors in Recognizing Requirements Errors in Deploying Requirements Problems implementing or translating requirements into design

Methodology: 

Methodology Process Flaws (Flaws in Control of System Complexity + Inadequacies in Communication or Development Methods) Inadequate Code Inspection and Testing Methods Inadequate Interface Specifications + Inadequate Communication (among S/W developers) Inadequate Interface Specifications + Inadequate Communication (between S/W and H/W developers) Requirements Not Identified or Understood + Incomplete Documentation Requirements Not Identified or Understood + Inadequate Design

Analysis - Program Faults: 

Analysis - Program Faults Safety-related software errors discovered during integration and system testing Voyager: 58% Galileo: 48% Functional Faults Most common Behavioral Faults Voyager: 52% of functional faults Galileo: 47% of functional faults Often failure associated with not performing adequate checks on data input Conditional Faults 73% are safety-related Nearly always an erroneous value on a condition or limit Correct values for data used in control decisions is of high-importance Interface Faults Voyager: 36% of safety-related faults Galileo: 19% of safety-related faults

Analysis - Program Faults and Root Causes: 

Analysis - Program Faults and Root Causes Trace backwards to the human factors involved in the program faults. Interface Faults (Safety-Related) Primary cause is misunderstood hardware interface specifications Voyager: 67% Galileo: 48% Functional Faults (Safety-Related) Primary cause is errors in recognizing (understanding) the requirements Voyager: 62% Galileo: 79% Difficulties with requirements is the key root cause of the safety-related software errors that have persisted until integration and system testing.

Analysis – Root Causes and Process Flaws: 

Analysis – Root Causes and Process Flaws Associates a pair of process flaws with each program fault: Identifies a process flaw or inadequacy in the control of the system complexity e.g. requirements which are not discovered until system testing Identifies an associated process flaw in the communication or development methods used e.g. imprecise or unsystematic specification methods Interface Faults (Safety-related): Most common complexity-control flaw is interfaces not adequately identified or understood Voyager: 56% Galileo: 87% On Voyager, most common communication or development methods flaw is hardware behavior not documented (44%) On Galileo, most common flaws are lack of communication between H/W and S/W teams (35%) and interface specifications known but not documented or communicated (35%)

Analysis – Root Causes and Process Flaws – Cont.: 

Analysis – Root Causes and Process Flaws – Cont. Functional Faults (Safety-related): Requirements not identified and requirements not understood are the most common complexity-control flaws. Safety-related vs. Non-safety-related Faults On Galileo, incomplete documentation of requirements is an important a factor for safety-related software errors, but not for non-safety-related errors. Imprecise or unsystematic specifications are more than twice as likely to be associated with safety-related functional faults. Unknown, documented, or wrong requirements are a greater cause of safety related than of non-safety-related errors.

Recommendations: 

Recommendations Focus on interfaces between the software and the system in analyzing the problem domain Identify safety-critical hazards early in the requirement analysis. Use formal specification techniques in addition to natural-language software requirements Promote informal communication among teams As requirements evolve, communicate changes to the development and test teams Include requirements for “defensive design”

Presentation Outline: 

Presentation Outline Summary of the paper Introduction Methodology Analysis of Safety-Related Software Errors Recommendations Strengths of the approach Weaknesses of the approach Relevance to embedded software F-18 ISHM Experiment

Strengths of the approach: 

Strengths of the approach Analysis of a real-world complex embedded system example Does not assume stable requirements or that requirements specifications are correct. Tries to distinguish between causes of safety-critical and non-safety-critical software errors Classification of software faults by criticality (FMECA vs. FMEA) Tracing of software faults to root causes and process flaws

Presentation Outline: 

Presentation Outline Summary of the paper Introduction Methodology Analysis of Safety-Related Software Errors Recommendations Strengths of the approach Weaknesses of the approach Relevance to embedded software F-18 ISHM Experiment

Weaknesses of the approach: 

Weaknesses of the approach Weak argument on distinctions between safety-related vs. non-safety-related relationships Data analysis specifically focuses on System Integration and Testing only Fails to provide any detail information on how to remove potential process flaws Spacecraft examples are completely outdated Voyager launched in 1977 Galileo launched in 1989

Presentation Outline: 

Presentation Outline Summary of the paper Methodology Analysis of Safety-Related Software Errors Comparison of Results with Previous Work Recommendations Strengths of the approach Weaknesses of the approach Relevance to embedded software F-18 ISHM Experiment

Relevance to embedded software: 

Relevance to embedded software Spacecraft examples provided are complex real-time embedded systems Criticality classification is important Ability to perform risk analysis

F-18 Experiment: 

F-18 Experiment ISHM = Integrated Systems Health Management F-18 Technology Demonstrator Experiment

F-18 Experiment – Cont.: 

F-18 Experiment – Cont. Monitored the engines of a Dryden Flight Research Center F-18 aircraft, and performed onboard, unattended analysis of 26 engine sensors from engine startup to shutdown. BEAM was tested on an F-18 simulator, static engine tests, and 25 individual flights totaling approximately 60 hours of flight time. During these tests, BEAM successfully identified planned anomalies (in-flight shutdowns of one engine) as well as minor unplanned anomalies (e.g., transient oil and fuel-pressure drops), with no false alarms or suspected false-negative results for the period tested. BEAM also detected previously unknown behavior in the F-18 compressor section during several flights.

F-18 Experiment – Cont.: 

F-18 Experiment – Cont.

F-18 Experiment – Cont.: 

F-18 Experiment – Cont. Anomaly detection based solely on the sensor data, which includes but is not limited to: Sensor failure Performance degradation Incorrect operation E.g. unplanned engine shutdown or flameout Major system faults. Automatically analyzes sensor data and classifies system behavior as either nominal or anomalous Characterizes anomalies according to strength, duration, and affected signals. Can be used to monitor a wide variety of physical systems and sensor types in real time.

F18 Experiment – Cont.: 

F18 Experiment – Cont. Top-Level BEAM Architecture

References: 

References R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems. In Proceedings of the IEEE International Symposium on Requirements Engineering, 1993. Mackey, Ryan; Iverson, David, et al. Integrated System Health Management (ISHM) Technology Demonstration Project, December 2005 Mackey, Ryan; Tikidjian, Raffi, et al. Flight Tested Prototype of BEAM Software. NASA Software Tech Briefs, September 2006, Pg. 32