Docstoc

DOE O 414.1C Regional Meeting - The Office of Health_ Safety and

Document Sample
DOE O 414.1C Regional Meeting - The Office of Health_ Safety and Powered By Docstoc
					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       1
      Agenda

Roles and Responsibilities
Significant Changes to Order
Safety Software Requirements
Implementation Guidance
Summary & Resources

Questions welcomed throughout presentation   2
  Roles and
Responsibilities



                   3
      EH Roles and Responsibilities
Serves the Secretary as DOE’s 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
                                                 4
Significant Changes




                      5
       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               6
      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]. 
                                                    7
     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.

                                                     8
        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].                                     9
The 5 Main Requirements




                          10
       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       11
       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
  V&V
  CM
  Maintenance activities
  Retirement                                     12
     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
                                              13
     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



                                           14
     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
                                            15
      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
                                                 16
     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)

                                             17
       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
                                                         18
Implementation of
  Requirements



                    19
     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
                                           20
       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


                                                        21
     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
                                           22
      Define Grading Levels

3 grading levels recommended
Based upon the safety software’s 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)                                          23
     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
                                              24
     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
                                       25
       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
                                               26
       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                                 27
       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
                                             28
Implementing the 10 Work
       Activities




                           29
       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

                                               30
      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
                                          31
       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, 
  SV&VP
                                                            32
       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)
                                                              33
     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


                                        34
              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



                                                                   35
         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 36
        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, 
                                                             37
  SEI CMMi)
      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:
§Functional            §Performance (timing)
§Security              §Safety

§User Access Control   §Design Constraints

§Installation          §Interfaces w/ other 
                                               38
considerations         systems/software
    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


                                               39
       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
                                                         40
     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)                              41
      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                                     42
      Work Activity 8 V&V

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?”                     43
         Work Activity 8 V&V
         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)

                                                                     44
     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
                                          45
     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           46
In Summary




             47
      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                                        48
      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)


                                                  49
       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/s
  td11722003.pdf
                                                 50
    Resources continued

QA - Bud Danielson 
301-903-2954
bud.danielson@eh.doe.gov
SQA - Debra Sparkman  
301-903-6888
debra.sparkman@eh.doe.gov
                            51
52

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:6/20/2013
language:Unknown
pages:52