Gustave E. Bud Danielson, Jr.

1
DOE O 414.1C Regional Meeting

• Gustave E. (Bud) Danielson, Jr.
• Quality Policy Manager
• Office of Quality Assurance Programs
• Debra Sparkman,
• Software Quality Engineer
• Lawrence Livermore National Laboratory for
• Office of Quality Assurance Programs

2
Agenda

• Roles and Responsibilities
• Significant Changes to Order
• Safety Software Requirements
• Implementation Guidance
• Summary Resources
• Questions welcomed throughout presentation

3
Roles and Responsibilities
4
EH Roles and Responsibilities

• Serves the Secretary as DOEs independent element
  responsible for safety of the public, worker and
  environment
• Develops and maintains QA policy, requirements,
  guides, and standards for all DOE work
• Provides assistance to DOE contractors
• Conducts Nuclear Safety Regulation Enforcement
• Implements Safety SQA for EH work

5
Significant Changes
6
DOE O 414.1C Safety Software Changes

• Safety software established as specific category
  of software
• Scope of 10 CFR 830 and DOE O 414.1C includes
  software related to nuclear (including
  radiological) facilities
• Identification of Safety Software definitions,
  responsibilities and requirements
• Federal staff with SQA responsibilities must be
  qualified according to TQP and DOE-STD-1172

7
Safety Software Definitions

• Safety System Software Software for a nuclear
  facility that performs a safety function as part
  of a structure, system, or component and is cited
  in either (a) a DOE approved documented safety
  analysis or (b) an approved hazard analysis per
  DOE P 450.4, Safety Management System Policy,
  dated 10-15-96, and the DEAR ISMS clause 48 CFR
  970.5223-1.

8
Safety Software Definitions continued

• Safety and Hazard Analysis Software and Design
  Software Software that is used to classify,
  design, or analyze nuclear facilities.  This
  software is not part of a structure, system, or
  component (SSC) but helps to ensure the proper
  accident or hazards analysis of nuclear
  facilities or an SSC that performs a safety
  function.

9
Safety Software Definitions continued

• Safety Management and Administrative Controls
  Software Software that performs a hazard control
  function in support of nuclear facility or
  radiological safety management programs or
  technical safety requirements or other software
  that performs a control function necessary to
  provide adequate protection from nuclear facility
  or radiological hazards. This software supports
  eliminating, limiting, or mitigating nuclear
  hazards to workers, the public, or the
  environment as addressed in 10 CFR 830, 10 CFR
  835, and the DEAR ISMS clause 48 CFR
  970.5223-1.

10
The 5 Main Requirements
11
1. Federal SQA Technical Qualifications

• Must be qualified according to the Technical
  Qualification Program and DOE-STD-1172
• Review evaluate safety software plans and
  processes
• Verify safety software plans and processes are
  based upon hazard and risk analyses
• Verify that safety software is developed,
  procured, verified, validated, used and
  maintained according to nuclear safety
  requirements
• Assess monitor safety software QA programs
• Provide technical support for accident
  occurrence investigations as they relate to
  safety software

12
2. Facility Design Authority Involvement

• Safety software cannot and should not be
  separated from the safety system
• Facility Design Authority needs to be involved in
  all aspects of the safety software
• Specifications
• Acquisitions
• Design and development
• VV
• CM
• Maintenance activities
• Retirement

13
3. Safety Software Inventory

• Identify, document, and maintain the safety
  software inventory
• DSAs, TSRs and other safety documentation will
  assist in the identification
• Key attributes include a unique identifier (name
  and version or date)
• Must be available to PSOs, regulators, and any
  oversight organizations

14
3. Safety Software Inventory continued

• Focuses the application of DOE O 414.1C
  requirements to safety software
• Assists in applying engineering and financial
  resources effectively by focusing on software
  that impacts safety

15
4a. Define Grading Level

• Define grading levels
• Document in QAP or other appropriate document
• DOE reviews and approves
• DOE G 414.1-4 grading levels
• Are recommended but can use any grading level as
  noted above
• Will be used by DOE EH for their safety software

16
4b. Define Consensus Standards

• Order invokes ASME NQA-1-2000
• Implementing organization defines standards
• Document in QAP or other appropriate document
• DOE reviews and approves all standards
• Standards that provide an equivalent level of SQA
  requirements to NQA-1 may be approved
• Determination and documentation of equivalency is
  required
• Crosswalk is needed
• DOE G 414.1-4 Table 3 provides assistance

17
5. Select and Implement Work Activities

• Basic SQA practices
• Consistent with consensus standards
• Map very closely to most sites institutional SQA
  program practices
• All work activities are not applicable to every
  type of software (i.e. acquired vs. custom
  developed)

18
10 Work Activities

• Software project management and quality planning
• Software risk management
• Software configuration management
• Procurement and supplier management
• Software requirements identification and
  management
• Software design and implementation
• Software safety
• Verification and validation
• Problem reporting and corrective action
• Training of personnel in the design, development,
  use and evaluation of safety software

19
Implementation of Requirements
20
Federal Line Management Activities

• Approve QAP or other document(s) that include
  graded approach and consensus standard(s) to be
  used
• Understand basis for software included in safety
  software inventory list (DSA, TSR, etc)
• Perform oversight functions, including
  assessments/reviews of safety software

21
EH Specific Activities

• Implement SQA safety software requirements
  according to DOE G 414.1-4
• Filter Test Facility contractor
• Radiological and Environmental Sciences Lab
• Central Registry
• Safety software used to validate nuclear
  facility design or safety analysis
• Other instances of safety software use with EH

22
Identify Safety Software

• Organization applying the software is responsible
  for identifying, evaluating and designating the
  software as safety software
• Based upon the requirements in DOE O 414.1C, and
  10 CFR 830 Subparts A and B
• Application of the software determines the
  grading level

23
Define Grading Levels

• 3 grading levels recommended
• Based upon the safety softwares impact on safety
• Use of the safety software is the key
• Provides safety control
• Reliance on safety software results in making
  safety decisions
• Consider the software type (e.g., custom
  developed, configurable, acquired, utility
  calculations, and commercial design and analysis)

24
Fold in Grading

• For each of the 10 work activities, review ASME
  NQA-1-2000 sections1 associated with each work
  activity
• Identify the specific sub-activities or tasks
• Determine the impact of performing (or not
  performing) each of these sub-activities/tasks in
  producing, procuring, and/or using safety software

25
Fold in Grading continued

• Then identify the work activity as
• Needing to be fully implemented
• Has some but not all of the sub-activities
  needing to be performed
• Not applicable
• The recommended grading of the 10 work activities
  is contained in DOE G 414.1-4 Table 4 and Section
  5.2

26
Recommended Level A

• Meets one or more of the following criteria
• Could initiate a limiting condition for operation
  (LCO)
• Could cause a reduction in the safety margin
• Could result in nonconservative safety analysis,
  design, or misclassification of facilities or SSCs

27
Recommended Level B

• Does not meet Level A criteria but meets one or
  more of the following criteria
• Aids in decision making that could impact safety
  SSC operation
• Could result in incorrect analysis, design,
  monitoring, alarming, or recording of hazardous
  exposures to workers or the public
• Could comprise the defense in depth capability

28
Recommended Level C

• Does not meet Level B criteria but meets one or
  more of the following criteria
• Could cause a potential violation of regulatory
  permitting requirements
• Could affect environment, safety, health
  monitoring or alarming systems
• Could affect the safe operation of a non-safety
  SSC

29
Implementing the 10 Work Activities
30
Safety Software Work Activities

• Reminders -
• Not all work activities will be applicable to all
  software types
• Must use the best judgment of the software
  quality engineering and safety systems staffs
  when applying the graded approach

31
Work Activity 1 Software Project Mgmt Quality
Planning

• Foundation to ensure a quality software product
  and results
• Flow down from system level
• Defines and guides the processes
• Identifies how the graded approach will be
  applied
• Identifies specific tasks
• Establishes quality goals

32
Work Activity 1 Sw Project Mgmt Quality
Planning continued

• The details should include
• All tasks associated with software development
  and procurements (e.g., hw, sw, PLCs and
  services)
• Estimate duration of tasks, resources allocated,
  and any dependencies between tasks
• Description of all tasks
• Documentation should be evaluated for
• The need to be separate from the system level
  documentation
• The need to have more detail planning documents
  associated with a particular work activity (e.g.
  SCMP, SVVP

33
Work Activity 2 Software Risk Mgmt

• Proactive decision making that continually
  assesses what can go wrong
• Identifies the important risks
• Includes risks associated with
• Software development and procurement process
  (e.g., using unproven technology or supplier)
• Unsuccessful software program/project completion
  (e.g., high turnover of software staff, staff
  unfamiliar with developing safety software,
  software funding being cut)

34
Work Activity 2 Software Risk Mgmt continued

• Addresses how to avoid, mitigate or transfer
  unacceptable risks
• Monitors those risks
• Takes necessary steps to bring risks to an
  acceptable level

35
Work Activity 3 Software Configuration Mgmt

• Includes all functions and tasks to
• Identify the configuration items
• Control the items
• Establish configuration baselines
• Perform status accounting
• Perform configuration audits reviews2
• Note 2. ASME NQA-1-2000 does not include this
  sub-activity/task

36
Work Activity 4 Procurement Supplier Mgmt

• Most projects have procurements or acquired
  software
• Commercial software (e.g., safety analysis,
  facility design applications)
• Embedded software (e.g., PLCs)
• Development tools (e.g., compilers, sw design,
  test tools)
• Developed by other DOE sites
• Include technical and quality requirements
• Specifications for features, including safety,
  security, and performance/timing
• Steps used to develop and validate safety
  software
• Documentation and test results to be delivered
• Requirements for supplier notification of
  defects, new releases or other issues
• Mechanism for users to report defects and request
  assistance

37
Work Activity 4 Procurement Supplier Mgmt
continued

• Requires a variety of approaches based upon
• Level of control DOE or its contractors have on
  the quality
• Complexity of the safety software
• 4 major approaches
• Assess the supplier
• Self-declaration by the supplier
• Accepting safety software as is based upon key
  characteristics
• Supplier certification or accreditation (e.g.,
  ISO, UL, SEI CMMi)

38
Work Activity 5 Sw Rqmts Identification Mgmt

• System requirements provide the foundation for
  the sw requirements
• Requirements should be complete, correct,
  consistent, clear, verifiable, and feasible
• Include software requirements for

39
Work Activity 5 Sw Rqmts Id Mgmt continued

• Manage requirements to
• Minimize conflicts with other safety software or
  system requirements
• Maintain accuracy of requirement for later
  validation
• Trace requirement throughout the software life
  cycle

40
Work Activity 6 Sw Design Implementation

• Key sub-activities
• Developing (designing coding)
• Documenting
• Verifying (reviews, traceability, developer
  testing)
• Controlling (SCM)
• Applies primarily to custom safety software
• Design needs to be complete sufficient to meet
  software requirements
• Design needs to be adequate to fully describe
• Interfaces with other system components
• Software structure and process flow

41
Work Activity 7 Software Safety

• Sw failures WILL affect the overall safety
• 2 primary activities
• Performing safety hazard analysis of software
  throughout the life cycle
• Implementing design methods to promote safe
  operation of system
• Identify evaluate potential failures for
  consequences of failure and the probability of
  occurrence (software level hazard analysis)

42
Work Activity 7 Software Safety continued

• Evaluate software design for effectiveness in
  mitigating or eliminating the hazards identified
• Assess impact of partial sw failures that may
  degrade system performance
• Implement safety design techniques
• Simplicity
• Decoupling
• Isolation
• Redundancy
• Reduction in complexity (software and data
  inputs)
• Fault detection
• Self diagnostics

43
Work Activity 8 VV

• Largest work activity
• Verification is performed throughout the software
  life cycle
• Verifies that the requirements or conditions of
  the previous phase were fulfilled
• Did we build the widget right?
• Validation is performed at the end of software
  development or acquisition process
• Validates that the software meets the intended
  software requirements
• Did we build the right widget?

44
Work Activity 8 VV continued

• Activities include
• Reviews (e.g., software, documentation,
  procedures, users manuals)
• Inspections (e.g., Fagan, walkthroughs, desk
  checks)
• Assessments Audits (e.g., product, process,
  supplier)
• Observations
• Testing (e.g., developer, acceptance,
  installation, in-use)
• Continually monitor system to estimate software
  reliability and safety
• Evaluate defects discovered for trends
• Perform periodic testing (in-use) if possible
• Monitor operational parameters (e.g., timing,
  file and/or data size)

45
Work Activity 9 Prblm Rpting Corrective Action

• Addresses documenting, evaluating and correcting
  defects
• Defines roles and responsibilities
• For custom built sw, should be part of the
  overall software change control management
  system as described in the SCM work activity
• Integrated with system level problem reporting
  and corrective action system

46
Work Activity 10 Training

• More than training the user/operator
• Training of personnel in
• Safety software analysis
• Safety software design techniques
• Human factors/User interface design
• Testing techniques using emulators
• Commensurate with scope, complexity, and
  importance of the task
• Consider education, experience, and proficiency
  of the individual

47
In Summary
48
Important Things to Remember

• Scope of 10 CFR 830 and DOE O 414.1C includes
  software related to nuclear (including
  radiological) facilities
• Involve the facility design authority
• Maintain a safety software inventory
• In an approved DOE document, define grading
  levels consensus standards
• Select and implement the SQA work activities in
  accordance with ASME NQA-1-2000 or equivalent
  level of SQA
• If not using ASME NQA-1-2000, a crosswalk or
  other documentation must be able to show
  equivalency

49
Important Things to Remember - continued

• For Federal Staff
• Staff responsible for SQA activities must be
  qualified according to DOE Technical
  Qualification Program and DOE-STD-1172
• Staff must be knowledgeable of alternative
  standards and ASME NQA-1-2000 to approve the use
  as an alternate standard(s)

50
Resources

• EH QA Web Site
• http//www.eh.doe.gov/qa
• EH SQA Knowledge Portal
• http//www.eh.doe.gov/sqa
• EH SQA Discussion Forum
• DOE-STD-1172-2003, Safety Software Quality
  Assurance Functional Area Qualification Standard
• http//www.eh.doe.gov/techstds/standard/std1172/st
  d11722003.pdf

51
Resources continued

• QA - Bud Danielson
• 301-903-2954
• bud.danielson_at_eh.doe.gov
• SQA - Debra Sparkman
• 301-903-6888
• debra.sparkman_at_eh.doe.gov

52
(No Transcript)