DOE Review – August 2010

1. Software QASafety SystemsatSLACEnzo CarroneControls Department – Safety SystemsSLAC National Accelerator Laboratory

2. DOE Review – August 2010 Assessment of the- Natural Phenomena Hazards, - Quality Assurance- Work Planning and Control- Safety Software, and - Control of Hazardous Energy Programs

3. Safety Software Courtesy of Carl Mazzola DOE ES&H, Office of Quality Assurance Programs • Safety Software includes: • Safety System Software: it 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.

4. Safety Software • Safety Software includes: • Safety and Hazard Analysis Software and Design Software: 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.

5. Safety Software • Safety Software includes: • Safety Management and Administrative Controls Software – it 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.

6. Description of Grading Levels • Level A: • Software failure that could compromise a limiting condition for operations; • Software failure that could cause a reduction in the safety margin for a safety SSC that is cited in DOE approved documented safety analysis; • Software failure that could cause a reduction in the safety margin for other systems […]; • Software failure that could result in non-conservative safety analysis, design or misclassification of facilities or SSCs

7. Description of Grading Levels • Level B: • 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.

8. Description of Grading Levels • Level C: • Includes safety 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

9. Functional Area: Safety-Related Software Applications Criteria (NQA-1-2004) Findings: SS.1.12-P2-009 A SLAC-wide safety software inventory has not been identified, documented, and maintained. SS.1.13-P2-010 Graded approach for implementation of software requirements is not complete or formalized for all three types of safety software.

10. Functional Area: Safety Instrumented System Criteria (ANSI/ISA 84.01) Observation: SS.2.12-P3-006 Requirements associated with use of Safety Integrity Levels for Safety Instrumented Systems are not fully implemented per ANSI/ISA-84.00.01-2004.

11. What we have now

12. What we are building (CCR Upgrade) Note: Only Chain A Shown CCR Equipment LW CPU +I/O LE CPU +I/O LI20 I/O MCC I/O

13. 10 Required SQA Work Activities 1.Software project management 2.Software risk management 3.Software configuration management 4.Procurement & vendor management 5.Software requirements identification & management 6.Software design & implementation 7.Software safety design 8.Verification & validation 9.Problem reporting & corrective action 10.Training of personnel in the design, development, use & evaluation of safety software

14. Software Configuration Control Siemens has two levels of password protection – one for the safety hardware setup and another for the safety program.

15. CVS

16. Change (and risk) Management

17. Safety Systems at SLAC

18. Change Control Board (CCB) • • Reviews change requests submitted by Project Managers; • • Authorizes new projects approving Project Initiation Documents (PID); • • Acts as a consulting body to the Section Leader (e.g. for acceptance of follow-up to reviews); • Maintains, reviews and approves corrective actions and requests from customers (using a tracking database).

19. CCR Relocation – An Organizational Perspective E. Carrone Program Governance Model Projects are managed through a matrix structure internal to the Section.

20. Project Initiation and Design Review

21. Lifecycle

22. Engineering Work Order Quality Tracking Sheet (EWOQ)

23. Project QA Process Example

24. Review Process

25. Review Process • Minor Modifications: adding or moving an emergency off button, BSOIC, or Ion Chamber, equivalent device substitutions such as upgraded annunciator panels, or minor logic changes that improve performance but are not changes in the logic specification; • Medium Changes: redesigns of stopper, BTM, BSOIC, PIC Chassis, or power supply interface chassis, or minor changes in PPS logic specification; • Large Changes: new PPS zones, new BCS regions, complete PPS rebuilds or significant logic modification.

26. Future upgrades Note: Only Chain A Shown CCR Linac Supervisory I/O + BSY SSRL ??? PEP-X MCC + + + Linac Sector PPS’

27. Cyber Security

28. Specifications and Certification • Finite State Machine; • MatLab, Simulink, Stateflow. My most pressing questions: How to streamline the process? Can we take credit for an automatic, extensive software-based test? Where does cyber security fit?

29. The Bottom Line • “In God we trust, • all others bring data.” • - W. Edwards Deming