Engineering SafetyRelated Software

1
Engineering Safety-Related Software

• Bob Quirk
• Defense Nuclear Facilities Safety Board
• The views expressed are those of the author. No
  official support or endorsement of this work by
  the Defense Nuclear Facilities Safety Board is
  intended or should be inferred.

2
Topics

• Background
• Board Actions
• Observations
• Standards Guidance
• Key Processes
• Future Evolutions
• Conclusions

3
Background

• Software is used by DOE and its contractors to
  analyze hazards, to design effective controls,
  and for automatic control of safety systems
• As a result, the safety posture of many
  facilities is strongly dependent on the quality
  of this underlying body of analysis, design, and
  control software

4
What is Different about Software

• Other engineering projects are governed by laws
  of physics and material properties, but software
  engineers work with abstract materials with no
  natural limits
• Software errors can be hard to find implying a
  need for a rigorous, well documented process,
  particularly for development of safety-related
  software

5
MAJOR BOARD ACTIONS

• In January 2000, DNFSB/TECH-25 identified
  numerous deficiencies in safety-related software
  at DOE the Board asked for a corrective action
  plan (CAP)
• On October 3, 2000, the Board received the CAP
  but found it was not responsive to the Boards
  concerns
• On September 23, 2002, the Board issued
  Recommendation 2002-1, Quality Assurance for
  Safety-Related Software

6
Ongoing Efforts by the Board

• The Board held three public meetings on QA with
  SQA as a special interest item
• The staff has reviewed directives and guidance
  from other agencies as well as industry consensus
  standards and visited the NASA Independent
  Verification and Validation Center
• The staff completed several on-site reviews of
  SQA activities at Y-12, SNL, Hanford, Pantex,
  LANL, and SRS
• Followup process implementation reviews are in
  progress

7
Key Observations

• Expectations for SQA in DOE directives and
  guidance are not clearly set
• Responsibility and authority for SQA functions
  within DOE are not adequately defined, nor is
  there an effective champion

8
Key Observations (cont.)

• There is no formal DOE training program for SQA
• Contractor implementing procedures do not have
  sufficient detail to define a process which will
  ensure quality software products

9
BUT .

• Accidents are typically the result of the complex
  interaction of Product/Process/People/Resources
• All must be balanced to ensure safety
• Process alone is not the answer

10
Non-Nuclear Software Safety Standards

• IEEE IEEE STD 1228-1994, Standard for Software
  Safety Plans
• NASA NASA-STD-8719.13A, Software Safety and NASA
  NASA-GB-8719.13, Guidebook for safety-critical
  systems
• DoD MIL-STD-882D, Standard Practice for System
  Safety
• U.K. Ministry of Defense DEF STAN 00-55,
  Requirements for safety-related software
• Joint Services Software Safety Committee, G-48
  Committee, Software System Safety Handbook
• NATO Standardization Agreement, STANAG 4404
  Safety design requirements and guidelines for
  computing systems
• IECIEC 601-1-4, Medical Electric Equipment
  Part 1 General Requirements for Safety 4.
  Collateral Standard Programmable Electrical
  Medical Systems

11
Nuclear Industry Software Safety Standards

• IEEE STD 7-4.3.2-1993
• NQA-1 NQA-2 Subpart 2.7
• NRC Reg Guides, BTPs, NUREGs
• ANSI/ANS 10.4 8.1
• IEC 608801986-09
• CE-1001-STD Rev.1
• IAEA-TECDOC-1066
• IAEA Safety Guide NS-G-1.1

12
General Software Engineering Standards
13
Software Safety Process

• Acceptance Test
• System Test
• Integration Test
• Unit Test

• Concept of Ops
• Software Requirements Specification
• Hi-Level Design
• Low-Level Design

Safety Assessment Occurs in All Phases
14
Tailoring the Software Safety Effort

• Identify safety critical software
• Determine how critical the software is
  (classification)
• Determine the extent of the development effort
  and oversight required 

15
Software Requirements Phase
16
Architectural or Preliminary Design
17
Detailed Design
18
Software Implementation
19
Software Integration and Test
20
Software Maintenance
Same Activities as in Development
21
Future Evolutions

• ANSI/ANS 10.4 Revisions
• NQA-1 Revisions
• Federal Working Group Meeting on SQA for
  safety-related software
• Oversee execution of the Implementation Plan for
  DNFSB Recommendation 2002-1

22
Questions