Presentation is loading. Please wait.

Presentation is loading. Please wait.

Breakout Group 2: Software Quality Assurance Objectives and Goals 8/18/10 1.

Similar presentations


Presentation on theme: "Breakout Group 2: Software Quality Assurance Objectives and Goals 8/18/10 1."— Presentation transcript:

1 Breakout Group 2: Software Quality Assurance Objectives and Goals 8/18/10 1

2 Why Worry? Adapted from Computer Technik Magazine. Ritsch und Renn 8/18/10 2

3 Objectives Review 2009 Workshop Outcome. Three talks on SW QA activities at accelerator labs. Identify SW Assurance activities for high impact operations at Accelerator Facilities. Recommendations for incorporating value added SW Assurance activities into a revised ASO guidance document. 8/18/10 3

4 2009 ASW SQA Session M. Cole. “DOE Accelerator Software and Quality Assurance” M. Cole. “DOE Accelerator Software and Quality Assurance” – Injury, property damage, or program interruption are all credibly possible [outcomes] if software fails in the operation of an accelerator facility – 414.1-4 guidance is intended for nuclear facilities – Address the synergism between safety, reliability, and quality – Address the integration of the software with hardware and humans – One may select a consensus standard that addresses the 10 criteria of 414.1C A. Etkin. “Draft DOE Standard Application of Safety Instrumented Systems Used at DOE Non-Reactor Nuclear Facilities” A. Etkin. “Draft DOE Standard Application of Safety Instrumented Systems Used at DOE Non-Reactor Nuclear Facilities” – Draft DOE Standard for use of programmable electronics in non-reactor nuclear safety systems – Consolidation of information for SS & SC safety instrumentation and – Safety Significant material Based on ANSI/ISAS84.01-2004 – Adds Alarm Functions, Fire Protection Systems, Systems that monitor start-up 8/18/10 4

5 5 2009 Recommendations SQA for software identified in ACE Program shall be developed using 414.1-4 as guidance or be based on a consensus standard Authority needs to be established to identify/approve equivalent controls/processes when requirements can not be implemented as written in order/standards SQA for other software Should be risk based (Graded Approach) Specify minimum requirements, e.g. documented design criteria, configuration management, testing protocols Linked to the 10 basic QA criteria in 414.1C Next revision of QA Order > 414.1D Addresses SQA in non-nuclear facilities (current status - comment resolution phase) Suggested Action Plan: Assess implemented SQA program against requirements in revised order. 5

6 Ten SQA Work Activities from 414.1C.5d (1) Software project management and quality planning (2) Software risk management (3) Software configuration management (4) Procurement and supplier management (5) Software requirements identification and management (6) Software design and implementation (7) Software safety (8) Verification and validation (9) Problem reporting and corrective action (10) Training of personnel in the design, development, use, and evaluation of safety software 8/18/10 6

7 SQA for All SQASG-TP-10-01-REV. 0 (January, 2010) “Systematic Approach to Implementing the Quality Requirements of DOE O 414.1C for Software” – Safety software, and – All other software Business Science Enterprise Controls… 8/18/10 7

8 Software Quality Assurance  Software Assurance NASA-STD-8739.8 (w/Change 1) July 28, 2004 “Software assurance consists of the following disciplines: Software Quality – Software Quality Assurance – Software Quality Control – Software Quality Engineering Software Safety Software Reliability Software Verification and Validation (V&V) Independent Verification and Validation (IV&V)” 8/18/10 8

9 New Risks August 2006 – Network storm freezes PLC based control at Brown’s Ferry. Non-safety control. (NRC INFORMATION NOTICE: 2007-15) June 2010 – Triple redundant processor has systematic software error. - Fail Safe. Affected Safety Significant safety computer at SRS (Rockwell Product Notice - 2010-06-002 – 8110) July 2010 – Stuxnet Trojan used Windows vulnerability to infect Siemens PC based software. Transferred through USB stick. No damage reported. (Siemens Support Entry ID:43876783) August 2010 – VxWorks (EPICS real time operating system) security vulnerability identified by DHS. (CERT Advisory ICSA-10-214-01) 8/18/10 9

10 New Help Control Systems Security Program (CSSP) cssp@hq.dhs.govcssp@hq.dhs.gov. 8/18/10 10

11 Alignment with the Safety Order DOE Responsibilities Facility operations meet DOE mission and operational objectives Operations comply with safety program and objectives Ensure facility safety program incorporates: – ASE and SAD – clearly defined roles and responsibilities – a configuration management process – readiness review – inventory of exempt accelerators Major Constituents of the CRD Accelerator Safety Envelope (ASE) – Bounding conditions for safe operations Safety Assessment Document (SAD) – Describe Engineered and Administrative Controls Unidentified Safety Issue (USI) – Configuration Management Accelerator Readiness Review (ARR) – Contractor Assurance Process – Configuration Management Program – Administrative Processes Related to Accelerator Safety 8/18/10 11

12 Guidance Content Discussion forum 8/18/10 12

13 Outcome Scott has asked that the breakout sessions produce a set of “outcomes” from the breakout sessions. Review Recommended Action Items Recommendations to DOE/Contractors 8/18/10 13


Download ppt "Breakout Group 2: Software Quality Assurance Objectives and Goals 8/18/10 1."

Similar presentations


Ads by Google