QA Requirements for DOE Accelerator Safety System Software K. Mahoney Group Leader, Safety Systems TJNAF Presented at the 2008 DOE Accelerator Safety Workshop August 13, 2008

“Musts” DOE O 414.1C ‘QA ORDER’ –Updated in 2005 to incorporate Software QA (SQA) for DOE Nuclear Facilities –Scope – Required for all DOE organizations, field elements, and contractors with two exceptions: Naval rector program Bonneville Power Administration –Requires Contractor QA Program (QAP) Part 5 of contractor requirements give requirements for “Safety Software Quality Requirements”

“Safety Software” Safety System Software. Software for a nuclear facility that performs a safety function… Safety and Hazard Analysis Software and Design Software. Software that is used to classify, design, or analyze nuclear facilities. Safety Management and Administrative Controls Software. Software that performs a hazard control function in support of a nuclear facility… necessary to provide adequate protection from nuclear facility or radiological hazards.

QA Order Contractor QAP Requirements for “Safety Software” Work processes involving safety software must be developed and implemented using national or international consensus standards and must include the following elements: a. Facility design authority involvement in the [lifecycle of a safety software application] b. Identify, document, and maintain safety software inventory.

QA Order Contractor QAP Requirements for “Safety Software” c. Establish grading levels for safety software. Document those grading levels in the QAP. d. Using the grading levels established and approved above, select and implement the applicable software QA work activities from the following list to ensure that safety software performs its intended functions.

Software QA Activities ‘Menu’ from 414.1C Contractor Requirements Project Management Risk Management Procurement and supplier management Requirements identification and management Design and Implementation Safety Verification and Validation Problem Reporting and Corrective Action Training of personnel in design, development, use, and evaluation of safety software

DOE Standards with ‘Software’ in the Title DOE-STD Safety Software Quality Assurance Functional Area Qualification Standard –Qualification of Software QA people DOE-STD Design Criteria Standard for Electronic Records Management Software Applications

Guidance DOE G “Safety Software Guide…” –Not bad in generic guidance –Does not hit the mark with respect to hazards and mitigation usign programmable systems at accelerator facilities –Written meet the needs of nuclear facilities –Tries to be non-committal but really ends up with ANSI/ASME NQA (QAPs for Nuclear Facilities) Note: this includes reactor and non-reactor facilities. –Defines levels based on 10CFR830 and by reference DOE STD 1027 “Hazard Categorization and Accident Analysis Techniques for Compliance with DOE Order , Nuclear Safety Analysis Reports”

1027 NF Hazard Category 3 DEFINITION –Hazard Analysis shows the potential for only significant localized consequences. INTERPRETATION –Facilities with quantities of hazardous radioactive materials which meet or exceed Table A.1 values [Radionuclides] 2 DEFINITION –Hazard Analysis shows the potential for significant on-site consequences. INTERPRETATION –Facilities with the potential for nuclear criticality events or with sufficient quantities of hazardous material and energy, which would require on-site emergency planning activities (see Attachment 1). 1 DEFINITION –Hazard Analysis shows the potential for significant off-site consequences. INTERPRETATION –Category A reactors and facilities designated by PSO.

Accelerator Safety Systems Multiple safety functions mitigating hazards from: –Prompt Ionizing Radiation –Radioactive Materials –RF Power –Laser –Electrical Systems –Machinery –Chemical Processing Systems What? No Nuclear?

Accelerator Safety System Software – Scope Application software program used to implement a safety function Embedded software used to execute the application software program Utility software used to code and compile the application software

Software QA QA –Process or methods to ensure desired result or outcome is implemented in an efficient manner Software –Instructions for the implementation of desired functional relation Software QA is –process or methods to ensure efficient implementation of desired functional relation –Note: inferred Safety QA requirement is complement – not to implement undesired functions

Software QA Focus of safety software QA should be on the desired function Requirements –What is the intended function? –How should the function be carried out? –What are constraints and assumptions?

Accelerators and Programmable Safety Systems Using Systems approach where: –Safety functions are identified and ranked –Ranking triggers performance requirements for: Management Technical Staff Hardware Software Lifecycle Testing Management of Change End of Life

ISA/IEC Standards IEC61511/ISA S84 Defined from a safety function perspective. Performance based consensus standards Extensive requirements and guidance on software

Incorporation of System Safety Engineering Higher level than Functional Safety standards –ISO/IEC 15288:2002(E) – Systems engineering – system life cycle processes. –Defines processes for ‘system of systems’ –Incorporates human element

From: INCOSE Systems Engineering Handbook v3.1 Continuing Resolution Continuing Resolution Continuing Resolution Continuing Resolution Continuing Resolution Continuing Resolution

Traditional QA applied to the Program Process and methods to ensure program is: –Free from defects –Dependable –Maintainable –Reviewable –Testable This has to do with requirements for implementation, not the function - Do not confuse quality programming with quality software

Issues 1 Can consensus standards like ISA S84/IEC61511 be used to meet requirements of QA order? (in the context of the accelerator safety order) Are there common hazard ranking levels at accelerator facilities? What are appropriate levels of review for accelerator safety system software? Should this issue be addressed in the ASO Guidance?

Issues 2 What is an acceptable level of competency at various lifecycle stages? Is Functional Safety requirements enough? System Safety? What are implications of General Standard – IEC61508? How does one handle reconfigurable devices like Field Programmable Gate Arrays (FPGA)?