Safety Software QA at BNL’s Collider-Accelerator Department (C-AD)

Accelerator Safety Workshop

E. Lessard

Collider-Accelerator Department

August 12-14, 2008

2

BNL Software Management Flow Chart

3

Current BNL Requirements for Safety Software Designated QA Level A1/A2

Obtain written requests and approvals for all new and enhanced software development and keep requests on file

Isolate the development environment from the production environment (e.g., separate physical device, production system offline, production system with safeguards)

Document and review all development/modifications to the source program Document and track all problems and resolutions Ensure that source revision control procedures are in place Ensure that a disaster recovery plan is in place If a "User's Manual" is required, control the manual If training is required on the software, determine training qualifications and

implement training

4

Current BNL Requirements for QA Level A1/A2 Verification

Record and file a test plan that documents input, expected results, and actual results

One or more qualified persons (other than the developer if possible) execute the test plan to prove the software satisfies system specifications

Obtain written approval before software is moved into production

5

Current BNL Requirements Safety Software Designated QA Level A3

Document all development/modifications to the source program

Ensure that source revision control procedures are in place

Ensure that a disaster recovery plan is in place If a "User's Manual" is required, control the manual If training is required on the software, determine training

qualifications and implement training

6

Current BNL Requirements for QA Level A3 Verification

Test the software to prove it satisfies system specifications

Obtain approval before software is moved into production

7

BNL / DOE G 414.1C Software QA Levels

DOE G 414.1C Level A (BNL ESS&H Category A1 - Critical) This grading level includes safety software applications that meet one or more of the following criteria: Software failure that could compromise a limiting condition for operation Software failure that could cause a reduction in the safety margin for a

safety systems, structures or components (SSC) that is cited in DOE approved documented safety analysis

Software failure that could cause a reduction in the safety margin for other systems such as toxic or chemical protection systems that are cited in either (a) a DOE approved documented safety analysis or (b) an approved hazard analysis per DOE P 450.1 and the DEAR ISMS clause

Software failure that could result in nonconservative safety analysis, design, or misclassification of facilities or SSCs

8

BNL / DOE G 414.1C Software QA Levels

DOE G 414.1C Level B (BNL ESS&H Category A2 - Major) This grading level includes safety software applications that do not meet Level A criteria but meet one or more of the following criteria: Safety management databases used to aid in decision

making whose failure could impact safety SSC operation Software failure that could result in incorrect analysis,

design, monitoring, alarming, or recording of hazardous exposures to workers or the public

Software failure that could comprise the defense in depth capability for the nuclear facility

9

BNL / DOE G 414.1C Software QA Levels

DOE 414.1C Level C (BNL ESS&H Category A3 - Minor) This grading level includes software applications that do not meet Level B criteria but meet one or more of the following criteria: Software failure that could cause a potential violation of

regulatory permitting requirements Software failure that could affect environment, safety,

health monitoring or alarming systems Software failure that could affect the safe operation of an

SSC

10

Excerpt From DOE G 414.1C

Problem!

11

C-AD Safety Software QA Levels (BNL Plans to Use)

12

C-AD Safety Software QA Levels

Brief Description Of The Software’s Function QA Level (A1, A2 or A3)

MicroShield – shielding calculations 1 A3

MCNPX – calculations for shielding, beam loss energy deposition, etc… 2

A3

Radioactive Waste Calculation – Calculations for isotopic activity content of radioactive waste from high energy accelerator

A3

Particle Accelerator Safety System (PASS) – Controls access, detects radiation levels outside shielded areas and detects oxygen deficiency hazard (ODH) conditions

A1

Beam Loss Accounting Manager (BLAM) A3

Key Tree & Card Reader Firmware 1 A3

1. COTS – Commercial Off The Shelf2. Software code is maintained at LANL3. BLAM is used to help maintain compliance with RHIC Operational Safety Limits (OSL). These limits define

an acceptable level of radiation at the berm if beam were to be lost at a single RHIC Controlled Area location. The limits are specified by the Radiation Safety Committee.

13

New BNL Software Control Requirements Under Development

Requirements taken from Department of Energy Quality Managers Software Quality Assurance SubcommitteeReference Document SQAS21.01.00 – 1999:1. Project management2. Project risk management3. Software requirements4. Software hazard analysis5. Training on design and development6. Design and coding7. Validating and verifying software8. Configuration management and problem reporting9. User training

Cyber Security risks and controls are also addressed in new requirements

14

New BNL Requirements Under Development

15

Example Details of New BNL Requirements

16

Summary

Develop lab-wide safety software requirements as a function of QA level

Determine QA level Do not adopt nuclear facility software QA levels if not

applicable Develop software QA levels for accelerator facilities

based on ESSH risk

Use graded approach to meet software requirements Walk down interpretation of “graded” requirements

with management to assure concurrence