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 Manager Acceptance
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
Project Manager Acceptance
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
Monitor 17" Super XGA monitor with resolution 1280x1 024 and 32 bit color
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
Monitor 21" Super XGA monitor with resolution 1280x1 024 and 32 bit color
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
Visual Basic Coding Standard
APPROVED:
Signature of Element Manager Date
cc: QA Element Manager Principal Investigator
APPENDIX
Visual Basic Coding Standard
Visual Basic Coding Standard
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
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 : 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
End Select Resume Next End Sub
("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
Top Related