1 / 39

SpecTRM and Safety

SpecTRM and Safety. Jeffrey Howard Patrick Anderson. 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

buffy-floyd
Télécharger la présentation

SpecTRM and Safety

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. 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

More Related