1 / 13

Breakout Group 2: Software Quality Assurance

Breakout Group 2: Software Quality Assurance. Objectives and Goals. Why Worry?. Adapted from Computer Technik Magazine. Ritsch und Renn. Particle Accelerator. Objectives. Review 2009 Workshop Outcome. Three talks on SW QA activities at accelerator labs.

becca
Download Presentation

Breakout Group 2: Software Quality Assurance

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. Breakout Group 2:Software Quality Assurance Objectives and Goals

  2. Why Worry? Adapted from Computer Technik Magazine. Ritsch und Renn Particle Accelerator

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

  4. 2009 ASW SQA Session • 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” • 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

  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

  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. 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)”

  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)

  10. New Help • Control Systems Security Program (CSSP) cssp@hq.dhs.gov.

  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

  12. Guidance Content Discussion forum

  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

More Related