1 / 31

Validation of Guidance Control Software Requirements Specification for Reliability and Fault-Tolerance

Validation of Guidance Control Software Requirements Specification for Reliability and Fault-Tolerance. Annual Reliability & Maintainability Symposium January 30, 2002 Frederick T. Sheldon and Hye Yeon Kim Software Engineering for Dependable Systems (SEDS) Research Laboratory

elmo
Download Presentation

Validation of Guidance Control Software Requirements Specification for Reliability and Fault-Tolerance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Validation of Guidance Control Software Requirements Specification for Reliability and Fault-Tolerance Annual Reliability & Maintainability Symposium January 30, 2002 Frederick T. Sheldon and Hye Yeon Kim Software Engineering for Dependable Systems (SEDS) Research Laboratory School of Electrical Engineering and Computer Science Washington State University

  2. Overview • Goal:Show the feasibility of this analysis approach using a industrial strength SRS to ensure: • Completeness and Consistency • Fault-tolerance • Specification Under Study • A NASA provided Guidance and Control Software (GCS) development specification for the Viking Mars Lander. • Analysis Approach • Using Zed to specify the data • Using Statecharts : Statemate for dynamical analysis • Summary and Future study

  3. Introduction • Why Requirements Specification? • Cost, Time, and Effort

  4. Reliable Specification • Is Correct • Complete, consistent and robust • Can the specification be trusted while minimizing the risk of costly errors? • How to analyze the specification to prevent the propagation of errors into the downstream activities?

  5. Consistency and Completeness • Completeness: The lack of ambiguity • Incomplete if … • … the system behavior is not specified precisely because the required behavior for some events or conditions is omitted or is subject to more than one interpretation. • Consistency • The Specification is free from conflicting requirements and undesired nondeterminism.

  6. Fault Tolerance • Faults • A fault is a feature of a system that precludes it from operating according to its specification • H. Ammar, B. Cukic, C. Fuhrman, and A. Mili, A comparative Analysis of HW and SW fault tolerance: Impact on software reliability engineering, 1999 • Fault Tolerance • The ability to respond to unexpected system failure (detection and mask/recover)

  7. Guidance and Control Software • Software Requirements – GCS Dev. Spec. • The system was designed to provide software control of the embedded sensors and actuators of the Viking Mars Lander during the terminal decent (landing) phase. • ARSP (Altimeter Radar Sensor Processing) • The ARSP module reads data provided by the altimeter radar sensor to determine the lander’s altitude from the Mars surface.

  8. Mars Lander trajectories

  9. Velocity – Altitude Contour

  10. Zed Overview • Clarifying ambiguities • Identify assumptions • Correctness checking • Mathematical proofs • Giving an in-depth understanding of the SRS

  11. Statecharts • Visual formalism: Diagrammatic in nature • Testability is provided through symbolic simulation • Predevelopment evaluation through • Fault Injection • Statemate consists of … • Activity chart • Statecharts

  12. Natural Language based SRS • Inherently ambiguous risking the possibility of multiple interpretations

  13. Zed Schema

  14. From NL to Zed • Discovered Ambiguities • The confusing definition of variable “Rotation”, and direction of the rotation. • The type assigned to the AR_COUNTER variable was unclear. • An undefined 3rd order polynomial. • Where the AR_COUNTER should be modified?

  15. Statecharts Model: Activity chart

  16. Statecharts Model: Statechart 1

  17. Statecharts Model: Statechart 2

  18. Some Theory … Set of Inputs () Unknowns () Set of Outputs Known Known Safe Unsafe Sources: Normal Operation Hardware Failures Human Intervention Models/Simulators Assumed Safe

  19. Paradigms … • Software Failures: “Software does not fail - it just does not perform as intended” Professor Nancy Leveson, MIT • Design and test for functionality: Also specify what the system should not do. . . . . . then test it!

  20. Fault Injection (added known) Some Theory… lets take a second look Set of Inputs () Unknowns () Set of Outputs Known Known Safe Unsafe Sources: Normal Operation Hardware Failures Human Intervention Models/Simulators Assumed Safe

  21. Testing and Fault Injection • By using symbolic simulation in Statemate • Boundary Testing • Input that is inside of the variable range • Input that is outside of the variable range • Fault Injection • State variable alternation • State transition redirection

  22. Variable Case 1 Case 2 Case 3 Case 4 Case 5 Input FRAME_COUNTER 2 2 1 1 3 AR_STATUS - - [0, 0, 0, 0] - [0, 1, 0, 0] AR_COUNTER -1 19900 -1 20000 -1 Output AR_STATUS KP KP [1, 0, 0, 0] [0, -, -, -] [1, 0, 1, 0] K_ALT KP KP [1, 1, 1, 1] [1, -, -, -] [0, 1, -, 1] AR_ALTITUDE KP KP [*, -, -, -] [2000,-,-,-] KP Testing Results ARSP Specification Test Input and Output

  23. Variable Case 1 Input FRAME_COUNTER 2 AR_STATUS - AR_COUNTER -1 Output AR_STATUS [1, 1, 0, 0] [1, 0, 0, 0] K_ALT [1, 1, 1, 1] [1, 1, 1, 1] AR_ALTITUDE [2000, 2000, -, -] [2000, -, -, -] Detailed Testing Results - Case 1 • Initial values • Final values • Initial variable values are being calculated based on the given equations.

  24. Fault Injection Results

  25. Variable Case 1 Input FRAME_COUNTER 2 AR_STATUS - AR_COUNTER -1 Output AR_STATUS [1/0, 1, 0, 0] [1, 0, 0, 0] K_ALT [1, 1, 1, 1] [1, 1, 1, 1] AR_ALTITUDE [*, 2000, -, -] [2000, -, -, -] Detailed Fault Injection Results • Change FRAME_COUNTER at CURRENT_STATE from 2 to 3

  26. Summary • Interpretation from NL to Zed • Clarifying ambiguities • Interpretation from Zed to Statecharts • Clarifying misinterpreted Zed specification • Iterative process • Boundary Testing, Fault Injection analysis • Reveals weak point(s) in the system • Fault Tolerance validation

  27. Conclusion • Using this combination of FMs we could: • Clarify ambiguities • Validate Correctness, Completeness, and Consistency • Validate Fault tolerance features of the SRS • This approach enabled us to: • Avoid the problems that result when incorrectly specified artifacts force corrective rework. • Minimize the risk of costly errors being propagated into downstream activities

  28. Future Study • Build concrete translation rules between the methods • Find an effective algorithm to automate the process • Validate the algorithm for the different (domain/ application specific) critical software requirements • In depth comparative study with other approaches

More Related