22
Presentation Presentation R. R. Lutz. R. R. Lutz. Analyzing Software Analyzing Software Requirements Errors in Safety- Requirements Errors in Safety- Critical Embedded Systems. Critical Embedded Systems. In In Proceedings of the Proceedings of the IEEE International IEEE International Symposium on Requirements Engineering Symposium on Requirements Engineering , , 1993. 1993. Phyllis Cheng 9/17/2002

Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

  • View
    217

  • Download
    2

Embed Size (px)

Citation preview

Page 1: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

PresentationPresentation

R. R. Lutz. R. R. Lutz. Analyzing Software Analyzing Software Requirements Errors in Safety-Critical Requirements Errors in Safety-Critical Embedded Systems.Embedded Systems. In Proceedings of the In Proceedings of the IEEE International Symposium on IEEE International Symposium on Requirements EngineeringRequirements Engineering, 1993., 1993.

Phyllis Cheng 9/17/2002

Page 2: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

GoalGoal To proof that safety-related software To proof that safety-related software

errors tend to be produced by different errors tend to be produced by different error mechanisms than non-safety-related error mechanisms than non-safety-related onesones

Then, the system safety can be directly Then, the system safety can be directly enhanced by targeting the causes of enhanced by targeting the causes of safety-related errorssafety-related errors

Finally, to reduce safety-related software Finally, to reduce safety-related software errorserrors

Page 3: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Research TargetResearch Target

2 spacecrafts: Voyager and Galileo2 spacecrafts: Voyager and Galileo reasons:reasons:

- spacecrafts’ software is safety-- spacecrafts’ software is safety-criticalcritical

- each spacecraft involves embedded - each spacecraft involves embedded software distributed on several software distributed on several different flight computersdifferent flight computers

Page 4: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

OVERVIEW OF CLASSIFICATIONOVERVIEW OF CLASSIFICATION

Program Faults Program Faults (Documented Software Errors)(Documented Software Errors)

Human Error Human Error (Root Causes)(Root Causes)

Process Flaws Process Flaws (Flaws in Control of System Complexity + (Flaws in Control of System Complexity +

Inadequacies in Communication or Development Inadequacies in Communication or Development Method)Method)

Page 5: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Relationships between Relationships between Program FaultsProgram Faults, , Root CausesRoot Causes and and Process FlawsProcess Flaws

Program Faults

Root Causes

Process Flaws

Effects

Causes

Page 6: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

PROGRAM FAULTSPROGRAM FAULTS

Internal FaultsInternal Faults: : • Syntax, Programming Language SemanticsSyntax, Programming Language Semantics

Interface Faults:Interface Faults:• Interaction with other Software ComponentsInteraction with other Software Components• Interaction with hardware in the systemInteraction with hardware in the system

Functional Faults: Functional Faults: • Operating FaultsOperating Faults• Conditional FaultsConditional Faults• Behavioral FaultsBehavioral Faults

Page 7: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

HUMAN ERRORHUMAN ERROR

Coding or Editing ErrorsCoding or Editing Errors Communication ErrorsCommunication Errors

Within a TeamWithin a Team Between TeamsBetween Teams

RequirementsRequirements Errors in RecognitionErrors in Recognition Errors in DeploymentErrors in Deployment

Page 8: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

PROCESS FLAWSPROCESS FLAWS

Flaws in Inspection and Testing MethodsFlaws in Inspection and Testing Methods Inadequate Interface-Specification & Inadequate Interface-Specification &

CommunicationCommunication• Between Software Designers and ProgrammersBetween Software Designers and Programmers• Between Software and Hardware EngineersBetween Software and Hardware Engineers

Requirements Not Identified or UnderstoodRequirements Not Identified or Understood• Incomplete DocumentationIncomplete Documentation• Missing RequirementsMissing Requirements• Inadequate DesignInadequate Design

Page 9: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Results: Program FaultsResults: Program Faults

Program FaultsProgram Faults Non-Safety-RelatedNon-Safety-Related Safety-RelatedSafety-Related

VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Internal FaultsInternal Faults 1%1% 3%3% 0%0% 2%2%Interface FaultsInterface Faults 34%34% 18%18% 36%36% 19%19%Function FaultsFunction Faults 65%65% 79%79% 64%64% 79%79% OperatingOperating 22%22% 43%43% 19%19% 44%44%

ConditionalConditional 26%26% 10%10% 31%31% 18%18%

BehavioralBehavioral 52%52% 47%47% 50%50% 38%38%

• Both errors display similar proportions of program faults

• Functional Faults are the most common kind of software error

• Almost half of the errors are attributable to behavioral faults

Page 10: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Root CausesRoot Causes causing Interface Faults causing Interface FaultsInterface FaultsInterface Faults Non-Safety-RelatedNon-Safety-Related Safety-RelatedSafety-Related

Root Causes Root Causes

(Human Errors)(Human Errors)VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Communication Within Communication Within TeamsTeams

7%7% 28%28% 7%7% 22%22%

Communication between Communication between Teams :Teams : Misunderstood H/W Misunderstood H/W Interface SpecInterface Spec

50%50% 42%42% 67%67% 48%48%

Misunderstood S/W Misunderstood S/W Interface SpecInterface Spec

43%43% 30%30% 26%26% 30%30%

• The primary cause of safety-related interface faults is Misunderstood H/W interface spec

• Communication error between development teams is the leading cause of interface faults

Page 11: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Root CausesRoot Causes causing Functional Faults causing Functional Faults

Functional FaultsFunctional Faults Non-Safety-RelatedNon-Safety-Related Safety-RelatedSafety-Related

Root Causes Root Causes

(Human Errors)(Human Errors)VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Requirement Requirement Recognition ErrorRecognition Error

47%47% 62%62% 62%62% 79%79%

Requirement Requirement Deployment ErrorDeployment Error

53%53% 38%38% 38%38% 21%21%

• The primary cause of safety-related functional faults is errors in recognizing the requirements

• Non-safety-related functional faults are more often caused by errors in deploying implementing the requirements (Problem: small scale of statistic sample!!!)

Page 12: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Process FlawsProcess Flaws causing Interface Faults causing Interface Faults

Interface FaultsInterface Faults Non-Safety-Non-Safety-RelatedRelated

Safety-RelatedSafety-Related

Process FlawsProcess Flaws VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Flaws in Control of System Flaws in Control of System Complexity:Complexity: Interfaces not adequately Interfaces not adequately identified or understoodidentified or understood

70%70% 85%85% 56%56% 87%87%

H/W behavior anomaliesH/W behavior anomalies 30%30% 15%15% 44%44% 13%13%

• The most common complexity-control flaw is interfaces not adequately identified or understood for both non-safety-related and safety-related errors

Page 13: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Process FlawsProcess Flaws causing Interface Faults causing Interface FaultsInterface FaultsInterface Faults Non-Safety-Non-Safety-

RelatedRelatedSafety-RelatedSafety-Related

Process FlawsProcess Flaws VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Flaws in Comm. Or Dev. Methods Flaws in Comm. Or Dev. Methods causing misunderstood S/W causing misunderstood S/W interfacesinterfaces Interface Spec known but not Interface Spec known but not documented or communicateddocumented or communicated

20%20% 38%38% 11%11% 35%35%

Interface design during testingInterface design during testing 26%26% 2%2% 19%19% 0%0%

Flaws in Comm. Or Dev. Methods Flaws in Comm. Or Dev. Methods causing misunderstood H/W causing misunderstood H/W interfacesinterfaces Lack of communication between Lack of communication between H/W and S/W teamsH/W and S/W teams

24%24% 28%28% 26%26% 35%35%

H/W behavior not documentedH/W behavior not documented 30%30% 32%32% 44%44% 30%30%

• (Problem: small scale of statistic sample!!!)

Page 14: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Process FlawsProcess Flaws causing Functional Faults causing Functional Faults

Functional FaultsFunctional Faults Non-Safety-Non-Safety-RelatedRelated

Safety-RelatedSafety-Related

Process FlawsProcess Flaws VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Flaws in Control of System Flaws in Control of System Complexity:Complexity:

Requirements not identified: Requirements not identified: unknown, undocumented or unknown, undocumented or wrongwrong

3737 5353 4444 6060

Requirements not understoodRequirements not understood 6363 4747 5656 4040

• Safety-related functional faults are more likely than non-safety-related functional faults to be caused by Requirements not identifiedRequirements not identified (Problem: small scale of statistic sample!!!)

Page 15: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Process FlawsProcess Flaws causing Functional Faults causing Functional FaultsFunctional FaultsFunctional Faults Non-Safety-Non-Safety-

RelatedRelatedSafety-RelatedSafety-Related

Process FlawsProcess Flaws VoyagerVoyager GalileoGalileo VoyagerVoyager GalileoGalileo

Flaws in Comm. Or Dev. Flaws in Comm. Or Dev. Methods causing errors in Methods causing errors in Recognizing RequirementsRecognizing Requirements Spec imprecise or Spec imprecise or unsystematicunsystematic

16%16% 28%28% 21%21% 38%38%

Requirements missing from Requirements missing from requirements documentsrequirements documents

31%31% 35%35% 42%42% 42%42%

Flaws in Comm. Or Dev. Flaws in Comm. Or Dev. Methods causing errors in Methods causing errors in Deploying RequirementsDeploying Requirements

53%53% 37%37% 37%37% 20%20%

• The source of safety-related software errors lie in inadequate requirements, however, the source of non-safety-related errors more commonly involve inadequacies in the design phase (Problem: small scale of statistic sample!!!)

Page 16: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Comparison of Results with Comparison of Results with Previous WorkPrevious Work

1. The role of 1. The role of Interface SpecificationsInterface Specifications in controlling software was in controlling software was underestimatedunderestimated

2. Previous reports analyzed fairly 2. Previous reports analyzed fairly simple systems in well-understood simple systems in well-understood application domainsapplication domains

Page 17: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Comparison of Results with Comparison of Results with Previous Work (contd.)Previous Work (contd.)

3. Underestimate the impact of 3. Underestimate the impact of unknown requirements on the unknown requirements on the scope and schedule of the later scope and schedule of the later stages of the S/W dev. Processstages of the S/W dev. Process

4. Distinction between causes of safety 4. Distinction between causes of safety critical and non-safety critical S/W critical and non-safety critical S/W errors was not adequately errors was not adequately investigated investigated (?)(?)

Page 18: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Recommendations (6)Recommendations (6)

1. Focus more on the interface 1. Focus more on the interface between software and the system between software and the system in analyzing the problem domainin analyzing the problem domain

2. Identify safety-critical hazards early 2. Identify safety-critical hazards early in the requirements analysisin the requirements analysis

Page 19: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Recommendations (6)Recommendations (6)

3. Use formal specifications techniques 3. Use formal specifications techniques in addition to natural-language in addition to natural-language software requirementssoftware requirements

4. Promote informal communication 4. Promote informal communication among teamsamong teams

Page 20: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Recommendations (6)Recommendations (6)

5. As requirements evolve, 5. As requirements evolve, communicate the changes to the communicate the changes to the development and test teamsdevelopment and test teams

6. Include requirements for “defensive 6. Include requirements for “defensive design”design”

Page 21: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

Later Work (1993)Later Work (1993) Safety ChecklistSafety Checklist was developed to analyze was developed to analyze

software requirements, particularly with software requirements, particularly with regard to regard to interfacesinterfaces and and robustnessrobustness

It can be used as a first step towards It can be used as a first step towards specifying and checking safety constraints specifying and checking safety constraints or as a supplement to the formal or as a supplement to the formal inspection of requirements spec.inspection of requirements spec.

Lutz, Robyn R. (1993) Targeting Safety-Related Errors During SoftLutz, Robyn R. (1993) Targeting Safety-Related Errors During Software Requirements Analysis. Technical Report TR93-11, Departmeware Requirements Analysis. Technical Report TR93-11, Department of Computer Science, Iowa State University.nt of Computer Science, Iowa State University.

Page 22: Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium

End of PresentationEnd of Presentation

Phyllis Cheng 9/17/2002Phyllis Cheng 9/17/2002