1. Safety Software QA at BNL’s Collider-Accelerator Department (C-AD) Accelerator Safety Workshop E. Lessard Collider-Accelerator Department August 12-14, 2008

2. 2 BNL Software Management Flow Chart

3. 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. 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. 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. 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. 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. 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. 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. 10 Excerpt From DOE G 414.1C Problem!

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

12. 12 C-AD Safety Software QA Levels Brief Description Of The Software’s FunctionQA 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 Shelf 2.Software code is maintained at LANL 3. 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. 13 New BNL Software Control Requirements Under Development  Requirements taken from Department of Energy Quality Managers Software Quality Assurance Subcommittee Reference Document SQAS21.01.00 – 1999: 1. Project management 2. Project risk management 3. Software requirements 4. Software hazard analysis 5. Training on design and development 6. Design and coding 7. Validating and verifying software 8. Configuration management and problem reporting 9. User training  Cyber Security risks and controls are also addressed in new requirements

14. 14 New BNL Requirements Under Development

15. 15 Example Details of New BNL Requirements

16. 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