SpecTRM and Safety

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


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


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


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


6

SpecTRM-RL ModelingSpecTRM-RL Modeling

Intent Specifications include blackbox models of software behavior

Models are executable and analyzable


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

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


9

EditingEditing

SpecTRM’s editing environment– Is easy to use– Contains templates for SpecTRM-RL

model elements– Facilitates editing of AND/OR tables


10

Editing DemonstrationEditing Demonstration

SpecTRM combines common word processing features with customization for writing specifications and building models


11

Editing Demonstration (2)Editing Demonstration (2)

SpecTRM facilitates model building with model element templates and AND/OR table editing commands


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


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


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


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


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


17

SpecTRM-RL ModelsSpecTRM-RL Models

Completeness criteria are built into the design of SpecTRM-RL’s syntax


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


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


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


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


22



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


23

Model ValidationModel Validation

SpecTRM’s validator automatically checks models

Errors, such as references to nonexistent model elements, are highlighted in red


24

Model Validation (2)Model Validation (2)

Tool tips provide descriptions of errors

Easy navigation between validation errors is provided


25



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


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


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


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


29



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


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


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


32


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


33


Many accidents stem from inadequate requirements for off-nominal processing

Scenario slicing facilitates review of model behavior in off-nominal modes


34


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


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


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


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


38

DiscussionDiscussion


39

The EndThe End

SpecTRM and Safety

Documents

Transcript of SpecTRM and Safety