Software Engineering for Safety : A Roadmap

1
Software Engineering for Safety A Roadmap

• By Robyn R.Lutz
• Presentation by Jeongwon Yoon.

2
Agenda

• Introduction
• Six key areas for safety
• Six directions for future work.
• Conclusion
• Evaluation

3
I. Introduction

• Wider use of safety-critical systems
• - from nuclear defense applications to
  medical services, traffic control.
• The Nation depends on fragile software
• - needs of software engineering of
  safety-critical systems

4
II. Six key areas

• Hazard analysis
• Safety requirements specification analysis
• Designing for safety
• Testing
• Certification and standards
• Resources

5
1. Hazard Analysis

• Core of the development of safe systems.
• Two methods
• - Identify and analyze hazard
• - Investigate which s/w components
  contribute or prevent hazard
• Derive safety requirements constraints
• on design of system.
• Help prioritize requirements to focus
• vulnerable features.

6
2. Req. specification Analysis.

• Formal specification
• - make development easier more accurate
• - allow formal analysis
• investigate if safety properties are
  preserved
• ex) model checker, interactive theorem
  prover
• Translating system safety req.-gtsoftware req.
• - problem mismatches between them.
• - SpecTRM

7
3. Designing for safety

• Design includes
• - prevent hazard ex) hardware lockout,
  interlock..
• - detect control hazard ex) fail-safe
  design, self-test..
• Three obstacles in design
• - Design tradeoffs
• between safety and other desirable
  attributes
• - Vulnerability to simple design errors
• - Limited use of known design techniques

8
4. Testing

• Role
• - verify fault-tolerance aspects
• - check whether software responds appropriately
• - test cases focusing on boundary, anomalous
  condition
• Correct assumptions about
• environment, users, operations.
• Measuring and modeling software reliability

9
5. Certification Standards

• Certification needs criteria for assess
• - more complicated, less well-defined
• Standards
• - issue what standards are appropriate for
  large, safety-critical systems composed of
  subsystems from different domains?
• - Problems lack of guidance, poor
  integration
• - Recommendation
• Classifying and evaluating standards
• Constructing domain specific standards

10
III. Six direction for future

• Further integration of informal formal methods
• Constraints on safe reuse safe product families
• Testing and evaluation of safety-critical systems
• Runtime monitoring
• Education
• Collaboration with related fields

11
1. Integration of informal formal methods

• Three working area
• Automatic translation of informal notations into
  formal models
• - integrating graphical tool, visual
  programming environment..
• Lightweight formal method
• Integration of previously distinct formal
  methods.
• - to have flexibility to choose the
  best-suited method

12
2. Constraints on safe reuse safe product
families

• Two research area
• Safety analysis of product families
• - need to know extent to which systems with
  similar requirements
• can reuse requirements analysis
• Safe reuse of COTS software
• - confirm that software does what it should
• - confirm that there arent unexpected behaviors.

13
3. Testing evaluation

• Four challenges
• Requirement-based testing
• - Integration of testing tool with
  requirements analysis tool
• - improved test-case generation for
  safety-related scenarios.
• - better support evolutionary development
• Evaluation from multiple sources
• - how to structure combine information
• - include field studies of deployed system
• Model consistency
• - mismatches between actual expected
  behavior
• Virtual environments

14
4. Runtime Monitoring

• Monitoring
• - Enhance the safety by detecting recovering
  from hazardous states.
• Role
• - Detection of known faults
• tradeoff between safety and complexity
• - Detection of unexpected faults
• - Monitoring to profile usage
• enhance safety analysis by identifying
  evolving hazardous
• conditions, deviations from requirements

15
Education Collaboration

• 5. Education
• - For graduate more scientific issues
• - For undergraduate textbook, case-based
  learning
• 6. Collaboration with related fields
• - Security and survivability
• - Software architecture
• - Theoretical computer science
• - Human factors engineering
• - etc..

16
Conclusion

• SE for safety Demands
• Advances in related fields
• Better integration of safety techniques with
  industrial development environments.

17
Evaluation

• Strength
• - Clear explanation
• - Appropriate example to help understanding
• Weakness
• - Too theoretical approach
• - Too many quotation and attempt to cover
  several area degrade papers coherence.
• Relevant to embedded system
• - safety is essential factor of embedded
  systems.

18
Question?