View
14
Download
0
Category
Tags:
Preview:
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
8/7/2002 Safeware Engineering Corporation 1
SpecTRM and SafetySpecTRM and Safety
Jeffrey Howard
Patrick Anderson
8/7/2002 Safeware Engineering Corporation
2
Safety and RequirementsSafety 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
8/7/2002 Safeware Engineering Corporation
3
Safety ProcessSafety 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
8/7/2002 Safeware Engineering Corporation
4
Intent SpecificationsIntent 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
8/7/2002 Safeware Engineering Corporation
5
Intent Specification StructureIntent Specification Structure
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
8/7/2002 Safeware Engineering Corporation
6
SpecTRM-RL ModelingSpecTRM-RL Modeling
Intent Specifications include blackbox models of software behavior
Models are executable and analyzable
8/7/2002 Safeware Engineering Corporation
7
SpecTRM-RL Modeling (2)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
8/7/2002 Safeware Engineering Corporation
8
SpecTRM Tool CapabilitiesSpecTRM 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
8/7/2002 Safeware Engineering Corporation
9
EditingEditing
SpecTRM’s editing environment– Is easy to use– Contains templates for SpecTRM-RL
model elements– Facilitates editing of AND/OR tables
8/7/2002 Safeware Engineering Corporation
10
Editing DemonstrationEditing Demonstration
SpecTRM combines common word processing features with customization for writing specifications and building models
8/7/2002 Safeware Engineering Corporation
11
Editing Demonstration (2)Editing Demonstration (2)
SpecTRM facilitates model building with model element templates and AND/OR table editing commands
8/7/2002 Safeware Engineering Corporation
12
SpecTRM Tool Capabilities (2)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
8/7/2002 Safeware Engineering Corporation
13
Linking and NavigationLinking 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
8/7/2002 Safeware Engineering Corporation
14
Linking and Navigation (2)Linking and Navigation (2)
Results of following links from high-level requirements into the model.
Backward and forward buttons ease model traversal
8/7/2002 Safeware Engineering Corporation
15
Preliminary Hazard AnalysisPreliminary 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
8/7/2002 Safeware Engineering Corporation
16
System DesignSystem 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
8/7/2002 Safeware Engineering Corporation
17
SpecTRM-RL ModelsSpecTRM-RL Models
Completeness criteria are built into the design of SpecTRM-RL’s syntax
8/7/2002 Safeware Engineering Corporation
18
SpecTRM-RL OutputsSpecTRM-RL Outputs
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
8/7/2002 Safeware Engineering Corporation
19
SpecTRM-RL States and ModesSpecTRM-RL States and Modes
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
8/7/2002 Safeware Engineering Corporation
20
SpecTRM-RL InputsSpecTRM-RL Inputs
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
8/7/2002 Safeware Engineering Corporation
21
Software Hazard AnalysisSoftware 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
8/7/2002 Safeware Engineering Corporation
22
SpecTRM Tool Capabilities (3)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
8/7/2002 Safeware Engineering Corporation
23
Model ValidationModel Validation
SpecTRM’s validator automatically checks models
Errors, such as references to nonexistent model elements, are highlighted in red
8/7/2002 Safeware Engineering Corporation
24
Model Validation (2)Model Validation (2)
Tool tips provide descriptions of errors
Easy navigation between validation errors is provided
8/7/2002 Safeware Engineering Corporation
25
SpecTRM Tool Capabilities (4)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
8/7/2002 Safeware Engineering Corporation
26
Model ExecutionModel Execution
SpecTRM executes requirements models
Adherence to safety constraints can be observed before design and code are generated
SpecTRM animates the graphical view
8/7/2002 Safeware Engineering Corporation
27
Model Execution (2)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
8/7/2002 Safeware Engineering Corporation
28
Model Execution (3)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
8/7/2002 Safeware Engineering Corporation
29
SpecTRM Tool Capabilities (5)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
8/7/2002 Safeware Engineering Corporation
30
SlicingSlicing
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
8/7/2002 Safeware Engineering Corporation
31
Slicing (2)Slicing (2)
Forward data flow slices show what parts of the model are affected by the selected element
Irrelevant elements are hidden
8/7/2002 Safeware Engineering Corporation
32
Slicing (3)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
8/7/2002 Safeware Engineering Corporation
33
Slicing (4)Slicing (4)
Many accidents stem from inadequate requirements for off-nominal processing
Scenario slicing facilitates review of model behavior in off-nominal modes
8/7/2002 Safeware Engineering Corporation
34
SpecTRM Tool Capabilities (6)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
8/7/2002 Safeware Engineering Corporation
35
RobustnessRobustness
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
8/7/2002 Safeware Engineering Corporation
36
NondeterminismNondeterminism
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
8/7/2002 Safeware Engineering Corporation
37
SpecTRM BenefitsSpecTRM 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
8/7/2002 Safeware Engineering Corporation
38
DiscussionDiscussion
8/7/2002 Safeware Engineering Corporation
39
The EndThe End
Recommended