Software Engineering for safety : A Roadmap

1
Software Engineering for safety A Roadmap

• cs589 Fall 2006
• Presented By
• 
  Sagar Morabia

2
RoadMap to the presentation

• Motivation.
• 6 key areas in SE for safety.
• Key research Pointers.
• Conclusion.
• References
• Discussion

3
Motivation

• Software has become an integral part of many
  safety-critical systems.
• The nations demand for software exceeds what it
  can produce. The Nation depends on fragile
  software more work needed. PITAC
• Technologies to build reliable and secure
  software are inadequate.
• More and more safety-critical systems are built.

4
You Cant Compromise
5
RoadMap to the presentation

• Motivation.
• 6 key areas in SE for safety.
• Key research Pointers.
• Conclusion.
• References
• Discussion

6
Six key areas in SE for safety

• Hazard Analysis
• Hazard analysis is the core of the development of
  safe systems.
• System level hazards can lead to accidents.
  Hazards are identified in the terms of their
  criticality and probability of occurrence.
• Some hazards are avoidable and some are not.
• various techniques are used to determine the
  s/w components that contribute to
  existence/prevention of hazards.
• example Fault-tree analysis, FMECA, HAZOP
• Way the software is designed makes it prevent the
  system from entering the hazardous state/detects
  it/ moves it to safe state. Hence design specs
  are subsequently analyzed.
• Hazard analysis often guide the choice of which
  aspects or subsystems merit more intense scrutiny
  via formal methods.

7
Safety requirements specs and analysis.

• formal notations make all aspects of s/w
  development and testing more easier and accurate.
• It helps in ensuring that certain safety measures
  are preserved.
• It ensures automated checks whether the
  requirements are consistent and non-conflicting.
• For example recent spacecraft project.
• However, advances have been made to translate
  the system requirements to software safety
  requirements.
• Example tool SpecTRM by leveson and
  colleagues

8
Designing for safety

• A dependable system is one for which reliance may
  justifiably placed on certain aspects of QoS that
  it delivers. Dependability is thus concerned with
  the fault-tolerance.
• Safety engineering focuses on the consequences to
  be avoided. Sometimes there is no safe
  alternative to normal service in which case the
  system must be dependable to be safe.
• However, there are 3 obstacles
• 1. Design tradeoff
• usually there is a conflict between the
  safety reqs. and other desired functions of the
  system.
• 2. Vulnerability to simple design errors
• Example Mars climate orbiter was lost
  due to an use of English measurement when
• metric measurement was
  required.
• 3. Limited use of known design techniques.
• Example Aegis missile cruiser was
  crippled by entry of 0 in the data field which
  led
• led to overflow of database, crashing
  all the LAN consoles and miniature remote
  terminals.

9
Testing

• Safety requirements generated during the system
  and s/w hazard analysis are tracked into testing
  to validate that the as-built system satisfies
  them. Test can also demonstrate that the
  software responds appropriately to some
  anticipated and envisioned , abnormal situations.
• Some of the reason we need to test are
• 1. Assumptions about the environment.
• 2. Assumption about the users.
• 3. Assumption about the operations.
• However, I would not completely agree with
  the claim of the author. It has been proved by
  the work of some other researchers like
  littlewood and wright that testing is not a
  sufficient condition for a safe system and also I
  think it is next to impossible to test a
  safety-critical system and quantify it as
  dependable.

10
Certification and Standards

• Certification of the software involves assessing
  it against certain criteria (more complicated and
  less well-defined).
• There are also the list of international software
  safety initiatives with respect to standards
  provided.
• A large safety critical systems often contain
  COTS components or subsystems from different
  domains, previously certified under different
  national authorities, that now needs to be
  integrated and certified.
• Problems with current safety standards are lack
  of guidance in existing standards, poor
  integration of software issues and heavy burden
  of making a safety case for certification.
• Recommendations include evaluating according to
  the product, process and resources.

11
Resources

• Several good books are available.
• a) Safeware by Leveson
• b) Software Safety and Reliability by
  D.S.Hermann
• Website
• a) Bowens Website Safety critical systems
• b) A recent IEEE video on Developing
  Software for safety-critical systems.

12
RoadMap to the presentation

• Motivation.
• 6 key areas in SE for safety.
• Key research Pointers.
• Conclusion.
• References
• Discussion

13
Key Research Pointers

• Aid the developers of the safety critical
  systems.
• provide readier access to formal methods for
  developers of safety critical systems by further
  integration of formal and informal methods.
• Develop better methods of safety analysis for
  product families and safe reuse of COTS software.
• Improve the testing and evaluation of safety
  critical systems.
• Use of requirements based testing, evaluation
  from multiple sources, model consistency and
  virtual environments.

14
cont.

• Advance the use of runtime monitoring to detect
  faults or recover to the safe state.
• Promote collaboration with related fields in
  order to exploit advances in areas such as
  security and survivability, software
  architecture, theoretical computer science, human
  factors engineering, and software engineering
  education.

15
cont

• Education
• More Scientific University courses (likes of
  courses offered by USC) and
• Textbooks be made available
• Related Areas
• a) Safety a subset of survivability,
  security?
• b) Software Architecture.
• c) Human factors engineering.

16
RoadMap to the presentation

• Motivation.
• 6 key areas in SE for safety.
• Key research Pointers.
• Conclusion.
• References
• Discussion

17
What I conclude

• Placing too much reliance on probabilistic risk
  assessment is unwise
• Building safety into a system instead of adding
  protection devices
• Safety is a system problem
• Automate the process of safety analysis
• Tools able to evolve dynamically over time

18
RoadMap to the presentation

• Motivation.
• 6 key areas in SE for safety.
• Key research Pointers.
• Conclusion.
• References
• Discussion

19
References

• http//en.wikipedia.org/wiki/Safety_engineering
• www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallut
  z.pdf
• http//www.cs.cmu.edu/koopman/des_s99/safety_crit
  ical/
• cs589 course website

20
RoadMap to the presentation

• Motivation.
• 6 key areas in SE for safety.
• Key research Pointers.
• Conclusion.
• References
• Discussion

21
Discussion

• Thank you.