1 / 22

QA Requirements for DOE Accelerator Safety System Software

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

arnaud
Télécharger la présentation

QA Requirements for DOE Accelerator Safety System Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. “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”

  3. “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.

  4. QA Order Contractor QAP Requirements for “Safety Software” Work processes involving safety software mustbe 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.

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

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

  7. DOE Standards with ‘Software’ in the Title • DOE-STD-1172-2003 Safety Software Quality Assurance Functional Area Qualification Standard • Qualification of Software QA people • DOE-STD-4001-2000 Design Criteria Standard for Electronic Records Management Software Applications

  8. Guidance • DOE G 414.1-4 “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-1 2000 (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 5480.23, Nuclear Safety Analysis Reports”

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

  10. 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?

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

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

  13. 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?

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

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

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

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

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

  19. 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?

  20. 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)?

More Related