ML20017A147

From kanterella
Jump to navigation Jump to search

T9S900D970-SWP-2, Rev a, Triga INL Channels Software Development Plan - Redacted
ML20017A147
Person / Time
Site: University of Lowell
Issue date: 01/06/2020
From:
General Atomics, Xerox Corp
To:
Office of Nuclear Reactor Regulation
References
GA/EMS-4791 T9S900D970-SWP-2, Rev A
Download: ML20017A147 (18)


Text

arseam xerox 8 arseam T9S900D970-SWP-2A_REDACTED.pdf 01 /06/20 10:38 AM Xerox WorkCentre 7855

REV GA PROPRIETARY INFORMATION THIS DOCWENT IS THE PROPERTY OF GENERAL ATOMICS (GA). Af('( TAANSMITIAL'OF TIIS DOCUMENT QUTSIDE (GA) W1LI, BE IN CO/IF!DENCE EXCEPT '{l'ITH THE WRITTEN CONSENT~ (GA) (1) THIS OOCUI.ENT MAY NOT BE COPED IN WHOLE OR IN PART AND Will BE RETURNED UPON REQUEST OR WHEN NO LONGER NEEDED BY RECIPIENT AND (2) INFORM4.TION CONTAINED HEREIN MAY NOT BE COMI\\UIICA TED TO OTHERS AND MA.Y BE USED BY RECIPIENT ONLY i:OR TI-E PURPOSE FOR WHICH IT WAS 'fRANSMTTS)

REVISIONS DESCRIPTION

+

t:SNSRAL ATOMICS ELEt:TROMAGNETICS DATE 16969 ~SAMM STREET SAN DIEGO, CA_92127 APPROVED TRIGA INL CHANNELS SOFTWARE DEVELOPMENT PLAN.

SIZE CAGE COOE REY T9S900D970-SWP-2.

A DRWlEVEL SCALE SHEET 3

NONE 1 OF 17 GA-ESl-0258 FORM-A Rev. 10/25/2013 [Sheet 2 unbrmatted]

Contents 1.0 SCOPE............................................................................................................. :......................................... 5 2.0 PURPOSE,............ '.............................................................. :.......................................... :.:......................... 5 2.1 Project Identification 5

3.0 DEFINITIONS......................................................................................................................... :................. 6 4.0

  • REFERENCE DOCUMEN!'S.......... :........................................................................... :..... :******................ 7 4.1 Industry Standards 7

4.2 GA Process and Operational Procedures And Project Documents 7

4.3 Customer Documents 7

5.0 PROJECT ORGANIZATION and RESPONSIBILITIES......................................................................... 8 5.1 Organization 8

5.2 Roles and Responsibilities 9 _

6.0 1RAINING......................................... *....................................................................................................... 9 7.0

. PROJECT MANAGEMENT **************************~*****:************************~........................................... :......... :.-9 7.1 Project Objectives 9

7.2 Assumptions, Dependencies and Constraints.

7.3 Risk Management 7.4 Project Control 7.5 Hazard Management 9

. 10 10 10 8.0 PROJECT SOFIW ARE DEVELOPMENT MODEL...................................................... *......................... 11 8.1 Development Management 11 9.0 1ECHNICALME1HODS and TOOLS.................................................................................................... 11 9.1 Project Documentation 11 9.2 Software Change Control*

9.3 Development Change Control 9.4 Release Process 9.5 Tools And Development Aids.

11 11 1*2 12 10.0

  • PROJECT TASKS, SCHEDULE and ESTIMAIBS...................................................................... :.......... 12 T9S900D970-SWP-2 REV A Page2

10.1 Tasks 10.2 Resource Requirements 10.3 Dependencies See Assumptions, Dependencies and Constramts section 7.2 for dependencies.

12 13 13 13 11.0 PROJECT SOFIWAREDEVICEDESIGN CONTROL.......................................................................... 14 12.0 REVIEWS.................................................................................................................................................. 16 12.1 Management ReVIews 16 12.2 Technical Reviews 16 12.3 Software Reviews and Inspections 12.4 Software Project Management ReVIews 16 16 13.0 MEIRICS andMEASlJREMENTS.......................................................................................................... 17 14.0 APPENDICES............................................................................................................................................ 17 T9S900D970-SWP-2 REV A Page3

Open Items:

1) Need document numbers
2) CCB members need to be decided
3)

Some project level description is llllssing

4)

Cover page needs to be updated and some formatting is wrong T9S900D970-SWP-2 REV A Page4

1.0 SCOPE A Software Development Plan (SDP) describes the development activities to be conducted throughout all phases of the Software Development lifecycle. It describes the organization and responsibilities, management structure, development schedule, deliverable work products, staffing requirements, and other resources that are used to develop a specific software project The software development plan serves as a vehicle for plannlng, establishing of project-level controls and the specific operating procedures that will be applied to the software project.

This SDP has been created under the guidance of IEEE 1058-1998 - IEEE Standard for Software Project Management Plans. This SDP describes the development environment, development' tool set, Internally developed software tools and utilities, COTS tools, and the processes required to manage and control their use during the project.

This SDP applies to the development and release of the TRIGA NMP and NLW Nuclear Channels, software which is being developed to replace the analog design of the NMP-1000 and NLX-1000 monitoring channels.

2.0 PURPOSE This Software Development Plan describes the process, practices, organization, schedules, and resources that are used to produce the TRIGA NMP-1000 and NLX-1000 Channel Software identified in Section 2.1 below.

In addition to providing traditional project planning information, this software development plan will cite any 'talloring' to the Software Engineering operating procedures to align with the activities, needs and constraints of this project The TRIGA INL Software Configuration Management Plan and the Software Quallty Plan address the change management and quality requirements planned for developing product software and are each separate documents and are referenced throughout this SDP.

2.1 Project Identification The TRIGA INL project will replace the existing Neutron Radiography Reactor (NRAD)

Instrumentation and Control System Console. The new instrumentation and control console will replace existing systems located in the Hot Fuel Examination Facility (HFEF) at INL. The NRAD instrumentation and control console provides operators with reactor controls, indications, and alarms; balance of plant controls, Indications, and alarms; and video surveillance of the NRAD facility.

As part of the replacement, the monitoring channels will be updated to support the new Control System Console. The NRAD utilizes three NMP-1000 and one NLW-1000 monitoring channels. The NMP-100p monitoring channel is a wide-range linear manual and automatic range switching current-to-voltage signal conditloning device. It Includes adjustable bl-stable trip circuits for local and remote alarms and isolated current outputs for display by other devices. The NLW-1000 ls a wide-range nuclear power channel monitor capable of resolving power from 1x10*1 to 1x102 percent.

T9S900D970-SWP-2 REV A Page5

Each nuclear channel Includes a NetBurner Ethernet Module and an Amulet LCD Display.

GA-ESI wlll develop and deliver customized code for both the NetBurner Ethernet Module and Amulet LCD Display for each channel. The software development effort will utilize Perforce for software change management. The source for the NMP-1000 and NLW-1000 will be stored in separate code bases. The NLW-1000 will reuse and leverage as much as possible from the NMP-1000 code base.

Software work activities and project milestones will be captured In the project schedule as discussed in Section 10 of this document.

3.0 DEFINITIONS This section defines special terms, abbreviations, and acronyms used in this Software Development Plan.

artifact CCB CDR ECN FMEA IEEE INL NLl-1000 NLS-1000 NLW-1000 NLX-1000 NMP-1000 NRAD OP PDR OAP SCR SCM SOD SON SOP sow SQA SRS Record of process such as meeting minutes or review checklists Change Control Board Critical Desh:m Review Engineering Change Notice Failure Modes and Effects Analysis Institute of Electrical and Electronics Enqineers Idaho National Laboritorv A channel monitor designed to work with a compensated ion chamber and measure seven decades of neutron flux. For use with a TRIGA reactor.

A channel monitor designed to work with a fission chamber and measure seven decades of neutron flux.

For use with a TRIGA reactor.

A channel monitor designed to work with a fission chamber chamber and measure ten decades of neutron flux. For use with a TRIGA reactor.

A platform module that can be configured as a NLW-1000, NLl-1000 or NLS-1000.

The NMP-1000 Module is a wide-range linear power channel module which can be used as part of a research reactor control console to provide a percent reactor oower indication and bi-stable trip circuits.

Neutron Radioaraphv Reactor (NRAD)

Operating Procedure Preliminary Design Review Quality Assurance Plan Software Chanqe Request Software Configuration Management Software Detailed Design Software Discrepancy Notice Software Development Plan Statement Of Work Software Quality Assurance Software Requirements Soecification T9S900D970-SWP-2 REV A Page6

SyRS Systems Requirements Specificatlon SVG Software Verification Group SVVP Software Verification and Validation Plan TINA TRIGA ??? test tool TRIGA TraininQ Research Isotopes General Atomics TSR Test Summarv Reoort V&V Verification and Validation VDD Version Description Document 4.0 REFERENCE DOCUMENTS 4.1 Industry Standards IEEE 1058-1998 IEEE Standard for Software Project Management Plans NQA-1-2000 American National Standards Institute/American Society of Mechanical Engineers "Quality Assurance Requirements for Nuclear Facility Applications" 4.2 GA Process and Operational Procedures And Project Documents Only cognizant engineers will perfonn the software engineering activities/tasks and shall be familiar with the following operating procedures:

OP-4.0-120 Design Documentation OP-4.0-130 Engineering Change Notice Rev Y OP-A-.0-140 Design Control OP-4.0-150 Design Reviews OP-4.1-100 Software Development Plan Template Rev A OP-4.1-120 Software Development Process Rev B OP-4.1-130 Software Inspection & Review Process Rev A OP-6.2-140 RMS Software Development OP-6.2-190 Software Versioning Specification OP-6.2-210 Software Tool Validation Procedure Rev A OP-6.6-160 Software Change Control Board Procedure Rev C OP-6.2-200 Software Hazard/FMEA and Rlsk Management Procedure OP-6.6-210 Software Discrepancy Reporting T9S900D970-CMP TRIGA Software Configuration Plan Rev A T9S900D97003 TRIGA IN UN RAD Software Quality Assurance Plan Rev C 4.3 Customer Documents SOW-8330 Statement of Wori<. Replacement of the NRAD Instrumentation and Control Console T9S900D970-SWP-2 REV A Page7

5.0 PROJECT ORGANIZATION and RESJ;>ONSIBILITIES This section describes the project organization, roles and responsibilities that wlll b:e used to execute the Project 5.1 Organization Software*

Engneerlng Lead Software Engneer Project Manager Software Engneemg Manager Conflg uratl on Manager Test Lead T9S900D970-SWP-2 REV. A Page 8

Software*C~ -

Has, aihiliru for flle.over'aJI

.... ~!""-".**9-_

. - ~~

. ~, *

-software~ espedaiy m t11e areas

-otp,oces5*~ staffing-and **:

unmate* software reatoks and -.

~

-~~~

software.

Reqtii"erneirts Re$0nsible'for creati)g SyRS anti

~

SRs..-

Al software ttlal are--~ ord~

  • ect-wil be trained on licable

___.~

..... engIJeefS

_.... '!"~'l:I PPJJ

_. app __..., ~Y~OV?

'Staridard Operati1g Procedures arid the f_olkWmg set of-"'~" --

. *anc11or "deliies..

~

... ~

,~. -

1.0 PROJECT MAN~GEMENT

.7.1

~Qb~

The -pl'immy objective of fhe-softWafe development effort is lo deliver the.new NMP-1000 and N~-:.109()d1annel ~-ITIC>die fil;ntware_to be.used with the TRlGA-INL replacement of the NRAD 11strumentati0n* and control console,

  • ~--

The NIXco&!. will leo.ieraQ:e ~ inapilY of the-~

from the_NMP-~

.~

T9S9QQD97~2 I$v i P!t~9

Channel testing has a dependency on the completion of the CONSOLE hardware to complete system testing.

Constraints:

The project is already severely over budget and outside of the original schedule, leaving no room for modifications without incurring additional losses.

7.3 Risk Management Listed below are the current known risks. All risk mitigation is the responsibility of the project manager.

The software knowledge base consists of a single software engineer.

Reviewing the code may take significantly longer since it was written using non-standard languages.

Any hardware defects resulting in the need to create new PCBs could delay final testing.

An error in estimated work could result in missing the ship date.

The new digital design may be more susceptible to noise, resulting in unacceptable performance at INL.

The customer may not accept the final product without modification.

The new channel monitor design is slightly larger than the previous version and may not fit 7.4 Project Control Project progress will be measured by task completion. A Task Is deemed to be complete when all associated product requirements have been implemented, be It requirement analysis, design, code Implementation or testing.

Weekly meetings will be conducted to track task completion and address any issues that arise. Meeting minutes will be taken and stored in TRIGA INL folder in SharePoint.

Software quality will be provided as stated In the Software Quality Plan.

A Preliminary Design Review (PDR) and a Critical Design Review (CDR) will be held. The PDR will ensure that all requirements documents needed for design of the functional changes are completed. The CDR will ensure the completeness of the design practices, design correctness and all applicable documentation standards.

All artifacts that are not released to the Doc Center will be stored in SharePoint under the TRIGA INL project directory.

http://teams.ga.com/esi/ProJects/trigainl/SitePages/Home.aspx 7.5 Hazard Management A system Failure Modes and Effects Analysis (FMEA) will be performed and documented for the NMP-1000. Any hazard or failure modes requiring mitigation will be addressed within the document. Hazards or failure modes that Impact requirements or design will be captured as issues in the Defect Tacking Database and tracked to resolution.

T9S900D970-SWP-2 REV A Page 10

No FMEA Is planned for the NLW-1000, NLl-1000 or NLS-1000, however since the hardware and code base are similar any hazard mitigation applled to the NMP-1000 wlll be likewise applied the other monitoring channels.

8.0 PROJECT SOFIW ARE DEVELOPMENT MODEL This upgrade of the NMP-1000 and NLX-1000 shall follow a Waterfall llfecycle model with a phased approach as reflected in the schedule. The project phases reviews shall assess that required artifacts have been completed during the appropriate phase. Each phase has a set of deliverable that should be produced In order to complete/pass the phase. Deliverables that are not complete may be deferred to the next phase by project level approvals (Project Management, Quality, etc.).

8.1 Development Management The development model Phases begin with an assessment of needed artifacts to perform the work and cannot officially start such artifacts are complete and their quality satisfy the required standards. The Phase entry review serves as the artifact assessment Completion of the phase will require that all phase deliverables are finished, and ready for check in. This level of completeness shall meet approval of SQA and Document Control Standards.

The Phases are:

o Planning o

Design and Implementation o

Test o

Production 9.0 TECHNICAL METHODS and TOOLS 9.1 Project Documentation All software project documentation shall use the Microsoft SharePoint directory created for the TRIGA INL project.

All unreleased documents shall be stored in SharePoint and released to the Doc Center upon the release of the software to production.

9.2 Software Change Control Software change control will be conducted as specified in the Software Configuration Management Plan.

9.3 Development Change Control Per the Software Development process, Baselines to project deliverables shall be established and maintained. Changes to established baselines affecting software development such as changes to requirements and design input documentation shall be tracked, reviewed and dispositioned by the project cross functional team or Change Control Board (CCB). A project T9S900D970-SWP-2 REV A Page 11

shall be mme<1 and ~

in JiRA to record, and track an_changes affecting project scope. The role of the CCB w11 be to evaluate. coordinate and schedule implementation of 5:3id changes. Established baselines reflect the miestones identified in the project scheduJe.

Scope changes shal be tracked as an en1ry In the Defect Database. The Orignator shall fill out 1he '"Defect ldenfiliers'" section aid the "Defect Behavior".

The CCB is responsible for evaluating. schedufmg. and assigning WOik to the dlJPi<>lkale

~- The CCB wll be responsible for the "CCB Review" section.ot the defect.

The engineer is 18SPQ1asi;Jle for evalua1k1g and Jmplementi1g the fixfupdale to the document. or code. The engineer is responsible for filing out the "S/W Development" section of the defect Each defect shall be yeiled for its COl11)letion and marlred as completed by the Software Verfficafion Group (SVG)*and checked b>/ SQA. The SVG shall Iii out the "Resolution Narrafivea section.

9A Rel~ Process Soflwae releases shall be released as specified i1 the Soflwm:e Configuration Management Plan.

9.5 Tools.hd Dewlopmeut Aids

  • The essential ~opment tools from.vendors and Ile~

products are fisted.in the 1oD<PNing 1abJe. The suppomng tools such as doa.ment sharing. software configuration management and project tracking are also lisled. but their functlonal equivalents ae acceptable.

LCD folder.

10.0PROJECT TASKS, SCHEDULE and ESTIMATES The tasks and dea<lines for the TRIGA INL monitoring channels are laid out in the project schedule.

The schedlle shall be maintmed by the Project Manager and located on the X drive in the TRIGA INL Project folder.

lD.l Tasks The project tasks are detaiJed in the scheck.ie. The up-<<>-date schedule shaD be available on the folowing network ~

location:

T9S900D970-SWP-2 REV A Page 1~

io~- ~~~.

Toe*,folq,.mg ~-WIii be ~

to,cotnpk!te the pto]ect.

i~ Depeadelldes

' See

,' JSchodOl9

,SQe, See.

ScheilJie flroood' Assurance.

Pioducion Confml*

CUslumer' Smvica '

See :A.ssumptions., Depeodericies and Coosfraints section 7-2 for*dependencies~

  • 'J,"9S900D97~~

lIBV 4 Page 13,

11.oPROJECT SOFfWARE DEVICE Dl;~IGN CONTRO~.

")'.

~

(

.. Documenf Number.

Yes/NolN

~Deliverable.,....

Pflase. -_,:

~.. *,.

  • Responsible Person,

- ;:~.

  • --A.

- \\ Notes* *.'.

NlX-1000 Sy~S Yes 1'9s900!)9~YR WBlbe~ln NLw.:1000 s~

No

~

I

~

NLX, 1000 SvRS NMP-1000 SyRS Ye$

~~:VR T9S900D951-SRS.

SRS' will. be updated at NL;X-1000 SRS Yes a later date post re{ease due Jo ijme

  • Design Input

~-p~on

. NLW-1000-*SRS:

No*

WiPbe.~in Ni.X:-1000 SRS NMP-1000. SRS.

.Y!:$

T~941-SRS Use 'Case Scenarios No T9S900D980-FME

~

i:s ctone only ror the NMP-1000 'due to its safet\\l related nature SoftWare* Qualify Pla1 Yes 1W900D97003 Desjgnand' Dev Software CM 'Plan y~

T9S900D970-CMP

  • Planning Unit l'~ Plan Yes T9S900D952-S0D.

SOD wilt be updated at NLX-1000 SOD Yes a later date post.

~el~. due to tine

~~on the :-....u:.......

Design NLW-1000.SOD No.

~

-be mcorporate4 in NJ.J<,-10QO*SD0

'Output NMP-1000SDD Yes T9S9000942-SDD NLW-1000 source Code Yes NMP-1000 Source Code Y$

Software Hazard Analysis No' Included as an

- :totheFMEA T9~D9:7~WP-2

~

A Page14

NLW Trace Matrix Yes T3322000-RTM NMP Trace Matrix Yes T3401000-RTM Unit Test Protocols and Reports No Coding Standards No Design Reviews Yes Code Reviews Yes Software Project Management Reviews Yes Software Quality Plan Yes T9S900D97003 Software CM Plan Yes T9S900D970-CMP Unit Test Plan Yes NMP System Test Plan (STP)

Yes T9S900D991-PLN Testlng NLW System Test Plan Yes T9S900D981-PLN Component Test Plan (CTP)

No NMP Test Design Specification No T9S900D991-TDD Letter to file for NLW Test Design Specification No rationale will be created in place of missing test design specification NMP Test Case Specification Yes T9S900D991-SPC Design and This will be rolled into Dev NLW Test Case Specification No the NLW Test Planning Procedure NMP Test Procedure Specification Yes T9S900D991-CSE NLW Test Procedure Specification Yes T9S900D982-CSE Test Item Transmittal Reports Yes Test Logs Yes Test Incident Reports (TIR)

Yes Test Summary Reports (TSR)

Yes T9S900D970-SWP-2 REV A Page 15

12.0 REVIEWS This section defines the types of management, technical, and peer reviews which will be conducted during this project.

12.1 Management Reviews The following software work products will be reviewed and signed off by engineering management.

NLX-1000 SyRS NMP-1000 SyRS FMEA SDP TSR 12.2 Technical Reviews 12.3 The following work products will be reviewed or inspected per the Software Inspection and Review Process (OP4.1-130).

NLX-1000 SyRS NMP-1000 SyRS NLX-1000 SRS NMP-1000 SRS NLX-1000 SDD NMP-1000 SDD NLW-1000 Source Code NMP-1000 Source Code FMEA Software Reviews and Impectiow The procedure for performing software reviews is the Software Inspection and Review Process (OP 4.1-130). The software review and inspection activity is a method that can be used to verify the output from a development activity that cannot be verified by means of an objective test. Records will be kept and stored in accordance with OP 4.1-130 from all software reviews or inspections.

12.4 Software Project Management Reviews A Software Project Management Review will be held by Software development and supporting groups to determine the fitness of the software for release to formal verification. This review will be held after all code reviews and unit tests have taken place.

T9S900D970-SWP-2 REV A Page 16

13.0 METRICS and MEASUREMENTS The metrics to be collected provide indicators that track ongoing project progress, software products, and software development processes. This section describes the qualfty and process measurements that will be obtained for this project and specify the metric data that is to be collected In order to derive the measurement. These metrics are to be collected quarterly unless otherwise noted.

No metrics will be collected on this project to cut cost.

14.0 APPENDICES None T9S900D970-SWP-2 REV A Page 17