SOFTWARE DEVELOPMI3 T PLA

w

SOFTWARE DEVELOPMI3

U

T PLA

Prepared for

US. Nuclear Regulatory Commission Contract NRC-02-02-012

Prepared by

Biswajit Dasgupta Roland Benke George Adams

Center for Nuclear Waste Regulatory Analyses San Antonio, Texas

December 2003 t

Approval Asad Chowdhury

Date

V W

SOFTWARE DEVELOPMENT PLAN FOR THE PCSA TOOL REVISION 04

The Software Development Plan (SDP) describes the approach to be followed in the development of the PCSA Tool.

1.0 SCOPE

The scope of this task is to develop a PCSA Tool to provide the NRC and CNWRA staff the capability to conduct an independent confirmatory analysis and to review the DOE preclosure safety analysis. The PCSA Tool structure is modeled after tkle safety analysis review methodology which is based on the requirements of the 10 CFR Part 63 for preclosure safety analysis of the geologic repository operations area. The review activity and the typical tool functions consist of (i) collection of site-specific data and information on facility operations and processes; (ii) natural and human-induced, and facility hazards analysis; (iii) event sequence analysis; (iv) categorization of events; (v) consequences analysis; (vi) safety assessment; and (vii) identification of structures, systems, and components important safety. In addition, the tool will have the capability to assess system risk using an approach developed by Benke et. al. (2002). The PCSA Tool will use a graphical user interface erivironment developed in Microsoft Visual Basic 6.0 to control the functions of the tool. The PCSA Tool makes use of the Microsoft Access database software and three other software packages: (i) SAPHIRE (Idaho National Engineering Laboratory, 1998); (ii) RSAC (Wenzel, 1994); and (iii) MELCOR (NRC, 2000). In addition, several utility codes were developed using the Lahey LF95 Fortran compiler. Incorporation of consequence analysis code MACCS2 (NRC 1998) is under consideration.

2.0 BASELINE ITEMS

The baseline items are: (1) PCSA Tool template using MS Access database; (2) PCSA Tool code developed using Visual Basic 6.0; (3) Equipment System Failure Rate database and failure mode check list database; (4) SAPHIRE Version 6.77; (5) RSAC Version 6.2; (6) MELCOR Version 1.8.5; and (7) the suite of utility codes developed in Fortran: PCSA-LHS, PCSA-LHSINP, PCSA-PROB, PCSA-RSACRD, PCSA-IET'CCDF, and PCSA-TOTRISK.

3.0 PROJECT MANAGEMENT This section contains the work breakdown structure for development of the PCSA Tool Version 3.0. Note that PCSA Tool Version 1 .O was released to NRC on 7/31/2002, and PCSA Tool Version 2.0 was released to NRC on 6/27/2003.

1

W

20 I 2 0 0

3/3 1 /2004 3/3 1 /2004

65 60 60 520

3/3 112004 313 1 12004 3/31 /2004 3/31/2004

T. Maxwell R. Benke B. Dasgupta G. Adams D. Stead

G. Adams TBD

20 613012004 20 613012004 20 6/3 012 0 04 120 613 012 0 04

'1 0 4/14/2004

4 0 4/14/2004 130 4/14/2004

3.1 Work Breakdown Struc ture

Completion Date

Completed Software Procurement for Version 3.0

I I I Com c) leted Hard ware Client Furnished Project Management SDP Development

I

I I I I I I I I I I I I I

I I I I

I I I I I I

G. Adams 1 2/3 1 /2003 Istatus ReDorts IC I ie n t Reviews INone I I

6/30/2002 Com p le ted 6/30/2002 Comdeted

B. Dasgupta 20 R. Benke 20

5/30/2003 Com p le ted 5/30/2003 Completed 12/09/2003 Completed

for Version 3.0 IG.Adams I 20

Design and Code for Version 3.0

User's Manual for Version 3.0

Installation Testing for Version 3.0

R. Benke

IM. Silliman I 100 I 3/3 1 /2004

Accept a nce Test i n g for Version 3.0 4/14/2004

4/14/2004 G. Adams M. Silliman

8/2 912 003 Co m D I e ted Develop men t of Softwa re Va I ida t i o Test Plan PCSA Tool Version 3.0

Validation Testing for PCSA Tool Version 3.0

IR. Benke I :30 I 8/29/2003 Comdeted 8/29/2003 Completed 8/2 9/2003 Com p le ted

5/15/2004 5/15/2004

T. Maxwell G. Adams

R. Benke T. Maxwell 5/15/2004

5/15/2004 M. Silliman 160 5/15/2004

2

Tasks

Development of Software Validation Test Report

Hours 5/1 5/2004 7/15/2004

TBD B. Dasgupta R. Benke 40 7/15/2004 T. Maxwell '1 0 7/15/2004

Name

IG.Adams I 40 I 9/30/2004

Support Activities Materials Publications

Travel Training and preparation for training

ESTIMATED HOURS TOTAL:

G. Adams 120 711 5/2004

None R. Benke 40 913012004 B. Dasgupta 20 9/30/2004 G. Adams 40 9/30/2004 M. Silliman 40 9/30/2004 R. Benke 20 9/30/2 0 04 B. Dasgupta 20 913012 004 R. Benke 20 9/30/2 0 04

311 70

3.2 Project Schedule and Milestones

Work Element

Task 1 Design and populate the Equipment System Failure Rate Database

Task 2 Design and develop the PCSA software with followina sub-tasks:

Infrastructure

Functional Area module

External hazards module

System description

Internal hazards analysis

(What-If, FMEA, Energy module

Method) Software Re1 ia bi I i ty (Qua I i tat ive)

Event Sequence module

les to nes Milestone

Description Database is populated

Software is co m p leted and ready for test

Completion Criteria

Project Manager Accept a n ce

Project Manager Accept a nce

Estimated End Date

1 2/3 1 /2004

Completed

Completed

Completed

Mod ifica t io n s 1 1 /26/2003 Completed

Completed

Modifications %%004

I

I I

I I

I I

I

I

3

Task 5 test Database is

' PCSA Tool Ver 3.0. Task 6 Completed

1 Write Validation Test Plan for PCSA Tool Version 3.0

Estimated Completion Criteria

Milestone Description Work Element End Date

Mod if icat ions I I

I

I I I I I I I I I I I I I

I

I

Consequence analysis module (i n p ut/o u t p u t ) Result module with search

capability

Safety Analysis

1211 712003 Mod if icat ions 1211 512003

Mod if icat ions %%004 Deve I o pme n t 3/17/2004 Mod i fica t i o n s 1/21/2004 Develop men t 3/17/2004

SSClS module

I Risk Analysis module I 1 Worker Dose Task 3 Design Crystal Reports for all the forms and add the printing capability to all the ReDorts

Development of Crystal Reports 311 712004 Completed

Project Manager Acceptance

Software is co m p I e ted and ready for test Software is com p leted and ready for

Task 4 ~ Human Error Probability Generator ,


Project 4/14/2004 I Acceptance and Installation Test of I designed I Manager

AcceDta n ce Project Manager Acceptance

Completed Acceptance Test Plan

~~

Task 7 Validation Test the PCSA Tool Version 3.0

S uccessf u I execution of acceptance test


511 5/2004

Task 8 Write PCSA Tool Validation Report Task 9 ,--- Update User Manual for Version 3.0

7/15/2004

Completed Manual

Project Manager Acce D ta nce

6/3 0/2 0 04

4

3.3 Staffing Plan

The following table contains the project team members that are planned to execute the project.

Team Member Project Ro I e Start Date

End Date % Commitment

B. Dasgupta

6/00 R. Benke 912004 25

A. Lozano 8/00

410 1 3/0 1 1 /03 7/02

D. Stead

9/2003 10

912004 75 912004 8 9/2004 10 9/2004 5

(Com ple ted )

R. Janetzke T. Maxwell

Report Accept a nce Test i ng

Code Development, Testing, Manual, Report Code Development, Testing

A. Ghosh 7102 9/2004 5 3/03 512003 25

8/03 9/2004 80

8/03 9/2004 25

(Com pleted)

Project Lead Development , Testing , Manual, Report Development, Testing, Manual, Report Code Development, Manual

Risk Running out of

Code Development, Manual

Impact to Probability Low High

Code Development. Manual

Medium

Low

Testing, Manual Testing, Report

High

High

11’99 1 9/2004 I 30

A. Chowdhurv M. Menchaca

G. Adams

M. Silliman

3.4 Risk Management

The following table contains the risk management plan for the project. The table contains each of the risks that have been identified for the project.

Not completing in time

Failure to implement requirements of

Closely monitor schedule, and add additional man-

hours as necessary Verify implementation

through testing

5

4.0 DEVELOPMENT PROCEDURES

4.1 Environment and Resources

The following sections describe the hardware and software resources that will be utilized during the project.

4.1 .I Hardware Resources

The following table lists the hardware resources that will be uitilized during the project.

Descrintion IBM Compatible PC -2 ADRIANA Pentium II 266 MHz clock 256 MB Ram 20(2xIO)GB Hard Drives

Monitor 21" Super XGA monitor with resolution 1280x1 024 and 32 bit color

Printer Laser minter (shared) IBM Compatible PC -2 ASTl N I US Pentium II 266 MHz clock 128 MB Ram 20(2xI 0)GB Hard Drives

Monitor 17" Super XGA monitor with resolution 1 152x864 and 32 bit color

Printer Laser printer (shared)

Hardware R Sumlier

0 Net Force

0 NEC

0 Net Force

0 NEC

sources Owner

0 CNWRA

CNWRA

Cl CNWRA

17 CNWRA

Purpose Software Development and Testing

Software Development and Testing

6

DescriDtion

Description Microsoft - Visual Basic 6.0 Professional Graphical User Interface Software

IBM Compatible PC -2 ALBY Pentium II 450 MHz clock 6 GB Ram 20(2xIO)GB Hard Drives

Supplier 0 Microsoft


Development Tool Microsoft Access (Office 97)

Printer Laser printer (shared) IBM Compatible PC -2 PITOR Pentium IV 2.8 GHz clock 496 MB Ram 49.2GB Hard Drives

0 Microsoft


0 CNWRA

Printer Laser minter (shared)

Software Develop men t

Sumlier 0 Net Force

0 NEC

0 Net Force

0 NEC

sources Owner

0 CNWRA

0 CNWRA

0 CNWRPI

0 CNWRA

Purpose Software Develop men t and Testing

Software Deve I o pmen t and Testing

4.1.2 Software Resources

The following table lists the software resources that will be utilized during the project.

Database Development Tool

La he y/F uj its u FO RTRAN -95 0 Lahey

Deve I o pme n t

Database Develop men t OCNWRA I

7

Description Microsoft-Visual Source Safe 6.0

SAPHIRE Version 6.77

RSAC Version 6.2 National Environmental and Eng i neeri ng

Supplier Owner Purpose 0 Microsoft OCNWRA Software

Configuration 0 Oak Ridge 0 CNWRA Fault Tree & National Event Analysis Laboratory 0 Idaho 0 CNWRA Radiological

Dose Calculations

MELCOR Version 1.8.5 Transport

Laboratory 0 Sandia National La bora to rv

MACCS2

(Under consideration) Windows NTlXP

Install Shield Professional, Windows Installer Edition, V. 2.03

Crystal Reports 9.0, Developer

4.2 Software Development Lifecycle

The development lifecycle for the PCSA Tool includes the following seven (7) phases:

0 Sandia 0 CNWRA Radiological National Dose Laboratory Calculations 0 Microsoft 0 CNWRA Operating

System 0 Install Shield 0 CNWRA Operating Corporation System

0 Crystal 0 CNWRA Report capability Decisions, Inc.

Phase An a I y s is

Development

I OUtDUt I Description Determine input formats, formulate requirements interface, and determine output requirements and format. Develop code and perform module level testing.

Software Requirements Description

Preliminary Release

Acceptance Testing

Software Scientific Notebook entries Software development files

Users provide developer feedback on the "look Scientific notebook entries and feel" and functionality of the software. Developer uses this information to develop the final version of the software. Demonstrates whether the requirements Scientific Notebook entries specified in the SRD have been fulfilled. Software development files

8

Final delivery r Developer incorporates changes, performs necessary regression testing, and provides final version of software to users.

Developer addresses problems and identifies enhancements

Validation PCSA Tool Version 3.0

Maintenance

Validation

Final version of software Design Verification Report

Software Summary Form Software Release Notice

Software Change Reports Software update Software Summary Form Software Release Notice

Softwate Validation Test Plan. Software Validation Report Software Notebook entries

The following language(s) will be used: The following coding style guide(s) will be used:

4.3 Coding

0 Visual Basic 6 0 Fortran 95 0 Fortran (Cook et al., 1990)

Visual Basic (see Appendices

This section describes the coding conventions that will be applied throughout the project.

Documentation 0 Scientific Notebook 0 Software Development File 0 Software Change Report

0 Other:

4.4 Acceptance Testing

The following table lists the documentation technique and tools that will be used for acceptance testing.

5.0 CONFIGURATION MANAGEMENT

This section contains the configuration management plan for the project.

5.1 Tools

Visual Source Safe V 6.0 by Microsoft will be used to perform software configuration management.

9

5.2 Con f i g u rat i o n lden t if i cat i on

Software version numbers will be of the form Version V.r, where V is an incrementing major version number beginning at 1 and r is an incrementing minor revision number beginning at 0.

5.3 Configuration Procedures

The software will be maintained using Visual Source Safe by Microsoft. The software will reside on the personal computer ADRIANA (in Room Al08, Bldg 189, SwRI) located in directory D:\DStead\PCSA Tool. For PCSA Tool Version 3, configuration management will transition to personal computer PITOR (in Room A I 13, Bldg 189, SwRI) located in directory D:\PCSAToolSourceSafe.

5.3.1 C heck-ink hec k-out Procedures

Software under development will be checked out of the repository into a developer directory for modification. Modified files will be checked back into and newly created files will be added to the repository prior to release.

5.3.2 Creating Releases and Preparing For Deliveries

New releases of the software will be created at determined times during the project at the discretion of the developer. Procedure specified in TOP- 18 for creating a new release will be followed.

5.3.3 Problem Reporting and Change Control

A Software Change Report (SCR) will be used to track problems, design changes, and enhancements to the software.

5.3.4 Backups

The project repository will be used to store the baseline configuration items during development. The following parameters apply to the configuration repository

I P roiect Files Host information:

Backup

Automated backup tools:

Host name: ADRIANA Directory: D:\DStead\PCSA Tool Host name: PITOR Directory: D:\PCSAToolSourceSafe 0 Compact Disk (CD) 0 Hard Disk (DRACO)

0 lomega: Zip 250

0 Daily 0 Weekly 0 Other: As needed. 0 Other:

10

6.0 REFERENCES

Benke, R. “Analytical and Numerical Solutions of the Expected Number of Occurrences for Combinations of Event Sequences due to Variability.” San Antonio, TX: Center for Nuclear Waste Regulatory Analyses. 2003.

Benke, R., B. Dasgupta, B. Sagar and A.Chowdhury, “A Methodology for Preclosure Risk Assessment for a Geologic Nuclear Waste Repository”, Protiabilistic Safety Assessment and Management (PSAMG), Proceedings of the 6th International Conference on Probabilistic Safety Assessment and Management, San Juan, Puerto Rico, June 23-28, 2002, Oxford: Elsevier Science, Ltd. Vol. I, pp. 983-988, 2002.

Cook, D. M., N.H. Marshall, E.S. Marwil, S.D. Matthews, and G.A. Mortensen, “Fortran Coding Guidelines”, EG&G Idaho, Inc. EGG-CATT-8898 Idaho Falls, ID: U.S. Department of Energy, Idaho Operations Office February 1990.

Idaho National Engineering Laboratory. “Systems Analysis Programs for Hands-on Integrated Reliability Evaluations (SAPHIRE) Version 6.0, Saphire Reference Manual.” Idaho Falls, Idaho: Idaho National Engineering Laboratory. 1998.

Wenzel, D. R. and B. J. Schrader. “The Radiological Safety Analysis Computer Program (RSAC-6) Users’ Manual”. INEEL/EXT-O1-00540. Idaho National Engineering and Environmental Laboratory. 2001.

U.S. Nuclear Regulatory Commission. “MELCOR Computer Code Manuals”. NUREG/CR-6119, Revision 2. Washington, DC: U.S. Nuclear Regulatory Commission. October 2000.

U.S. Nuclear Regulatory Commission. NUREG-661 3, “Code Manual for MACCS2; Volume, Users Guide.” Washington, DC: NRC. May. 1998.

7.0 APPENDICES

Visual Basic Codina Standard

11

APPENDIX Visual Basic Coding Standard

Visual Basic Coding Standard

1, overview

The scope of this effort is coding in the MS Visual Basic (VB) coding The use of good VB style will encourage consistent layout, improve style.

the portability, and consequently reduce the coding errors during the development of the software. for those situations not covered by this procedure.

Experience and good judgment should be used

2. Naming Standards

The software will use a consistent naming convention for variables throughout coding process as specified in paragraph 6.1.2, Variable Naming Conventions. Using a consistent standard for naming components in the program will save a significant amount of time during the code development process, and during future maintenance work.

3, Variables

Variable names are used frequently in the process of code development; most statements contain the name of at least one variable. Through the use of a consistent naming system for variables, the programmer will be able to minimize the amount of time spent tracking down the exact spelling of a variable's name.

By encoding some information about the variable itself into the variable name, the programmer can make it easier to decipher the meaning of any statement in which that variable is used, in addition to identifying errors that are otherwise difficult to find.

The attributes of a variable that are useful to encode into its name include its scope and its data type as outlined in the following paragraphs.

4 . Scope

In VB, there are three scopes by which a variable may be defined. The three scopes include the following.

a. If defined within the procedure, the variable is local to that procedure.

b.

C.

If defined in the general dec1arat:Lons area of a form or module, then that variable can be referenced from all procedures in that form or module, and is said to have module scope.

If it is defined with Public keyword, then it is global to the application.

1

5 . Data Types

VB supports an assortment of data types. By encoding the type of variable in its name, the programmer can visually check that the assignment to that variable is credible. This helps the programmer to identify an error quickly.

Encoding the data type into the variable name has another benefit: the capability to reuse data names. If the programmer needs to store the start date in both a string and a double, then the same root name for both variables can be used. The start date is always the StartDate; it takes on a different tag to distinguish the different formats in which it is stored.

60 File Organization

Procedures and functions within form files shall be separated by a blank line. A header description for each procedure and function will be provided where applicable.

6.1 File Naming Conventions

File names are made up of a base name, function name, and a period and extension. File names must follow the MS DOS 8 dot 3 convention. Supporting file structures are automatically generated.

<BASE NAME><FUNCTION>.<EXTENSION>

The categories of files are as follows:

a. b.

d. e. f. g- h. i.

k.

C.

j -

Executable files - 8x8 Microsoft Access 97 Database files - m d b Dynamic Link Library files - dll Help files - hlg Microsoft Windows IN1 files - Ani Microsoft Windows Bit Map files - Emg Backup files - bak Microsoft Word 97 files - doc Temporary files - tmg Table of Contents files - cnt Microsoft Windows Program Information files - gif

The following are examples of file names:

a. FORM = frm1553T.frm

b. ,BAS = globalsobas

c. MS Access Database = session.mdb

2

V 6.1.1 Object Naming Conventions

Table 6-1 defines the object naming conventions used in code development.

Table 6-1. Object Name Conventions

Prefix Comment

Label lbl List Box 1st List View lsv Mask Edit Box meb MDI Form mdi f rm

Tree View trv True DBGrid tdbg True Grid VBX tdgrd Vertical scroll vsb bar

3

6.1.2 U

Variable Naming Conventions

Table 6-2 defines the Variable Naming Conventions used in code development.

Table 6-2. Variable Naming Conventions

Notes : 1. Variables i, j, k, 1, m, and n will be

and used in places where their value is unambiguous:

For i = 1 to iArrayLength

next i sReceiveData (i) = %H"+ sTemp

reserved to be integers

2. All variables will be defined and at the beginning of each subroutine or event.

6.2 Program F i l e s

Program files describe the contents of a particular file. A description of the purpose of the objects in the files (whether they

form,

are functions , external data declarations or definitions , or other) is more useful than a list of the object names. The program files may optionally contain author(s), revision control informati-on, or references.

6.3 Other Files

An example is rcvb5.ini file, which might initialize the RS-232 communication ports and identify the operating system or contain paths to bi tmaps .

4

6.4 Comments

The comments should describe w h a t is happening, h o w it is being done, w h a t the parameters mean, w h i c h globals are used or modified, and any restrictions or bugs. Comments that are clear from the code should be avoided due to the information becoming outdated. with the code are of no value. Short comments should be w h a t comments, such as "compute mean value,,' rather than how. comments such as "sum of values divided by n.

Comments that disagree

6.4.1 Standard Structure for a Form (Used in Load event)

The following outline illustrates the standard structure for a Form ( u s e d i n L o a d event) .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

'SRD Section Reference: 2

'File Type: Form

'File Name: frmSigMon.frm

Southwest Research Institute

I

1

1

'Use: 1

1

1

'Description: I

I

I

I

This file communicates through the RS232 Port to the LASTE t o provide r e a l time feel3 back-of signal states on the A-10.

Data from the LASTE is queried by this form. (1) First a Control Y (ChrS(25)) is sent. The expected response is (in hlex): ODODOA3E3E. ( 2 ) LASTE is then asked for data on each signal. The query format is: MRP XXXXC:R where XXXX is the signal address and CR is a carriage return. (3) LASTE then responds with a 26 character data string. Characters 17, 18, 19 and 20 hold the signal values.

'Modification History: I Date Software Developer Reason 11-13-96 Ima Engineer Created 12-12-96 Vendela Kirsebom Changed GUT interface

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I***********************Variable definition**^*********************** Dim iLengthString As Integer Dim sCR As String 'Carriage Return Dim sLF As String 'Line Feed Dim SLASTETermination As String Dim cString As String Dim i, j , k As Integer Dim sControlY As String Dim sReceiveStr As String Dim sSendCommand(4) As String 'LASTE query

I * * * * * * * Error Trapping * * * * * * * On Error GoTo frmLASTEFunctionsErrorHandler

5

<Body of Program>

Exit Sub

frmLASTEFunctionsErrorHandler: Select Case Err.Number Case 55

Case 53 'File does not exist MsgBox ( ''File Already Open" )

MsgBox ("0tp.ini does not exist in C:\Windows - ending program") End

MsgBox ("Error is: 'I & Err.Number) End I End Program

Case Else

End Select Resume Next End Sub

6.4.2 Object Structure

The following outline defines the Object Structure (buttons, subroutines, etc.) used in the development of code.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

'Use: I

The event allows the user to cancel the RS232 communications.

I

'Description: When the user presses the Cancel command button a I global flag (glbbyteStopFlag) .is set True. The main form I frmSignalMonitor) periodically checks the state of the flag. 1 If the flag is True then the form is unloaded and the MDI I form (mdifrmSignalMonitor) is displayed. 1

'Modification History: Date Software Developer Reason

' 11-13-96 Ima Engineer Jr. Created I 12-12-96 Vendela Kirsebom Changed GUI interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I * * * * * * * Error Trapping * * * * * * * On Error GoTo cmdCancelErrorHandler

<Body of routine >

Exit Sub

cmdCancelErrorHandler: Select Case Err.Number Case 55

Case 53 'File does not exist MsgBox ("File Already Open")

MsgBox ( "Otp. ini does not exist in C: \,Windows - ending program") End

6

U Case Else

MsgBox ("Error is: 'I

End 'End Program End Select Resume Next End Sub

6 . 5 Declarations

Declarations or module.

& Err.Number)

should be placed in the decj .ara t ion section of the form

7

Software Development Plan for lthe PCSA Tool Revision 05

The Software Development Plan (SDP) describes the approach to be followed in the maintenance of the PCSA Tool.

1.0 SCOPE

The scope of this task is to maintain the PCSA Tool to provide the NRC and CNW RA staff the capability to conduct an independent confirmatory analysis arid to review the DOE preclosure safety analysis. The PCSA Tool structure is modeled after the safety analysis review methodology which is based on the requirements of 10 CFR IPart 63 for preclosure safety analysis of the geologic repository operations area. The review activity and the typical tool functions consist of (i) collection of site-specific data and information on facility operations and processes , (ii) natural and human-induced, and facility hazards analysis; (iii) event sequence analysis; (iv) categorization of events; (v) consequences analysis; (vi) safety assessment; and (vii) identification of structures, systems, and components important safety. In addition, the tool has the capability to assess system risk using an approach dleveloped by Benke et. al. (2002). The PCSA Tool uses a graphical user interface environment developed in Microsoft Visual Basic 6.0 to control the functions of the tool. The PCSA Tool makes use of the Microsoft Access database software and three other software packages: (i) SAPHIRE (Idaho National Engineering Laboratory, 1998), (ii) RSAC (Wenzel, 1994), and (iii) MELCOR (NRC, 2000). In addition, several utility codes were developed using the Lahey LF95 Fortran compiler.

2.0 BASELINE ITEMS

The baseline items are: (1) PCSA Tool template using MS Access database; (2) PCSA Tool code developed using Visual Basic 6.0; (3) Equipment System Failure Rate database and failure mode check list database; (4) SAPHIRE Version 6.80; (5) RSAC Version 6.2; (6) MELCOR Version 1.8.5; and (7) the suite of utility codes developed in Fortran: PCSA-LHS, PCSA-LHSINP, PCSA-PROB, PCSA-RSACRD, PCSA-IET'CCDF, and PCSA-TOTRISK.

3.0 PROJECT MANAGEMENT

This section contains the work breakdown structure for mainteinance of the PCSA Tool. Note that PCSA Tool Version 1 .O was released to NRC on 7/31/2002, PCSA Tool Version 2.0 was released to NRC on 6/27/2003, and PCSA Tool Version 3.0.0 was released to NRC on 9/20/2004.

3.1 Work Breakdown Structure

Tasks I Completion Date I Name I Hours

1 0/1/2004

1 1 /30/2004 1 1/30/2004 1 1 /30/2004 12/10/2004 12/10/2004 12/10/2004 12/10/2004

~

12/10/2004 12/10/2004

B. Dasgupta Acceptance Testing T. Maxwell Validation Testing G. Adams 12/10/2004

T. Maxwell SI0 12/10/2004

I I 5i76 I IESTIMATED HOURS TOTAL:

3.2 Project Schedule and Milestones

Milestone Descriotion Work Element Completion

Criteria Task 1 Update User Manual for Version 3.0

Task 2 Complete software changes

Completed Project Manual

Software Project changes made Manager

MI an ag e r Acceptance

Complete testing of the software I tested I Manager Software is Task 3

Acceptance Froject

-

Task 4

Estimated

Acceptance Software is F'roject

End Date 1 1 /30/2004

Complete QA review and release of version 3.0.1

12/10/2004

released Man age r Acceptance

12/10/2004

Team Member Project Role

12/10/2004

Stirrt Date

3.3 Staffing Plan

The following table contains the project team members that a.re planned to execute the project.

B. Dasgupta G. Adams T. Maxwell

Support, Manual Coding, Testing, Manual Testing, Manual

3.4 Risk Management

The following table contains the risk management plan for the project. The table contains each of the risks that have been identified for the project.

Risk Probability Impact to Project Running out of Low High budget Not completing in Medium High time

Mitigation Allocate appropriate funding

Closely monitor schedule, and add additional man-hours as

necessary

4.0 DEVELOPMENT PROCEDURES

0 CNW RA

4.1 Environment and Resources

Software Deve lo pm efi- and Testing

The following sections describe the hardware and software resources that will be utilized during the project.

Description Microsoft - Visual Basic 6.0 Professional Graphical User Interface Software Development Tool Microsoft Access (Office 97) Database Development Tool

Lahey/Fujitsu FORTRAN-95

4.1.1 Hardware Resources

Supplier Owner Purpose 0 Microsoft I7 CNW RA Software

Develop m en t

0 Microsoft [I CNWRA Database Development

0 Lahey CNWRA Software DeveloDment

The following table lists the hardware resources that will be utilized during the project.

Microsoft-Visual Source Safe 6.0a

SAPHIRE Version 6.80

RSAC Version 6.2

Description IBM Compatible PC -2 PlTOR Pentium IV 2.8 GHz clock 496 MB Ram 49.2GB Hard Drives

0 Microsoft I7 CNWRA Software Configuration

0 Oak Ridge [7 CNW RA Fault Tree & National Event Analysis Laboratory 0 Idaho National I7 CNWRA Radiological Dose Environmental Calculations and Engineering Laboratory

Monitor 21 " Super XGA monitor with resolution 1280x1 024 and 32 bit color

Printer Laser printer (shared)

Hardware Resources Sumlier

0 Net Force

0 NEC

Owner I PurDose

0 CN\ I R,

4.1.2 Software Resources

The following table lists the software resources that will be utillized during the project.

I Software Resources

I Software Resources I Description

MELCOR Version 1.8.5 Supplier Owner Purpose

0 Sandia 17 CNW RA Radionuclide National La bo rat0 rv

Windows XP

Install Shield DevStudio, Version 9.0

I Transport

0 Install Shield

0 Microsoft

Corporation

Crystal Reports 9.0, Developer

0 Crystal [7 CNWRA Report capability Decisions, Inc.

4.2 Software Development Lifecycle

will be used: The following coding style guide@) will be used:

The PCSA Tool is currently in the maintenance phase of the software development Iifecycle. Software updates will be documented on Software Change Reports (SCRs) and new releases will be provided and documented using Software Summary Forms and Software Release Notices.

0 Fortran 95 0 Fortran (Cook et al., 1990)

Visual Basic (see Appendices)

4.3 Coding

This section describes the coding conventions that will be applied throughout the project.

~~

I Coding Standards The following language@) I 0 Visual Basic 6

4.4 Acceptance Testing

The following table lists the documentation technique and tools that will be used for acceptance testing.

I Acceatance Testina Methodoloav I

0 Scientific Notebook 17 Other: 0 Software Development File 0 Software Change Report 0 Other:

5.0 CON FI GU RATION MANAGEMENT

This section contains the configuration management plan for the project.

5.1 Tools

Visual Source Safe V 6.0a by Microsoft will be used to perform software configuration management.

5.2 Configuration Identification

Software version numbers will be of the form Version V.v.r, where V is an incrementing major version number beginning at 1, v is a minor version number, and r is an incrementing revision number beginning at 0.

5.3 Configuration Procedures

The software will be maintained using Visual Source Safe by Microsoft. The software will reside on the personal computer PITOR located in directory D:\PCS;AToolSourceSafe.

5.3.1 C hec k-ink hec k-ou t Procedures

Software under development will be checked out of the repolsitory into a developer directory for modification. Modified files will be checked back into and nevvly created files will be added to the repository prior to release.

5.3.2 Creating Releases and Preparing For Deliveries

New releases of the software will be created at determined times during the project at the discretion of the developer. Procedure specified in TOP- 18 for creating a new release will be followed.

”

~ ~

I Automated 0 Other: backup tools:

c)

5.3.3 Problem Reporting and Change Control

A Software Change Report (SCR) will be used to track problems, design changes, and enhancements to the software.

5.3.4 Backups

The project repository will be used to store the baseline configuration items during development. The following parameters apply to the configuration repository.

I Project Files I ~~

Host information:

Backup media:

Backup frequency:

Host name: PlTOR Directory: D:\PCSAToolSourceSafe

0 Compact Disk (CD)

0 Weekly 0 Other: As needed.

6.0 REFERENCES

Benke, R. “Analytical and Numerical Solutions of the Expected Number of Occurrences for Combinations of Event Sequences due to Variability.” San Antonio, TX: Center for Nuclear Waste Regulatory Analyses. 2003.

Benke, R., B. Dasgupta, B. Sagar and A.Chowhdury, “A Methodology for Preclosure Risk Assessment for a Geologic Nuclear Waste Repository”, Probabilistic Safety Assessment and Management (PSAMG), Proceedings of the 6th lntenational Conference on Probabilistic Safety Assessment and Management, San Juan, Puerto Rico, June 23-28, 2002, Oxford: Elsevier Science, Ltd. Vol. I, pp. 983-988, 2002.

Cook, D. M., N.H. Marshall, E.S. Marwil, S.D. Matthews, and G.A. Mortensen, “Fortran Coding Guidelines”, EG&G Idaho, Inc. EGG-CATT-8898 Idaho Falls, ID: U.S. Department of Energy, Idaho Operations Office February 1990.

Idaho National Engineering Laboratory. “Systems Analysis Programs for Hands-on Integrated Reliability Evaluations (SAPHIRE) Version 6.0, Saphire Reference Manual.” Idaho Falls, Idaho: Idaho National Engineering Laboratory. 1 998.

Wenzel, D. R. and B. J. Schrader. “The Radiological Safety Analysis Computer Program (RSAC-6) Users’ Manual”. INEEUEXT-01-00540. Idaho National Engineering and Environmental Laboratory. 2001.

US. Nuclear Regulatory Commission. “MELCOR Computer Code Manuals”. NUREG/CR- 61 19, Revision 2. Washington, DC: U.S. Nuclear Regulatory Commission. October 2000.

U.S. Nuclear Regulatory Commission. NUREG-661 3, “Code Manual for MACCS2; Volume, Users Guide.” Washington, DC: NRC. May. 1998.

7.0 APPENDICES


APPROVED:

Signature of Element Manager Date

cc: QA Element Manager Principal Investigator

APPENDIX



V

1- Overview

The scope of this effort is coding in the MS Visual Basic (VB) coding style. The use of good VB style will encourage consistent layout, improve the portability, and consequently reduce the coding errors during the development of the software. Experience and good judgment should be used for those situations not covered by this procedure.

2 - Naming Standards

The software will use a consistent naming convention for variables throughout coding process as specified in paragraph 6.1.2, V a r i a b l e Naming Convent ions . Using a consistent standard for naming components in the program will save a significant amount of time during the code development process, and during future maintenance work.

3 m Variables

Variable names are used frequently in the process of code development; most statements contain the name of at least one variable. Through the use of a consistent naming system for variables, the programmer will be able to minimize the amount of time spent tracking down the exact spelling of a variable’s name.

By encoding some information about the variable itself into the variable name, the programmer can make it easier to decipher the meaning of any statement in which that variable is used, in addition to identifying errors that are otherwise difficult to find.

The attributes of a variable that are useful to encode into its name include its scope and its da ta type as outlined. in the following paragraphs.

4 m Scope

In VB, there are three scopes by which a variable may be defined. The three scopes include the following.

a. If defined within the procedure, the variable is local to that procedure.

b. If defined in the general declarations area of a form or module, then that variable can be referenced from all procedures in that form or module, and is said to have filodule scope .

C. If it is defined with public keyword, then it is global to the application.

1

V 5. Data Types

VB supports an assortment of data types. By encoding the type of variable in its name, the programmer can visual.ly check that the assignment to that variable is credible. error quickly.

This helps the programmer to identify an

Encoding the data type into the variable name has another benefit: the capability to reuse data names. If the prclgrammer needs to store the start date in both a string and a double, then the same root name for both variables can be used. The start date is always the StartDate; it takes on a different tag to distinguish the different formats in which it is stored.

6. File Organization

Procedures and functions within form files shall be separated by a blank line. A header description for each procedure and function will be provided where applicable.

6.1 File Naming Conventions

File names are made up of a base name, function name, and a period and extension. File names must follow the MS DOS 8' dot 3 convention. Supporting file structures are automatically generated.

<BASE NAME><FUNCTION>.<EXTENSION>

The categories of files are as follows:

a. b.

d. e. f. g * h. i.

k.

C.

j -

Executable files - exe Microsoft Access 97 Database files - m d b Dynamic Link Library files - dll Help files - hlp Microsoft Windows IN1 files - ini Microsoft Windows Bit Map files - bmp Backup files - bak Microsoft Word 97 files - doc Temporary files - tmp Table of Contents files - cnt Microsoft Windows Program Information files - pif

The following are examples of file names:

a. FORM = fzm1553T.frm

b. .BAS = globalsobas

c. MS Access Database = session.mdb

2

w 6.1.1 Object Naming Conventions

Object Chec kbox Combo box Command Button Common dialog box Communications

W

Prefix Comment chk cbo cmd dlg com

Table 6-1 defines the object naming converitions used in code development.

Table 6-1. Object Name Conventions

Data I dat Directory List I box dir

Drive List Box File list box Frame Group Push Button Horizontal Scroll bar Image Label List Box List View Mask Edit Box

IMDI Form

drv fil f ra gpb hsb

img lbl 1st lsv meb mdi f rm

3

'c, 6.1.2 Variable Naming Conventions

m e Prefix Static sta Constant con Variant var Integer i Long 1 Single f Double d Currency cur

w

Comments staiInitialize consName

Table 6-2 defines the Variable Naming Conventions used in code development.

String Byte Boolean Date Object Global (Public) Array Database Recordset

Table 6-2. Variable Naming Conventions

~ ~~

S

by b da obj g glbiArrayCounter arY db rs

Notes : 1.

Workspace ws I I Variables i, j, k, 1, m, and n will be reserved to be and used in places where their value is unambiguous:

For i = 1 to iArrayLength

next i sReceiveData (i) = '&H"+ sTemp

2. All variables will be defined and at the beginning of subroutine or event.

6.2 Program Files

Program files describe the contents of a plwzticular file. description of the purpose of the objects in th'e files (whether functions, external data declarations or definitions, or other)

integers

each form,

A they are is more

useful than a list of the object names. The program files may optionally contain author(s), revision control information, or references.

6.3 Other Files

An example is rcvb5.ini file, which might communication ports and identify the operating bi tmaps .

initialize the RS-232 system or contain paths to

4

.

6.4 Comments

The comments should describe w h a t is happening, h o w it is being done, w h a t the parameters mean, w h i c h globals are used or modified, and any restrictions or bugs. Comments that are clear from the code should be avoided due to the information becoming outdated. Comments that disagree with the code are of no value. Short comments should be w h a t comments, such as "compute mean value," rather than h o w comments such as "sum of values divided by n. ' I

6.4.1 Standard Structure for a Form (Used in Load event)

The following outline illustrates the standard structure for a Form (used i n Load event) .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

' Southwest Research Institute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

'SRD Section Reference: 2 1

'File Type:

'File Name: 1

1

'Use: I

1

1

'Description: 1

1

1

1

I

'Modification ' Date ' 11-13-96 ' 12-12-96

Form

frmSigMon.frm

This file communicates through the RS232 Port to the LASTE to provide real time feed back of signal states on the A-10.

Data from the LASTE is queried by this form. (1) First a Control Y (ChrS(25)) is sent. The expected response is (in hex): ODODOA3E3E. (2) LASTE is then asked for data on each signal. The query format is: MRP XXXXCR where XXXX is the signal address and CR is a carriage return. (3) LASTE then responds with a 26 character data string. Characters 17, 18, 19 and 20 hold the signal values.

His tory : Software Developer Reason Ima Engineer Created Vendela Kirsebom Changed GUI interface

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I***********************Variable Definition************************** Dim iLengthString As Integer Dim sCR As String 'Carriage Return Dim sLF As String 'Line Feed Dim SLASTETermination As String Dim cString As String Dim i, j , k As Integer Dim sControlY As String Dim sReceiveStr As String Dim sSendCommand(4) As String 'LASTE query

I * * * * * * * Error Trapping * * * * * * * On Error GoTo frmLASTEFunctionsErrorHandler

.

<Body of Program>

Exit Sub

frmLASTEFunctionsErrorHandler: Select Case Err.Number Case 55

Case 53 'File does not exist MsgBox ( ''File Already Open")

MsgBox ( "Otp. ini does not exist in C: \Ci'indows - ending program") End

MsgBox ("Error is: I' & Err.Number) End ' End Program

Case Else


6.4.2 Object Structure

The following outline defines the Object Structure (buttons, subroutines, etc.) used in the development of code.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

' Use : The event allows t he user t o cancel the RS232 1 communications.

'Description: When the user presses the Cancel command button a I

1 global flag (glbbyteStopFlag) is set True. The main form 1 frmSignalMonitor) periodically checks the state of the flag.

1 form (mdifrmSignalMonitor) is displayed. 1 If the flag is True then the form is unloaded and the MDI

1

'Modification History: Date Software Developer Reason 11-13-96 Ima Engineer Jr. Created

' 12-12-96 Vendela Kirsebom Changed GUI interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I * * * * * * * Error Trapping * * * * * * * On Error GoTo crndCancelErrorHandler

<Body of routine >

Exit Sub

cmdCancelErrorHandler: Select Case Err.Number Case 55

Case 53 'File does not exist MsgBox ( "File Already Open" )

MsgBox ( "Otp. ini does not exist in C: \W:indows - ending program") End

6

. V

Case Else MsgBox End


("Error is: I' & Err.Number) 'End Program

6 . 5 Declarations

Declarations should be placed in the d e c l a - a t i o n section of the form or module.

7

SOFTWARE DEVELOPMI3 T PLA

Documents

Transcript of SOFTWARE DEVELOPMI3 T PLA