SpecTRM and Safety

1. SpecTRM and Safety Jeffrey Howard Patrick Anderson Safeware Engineering Corporation

2. Safety and Requirements • Software-related accidents are usually caused by flawed requirements • Incomplete or wrong assumptions about the controlled system or required operation • Unhandled controlled-system states and environmental conditions • “Correct” (in the sense that the software meets the requirements) or “reliable” software will not necessarily be safe Safeware Engineering Corporation

3. Safety Process • Safety-Driven process must encompass the whole lifecycle • Safety activities must be integrated into system engineering • Hazards must be tracked from identification through resolution Safeware Engineering Corporation

4. Intent Specifications • Improved form for writing specifications • Based on “why” (design rationale) as well as what and how • Design decisions at each stage map back to requirements and constraints (including safety constraints) they are derived to satisfy • Earlier decisions map to later stages of the process • Results in a record of progression of design rationale from high-level requirements to component requirements and designs • Provides traceability of safety information Safeware Engineering Corporation

5. Intent Specification Levels Program Management System Purpose System Design Principles Blackbox Behavior Design Representation Physical Representation Operations Each level has information about Environment Operator System and Components Verification and Validation Links between sections and level provide traceability Intent Specification Structure Safeware Engineering Corporation

6. SpecTRM-RL Modeling • Intent Specifications include blackbox models of software behavior • Models are executable and analyzable Safeware Engineering Corporation

7. SpecTRM-RL Modeling (2) • SpecTRM-RL is based on state machines • Each state transition has an AND/OR table • Rows represent AND • Columns represent OR • SpecTRM-RL emphasizes readability • Review is vital to ensuring properties such as safety • The model is the specification Safeware Engineering Corporation

8. SpecTRM Tool Capabilities • Editing tools tailored to specification and model development • User-friendly editor • Easy AND/OR table creation and editing • Graphical control loop view is automatically updated Safeware Engineering Corporation

9. Editing • SpecTRM’s editing environment • Is easy to use • Contains templates for SpecTRM-RL model elements • Facilitates editing of AND/OR tables Safeware Engineering Corporation

10. Editing Demonstration • SpecTRM combines common word processing features with customization for writing specifications and building models Safeware Engineering Corporation

11. Editing Demonstration (2) • SpecTRM facilitates model building with model element templates and AND/OR table editing commands Safeware Engineering Corporation

12. SpecTRM Tool Capabilities (2) • Editing tools tailored to specification and model development • Links and navigation support traceability • Map between levels of the intent specification, bridging between downstream decisions and their rationale • Track hazards throughout the project life cycle from identification to resolution Safeware Engineering Corporation

13. Linking and Navigation • Links are underlined and displayed in blue for ease of use • Arrows denote whether the link is to a level above or below in the intent specification Safeware Engineering Corporation

14. Linking and Navigation (2) • Results of following links from high-level requirements into the model. • Backward and forward buttons ease model traversal Safeware Engineering Corporation

15. Preliminary Hazard Analysis • Begins with the identification of hazards • There may not be many • Distinguish between hazards and causes • Translate system hazards into high-level system safety design constraints • Establish the hazard log Safeware Engineering Corporation

16. System Design • Preliminary hazard analysis results feed into the system design process • Links from the safety constraints point into the system design to trace decisions that eliminate or control hazards • System design information is used in System Hazard Analysis, which feeds back into the design • System design becomes the basis of the SpecTRM-RL requirements model at level 3 of the intent specification Safeware Engineering Corporation

17. SpecTRM-RL Models • Completeness criteria are built into the design of SpecTRM-RL’s syntax Safeware Engineering Corporation

18. Output definitions enforce several safety-related completeness criteria Timing behavior, including environmental capacity for handling outputs, is addressed Feedback criteria are enforced Output reversal information is included Outputs are sent when the triggering condition is true SpecTRM-RL Outputs Safeware Engineering Corporation

19. States represent the state of the controlled process as inferred by the software Modes are groupings of software behavior To enforce completeness, all states must include an “Unknown” state SpecTRM-RL States and Modes Safeware Engineering Corporation

20. Input definitions address several completeness criteria Possible value attributes define handling for nonsensical values Timing behavior specifies what to do with late or missing input Obsolete forces considering data age: no data is good forever SpecTRM-RL Inputs Safeware Engineering Corporation

21. Software Hazard Analysis • SpecTRM and SpecTRM-RL build toward software hazard analysis • Software hazard analysis is a subsystem hazard analysis technique • The goal is to • Validate that specified software blackbox behavior satisfies system safety design constraints • Check that specified software behavior satisfies general software safety design criteria Safeware Engineering Corporation

22. SpecTRM Tool Capabilities (3) • Editing tools tailored to specification and model development • Links and navigation support traceability • Automated validation to ensure well-formed blackbox models • Catches missing or malformed model elements • Reduces time for model development • Prerequisite for execution and analysis Safeware Engineering Corporation

23. Model Validation • SpecTRM’s validator automatically checks models • Errors, such as references to nonexistent model elements, are highlighted in red Safeware Engineering Corporation

24. Model Validation (2) • Tool tips provide descriptions of errors • Easy navigation between validation errors is provided Safeware Engineering Corporation

25. SpecTRM Tool Capabilities (4) • Editing tools tailored to specification and model development • Links and navigation support traceability • Automated validation to ensure well-formed blackbox models • Execution of models • Evaluating software before design and code greatly reduces the cost of correcting requirements errors • Enforcement of safety constraints can be verified early • Execution animates the control loop view of the model Safeware Engineering Corporation

26. Model Execution • SpecTRM executes requirements models • Adherence to safety constraints can be observed before design and code are generated • SpecTRM animates the graphical view Safeware Engineering Corporation

27. Model Execution (2) • Input and output message values are displayed in blue • States and modes are lit up in yellow • The graphical view is animated as the simulation progresses Safeware Engineering Corporation

28. Model Execution (3) • Using the simulator control panel, it is possible to pause the simulator and advance in single steps • Input is provided by text files and other values may be logged to text files Safeware Engineering Corporation

29. SpecTRM Tool Capabilities (5) • Editing tools tailored to specification and model development • Links and navigation support traceability • Automated validation to ensure well-formed blackbox models • Execution of models • Slicing of models assists reviewers • Data flow slices show what elements affect each other • Scenario slices show how software operates under a given set of circumstances Safeware Engineering Corporation

30. Slicing • Slicing abstracts irrelevant detail from the model • Important properties, such as safety-related behavior, are made to stand out to reviewers • SpecTRM has three slicing operations • Forward data flow slicing • Backward data flow slicing • Scenario slicing Safeware Engineering Corporation

31. Slicing (2) • Forward data flow slices show what parts of the model are affected by the selected element • Irrelevant elements are hidden Safeware Engineering Corporation

32. Slicing (3) • Backward data flow slices show what parts of the model can affect a selected element, such as a safety-critical output • Color highlighting can be used for the slice result set Safeware Engineering Corporation

33. Slicing (4) • Many accidents stem from inadequate requirements for off-nominal processing • Scenario slicing facilitates review of model behavior in off-nominal modes Safeware Engineering Corporation

34. SpecTRM Tool Capabilities (6) • Editing tools tailored to specification and model development • Links and navigation support traceability • Automated validation to ensure well-formed blackbox models • Execution of models • Slicing of models assists reviewers • Specification completeness criteria enforcement • Professor Leveson developed a set of ~60 criteria for specification completeness (validated by Lutz at JPL) • Many are enforced by SpecTRM-RL syntax • SpecTRM enforces others with automated analyses • Robustness analysis searches transitions for unhandled cases • Nondeterminism analysis searches for multiple transition cases Safeware Engineering Corporation

35. Robustness is one of Professor Leveson’s completeness criteria Informally, a state or mode is robust if, for all scenarios, at least one AND/OR table is true SpecTRM offers an automated robustness analysis Robustness Safeware Engineering Corporation

36. Another completeness criteria SpecTRM automates No more than one AND/OR table can be true at one time In practice behavior is implementation dependent It is difficult to assure the safety of such a system Nondeterminism Safeware Engineering Corporation

37. SpecTRM Benefits • Finding specification errors early in development so they can be fixed with the lowest cost and impact on the system design • Tracing not only requirements but also design rationale and safety constraints throughout the system design and documentation • Building safety and other required system properties into the design from the beginning, rather than emphasizing assessment at the end of the development process Safeware Engineering Corporation

38. Discussion Safeware Engineering Corporation

39. The End Safeware Engineering Corporation