ML20237C985
Text
. . _ _ _ _ _ _ _ _ _ _ _ _ . . .
7
.. m .
@ REGug
/ UNITED STATES k'g NUCLEAR REGULATORY COMMISSION
[]
- g. .. p WASHINGTON, D. C. 20555 o,, ,
a
%O l
l D$0 0FFERORS:
SUBJECT:
REQUEST FOR PROPOSAL NO. RS-AED-87-129 ENTITLED, " EMERGENCY RESPONSE DATA SYSTEM IMPLEMENTATION" The U.S. Nuclear Regulatory Commission (NRC) is soliciting proposals for the project entitled above. The full scope of work anticipated is as set forth in Part I, Schedule.
It is our intention by this solicitation to secure the best qualified organization available to perform this project, cost and other factors consi6ered.
Proposals for this requirement may be submitted by all concerns, i.e., large businesses, small businesses, and small be*4nesses owned and controlled by socially and economically disadvantaged , ividuals. Enclosed with this solicitation is a list of large business 1irms responding to the notice in the Commerce Business Daily. Small businesses may wish to contact these firms for potential subcontracting opportunities under this requirement. The presence of a firm's name on the list in no way constitutes NRC's acceptance of the firm for award under this solicitation. A copy of this solicitation and all subsequent amendments have been provided to firms on this list.
The solicitation package is enclosed. If you desire to respond, your proposal should address the proposal requirements set forth in Section L of the solicitation. All proposals will be evaluated against the evaluation criterie shown in Part IV, Section M.
If you have any questions concerning the requirements of this solicitation, please contact Mrs. Patricia Smith, Senior Contract Negotiator, on (301) 492-4278 (collect calls will not be accepted).
Sincerely, T./
['
Q 222 g Bn 210 PatIiciaA." Smith..
SHDLLYB7-737 PDR Contracting Officer
Enclosures:
- 1. List of Large Business Firms
- 2. Solicitation Package 6,
e .
RAT 4NG PAGE OF SOLICITATION,0FFER AND AWARD E F " ^ ' " ^ "
%*t$'B sA RE l AND/ DS G.1 > 1 l 60 ,,,,,,
- 2. CONT R ACT No. 3. 50 LAC 6T A140N 90. A T VPE OF 50L 60tTAT60N 5.DA'E855VED 6. R E QU. sit 60N/PU RCHA5E "O'
] ADVERTISED (IFB)
RS-AED-87-129 May 12,198; 01E-87-129
] NEGOTIATED (RFP) 7, ISSUED DV S. ADDRESS OF FE R TO (If other than item 7)
CO E U.S. Nuclear Regulatory Commissfonl All proposals should be addressed as indicated Division of Contracts in Item 7. However, handcarried proposals--
Washington, DC 20555 including EXPRESS MAIL and other commercial RFP No: RS-AED-87-129 delivery services--must be delivered to the NOTE : In advertised sohcitations "of fer" and "of feror" mean " bid" and " bidder"M N N 3H A# 2 W3W*
SOLICITATION
- 9. Scaled offers in original and _._SEVall__ copies for furnishing the supphes or services in the Schedute will be received at the place specified in item 8, or if handcarried in thedepository hstedin A550 MontgomPrv Avenue _Bethesda._tg _ untii 4:00_fL time _ June 15. 1987 Room 2223 (Sec'ond Floor)
CAUTION - LATE Subinissions. Modifications, and Wsthd owais- See Section I, Provision No. 52.214 7 or $2.215-10. All offers are subject to all terms and conditions contained in this sohcetation.
- '"#"' "' * "" " ' "O' #"#'"d' **" # d' # '# U # O ##
- 10. FOR INFORMATION CALL: Patricia A. Smith (301) 492-4278
- 11. TABLE OF CONTENTS W)lSEC. l DESCRIPTION lPAGE(S) y) l SEC. l DESCRIPTION lPAGE(S)
PART I - THE SCHE DULE PART 11 - CONT R ACT CLAUSES
^ A SOLICITATION / CONTRACT FORM 1 Xl 8 l CONTRACT CLAUSES l 42
^ B SUPPLIES OR SERVICES AND PRICES / COSTS 2 PART IH - LIST OF DOCUMENTS, EXHIBITS AND OTHL R ATTACH.
A A
C DESCRIPTIONISPE CS1 WOR K ST AT E MENT 3 XlJ l LIST OF ATTACHMENTS l 44 D PACKAGING AND MARKING )) PART W ~ REPRESENTATIONS AND INSTRUCTIONS l
^ E INSPECTION AND ACCEPTANCE II g R E PRE SE NTAT IONS. CE RTI F ICAT IONS AN D
^ OTHER STATEMENTS OF OFFERORS F DELIVERIES OR PERFORMANCE I3 X 44 A c CONTRACT ADMINISTRATION DATA 18 X L INSTRS . CONDS., ANO NOTICES TO OF F E R 51 A H SPECIAL CONTRACT RE OutREMENTS M X M EVALUATION FACTORS FOR AWARD 8@
O F F E R (Must be fully completed by oife'orf NOTE: Item 12 does not apply if the solicitation includes the provisions at $2.21416, Minimum Bid Acceptance Period.
l 12. In comphance with the above, the undersigned agrees, if this of fer is accepted within calendar days (60 calendar days unless a dt/terent l period is anserted by the offeror) from the date for receipt of of fers specif i ed above, to furnish any of all items upon which praces are offered at the priCo Set i
opposite each item,dehvered at the desiDnated point (s), wethin the time specified in the schedule.
- 13. DISCOUNT FOR PROMPT PAYMENT 10 C ALENDAR OA V5 20 C ALENDAR DAM 30 CALENDAR DAG CALENDAR DAM (See Sectson L Clause No. 62 232 8) cfg cfn efn %
- 14. ACKNOWLEDGMENT OF AMENDMENTS AMENDME NT NO DATE AMENDMENT NO. DATE (The offeror ocainoudedges recespt of amend.
ments to the SOLICITA TION for offerors and related documents numbered and dated:
15A, N AME C# I#C #I E R (Type or pr t)
AND ADD R ESS OF OFFEROR 158. TELEPHON E NO. (laclude erra 15C. CHE CK QF REMITT ANCE ADDRESS 17. SIGN AT i> R E 18. OF F E R DAT E
'Od') f l tS DIF FE RENT FROM ABOVE - ENTE R L_J SUCH ADDRESS IN SCHrDUt f AWARD (To be completed by Govemment)
- 22. SUBMIT INVOICES TO ADDRESS SHOWN IN (4 topars unless otheraukse specified) to U.S C. 2304(a) ( ) )
C 41 U.S.C. 252(c) (
- 24. ADMINISTE RED BV ilt other than item 7) cong g 25. PAYMENT WILL BE MADE BV CODE l
- 26. NAME OF CONT R ACT ING OF F IC E A (T)pe or print) 27, UNtTTD STATES OF AMERICA 28, AW ARD DAT E
'j LSsenature of Contreettne Offlect) gPORT ANT - Award will be made on this Form, or on Standard Form 26. or by other authorised official written notice.
M l'ST. 64tbot- ts2134 33 132 ST ANDARD FORM 33 (REv.10 83)
PREVKVS E DiTION NOT USABLE Prescrit#ed t>y GSA
@ GPO 1984 0 - 421-526 (25) F AR ta8 CF R) 53.234(C)
1 1
, ENCLOSURE 1
)
j List of organizations who responded,to NRC's notice in the Commerce Business J Daily, concerning this solicitation, whegindicated to NRC that they were large !
businesses:
Vanguard Technologies Corporation Infotron Systems Corporation )
One Flint Hill, Suite 300 8521 Leesburg Pike 10530 Rosehaven Street Suite 440 j Fairfax, Virginia 22030 Vienna, Virginia 22180 First Data Resource Inc. Science Applications Government Services 1.
International Corp.
] 1900 N. .Beauregard Stieet 1710 Goodridge Drive Suite #110 McLean, Virginia 22102-1315 Alexandria, Virginia 22311 Contel ASC EI Inte Tational, Inc.
Government Networks Division P.O. Box '/36 i
, 7916 Westpark Drive One Energy Drive fcteau, Virginia 22102 Idaho Falls, Idaho 83402 y
,AT&T Federal Systems 1120 20th Street, N.W., 7th Floor Wdshington, DC 20036 , ,
1 1 7
? ,
=
I a
t
(
k a
RS-AED-87-129 PAGE 2 Section' B - Supplies or Services and Prices / Costs B.1 Brief Description of Work
" Emergency Response Data System Implementation" The objective of this project is to implement an Emergency Response Data System (ERDS). The ERDS design concept is an electronic transmis-sion link from the existing electronic data systems used by licensed nuclear power plants at their facilities. The link is to provide i automatic updating of a limited set of data necessary for the NRC to independently assess and project the condition of the plant, and to assess whether appropriate recommendations are being made to state and local officials with respect to measures which should be taken to protect the public during an emergency at a licensed nuclear power plant.
The contractor will be responsible for finalizing the designs, procuring, installing, and testing the hardware; and developing, installing, and testing the software necessery for the ERDS based on the design produced by the ERDS Requirements Analysis. This includes the equipment other than the telecommunications network for transmission of the data stream from the . licensee to the NRC Operations Center, and the Headquarters hardware and software for the receipt, reformatting, display, and retransmissions of the data. This does not include any significant new hardware or software modifications to licensee equipment.
B.2 Consideration and Obligation, a.
It is estimated that the total ccst to the Government for full performance of this contract will be ! *
, of which the sum of $
- represents the estimated reimbursable costs, and of which $
- l represents the fixed fee,
- b. There shall be no adjustment in the amount of the Contractor's fixed fee by reason of differences between any estimate of cost for performance of the work under this contract and the actual cost performance of that work.
- c. The amount presently obligated by the Government with respect to this contract is S *
- d. It is estimated that the amount currently obligated will ccver performance of work / phases / tasks through the corresponding month reflected in the Contractor's current NRC approved Spending Plan,
- To be incorporated into any resultant contract.
i 1
i n .
l
~- . . .
l RS-AED-87-129 PAGE 3 Section C - Description / Specifications / Work Statement C.1 Statement of Work C.I.1 Background This section describes the history and purpose of the Einergency Response Data System (ERDS) and its function during an emergency at a licensed nuclear power facility. The program for developing and implementing ERDS is described and the contractor's role in that program is delineated.
C.1.1.1 Purpose of the ERDS The NRC, by virtue of its position as a regulator of commercial nuclear power plants, will be involved in monitoring any emergency at' a licensed reactor that has the potential of affecting the public health and safety. While the licensee is always responsible for operating the plant, the NRC has a role in assessing the overall edequacy of licensee actions and recommendations for mitigating the accident consequences and protecting the public. The NRC may also develop independent analyses to assure that the public is fully protected, because experience indicates that Governors and other authorities may call upon the licensee and/or the NRC for advice. This'NRC role in protecting the health and safety of the public requires access to certain data from plants during emergencies tLat is as timely and accurate, though not nearly as extensive, as that available to the licensee. The current method of manual data collection and telephoned reports is marginal to unacceptable for the NRC to perfonn its role during emergencies. This process has frecuently proven unreliable and inaccurate during events and exercises. Errors are frequently introduced during acquisition, transcription and verbal transmission. The process has been burdensome to technical personnel at the plant site and at NRC. The Commission has determined that improved data acquisition capabilities are essential to enable the l Commission to adequately fulfill its response role during emergencies. j C.1.1.2 History of ERDS As a result of the March 28, 1979, accident at Three Mile Island I Unit 2, and at numerous less serious events and exercises since that time, the NRC recognized the need to substantially improve the NRC's capability to acquire data on plant conditions during emergencies..
The staff's response to this need immediately following the acci-dent at Three Mile' Island included a proposal for a Nuclear Data Link (NDL).- A conceptual design for a NDL was produced under contract with Sandia National Laboratories, and, in April 1981, the Commission directed the staff to proceed with an NDL prototype program. However .
beginning in June 1981, a series of Congressional actions and requests
__.__.________.__________________.___i
RS-AED-87-129 PAGE 4 caused the NRC to reassess releasing a Request for Proposal to conduct a prototype study. In the FY 1983 Pay Raise Supplement and the FY 1984 Appropriations Bills, the Congress took actions that effectively rejected several NRC requests to the Congress to allow the NDL to proceed. However, the NRC's FY 1984-85 Authorization required that the NDL concept be included as part of any analysis of alternative means for upgrading NRC data acquisition.
The FY 1984-85 Authorization Act required the analysis of four issues before an NDL or similar system could be implemented: (1) the appro-priate role of the Commission during an accident, (2) the information needed by the Commission to support that role, (3) the alternative means of acquiring that data, and (4) any changes in Comission author-ity necessary to enhance Commission response to nuclear emergencies.
The Act also required a cost-benefit analysis of the alternatives considered for acquiring the data. The staff addressed these issues in SECY-84-481 dated December 26, 1984, and following Commission approval, provided a response to Congress. The response described the NRC role in an emergency, as defined by the Commission, as one of monitoring the licensee to assure that appropriate recommendations are made with respect to offsite protective actions. The Commission, at this point, abandoned the NDL concept as being inappropriate to this agency role. The response stated that the Comission had selected the Emergency Respcnse Data System (ERDS) concept as the most appropriate means to support its emergency response role.
C.1.1.3 Program Plan C.1.1.3.1 - Phase 1. The first phase of the ERDS program was completed with the selection of the ERDS concept as the appropriate data acquisi-tion system. Options considered included various means of acquiring the data: manually, automatically from existing systems, or automati-cally with new systems. Options considered for transmitting the data to the Operations Center included electronically formatted data, image facsimile, and voice communications between specially trained and qualified personnel. The criteria used to compare these options included accuracy, reliability, timeliness, completeness, cost, per-sonnel requirements, and backfitting requirements.
The ERDS design concept embodies automatic acquisition of a predeter-mined list of plant parameters, with electronic transmission of the data over standard telephone or other NRC previded communication line <
to a computer at the NRC Operations Center. The ERDS approach emphasizes utilization of licensees existing electronic data systems and minimizes ,
the need for licensees to backfit their systems. Any parameter on the NRC's list which is not on a particular licensee's computer system will be transmitted by voice rather than reoviring the licensee to add the parameter to its system. In most cases data will be accepted
RS-AED-87-129 l PAGE 5 i
in the licensee's format to minimize the licensee's software develop- i ment requirements. Transmissions will be manually initiated by the l licensee af ter declaration of an emergency at the site. Upon receipt at the Operations Center, the ~ data will be automatically converted .'
to a standard format for display, logging and potential retransmissions.
Provisions will be made for display of the converted data stream in the Incident Response Center of the appropriate NRC regional office, on appropriate equipment available to the NRC site team, and other locations. This concept has been tested twice in exercises with Dule !
Power Company's McGuire facility and with Coninonwealth Edison's LaSalle fecility. Both tests demonstrated major improvements in assessments and communications due to the regular, accurate, time-tagged updating of a limited set of parameters.
C.1.1.3.2 - Phase 2. In the second phase, e contractor (the ERDS Requirements Analyst) surveyed the existing parameter availability and electronic data systems at most of the operating or nearly completed nuclear power plants in order to determine the appropriate means to acquire data from each facility and the variety of formats and conventions which must be accommodated by the receiving system at NRC headquarters. The contractor determined the hardware require-ments at the sites, at the Operations Center, and at the Regional Incident Response Centers. The contractor determined software functional requirements for each site and for the reformatting,' display, and retransmissions operations at NRC headquarters. The detailed report of the requirements is provided as Attachment 6.
C.3.1.3.3 - Phase 3. In the third phase, a contractor (the ERDS Imple-mshtation Contractor) will implement the Emergency Response Data System.
Based on the system design produced in phase 2 the ERDS Implementation Contractor will firt.lize the oesign; procure, install, and test the necessary hardware; and develop, install, and test the necessary ',
software to produce a functional ERDS. The contractor will furnish a fully operational system.
C.1.1.4 Role of the NRC The NRC will provide overall program direction and review and I approve all plans and deliverable documents. Plans and documents will be approved or disapproved by the NRC Project Officer.
The NRC is responsible for arranging and scheduling the participa-tion of licensees with ERDS implementation. The NRC will monitor the contractor-licensee interaction to help prevent any difficulties and to help resolve any problems which might arise. The NRC will arrange dCcess to any existing NRC equipment which may interface with the ERDS.
l
RS-AED-87-129 PAGE 6 C.1.1.5 Role of the Contractor The contractor shall assume complete technical and administrative responsibility for completion of work described in a plan that has been approved by the NRC.
The contractor shall notify the contracting officer as soon as pos-sible of any circumstances that may cause a "significant variation" in the effort or schedule from that described in the approved plan.
Failure to meet a scheduled milestone or ten percent or more overrun at the end of any month above the budget planned for that month are examples of "significant variation."
C.1.2 Objective The objective of this effort is to implement the Emergency Response Data System.
C.I.3 Scope All efforts being sought by this solicitation constitute the third (implementation) phase of the ERDS program described in Section C.1.1.3.3.
Offerors are required to propose an approach, costs, and a schedule for completion of all efforts described in Section C.1.4. The successful offeror will become the ERDS Implementation Contractor, and the contract will be awarded for all work described in the Work Statement.
C.l.4 Work Statement C.I.4.1 Familiarization C.I.4.1.1 - The contractor shall become familiar with the NRC Inci-dent Response Program, including the roles and responsib111 ties of the agency and its response personnel as described in the NRC Incident Response Plan (NRC Manual Chapter 0502) and other docu-ments available in the NRC Public Document Room. See Section C.1.5.
C.1.4.1.2 - The contracter shall become familiar with the functions, activities, and operational organization of the NRC's Reactor Safety Team and Protective Measures Team, which directly utilize the data received from the site of the nuclear power plant during an event.
The contractor is responsible for understanding the uses for which the data is to be acquired and the prnblems which are to be corrected by implementation of ERCS.
C.I.4.1.3 - The contractor shall become familiar with the design con-cept of ERDS and the reasons that this approach was selected.
.FS-AED-87-129 PAGE 7
~
C.1.4.1.4 - The contractor shall become fan.iliar with the results.cf the ERDS Requirements Analysis. This includes the information on the licensees' equipment contained in the survey report and the hardware and software design specifications in the design report. In addition there may be additional design requirements, to be incorporated prior to implementation, which may have been added subsequent to completion of the Requirements Analysis. Any changes in the design requirements made by NRC after contract award shall be made under authority of FAR 52.243-2 " Changes" and may be subject to an equitable edjustment in price and/or other contract terms.
C.I.4.2 Implementation of the ERDS Transmission, Reception, and Storage System C.1.4.2.1 - The contractor shall prepare a detailed plan, schedule, and budget for establishing an ERDS connecticn with each plant on '
the list (under Section C.I.6) as described below in sections C.I.4.2.2, C.1.4.2.3, and C.I.4.2.4. The plan shall address plant by i plant and Headquarters implementation as separate and concurrent tasks. The plan shall be submitted to and reviewed by the NRC prior to initiation of work by the contractor. The contractor shall provide as part of the implementation plan for each site.and headquarters a formel Work Breakdown Structure which shows in detail the tasks to be performed and the resources allocated to each task.
C.l.4.2.2 - The contractor shall determine the appropriate hardware to satisfy the design specifications in the ERDS Requirements Analysis Report (Attachment 6). Following approval by the NRC, the contractor shall procure, on behalf of the NRC, install and test the hardware specified. Prior to procurement, all hardware requirements will be
~
reviewed and approved by the Division of Computer and Telecommunications Services, Office of Administration and Resources Management.
C.I.4.2.3 - The contractor shall develop, install, test, and ensure operability of' the software necessary for reception, storage, use and retransmissions of the ERDS transmission from each plant as follows: 1 In conjunction with the NRC, arrangements will be negotiated with each plant to provide an ERDS output transmission from the site to the NRC.
- As each licensee transmission design is finalized the contractor will develop, install, test, and ensure operability of the .
software necessary for receipt and modification, if necessary, !
of the data stream on the Operations Center ERDS hardware in compliance with the design specifications in the ERDS Requirements Analysis Report.
RS-AED-87-129 PAGE 8
- The contractor shall develop, install, test, and ensure operability of the software for storage of the data in compliance with the design specifications in the ERDS Requirements Analysis Report.
- The implementation shall be done in a manner that assures that the completed portions of the ERDS system are maintained in an operable condition at an effectiveness level of 99.9% or more over the duration of the project. The incorporation of each new plant transmission shall not affect the operability of the ERDS with the plants whose connections have been made. The contractor is responsible for all maintenance of the system from initiation to expiration of the contract.
The contractor shall acquire or otherwise provide a formal Configuration and Change Control Management program. This program will be maintained at a site accessible to the NRC (either on a micro computer located at NRC, on NRC's Data General MV/8000, or at a facility where NRC now has timesharing services.) The program will be used to track the configuration, changes, errors reported, end corrections made to all NRC owned or maintained hardware and software in the Emergency Response Data System. The system will be in place before more than five percent of the ERDS sites have been completed, and at the conclusion of the contract the contractor will provide training to NRC personnel in the use of the system.
l C.1.4.2.4 - All software will be documented in accordance with the criteria in NRC Manual Chapter 090a (Attachment 7).
C.I.4.3 Implementation of the ERDS Display System C.I.4.3.1 - The contractor shall prepare a detailed plan, schedule, and monthly budget for the implementation of the ERDS display system as described in sections C.I.4.3.2 and C.I.4.3.3. The plan shall be submitted to and reviewed by the NRC prior to initiation of work by the contractor. The NRC will complete its review within three weeks of receipt from the contractor.
The contractor shall coordinate the design and implementation of the ERDS Display System with the Division of Computer and Telecommunications Services, OARM to insure that the ERDS Display System is fully integrated with all other programs' involving data and information transfer in the Operations Center.
C.I.4.3.2 - The contractor shall develop, install, test, and ensure operability of the software for the ERDS displays at the Operations Center in accordance with the design specifications in the ERDS Requirements Analysis Report.
C.I.4.3.3 - All software will be documented in accordance with the criteria in NRC Manual Chapter 0904 (Attachment 5 ).
RS-AED-87-129 PAGE 9 l
)
C.1.4.4 Implementation of the ERDS Re-transmission System I C.'1.4.4.1 - The contractor shall prepare a detailed plan, schedule, and monthly budget for the implementation of the ERDS re-transmis- 1 sion system as described in section C.I.4.4.2 and C.I.4.4.3. The plan shall be submitted to and reviewed by the NPC prior to initiation of work by the contractor. The NRC will complete its review within three weeks of receipt from the contractor.
C.1.4.4.2 - The contractor shall develop, install, test, and ensure l operability of the software at the Operations Center for the re-trans-mission of the ERDS data to the Regional Incident Response Center, the Regional Site Team, and other locations in accordance with the design specifications in the ERDS Requirements Analysis Report.
C.1.4.4.3 - All software will be documented in accordance with the criteria in NRC Manual Chapter 0904 (Attachment 7).
C.I.4.5 Produce a Users Manual and Provide Training C.1.4.5.1 - Following completion of the efforts described in Section C.1.4.3, the contractor will produce a Users Manual for that portion of the system and provide training sessions for the intended users.
For proposal purposes assume two training sessions at NRC Headquarters.
C.1.4.5.2 - Following completion of the efforts described in section C.1.4.4, the contractor will produce a Users Manual for that portion of the system and provide training sessions for the intended users.
For, proposal purposes assume two training sessions at NRC Headquarters and one at each of five regional offices.
C.I.5 References
- a. USNRC Manual Chapter 0502, NRC Incident Response Program
- b. Criteria for Preparation and Evaluation of Radiological Emergency Response Plans and Preparedness in Support of Nuclear Power Plants, USNRC Report NUREG-0654, Revision 1, November 1980
- c. Functional criteria for Emergency Response Facilities, USNRC Report NUREG-0696, February 1981 References are available in the NRC Public Document Room at 1717 H Street, N.W., Washington D.C.
l
RS-AED-87-129 PAGE 10 l
C.1.6 List of Plants Arkansas .1. Eine Mile Point 1 Arkansas 2 Nine Mile Point 2 Beaver Valley 1 ilorth Anna 1 Beaver Valley 2 North Anna 2 Big Rock Oconee 1 Braidwood 1 Oconee 2 Braidwcod 2 Oconee 2 Browns Ferry 1 Oconee 3 Browns Ferry 2 Oyster Creek 1 Browns Ferry 3 Pelisades Brunswick 1 Palo Verde 1 Brunswick 2 Palo Verde 2 Byron 1 Palo Verde 3 Byron 2 Peach Bottom 2 Callaway 1 Peach Bottom 3 Calvert Cliffs 1 Perry 1 Calvert Cliffs 2 Pilgrim 1 Catawba 1 Point Beach 1 Catawba 2 Point Beach 2 Clinton 1 Prairie Island 1 Comanche Peak 1 Prairie Island 2 Cook I Quad Cities 1 Cook 2 Quad Cities 2 Cooper Station Pancho Seco 1 Crystal Piver 3 River Bend 1 Davis-Bessse 1 Robinson 2 Diablo Canyon 1 Salem 1 Diablo Canyon 2 Salem 2 Dresden 2 San Onofre 1 Dresden 3 San Orofre 2 Duane Arnold San Onofre 3 Fermi 2 Seabrook 1 Farley 1 Sequoyah 1 Farley 2 Sequoyah 2 Fitzpatrick Shorehan 1 Fort Calhoun 1 South Texas 1 Ginna St. Lucie 1 Grand Gulf 1 St. Lucie 2 Haddam Neck Summer 1 Harris 1 Surry 1 '
Hatch 1 Surry 2 Hatch 2 Susquehanna 1 Hope Creek 1 Susquehanna 2 Indian Point 2 Three Mile Island 1 Indian Point 3 Trojan 1 Kewaunee Turkey Point 3 LaSalle 1 Turkey Point 4 LaSalle 2 Vermont Yankee 1 Limerick 1 Vogtle 1 liaine Yankee Washington Nuclear 2 McGuire 1 Waterford 3 i' McGuire 2 Watts Bar 1-Millstone 1 Wolf Creek 1 Millstone 2 Yankee-Rowe 1 ,
Millstone 3 Zion 1 '
Monticello Zion 2 1
l
3
- t. *
-l RS-AED-87-129 PAGE-11 Section D - Packaging and Marking D.1 Packaging and Marking When Delivering a Product The Contractor shall package material for shipment to the NRC in such a manner that will insure acceptance by common carrier and safe delivery at destination. Containers and closures shall comply with the Interstate Coninerce Commission Regulations, Uniform Freight Classification Rules, or regulations of other carriers as applicable to the mode of transportation. On the front of the package, the Contractor shall clearly identify the contract number under which the product is being provided.
Section E - Inspection and Acceptance E.1 Place of Inspection and Acceptance ,
Inspection and acceptance of the deliverable items to be furnished hereunder shall be made by the Project Officer at the destination.
E.2 Standard of Performance and Acceptance of ADP Equipment
- d. General. This clause establishes a standard of performance which must be met before any ADP equipment delivered under this contract is accepted by the Government. This also includes replacement machines, substitute machines, and machines which are added or field modified (modifications of a machine from one model to another) af ter a successful performance period,
- b. Performance Period and Effectiveness Level. The performance period shall begin with the completion of the first site data reception portion of the system and shall end when the system has met the standard of performance for a period of 365 consecutive days by operating in confomance with the Contractor's technical specifications and functional descriptions, or as quoted in the Contractor's proposal, which must satisfy the requirements of this contract, at an effectiveness level of 99.9 percent or more.
- c. Failure to Meet Standard Performance. If the system fails to )
meet the standard of performance after 180 calendar days from the installation date or start of the perfomance period, whichever is later, the Government may at its option request a i replacement or terminate the contract and request the intnediate removal of the equipment.
l
RS-AED-87-129 PAGE 12
- d. Effectiveness Level Computations. The effectiveness level for a system is computed by dividing the operational use time by the sum of the operational use time plus system failure downtime.
- e. Changes ir. Equipment. The effectiveness level for machines added, field-modified, or substituted, or for a replacement machine is a percentage figure determined by dividing the operational use time of the machine by the sum of that time plus downtime resulting from equipment failure or the machine being tested,
- f. Operational Use Time for System. Operational use time for performance testing for a system is the accumulated time during which the Central Processing Unit is in actual operation, including any intervals of tine between the start and stop of the processing of the programs.
- p. Operational Use Time for Equipnent. Operational use time for performance testing for a machine added, field-modified, or substituted or for a replacement machine is defined as the accumulated time during which the machine is in actual use.
- h. System Failure Downtime. System failure downtime is that period of time during which the scheduled productive workload, or simulated workload, being used for acceptance testing cannot be continueo on the system due to machine (s) failure. If simulated workload is being used for acceptance testing, it must be consistent with the data processing requirements set forth elsewhere in this contract.
- 1. Start of Downtine. Downtime for each incident shall start from the time the Government contacts the Contractor's designated representative at the prearranged contact point until the system (s) or machine (s) is (are) returned to the Government in proper operating condition, exclusive of actual travel time required by the Contractor's maintenance personnel but not in excess of one hour on each day such services were requested.
However, at the request of the Contractor, the Government shall make available not only the failed equipment, but also those machines which must be used by the Contractor to accomplish such 4 repairs. The Contractor shall provide an answering service or '
other continuous telephone coverage to permit the Government to j make such contact. '
- j. Equipment Use During System Downtime. During a period of system failure downtime, the Government may use operable equipment when such action does not interfere with maintenance of the inoperable equipnent. The entire system will be considered down during such periods of use. Whenever the operable equipment is not released to the Contractor upon request, all such usage periods shall be considered system operational use time in computing the effectiveness level, w
- o
)
RS-AED-87-129 PAGE 13
)
- k. Machine Failure Downtime. Machine failure downtime for a machine added, field-modified, or substituted, or for a replacement machine after the system has completed a successful performance period is that period of time when such machine is i inoperable due to its failure. i l
- 1. Minimum of Use Time. During the performance period for a j system / machine, a minimum of 4 hours4.62963e-5 days <br />0.00111 hours <br />6.613757e-6 weeks <br />1.522e-6 months <br /> of operational use time with scheduled productive or simulated work will be required as a basis for computation of the effectiveness level. However, in -l computing the effectiveness level, the actual number of {
operational use hours shall be used when that number exceeds the i minimum of 4 hours4.62963e-5 days <br />0.00111 hours <br />6.613757e-6 weeks <br />1.522e-6 months <br />. Machines added, field modified and substitute machines are subject to the 4 hours4.62963e-5 days <br />0.00111 hours <br />6.613757e-6 weeks <br />1.522e-6 months <br /> minimum use time requirement. However. the Government shall accept such machine (s) without the addition of simulated work solely to 1 achieve the minimum of 4 hours4.62963e-5 days <br />0.00111 hours <br />6.613757e-6 weeks <br />1.522e-6 months <br /> use time, provided the average i effectiveness for the acceptance period is equal to or better 4 than the level specified in paragraph b above.
- m. Daily Records. The Government shall maintain appropriate daily l records to satisfy the requirements of this clause and shall notify the Contractor in writing of the date of the first day of the successful performance period.
- n. Measurement of Operational Use Time. Operational use time and downtime shall be measured in hours and whole minutes.
- o. Remote Devices. For remote devices the standard of performance shall be determined in accordance with paragraph m, above. A remote device is defined as any contractor-supplied device which is connected to the Central Processing Unit by way of data ,
transmission lines rather than contractor-supplied direct cable '
connection. The effectiveness ltvel for equipment supplied by the ;
Contractor shall be computed in accordance with paragraph f, '
l ebove, and shall exclude downtime attributable to related equipment, cables, transmission lines, wires, etc., not supplied by the Contractor.
Section F - Deliveries and Performance F.1 The contractor shall perform in accordance with the following schedule:
F.1.2 The effort described in Section C.I.4.2.] shall be completed within three months af ter contract award. 1 F.1.3 The effort described in Section C.I.4.2.2 shall be completed on a schedule aorced upon between the NRC cnd the contractor based on the delivery schedule agreed upon with the equipment supplier.
RS-AED-87-129 PAGE 14 F.1.4 The effort dese15ed in Sections C.I.4.2.3 and C.1.4.2.4 shall be completed on a schedule agreed upon between the NRC and the contractor based on arrangemen.ts negotiated with the licensees.
F.1.5 The effort described in Sections C.1.4.3.2 and C.1.4.3.3 shall be completed within six months after receipt of the hardware obtained under Section C.I.4.2.2.
F.1.6 The effort described in Sections C.1.4.4.2 and C.1.4.4.3 shall be completed within one year after receipt of the hardware obtained under Section C.1.4.2.2.
F.1.7 The effort described in Section C.1.4.5.1 will be completed within three months after C.I.4.3 is completed. The effort described in Section C.1.4.5.2 will be completed within three months after C.1.4.a is completed.
F.1.8 Once every two months briefings will be conducted for the NRC on project status. The location may vary between NRC and contractor offices. However, for cost proposal purposes, assume six trips per year to Bethesda, Maryland for two persons and one day each.
F.1.9 Occasional brief papers, oral briefings, and consultations may be required by the NRC. Whenever possible, the NRC will give at least one week notice of such requests. For cost proposal purposes, assume two trips per year to Bethesda, Maryland, for two persens and one day each.
F.2 Technical Progress Report The Contractor shall provide a monthly Technical . Progress Report to the Project Officer and the Contracting Officer. The report is due within 15 calendar days after the end of the report period and shall identify the title of the project, the contract number, project manager and/or principal investigator, the centract period of perfomance, and the period covered by the report. Each report shall include the following:
- a. A listing of the efforts completed during the period; milestones reached or, if missed, an e.xplanation provided;
- b. Any problems or delays encountered or anticipated and recommendations for resolution; (if the recommended resolution involves a contract modification, e.g., change in work requirements, level of ef fort (cost) or schedule delay, the Contractor shall submit a separate letter to the Contracting Officer identifying the required change and estimated cost impact).
- c. A summary of progress to date; and
- d. Plans for the next reporting period.
RS-AED-87-129 PAGE 15 One copy of this report shall also be sent to the following:
- 1) Chief, Incident Response Branch, AE0D
- 2) Program Assistant, Division of Operational Assessment, AEOD F.3 Financial Status Report J l
The Contractor shall provide a monthly Financial Status Report to the {
Project Officer and the Contracting Officer. The report is due within i 15 calendar days after the end of the report period and shall identify I the title of the project, the contract number, project manager and/or )
principal investigator, the contract period of performance, and the 1 l period covered by the report. Each report shall include the following l for each discrete task:
- a. Provide the total estimated cost (value) of the project as reflected in the contract, the amount of funds available in the contract to date, and the balance of funds required to complete the work as follows:
- 1) Total Estimated Contract Amount.
- 2) Total Funds Obligated To Date. !
- 3) Total Costs Incurred This Reporting Period.
- 4) Total Costs Incurred To date.
- 5) Balance of Obligations Remaining.
- 6) Balance of Funds Required To Complete Contract.
l
- b. Detail of all direct and indirect costs incurred during the I reporting period for each task.
One copy of this report shall also be sent to the following:
- 1) Chief, Incident Respens,e Branch, AE0D
?) Program Assistant, Division of Operational Assessment, AEOD F.4 Place of Delivery.
The reports to be furnished hereunder shall be delivered, with all charges paid by the Contractor, to:
- e. ProjectOfficer(1 copy) 0.S. Nuclear Regulatory Commission Centract Number:
- Office of
- Division of
- flail Stop:
- Washington, D.C. 20555 i
l PS-AED-87-129 PAGE 16 l b. Contracting Officer (1 copy)
. U.S. Nuclear Regulatory Comission l Contract Number:
Office of Administration Division of Contracts Contract Administration Branch Mail Stop: AR-2223 Washington, D.C. 20555 l
- To be incorporated into any resultant contract.
F.5 Place of Delivery.
l The equipment to be furnished hereunder shall be delivered, with all transportation charges paid by the Contractor, to:
U.S. Nuclear Regulatory Commission Contract Number:
- To be inc.orporated into any resultant contract.
F.6 Duration of Contract Period This contract shall commence on the effective date reflected in block 3 of the SF-26 and will expire 6 years thereafter.
This contract shall become effective on either the date of award or '
the effective date as otherwise specified, and shall continue for a five year period of performance. However, possible action by Congress may require completion of the effort within three years and at the same time ensure licensee cooperation with that time frame. ,
Therefore, the Contract may be accelerated and completed after a l shorter period of performance. Any such alteration shall be made j under the Changes clause of this contract (FAR 52.243.2) which '
provides for negotiation of an equitable adjustment to the contract as necessary.
I
RS-AED-87-129 PAGE 17 ,
F.7 Maintenance Requirements (ADP System / Equipment)
- a. Responsibilities of the Contractor. The Contractor shall provide maintenance (labor and parts), and shall keep the equipment in good operating condition during the entire period of performance. Maintenance services sball not include electrical work external to the equipment, the furnishing of supplies, and adding or removing accessories, attachments or other devices.
It shall not include repair of damage resultir.g from accident, transportation between Government sites, neglect, misuse, failure of electrical power of air-conditioning or humidity control, or causes other than ordinary use,
- b. Responsibilities of the Governnent.
(1). Government personnel shall not perform maintenance or. attempt repairs to equipment while such equipment is under the purview of this contract unless agreed to by the Contractor.
(2). Subject to security regulations, the Government shall permit access to the equipment which is to be maintained.
(3). The Government shall provide adequate storage space for spare parts and edequate working space, including heat, light, ventilation, electrical current and outlets and telephones l (for local calls only) for the use of maintenance personnel.
These facilities shall be within the reasonable distance of the equipment to be serviced and shell be provided at no charge to the Contractor.
(4). The Government shall provide time for contractor-sponsored modifications within a reasonable time after being notified
- by the Contractor that the modification is ready to be made.
I The time required to make the modification sball be outside the normal preventive maintenance hours.
(5). The Government shall maintain site requirements in accordance with the equipnent environmental specifications furnished by the Contractor.
F.8 FAR Citations
RS-AED-87-129 PAGE 18 Section G - Contract Administration Data G.1 Indirect Rates
- a. Pending the establishment of final indirect rates which shall be negotiated based on audit of actual costs, the Contractor shall be reimbursed for allowable indirect costs as follows:
Category Rate (%) Cost Base Applicable Period Overheao Fringe Benefits General & Administrative Expenses j Other: _
{
- b. The Contracting Officer may adjust the above rates as appropriate during the term of the contract upon acceptance of any revisions i proposed by the Contractor. It is the Contractor's responsibility' to notify the Contracting Officer in accordance with 52.232 Limitation of Cost ((APR 1984) or 52.232 Limitation of Funds (APR 1984), as applicable, if such change (s) affect (s) performance 1 of work within the established cost or funding limitations.
G.2 Project Of ficer Authority.
1 l
- a. The Contracting Officer's authorized representative hereinaf ter referred to as the Project Officer for this contract is:
1 Name:
Address:
- Telephone Number: *
- b. Perfonnance of the work under this contract shall be subject to the technical direction of the NRC Project Officer. The tenn ;
" Technical Direction" is defined to include the following: '
l 1). Technical direction to the Contractor which shifts work emphasis between areas of work or tasks, fills in details or otherwise serves to accomplish the contractual statement of t work.
2). Providing advice and guidance to the Contractor in the preparation of drawings, specifications or technical portions of the work description.
3). Review and, where required by the contract, approval of technical reports, drawings, specifications and technical information to be delivered by the Contractor to the '
Government under the contract.
i
. I
. _m _ _ _ . _ _ -
i RS-AED-87-129 PAGE 19
- c. Technical direction must be within the general statement of work stated in the contract. The Project Officer.does not have the authority to and may not issue any technical direction which:
1). Constitutes an assignment of additional work outside the general scope of the contract.
2). Constitutes a change as defined in the " Changes" clause cf this contract.
3). In any way causes an increase or decrease in the total estimated contract cost, the fixed fee, if any, or the time required for contract performance.
4). Changes any of the expressed terms, conditions or specifications of the contract.
5). Terminates the contract or settles any claim or dispute arising under the contract, or issue any unilateral directive whatever.
- d. All technical directions shall be issued in writing by the Project Officer or shall 9 confirmed by such person in writing within ten (10) working days after verbal issuance. A copy of said written direction shall be submitteo to the Contracting Officer,
- e. The Contractor shall proceed promptly with the performance of technical directions duly issued by the Project Officer in the manner prescribed by this clause and within such person's-authority under the provisions of this clause.
- f. If, in the opinion of the Contractor, any instruction or direction issued by the Project Officer is within one of the categories as cefined in c above, the Contractor shall not proceed but shell notify the Contracting Officer in writing within five (5) working days after the receipt of any such instruction or direction and l shall request the Contracting Officer to modify the contract accordingly. Upon receiving such notification from the Contractor, the Contracting Officer shall issue an appropriate contract modification or advise the Contractor in writing that, in -
the Contracting Officer's opinion, the technical direction is within the scope of this article and does not constitute a change under the Changes Clause. j l
RS-AED-87-129 PAGE 20
- g. Any unauthorized conrnitment or direction issued by the Project Officer may result in an unnecessary delay in the Contractor's performance, and may even result in the Contrector expending funds for unallowable costs under the contra:';.
- h. A failure cf the parties to agree upon the nature of the instruction or direction or upon the contract action to be taken with respect thereto shall be subject to 52.233 Disputes (APR1984).
- i. In addition to providing technical direction as defined above, the Project Officer is responsible for:
1). Monitoring the Contractor's technical progress, including '
surveillance and assessment of performance, and recommending to the Contracting Officer changes in requirements.
2). Assisting the Contractor in the resolution of technical problems encountered during performance.
3). Reviewing all costs requested for reimbursement by Contractor and submitting to the Contracting Officer reconsnendations for approval, disapproval, or suspension for supplies and services required under this contract.
G.3 Travel Reimbursement,
- a. The Contractor will be reimbursed for reasonable domestic travel costs incurred directly and specifically in the performance of this contract. The cost limitations for travel costs are determined by the Federal Travel Regulations that are in effect on the date of the trip These Regulations specify the daily maximum per diem rates for specific localities within the Conterminous United States (CONUS), the standard CONUS rate, the allowance for meals and incidental expenses (M&IE), the cost of travel by_
privately owned automobile, end the items which require receipts.
The Contractor can obtain the Regulations from the Superintendent of Documents, Government Printing Office, Washington, DC 20402.
- b. Ilhen the Government changes the Federal Travel Regulations, it is the responsibility of the Contractor to notify the Contracting Officer in accordance with the Limitation of Cost clause of this contract if the Contractor will be unable to make all of the approved trips and remain within the cost and fee limitations of this centract.
J RS-AED-87-129-PAGE 21
- c. The rates for any NRC approved foreign travel under this contract are established by the U. S. Department of State and are listed in a publication entitled " Maximum Travel Per Diem Allowances For Foreign Areas". Copies of this publication may q be obtained from U. S. Government Printing Office, Washington, ;
D.C. 20402 i 1 J G.4 Method of Payment
- a. Payment under this contract will be made by wire transfer through the Treasury Financial Communications System for each individual payment in excess of $25,000 and by Treasury check for each individual payment of $25,000 or less. ] l
- b. In the event that the Contractor's financial institution has 'l access to the Federal Reserve Communications System, the I Contractor shall forward the following information in writing to l the Contracting Of ficer within seven days af ter the effective date -
of the contract. i i
1). Name and address of organization. l 2). Contact person and telephone number.
3). Name and address of financial institution.
4). Contractor's Financial institution's 9-digit ABA identifying number for routing transfer of funds.
5). Telegraphic abbreviation of Contractor's financial institution.
6). Account number at Contractor's financial institution.
7). Signature and title of person supplying this infonnation.
- c. In the event the Contractor's financial institution does not have I access to the Federal Reserve Communications System, the Contractor shall forward the following information with renard to a correspondent or alternate financial institution. The information shall be in writing and submitted to the Contracting Officer within seven days after the effective date of the c.cntract.
1). Name and address of organization.
2). Contact person and telephone number.
RS-AED-87-129 PAGE 22 3). hame and address of financial institution. I 4). Telegraphic abbreviation of Contractor's financial institution.
l 5). Account number at Contractor's financial institution. !
6). Name anc address of the correspondent financial institution I that has access to the Federal Reserve Communications System.
7). Correspondent financial institution 9-digit ABA identifying l number for routing transfer of funds.
8). Telegraphic abbreviation of correspondent financial institution.
9). Signature and title of person supplying this information.
- d. Any changes to the information furnished under this clause shall be furnished to the Contracting Officer in writing. It is the Contractor's responsibility to furnish these changes promptly to avoid payments to erroneous bank accounts.
G.5 Payment Due Date. I
- a. Payments under this contract will be oue 30 calendar days after the later of:
1
- 1) The date of actual receipt of a proper invcice in accordance with the attached " Billing Instructions", or
- 2) The date the final deliverable product / service is accepted by the Government. >
l
- b. For the purpose of determining the due date for payment and for no other purpose, acceptance will be deemed to occur 30 calendar days after the date of delivery of the final deliverable '
product / service performed in accordance with the terms of the 4 contract.
- c. If the final product / service is rejected for failure to conform to the technical requirements of the contract, the provisions in paragraph b of this clause will apply to the new delivery of the final product / service,
- d. The date of payment by wire transfer through the Treasury Financial Communications System shall be considered the date payment is made for individual payments exceeding $25,000. The date a check is issued shall be considered the date payment is made for individual payments of $25,000 or less.
t RS-AED-87-129 j PAGE 23 J
G.6 Interest on Overdue Payments.
l
- a. The Prompt Payment Act, Public Law 97-177 (96 STAT. 85, 31 USC' 1 1801) is applicable to payment of the expiration invoice under I this contract and requires the payment of interest to Contractors .)
on overdue payments of the expiration invoice or improperly taken ,
discounts. ]
l
- b. Determinations of interest due will be made ',n accordance with the I provisions of the Prompt Payment Act and Office of Management and Budget Circular A-125, Vol. 47 Federal Register 37321, August 25, 1982. Among other considerations, OMB Circular A-125 provides that:
- 1) Interest penalties are not required when payment is delayed I because of a disagreement over the amount of payment or other )
issues concerning compliance with the terms of the contract. q
- 2) Whenever a proper invoice is paid after the due date plus 15 days, interest will be inc?uded with the payment at the interest rate applicable on the payment date. Interest will j be computed from the day after the due date through the q payment date. -
- c. For purposes of this clause, an expiration invoice is defined as a j claim submitted for costs incurred for performance through the . '
expiration date of a Cost Type contract.
l G.7 Penittance Address l
l If item 15c. of the Standard Fonn 33 has been checked, enter the remittance address below.
Name:
Address: - 1 l
I l
l z
__-_m.--___--_ _ . _ . . _ - _ _
i RS-AED-87-129 PAGE 24 Section H - Special Contract Requirements 4
H.1 Key Personnel
- a. The following individuals are considered to be essential to the ,
successful performance of the work hereunder. :
The Contractor agrees that such personnel shall not be removed from the contract work or replaced without compliance with paragraphs b and c hereof, i
- b. If one or more of the key _ personnel for whatever reason becomes, l or is expected to become, unavailable for work under this contract i for a continuous period exceeding 30 work days, or is expected to devote substantially less effort to the work than indicated in the proposal or initially anticipated, the Contractor shall !
immediately notify the Contracting Officer and shall, subject to !
the concurrence of the Contracting Officer, promptly replace such l personnel with personnel of at least substantially equal ability l and qualifications, j
- c. All requests for approval of substitutions hereunder must be in writing and provide a detailed explanation of the circumstances necessitating the proposed substitutions. They must contain a ecmplete resume for the proposed substitute, and other information requested by the Contracting Officer to approve or disapprove the proposed substitution. The Contracting Officer will evaluate such requests and promptly notify the Contractor of ,
i i
his/her approval or disapproval thereof in writing. I
- d. If the Contracting Officer determines that suitable and timely replacement of key personnel who have been reassigned.. terminated i
l or have otherwise become unavailable for the contract work is not reasonably . forthcoming or that the resultant reduction of' I productive effort would be so substantial as to impair the i successful completion of the contract or the service order, the contract may be terminated by the Contracting Officer for I
def ault or for the convenience of the Government, as appropriate, or, at the discretion of the Contracting Officer if he/she finds the Contractor at fault for the condition, the contract price or fixed fee may be' equitably adjusted downward to compensate the Government for any resultant delay, loss or damage.
- To be incorporated into any resultant contract
RS-AED-87-129 PAGE 25 H.2 Safety, Health, and Fire Protection.
The Contractor sh'all take all reasonable precautions in the performance of the work under this contract to protect the health and safety of employees and of members of the public and to minimize danger from all hazards to life and property and shall comply with all applicable health, safety, and fire protection regulations and requirements (including reporting requirements) of the Comission and the Department of Labor. In the event that the Contractor fails to comply with said regulations or requirements, the Contracting Officer may, without prejudice to any other legal or contractual rights of the Commission, l 1ssue an order stopping all or any part of the work; thereafter, a start order for resumption of work may be issued at the discretion of the Contracting Officer. The Contractor shall make no claim for an extension of time or for compensation or damages by reason of or in connection with such work stoppage.
H.3 Private Use of Contract Information and Data .
Except as specifically authorized by this contract, or as otherwise approved by the Contracting Officer, infomation and other data developed or acquired by or furnished the Contractor in the performance of this contract, shall be used only in connectier. with the work under this contract.
H.4 Drawings, Designs, and Specifications.
All drawings, sketches, designs, design data, specifications, notebooks, technical and scientific data, and all photographs, negatives, reports, findings, recommendations, data and memoranda of every description relating thereto, as well as all copies of the foregoing relating to the work or any part thereto, shall be subject to inspection by the Comission at all reasonable times (for which insyttion the proper facilities shall be afforded the Commission by the Contractor and its subcontractors), shall be the property of the Government and may be used by the Government for any purpose whatsoever withcut any claim on the part of the Contractor and its subcontractors and vendors for additional compensation and shall, subject to the right of the Contractor to retain a copy of said material for its own use, be delivered to the Government, or otherwise disposed of by the Contractor either as the Contracting Officer may from time to time direct during the progress of the work or in any event as the Contracting Officer shall direct upon completion or termination of this contract. The Contractor's right of retchtion and use shall be subject to the security, patent, and use of information provisions, if any, of this contract.
RS-AED-87-129 PAGE 26 H.S Contractor Organizational Conflicts of Interest (OMB Clearance Number 3150-01i_2)
- a. Purpose. The primary purpose of this clause is to aid in ensuring that the Contracter:
1). Is not placed on a conflicting role because of current or planned interest (financial, contractual, orpenizational, or-otherwise) which relate to the work under this contract, and 2). Does not obtain an unfair ccrpetitive advantage over other parties by virtue of its perfonnance of this contract.
- b. Scope. The restrictions described herein shall apply to performance or' participation by the Contractor as defined in 41 CFR 620-1.5402(f) in the activities covered by this clause,
- c. Work for Others. Notwithstanding any other provision of this contract, during the term of this contract, the Contractor agrees to forgo entering into consulting or other contractual arrangements with any firm or organization, the result of which may give rise to a conflict of interest with respcct to the work being performeo under this contract. The Contractor shall ensure that all employees who are employed full time under this contract and employees designated as key persorr.el, if any, under this contract abide by the provisior of this clause. If the Contractor l believes with respect to itself or any such employee that any proposed consultant or other contractual arrangement with any firm l or organization may involve a potential conflict of interest, the
! Contractor shall obtain the written approval of the Contracting )
Officer prior to execution of such contractual arrangement.
- d. Disclosure after award.
1). The Contractor warrants that to the best of its knowledge and belief and except as otherwise set forth in this contract, it does not have any organizational conflicts of interest, as defined in 41 CFR 20-1.5402(a).
2). The Contractor agrees that if after award it discovers organizational conflicts of interest with respect to this contract, it shall make an immediate and full- disclosure in writing to the Contracting Officer. This statement shall l include a description of the action which the Contractor has l taken or proposes to take to avoid or mitigete such conflicts. The NRC may, however, terminate the contract for convenience if it deems such termination to be in the best I interests of the Government.
- e. Access to and use of information.
i
._______.__..__-__-d
RS-AED-87-120 PAGE 27 I
1). If the Contractor in the performance of this contra 6 obtains access to infonnation, such as NRC plans, policies, reports, studies, financial plans, internal data protected by.4he Privacy Act of 1974 (Pub. L.93-579), or data which has not been released to the public, the Contractor agrees [M to:
(1) Use such information for any private purpose 'altil the /
information has been released to the public;f' (ii) Compete for work for the Commission based on such informationforaperiodofsix(6)monthsaftenhthar the completion of this cont act or the release r f .;usn
- information to the public, whichever is first; ,
(iii) Submit an unsolicited proposal to the Government based'-
on such information ur.+.il one year after the releise of such information to the public, or ,
(iv) Release the information without prior written apprcval by the Contracting Officer unless such information has previously been released to the public by the NRC. )
7 2). In addition, the Contractor agrees that to the extent it ,
receives or is given access to proprietary data, data n '
protected by the Privacy Act of 1974 (Pub. L.93-579), or other confidential or privileged technical, businqss, or '
financial infont.ation under this contrac'i, tne Contrator ,"
shall treat such information in accordanc* with r ub 'ctions placed on use nf the information.
- b
! ;l
- 3. The Cer. tractor shall have, subject to patent i.nd vecurhy provisions of this contract, the right to use terMta' M ta it produces under this contract for private puru.es proy#te that all requirements of this contract have been NL
- f. Subcontracts. Except as provided in 41 CrR 20-3.5402(b), tha Contractor shall include this cleuse, including this paragrapa, in subcontracts of any tier. The terms " contract," " Contractor," and
" Contracting Officer," shall be appropriates; mcdi+kd to preerve the Government's rights,
- g. Remedies. For breach of any of the above prese. iptions or for intentional nondisclosure or misreprescriatien e any reavart interest required to be disclosed cont.ctning'this centracy or for such erronecus representations as necessarily imply bad faith, the Governnier.t raay terminate the contract for default, diso,alify the '
Contractor f ror.: subsequent contractual efforts, and pursue bther remedies as may be permitted by law or this centract.
- h. Weiver. A request for waiver under this clause shall h directed in writing through the Contracting Offictr to the Execatie Director for Operations (EDO) in accordance with the potec'ures cutlined in t?0-1.5411.
/
i j i
./
s
, , / /
RS-AED-87-129 l' ,
- PAGE 28 H.6 g fisk of Loss f or D, mage--ADP System,er Equiprrent urchase
'[ o, The Government is relievd of all risks of Ass or damage to the equipment,'up to and influder @eNay prior to the first day of a s
successful gorformance' perfo{, ekept for:
(1) Loss or.dsmege causeo by buclear reaction, nuclear radiation, L,i' i radioactive contamination, war, insurrection, civil strife.
, Gebellion, weapons of war; or \
- j. c(
(2) Negligence on tht(art of the Covernment orNts agnits,
't provided, however,, that the Government'shall be relieved of i
the liability for such rists of loss or damage due to i! negM;er fe if any knmmercial customer of the Contractor is
[ ',j y p rel U ved of such fiabililtj un(er like circumstances.
\ <
l.
- b. If Co;the Ge'urrment is liaRhfor loss or damage of a machine, the
,c ntractor shall have tWanion to restore the machine to its I
previous condition, in sWh event the Government shall pay the y Contractor to pirfom such restoration at the Contractor's then current pg )*es, terms, and conditions. If the Contractor elects not to nrtore tae machine, the Governmen'. cay, at its own apense, restie'the macb,ine to its previous coedition. If, however, the machine it inn ir damaged beyond repair, the Covernment'shall pay to the kotractor the samelgice for the machine as the Government would have paid had it purchased the I
machine or. the day. prier to the loss or damage under the 3 ,
' provisions cf th h. contract. This clause shall govern risk of
}' - loss or cpnag% notwWstanding any other provisions of this i
contract reinit:4 tn title, payont, or ownership,
~
d.7 erm N Contrect-(AW sterns) f Ab)d.p)the coftware forGovendiat contemplated the sf stem's up of the life of 10 years fun system date of (s) (hardware and j '
irstalluton, the tem of this contract h from the effective d, ate of
%e comract through six (6) years thereafterl ; ,-
. ?
H.8 Refi acment Fort AvaMatility (ADRE) s 1 1
'; \ \ '
'The C1ntrec+nr guarattees that'n. placement pa'rts hr all systam' ,
e0uipa.ent fn this contract will be availab,le for the *ystem's j OtWs) life of 10 years. The Contractc/ shall not1ty, the Journment 1M d6ys before the end of the system * > jitem's) life as
' ,o De continuing triailability of parts Subsequcnt t? this period.
If parts will not ta availabh fru, the Contractor,, den the l 4 , Gcvernnent may require the Contractor to 'urnish cata that is J m ilable tt ass'st the Goverrrent to obtafn%ch parts from another j, sxt ce. '
I l J~!
\( \ .s
\
\
)
I. '
'A _ _ . _ - - - _ _ _ - -
cy .
s ,
4 RS-AED-87-129 PAGE 29 H.9 ADP System, Equipinent, land /or Software Training
.a. Schedule for Training. The Contractor shall provide training in accordance with the schedule below. Scheduling of courses for the trainir.g will be subject to mutual agreement between the Contractor and the Government. All instructors will be experienced and training should be geared to the ADP system, equipment, machine, and/or software covered by this contract' und not to basic concepts. The attendees will be provided with all appropriate manuals, text material, and course outlines necessary for the specified training. Any training cost to the Gcvernment will be as indicated in the Sciiedule of this contract.
(1). ?y[e of Training.
(2).Lecition.
(3). Approximate Number to be Trained, q l
t (4). Maximum Number of Students.
(5). Course Schedule.
- b. Review and Approval. The training course curriculum will be subject to review and approval by the Government. The schedule cf trainirg and number of personnel to be trained may be revised by the Government, provided the Government notifies the Contractor, in writing, of the changes at least 30 days prior to commencement
- of the specific training, and provided the total number of personnel to be trained does not exceed the above requirements. i
)
H.10 Gi nsary of ADP Termr The definitions and explanations set forth in this glossary are an integral part of the tenas ar.d ccnditions of this contract.
Dcta Processing Equipment System and/or Subsystem. The total a.
. S ccmplement of individual machines and cperating software furnished by the Contractor and ecquired to operate as to integrated group,
- b. Equipment. An all-inclusive term which refers either to an ,
individual machine or to the total ccmplement of machines tequired to operate as an integrated group.
- c. Equipment and/or Operating Software railure. A malfunction in the contractor-supplied equipment and/or cperating software, excluding all external f actups, which prevents the accomplishrrent of. the ,
,, !r. job. i x,
l
, q a l i
J
- i e
i I
RS-AED-87-129 PACE 30 i
- d. Installation Date. The date by which the Contractor must have the ordered equipment ready for use by the Government.
- e. Machine. An individual unit, including features installed i thereon, of a data processing system, or subsystem, identifiec by l a type and/or model number, such as a central processing unit, an '
additional memory module, a tepe unit, a card reader, etc.
- f. Mechanical Replacement. The replacement of one machine for i ancther occasioned by the ncchanical condition of the equipment being replaced.
g.
Opera hardware tingincluding (Sof tware. Those devices),
peripheral routines that interface directly the computer with operations, applications and utility programs,
- h. Operational Use Time. The time during which equipment is in I actual operation, exclusive of idle tine, standby time, or maintenance time due to machine feilure; not synonymous with
" power-of" time.
- 1. Preventive Maintenance. That maintenance performed by the Contractor which is designed to keep the equipment in proper operating condition. It is performed on a scheduled basis.
j.
Principal Period of Maintenance. Any 9 consecutive hours per day, including an offic1al meal period not to exceed I hour per day, between the hours of 7:30 a.m. and 4:30 p.m., Monday through Friday, excluding holidays observed at the NRC installation.
- k. Extended Maintenance Period Option. Option to require maintenance service, during any extension of the Principal Period of Maintenance at a fixed price for such period, regardless of the number of calls requested during such period.
- 1. Remedial Maintenance. That maintenance performed by the Contractor which results from Contractor supplied equipment or l
operating software failure. It is performed as required and therefore on an unscheduled basis.
I m. Total Monthly Charges.
(1). Rental. All monthly charges for the use (rental) of equipment and software and for maintenance thereof.
(2). Maintenance of Government-owned. All monthly charges for the maintenance of equipment and software supplied under this contract.
RS-AED-87-129 PAGE 31
- n. Alteration. An alteration is defined as any change to a machine which deviates from the physical, mechanical, or electrical machine design (including microcode), whether or not additional devices or parts are required.
- o. Attachment. An attachment is defined as the mechanical electrical, or electronic interconnection of equipnent manufactured by other than the original equipnent manufacturer of the machine or system.
H.11 Site Preparation Provisions
- a. Ecuipment environmental specifications shall be furnished in writing by the Contractor in its proposal. These specifications shall be in such detail as to ensure that the equipment to be installed shall operate efficiently from the point of view of environment.
- b. The Government will prepare the site at its own expense and in accordance with the equipment environmental specifications furnished by the Contractor in the proposal.
- c. /ny alterations or modifications in site preparation which are directly attributed to incomplete or erroneous equipment environmental specifications provided by the Contractor, which would involve additional expenses to the Governner.t. shall be made at the expense of the Contractor.
- d. Any such site alterations or modifications as specified in paragraph c above which cause a delay in the installation date will also result in liquidation damages for equiprent as specified under " Liquidated Damages".
- e. The Goverr.hent agrees to have the site prepared in accordance with the Contractor's written site specifications by thirty (30) days prior to the scheduled installation date, unless a shorter period of time is agreed to in writing,
- f. The Government will provide the Contractor with access to the site for the purpose of instelling the equipment prior to the scheduled installation date. The Contractor shall specify in writing the ,
time required to insttli the equipment. I H.32 FIPS PUBS ano Standards Compliance In no case shall the Contractor or any subcontractor take ery action or use any replacement parts that would result-in equipment that is not in ecmpliance with applicable FIPS PUBS and Standaros without written Contracting Officer approval.
R5-AED-87-129 PAGE 32 H.13 Rights in Technical Data and Ccmputer Software.
- a. Definitions.
" Commercial Computer Software" , as used in this clause, reans coniputer software which is used regulerly for other than Governnert purposes and is sold, licensed or leased in significant quantities to the general public at established n.arket or catalog prices.
Computer", as used in this clause, means a data processing device capable of accepting data, performing prescribed operations on the data, and supplying the results of these operations; for exanple, a device that operates on discrete data by perfonning arithmetic and logic processes on the data, or a device that operates on analog data by performing physical processes on the data.
"Ccmputer Data Base", as used in this clause, means a collection of data in a form capable of being processed and operated on by a computer.
" Computer Program", as used in this clause, means a series of instructions or statements in a form acceptable to a computer, designed to cause the computer to execute an operation or operations. Computer programs include crerating systems, assemblers, comp'lers, programs, and ADPE maintenance /diagncstic programs, as well as applications programs such as payroll, inventory control, and engineering analysis progrems. Computer programs may be either nachine-dependent or machine-independent, and may be general-purpose in nature or designed to satisfy the requirements of a particular user.
" Computer Sof tware" , as used in this clause, means computer programs ano computer data bases.
" Computer Software Documentation", as used in this clause, means technical data, including computer listings and printouts. in human-readable form which (1) occuments the design or details of computer software, (2) explains the capabilities of the software, or (3) provides operating instructions for using the software to obtain desired results from a computer.
" Limited Rights", as used in this clause, means rights to use duplicate, or disclose technical data, in whole or in part, by or for the Government, with the express limitation that such technical date shall not, without the written permission of the party furnishing such technical data be released or disclosed in whole or in part outside the Government, used in whole or in party
RS-AED-87-129 PAGE 33 by the Government for manufacture, or in the case of computer software documentation, for preparing the same or similar computer software, or used by a party other than the Government, except for:
(1). Emergency repair or overhaul work only, by or for the Government, where the item or process concerned is not otherwise reasonably available to enable timely performance l
of the work; Provided, that the release or disclosure thereof outside the Government shall be made' subject to a prohibition against further use, release' or disclosure; or (2). Release to a foreign government, as the interest of the United States may required,'only for information'or evaluation within such government or for emergency repair or overhaul work by or for such government under the conditions of(1)above.
" Restricted Rights", as used in this clause, means rights that apply only to computer sof tware, and include, as a minimum, the right to --
(1).Use computer software with the computer for which or with which it was acquired, including use at any Government installation to which the computer may be transferred by the Government; (2).Use computer software with a backup computer if the computer for which or with which it was acquired is increrative; (3).Copycomputerprogramsforsafekeeping(archives)orbackup purposes; and (4). Modify computer software, or combine it with cther sof tware, subject to the provisions that those portions of the derivative scftware incorporating restructured rights sof tware are subject to the same restricted rights.
In addition, restrictec rights include any other specific rights not inconsistent with the n.inimum rights in (1)-(4) above that are listed or described in this contract or described in a license or agreement made a part of this contract.
" Technical Data", as used in this clause, means recorded information, regardless of form or characteristic, of a scientific -
or technical nature. It may, for example, document research, experimental, developmental or engineering work or be usabic or used to define a design or process or to procure, produce, support, maintain, or operate material. The data may be graphic
l l
RS-AED-87-129 PAGE 34 or pictorial delineations in media such as drawings or -
l photographs, text in specifications or related performhnee or design type documents, or computer printouts. Examples of technical data include research and engineering data, engineering drawings and associated lists, specifications, standards, process sheets, manuals, technical reports, catalog item identifications and related information, and computer software documentation.
Technical data does not include computer software or financial, j administrative, cost and pricing, and management data or other i infomation incidental to contract administration.
" Unlimited Rights", as used in this clause, means rights to use, duplicate, or disclose technical data, in whole or in part, in any manner and for any purpose whatsoever, and to have or pennit others to do so.
- b. Government Rights.
(1). Unlimited Rights. The Government shall have unlimited rights in:
(1) Technical data and computer software resulting directly from performance of experimental, developmental or research work which was specified as an element of perforn.ance in this or any other government contract or subcontract; (ii) Computer software required to be eriginated or developed under a Government contract, or generated as a necessary part of perfonring a contract; (iii) Computer data bases, prepareo under a Governnent contract, consisting of information supplied by the Government, information in which the Government has unlimited rights, or information which is in the public domain; (iv) Technical data necessary to enable manufacture of end-items, components, and modifications, or to enable the performance of processes, when the end-items, components, modifications or processes have been, or are being, developed under this or any other Government contract or subcontract in which experimental, developmental or research work is, or was specified as an element of contract performance, except technical cata pertaining to items, components, processes, or computer software developed at private expense (but see subdivision (2)(ii)below);
l RS-AED-87-129 PAGE 35 (v) Technical data or computer software prepared or required to be delivered under this or any other Government contract or subcontract and constituting corrections or changes to Government-furnished data or l
computer software; l
(vi) Technical data pertaining to end-items; components or processes, prepared or required to be delivered under this or any other government contract or subcontract, for the purpose of identifying sources, size, configuration, mating and attachment characteristics, functional characteristics and performance requirements
(" form, fit ar.d function" data, e.g., specification control drawings, catalog' sheets, envelope drawings, etc.);
(vii) Manuals or instructional materials prepared or required to be delivered under this contract or any subcontract hereunder for installation, operation, maintenance or training purposes; (viii) Technical data or computer software which is in the public domain, or has been or is normally released or disclosed by the Contractor or subcontractor.without restriction on further disclosure; and (ix) Technical data or computer software listed or described in an agreement incorporated into the schedule of this centract which the parties have predetermined, on the besis of subparagraphs (1) through-(viii) above, and agreed will be furnished with unlimited rights.
(2). Limited Rights. The Government shall have limited rights in:
(1) Technical data, listed or described in an agreeraent.
incorporated into the Schedule of this contract, which the parties have agreed will be furnished with limited rights; and (ii) Unpublished technical data pertaining to items, components or processes developed at private expense, and unpublished computer software documentation related to computer software that is-acquired with restricted rights, other than such data as may be included in the data referred to in subdivisions-b(1)(1),(v),(vi),(vii),and(viii)above. The' work unpublished, as applied-to technical data and computer software documentation, means that which has not been
RS-AED-87-129 PAGE 36 i
released to the public nor been furnished to others without restriction on further use or disclosure. For the purpose of this definition, delivery of limited rights technical data to or for the Government under a contract ooes not, in itself, constitute releese to the public.
Limited rights shall be effective provided that only the portion or portions nf each piece of data to which limited rights are to be asserted pursuant to subdivisions (2)(1) and (ii) above are identified (for example, by circling, underscoring, or a note), and that the piece of data is marked with the legend below in which is inserted:
(a) The number of the prime contract under which the technical data is to be delivered, I
' (b) The name of the Contrr.ctor and any subcontractor by whom the technical data was generated, and (c) An explanation of the rrethod used to identify
, limited rights data.
1 LIMITED RIGHTS LEGEND Contract No.
Contractor:
Explanation of Limited Rights Data Identification Method Used (d) Those portions of this technical data indicated as limited rights data shall not, without the written permission of the above Contractor, be either used, released or disclosed in whole or in part outside I the Government; used in whole or in part by the Government for manufacture or, in the case of computer software documentation, for preparing the same or similar computer software; or used by a party other than the Government, except for: (1) i emergency repair or overhaul work only, by or for I
' the Government, where the item er process concerned is not otherwise reasonably available to enable tirrely perfortnance of the work, Provided, that the release or disclosure hereof outside the Government shall be made subject to a prohibition against further use, release or disclosure; or (ii) release to a foreign government, as the interest of the United States may required, only for information or
RS-AED-87-129 PAGE 37 evaluation within such government or for emergency repair under ortheoverhaul work conditions of by)or for such (1 above. Thisgovernment legend, together with the indications of the portions of this data which are subject to such limitations shall be included on any reproduction hereof which includes any part of the portions subject to such limitations.
(3). Restricted Rights.
(1) The Government shall have restricted rights in computer sof tware, listed or described in a license or agreenent made a part of this contract, which the parties have agreed will be furnished with restricted rights, Provided, hcwever, notwithstanding any contrary provision in any such license or agreement, the Governmerit shall have the rights iricluded in the definition of " restricted rights" in paragraph a above.
Such restricted rights are of no effect unless the computer software is narked by the Contractor with the following legend:
RESTRICTED RIGHTS LEGEND Use, duplication or disclosure is subject to restrictions stated in Contract No. ~
with (Neme of Contractor) .
and the reldted computer software documentation includes a prominent statenent of the restrictier.s applicable to the computer sof tware. The Contractor may not place any legend on computer software irdicating restrictions on the Government's rights in such software unless the restrictions are set forth in a license or agreement made a part of this contract prior to the delivery date of the software. Feilure of the Contractor to epply a restricted rights legend to such computer software shall relieve the Governnent of liability with respect to such unmarked softwere.
(ii) Notwithstanding subdivision (1) above, comnercial. l computer sof tware and related documentation developed at !
private expense and not in public domain may, if the Contractor so eltets, be marked with the following ,
Legend:
RS-AED-87-129 PAGE 38 RESTRICTED RIGHTS LEGEND Use, duplication, or disclosurc by the Government is subject to restrictions as set forth in subdivision b(3)(11) of the Rights in Technical Data and Computer Software clause in Section H.
(Name of Contractor and Address)
When acquired by the Government, commercial computer !
software and related documentation so legend shall be j subject to the following 1
(A) Title to and ownership of the software and documentation shall remain with the Contractor.
(B) User of the software and documentation shall be limited to the facility for which it is acquired.
(C) The Government shall not provide or etherwise make available the software or documentation, or any portion thereof, in any form, to any third party -
without the prior written approval of the Contractor. Third parties do not include prime Contractors, subcontractors anc' agents of the Government who have the Government's permission to use the licensed software ano documentation at the i
facility, and who have agreed to use the licensed l software and documentation only in accordance with
! these restrictions. This provision does not limited the riaht of the Government to use software, documentation, or information therein, l which the Government may already have or obtains without restrictions.
l (D) The Government shall have the right to use the l computer software and documentation with the computer for which it is acquired at any other facility to which that computer may be transferred; to use the computer software and documentation with a backup computer when the primary' computer is inoperative; to copy computer programs for safekeeping (archives) or backup purposes; and to modify the software and documentation or combine it with other software, Provided, that the unmodified.
portions shall remain subject to these restrictions.
l l
RS-AED-87-129 PAGE 39 (E) If the Contractor, within sixty (60) days after a written request, fails to substantiate by clear and convincing evidence that computer software and documentation marked with the above Restricted Rights Legend are commercial items and were !
developed at private expense, or if the Contractor fails to refute evidence which is asserted by the Government as a basis that the software is in the public domain, the Government may cancel or ignore any restrictive markings on such computer software and documentation and may use them with unlimited rights. Such written requests shall be addressed I
to the Contractor as identified in the Restricted Rights Legend.
(4). No legend shall be marked on, nor shall any limitation or restriction on rights of use be asserted as to, any data or computer software which the Contractor has previously delivered to the Government without restriction. The limited or restricted rights provided for by this paragraph shall not impair the right of the Government to use similar or identical data er computer software acquired from other sources.
- c. Copyright.
(1). In addition to the rights granted under the provisions of paragraph b above, the Contractor hereby grants to the Government a nonexclusive, paid-up license throughcut the world, of the scope set forth below, under any copyright owned by the Contractor, in any work _of authorship prepared for or acouired by the Government urder this contract, to reproduce the work in copies or phono-records, to distribute copies or phono-records to the public, to perform or display the work publicly, and to prepare derivative works thereof, and to have others do so for Government purposes. With respect to technical data and computer software in which the Government has unlimited rights, the license shall be of the same scope as the rights set forth in the definition of "unliniited rights" in paragraph a above. With respect to technical data in which the Government has ifmited rights, ,
the scope of the license is limited to the rights set forth j in the definition of " limited rights" in paragraph a above. J With respect to computer software which the parties have agreed in eccordance with subparagraph b(3) above will be i fornisheo with restricted rights, the scope of the license is limited to such rights.
RS-AED-87-129 PAGE 40' (2). Unless vritten approval of the Contracting Officer is obtained, the Contractor shall not include in technical data or computer software prepared for or acquired by the Governnent- under this contract any works of authorship in which copyright is not ovned by the Contractor without :
acquiring for the Government any rights necessary to perfect a copyright license of the scope speciiied in subparagraph c(1).
(3). As between the Contractor and the Government, the Contractor shall be censidered the " person for whom the work was -
prepared" for the purpose of. detennining authorship under Section201(b)ofTitle17,UnitedStatesCode.
(a). Technical data delivered under this contract which carries a copyright notice shall also include the following statement which shall be placed thereon by the Contractor, or should the Contractor fail, by the Government:
This material rnay be reproduced by or for the U.S.
Governnent pursuant to the copyright license under the clause Rights in. Technical Data and Computer Sof tware clause in Section H.
- d. Removal of Unauthorized Mar' kings.
Notwithstanding any provision of this contract concerning inspection and acceptance, the Government may correct, cancel, or ignore any marking not authorized by the terms of this contract on any technical data or computer software furnished hereunder if:
(1). The Contractor fails to respond within sixty (60) days to-a l written inquiry by the Government concerning the propriety of the markings, or (2).TheContractor'sresponsefailstosubstantiate,withinsixty (60) cays after written notice, the propriety of limited rights markings by clear and convincing evidence, or of restricted rights markings by idchtification of the.
restrictions set forth in the contract. In either case, the Government shall give written notice. to the Contractor of the action taken.
- e. Relation to Patents.
Nothing contained in this clause shall imply a license to the Government under any patent or be construeo as affecting the scope of any license or other right othemise granted to the Government under any patent. ;
1
RS-AED-87-129 PAGE 41
- f. Limitation on Charges for Data and Computer Software.
The Contractor recognizes that the Government or a foreign government with funds cerived through the Military Assistance Program or otherwise through the United States Government snay contract for property or services with respect to which the vendor may be liable to the Contractor for charges for the use of technical data or computer software on account of such a contract. The Contractor further recognizes that it is the policy of the Governnent not to pay in connection with its contracts,.or to allow to'be paid in connection with contracts made with funds derived through the Military Assistence Program or otherwise through the United States Government, charges for data or computer software which the Goverrxent has a right to use and disclose to others, which is in the public domain, or which the Government has been given without restrictions upon its use and disclosure to others. This policy does not apply to reasonable reproduction, handling, mailing, and similar administrative costs incident to the furnishing of such data or computer software.
In recognition of this policy, the Contractor agrees te participate in and make appropriate arrangements for the exclusion of such charges from such contracts, or for the refund of amounts received by the Contractor with respect to any such charges not so excluded.
- g. Acquisition of Data and Computer Software from Subcontractors.
(1). Whenever any technical data or computer software is to be obtained from a Contractor under this contract, the Contractor shall use this same clause in the subcontract, without alteratien, and no other clause shall be used to enlarge or diminish the Government's or the Contractor's rights in that subcontractor data or computer software which is required for the Governnent.
(?). Technical data required to be delivered by a subcontractor shall nornelly be delivered to the next-higher tier Contractor. However, when there is a requirement in the prin.e contract to rights pursuant forsubparagraph data which nay(be submitted b 2) above, with linited a subcontractor may fulfill such requirement by submitting such data directly to the Governhent rather than through the prir.c Contractor.
(3). The Contractor and higher-tier subcontractors will not.use their power to award subcontracts as econorric leverage to acovire rights in technical data or computer software from their subcontractors for themselves.
RS-AED-87-129 PAGE 42 PART II - CONTRACT CLAUSLS Section I - Contract Clauses 52.252-2 CLAUSES INCORPORATED BY REFERENCE. (APR1984)
This contract incorporates the following clauses by reference, with the same force and effect as if they were given in full text. Upon request, the Contracting Officer will make their full text available.
I. FEDERAL ACQUISITION PEGULATION (48 CFR CHAPTER 1) CLAUSES Section E 52.246-3 INSPECTION CF SUPPLIES--COST-REIMBURSEMENT. APR 1984 52.246-5 INSPECTION OF SERVICES--COST-REIMBURSEMENT. APR 1984 52.246-15 CERTIFICATE Or CONFORMAllCE. (APR 1984)
Section F E2.212-13 STOP-WORK ORDER.-- Alternate 1 (APR 1984) 52.247-34 F.O.B. DESTINATION. (APR 1984)
Section 1 52.202-1 DEFINITIONS. (APR1984) 52.200-1 0FFICIALS NOT TO BENEFIT. (APR1984) 52.2r3-3 GRATUITIES. (APR1984) 52.203-5 COVENANT AGAINST CONTINGENT FEES. (APR1984) 52.203-6 RESTRICTIONS ON SUBCONTRACTOR SALES TO THE GOVERNMENT (JUL1985) 52.203-7 ANTI-KICK BACK PROCEDURE (Feb 1987) 52.210-5 NEW PATERIAL. (APR1984) 52.215-1 EXAMINATION OF RECORDS BY COMPTROLLER GENERAL.. (APR 1984) 52.215-2 AUDIT--NEGOTIATION. (APR 1984) 52.215-22 PRICE REDUCTION FOR DEFECTIVE COST OR PRICING DATA. (APR 1984) 52.215-23 PRICE REDUCTION FOR DEFECTIVE COST OR PRICING DATA--
MODIFICATIONS. (APR 1985) 52.215-24 SUBCONTRACTOR COST OR PRICING DATA. (APR1985) 52.215-25 SUBCON1RACTOR COST OR PRICING DATA--MODIFICATIONS. (APR 1985) 52.215-26 INTEGRITY OF UNIT PRICES (JUL 1986) 52.215-30 FACILITIES CAPITAL COST OF MONEY. (APR 1984) 52.215-31 WA1VER OF FACILITIES CAPITAL COST OF MONEY. (APR1984) 52.215-33 ORDER OF PRECEDENCE. (JAN1986) 52.216-7 ALLOWABLE COST AND PAYMENT. (APR1984) 52.216-8 FIXED FEE. (APR 1984) 52.219-8 UTILIZATION OF SMALL BUSINESS CONCERNS AND SMALL DISADVANTAGED BUSINESS CONCERNS. (JUN1985)
. . l
RS-AED-87-129 PAGE 43 52.219-9 SMALL BUSINESS AND SMALL DISADVANTAGED BUSINESS SUBCONTRACTING PLAN. (APR1984) 52.219-13 UTILIZATION OF WOMEN-0WNED SMALL BUSINESSES. (AUG1986 52.220-3 UTILIZATION OF LABOR SURPLUS APEA CONCERNS. (APR1984))
52.222-3 CONVICT LABOR. (APR 1984) 52.222-20 WALSH-HEALEY PUBLIC CONTRACTS ACT, (APR1984) 52.222-26 EQUAL OPPORTUNITY. (APR1984) 52.222-28 EQUAL OPPORTUNITY PREAWARD CLEARANCE OF. SUBCONTRACTS. (APR 1984) 52.222-35 AFFIRMATIVE ACTION FOR SPECIAL DISABLED AND VIETNAM ERA VETERANS (APR 1984) 52.222-36 AFFIRMATIVE ACTION FOR HANDICAPPED WORKEPS (APR 1984) 52.223-2 CLEAN AIR AND WATER. (APR1984) 52.225-3 . BUY AMERICAN ACT--SUPPLIES. (APR 1984 52.227-1 AUTHORIZATION AND CONSENT.. (APR 1984))
52.227-2 NOTICE AND ASSISTANCE, REGARDING PATENT AND COPYRIGHT INFRINGEMENT. .-(APR 1984) 52.227-3 PATENT INDEMNITY. (APR1984) 52.228-7 INSURANCE-LIABILITY TO TilIRD PERSONS. (APR1984) 52.230-3 COST ACCOUNTING. STANDARDS. (AUG1986) 52.230-4 ADMINISTRATION OF COST ACCOUNTING STANDARDS.- (APR 1984) 52.230-5 DISCLOSURE AND CONSISTENCY OF COST ACCOUNTING PRACTICES.
(AUG 1986) 52.232-17 INTEREST. (APR 1984) 1
' 52.232-22 LIMITATION OF FUNDS. (APR 1984) 52.232-23 ASSIGNMENT OF CLAIMS. (JAN1986) l 52.233-1 DISPUTES. (APR1984) i 52.237-2 PROTECTION OF GOVERNMENT BUILDINGS, EQUIPMENT, AND YEGETATION. (APR 1984) 52.242-1 NOTICE OF INTENT TO DISALLOW COSTS. (APR1984) 52.243-2 CHANGES--COST-REIMBURSEMENT.' (APR1984)--AlternateII.
(APR 1984)-
l 52.244 SUBCONTRACTS (C0ST-REIMBURSEMENT AND LETTER CONTRACTS)
(JUL 1985) 52.244-5 COMPETITION IN SUBCONTRACTING. (APR1984) 52.246-23 LIMITATION OF LIABILITY. (APR1984) 52.246-25 LIMITATION OF LIABILITY--SERVICES. (APR 1984 52.249-6 TERMINATION (COST-REIMBURSEMENT). (MAY1986))
52.249-14 EXCUSABLE DELAYS. (APR1984)-
52.251-1 GOVEPNMENT SUFPLY SOURCES. (APR1984)
___m___,. _ _ - _ _ _ _ - - - - _ - - - - - - - - - - - - - - -
J i
RS-AED-87-129 PAGE 44 1 q
l PART Ill - LIST OF COCUMENTS, EXHIBITS, AND OTHER ATT/CHMENTS Section J - List of /.ttachments )
l J.1 Attachments i Attachnent Number Title. l 1
1 NRC Contractor Organizational Conflicts of Interest (41 CFR Part 20) )
2 Billing Instructions ]
3 Standard Form 1411 with Instructions 1 4 Emergency Response Data System Requirements Anaylsis Report 5 NRC Manual Chapter 0904 4
PART IV - REPRESENTATIONS AND INSTRUCTIONS Section K - Representations, Certific6tions and Other Statements of Offerors or Quoters K.1 Organizational Conflicts of Interest I represent to the test of my knowledge and belief that:
The award to of a contract or the modification of an existing contract does / / or' does not / /
involve situations or relationships of the type set forth in 41 CFR I
20-1.5403(b)(1).
Instructions to offcrors. The following shall be included in all NRC solicitations: (1) If the representation as completed indicates that l situations or relationships of the type set fcrth in 41 CFR 6 20-1.5403(b)(1) are involved or the Contracting Officer otherwise determines that potential organizational conflicts exist, the offeror shall provide a statement in writing which describes in a concise manner all relevant factors bearing on his representation to the contracting officer. If the contracting officer determines that l organizational conflicts exist, the following actions may be taken:
(1) Impose appropriate conditions which avoid such conflicts, (ii) Disqualify the offeror, or (iii) Determine that it is otherwise in the best interest of the United States to seek award of the contract under the waiver provisions of 6 20-1.5411.
RS-AED-87-129 PAGE 45 (
(2) The refusal to provide the representation required by 620-1.5404(b) {
or upon request of the contracting officer the facts required by 620-1.5404(c), shall result in disqualification of the offeror for award. The nondisclosure or misrepresentation of any relevant interest may also result in the disqualification of the offeror for award; or if ,
such nondisclosure or misrepresentation is discovered after award, the j resulting contract may be terminated. The offeror may also be )
disqualified from subsequent related NRC contracts and be subject to such other remedial actions provided by law or the resulting contract.
The offeror may, because of actual or potential organizational I conflicts of interest, propose to exclude specific kinds of work from !
the statements of work contained in a RFP unless the RFP specifically prohibits such exclusion. Any such proposed exclusion by an offeror will be considered by the NRC in the evaluation of proposals. If the NRC ccrsiders the proposed excluded wori: to be an essential or integral part of the required work and its exclusion would work to the detriment l of the competitive posture of the other offerors, the proposal must be i rejected as unacceptable. )
L The offeror's failure to execute the representation required by i subsection (b) above with respect to invitation for bids will be !
considered to be a minor informality, and the offeror will be pemitted '
to correct the omission.
K.2 FAR Provisior,s 52.203-4 CONTINGENT FEE REPRESENTATION AkD AGREEftEt;T. (APR1984)
(a) Representation. The offeror represents that, except for full-time bona tide employees working solely for the offeror, the offercr--
Note: The offeror niust check the appropriate boxes. For interpretation of the represent 6 tion, including the terr; " bona fide employee," see Subpart 3.4 of the Federal Acquisition Regulation. .
(1)/ / has, / / has rot employed or retain (d any person or company to l solicit or obtain this contract; and (2) / / has, / / has not paid or agreed to pay to any person ci company employed or retained to solicit or obtain this centract any comission, percentage, brckerage, er other fee cortingent upon or resulting from the award of this contract.
(b)Agreenent. The offercr agrees to provide information relating to the above Representation as requested by the Contracting Officer end, when subparagraph (a)(1) cr (a)(2) is answered affirmatively, to promptly submit to the Contracting Cfficer--
(1) A completed Standard Form 119, Statement of Contingent or Other Fees, (SF 119); or 1
l
j RS-AED-87-129 PAGE 46 (2) A signed statement indicating that the SF 119 was previcusly submitted to the same contracting office, including the date and applicable solicitation or contract number, and representing that the prior SF 119 applies to this offer or quotation.
(Endofprovision)
(R7-2002.11974APR)
(R1-1.505) 52.214-8 PARENT COMPANY AND IDENTIFYING DATA. (APR1984)
(a) A " parent" company, for the purpose of this provision, is one that owns or controls the activities and basic business policies of the bidder. To own the bidding company means that the parent company must own more than 50 percent of the voting rights in that company. A company may control a bidder as a parent even though not meeting the requirement for such ownership if the parent company is able to formulate, determine, or veto basic policy decisions of the offeror through the use of dominant minority voting rights, use of proxy voting, or otherwise.
(b)Thebidder/ / is, / / is not [ check applicable box] owned or controlled by a parent company.
(c) If the bidder checked "is" in paragraph (b) above, it shall provide the i following information:
Name and Main Office Address of Parent Company (Include Parent Company's Employer's Zip Code) Identification Number (d) If the bidder checked "is not" in paragraph (b) above, it shall insert its own Employer's Identification Number on the following line . . . . . . . .. .. .. . .
(End of provision)
R SF 33, Part 2, Para 61977 MAR)
R SF 33A, Para 16 and 171969 MAR) 52.215-6 TYPE OF BUSINESS ORGANIZATION. (APR1984)
The offeror or quoter, by checking the applicable box, represents that it operates as / / a corporation incorporated under the laws of the State of
...................... / / an individual, / / a partnership, / / a nonprofit organization, or / / a joint venture.
End of provision)
AVSF331977 MAR)
(R SF 19B, Para 4, 1976 JUNE) i i
, . i i
RS-AED-87-129 PAGE 47 52.215-11 AUTHORIZED NEGOTIATORS. (APR1984) i The offeror or quoter represents that the following persons are authorized '
to nego'tiate on its behalf with the Government in connection with this request for proposals or quotations:
Name Title Telephone Number ,
i l
(End of provision) I (R 3-501(b) Sec K (iv))
1 52.215-19 PERIOD FOR ACCEPTANCE OF 0FFER. (APR 1984)
In compliance with the solicitation, the offeror agrees, if this offer is accepted within....... calendar days (60 calendar days unless a different period is inserted by the offeror) from the date specified in the solicitation for l receipt of offers, to furnish any or all items on which prices are offered at the price set opposite each item, delivered at the designated point (s), within the time specified in the Schedule.
(End of provision (R SF 33 1977 MAR l 52.215-20 PLACE OF PERFORMANCE. (APR1984) ;
(a) The offerer or quoter, in the performance of any contract resulting from this solicitation / / intends, / / does not intend (check applicable block) i to use one or more plants or facilities located at a different address from the l address of the offeror or quoter as indicated in this proposal or quotation.
(b) If the offeror er quoter checks " intends" in paragreph (a) above, it i shall insert in the spaces provided below the required information:
Name and Adcress of Owner Place of Performance (Street and Operator of the Plant or Address, City, County, State, Facility if Other than Offeror Zip Code) or Quoter
..............................g.g . . ...............................
(R 3-501(b) Sec K (viii))
52.219-1 SMALL BUSINESS CONCERN P. REPRESENTATION. (MAY 1986)
The offeror represents and certifies as part of its offer that it / / is,
/ / is not a small business cor.cern and that / / all, / / not all end items to be furnished will be manufactured or produced by a small business concern in the United States, its territories or possessions, Puerto Rico, or the Trust Territory of the Pacific Islands. "Small business concern," as used in this
i RS-AED-87-129 PAGE 48 provision, means a concern, including its affiliates, that is independently owned and operated, nct dominant in the field of operation in which it is bidding on Government contracts, and qualified as a small business under the size standards in this solicitation.
(Endofprovision) 52.219-2 SMALL DISADVANTAGED BUSINESS CONCERN REPRESENTATICF. (APR1984)
(a) Representation. The offeror represents that it / / is, / / is not a strall disaovantoged tusiness concern.
(b) Definitions.
" Asian-Inoian American," as used in this provision, means a United States citizen whose origins are in India, Pakistan, or Bangladesh.
" Asian-Pacific Americon," as used in this provision, means a United States citizen whose origirs are in Japan, China, the Philippines, Vietnam, Korea, Sanoe, Guam, the U.S. Trust Territory of the Pacific Islands, the Northern Mariana Islands, Laos, Cambodie, or Taiwan.
" Native Americans," as used in this provision, mecns American Indians, Eskimos, Aleuts, and native Hawaiians.
"Small business concern," as used in this provision, means a concern, including its affiliates, that is independently owned and operated, not dominant ;
in the field of operation in which it is bidding on Governnent contracts, and qualified as a small business under the criteria and size standards in 13 CFR 121.
"Small disadvantaged business concern," as used in this provistor, means a small business concern that (1) is at least 51 percent owned by one or more individuals who are both socially and economically disadvantaged, or a publicly owned business having at least 51 percent of its stock owned by one or more socially and economically disadvantaged individuals and (2) has its management end daily business controlled by one or more such individuals.
(c) Qualified groups. The offeror shall presume that socially ano economically disadvantaged individuals include Black Americans. Hispanic i Anericans, Native Americans, Asian-Pacific Amcricans, Asian-Indian Americans, i and other individuals found to be cualified by the SBA under 13 CFR 124.1.
(End of provision)
(R 7-2003.74 1980 AUG)
(R 3-501(b)(3), Part IV, Section K, (1)(B) 1980 AUG) 52.219-3 WOMEN-0WNED SMALL BUSINESS REPRESENTATION. (APR 1984)
(a) Representation. The offeror represents that it / / is, / / is not a women-owned small business concern.
(b) Definitions.
"Small business concern," as used in this provision, means a concern, ;
including its af filiates, that is independently owned and operated, not dominant in the field of operation in which it is bidding on Government contracts, and qualified as a small business under the criteria and size standards in 13 CFR 121.
I RS-AED-87-129 PAGE 49
" Women-owned," as used in this provision, means a small business that is at least 51 percent owned by a woman or women who are U.S. citizens and who also control and operate the business.
(End of provision) l (RFPRTemp. Reg 48 1978 DEC) l 52.222-19 WALSH-HEALEY PUBLIC CONTRACTS ACT REPRESENTATION. (APR1984)
The offeror represents as a part of this offer that the offeror is / / or is not / / a regular dealer in, or is / / or is not / / a manufacturer of, the supplies offered.
(End of provision) i (41CFR50-201.1) 52.222-21 CERTIFICATION OF NONSEGREGATED FACILITIES. (APR1984)
(a) " Segregated f acilities," as used in this provision, means any waiting rooms, work areas, rest rooms and wash rooms, restaurants and other eating areas, time clocks, locker rooms and other storage or dressing areas, parking lots, drinking fountains, recreetion or entertainment areas, transportation, and housing facilities previded for employees, that are segregated by explicit directive or are in fact segregated on the basis of race, color, religion, or national origin because of habit, local custom, or otherwise.
(b) By the submission of this offer, the offeror certifies that it does not and will not maintain or provide for its employees any segregatec f acilities at any of its establishments, and that it does not and will not permit its employees to perform their services at any location under its control where segregated facilities are maintained. The offeror agrees that a breach of this certification is a violation of the Equal Opportunity clause in the contract.
(c) The offeror further agrees that (except where it has obtained identical certifications from propcsed subcontractors for specific time periods) it will--
(1) Obtain identical certifications from proposed subcontractors before the award of subcontracts under which the subcontractor will be subject to the Equal Opportunity clause; (2) Retain the certifications in the files; and (3) Forward the followir.g notice to the proposed subcontractors (exc6pt if the propcsed subcontr6ctors have submitted identical certifications for specifictimeperiods):
NOTICE TO PROSPECTIVE SUBCONTRACTORS OF REQUIREMENT FOR CERTIFICATIONS OF NONSEGREGATED FACILITIES.
A Certification of Nonsegregated Facilities must be submitted before the award of a subcontract under which the subcontractor will be subject to the Equal Opportunity clause. The certification may be subnitted either for each subcontract or for all subcontracts during a period (i.e., quarterly, semiannually,orannue11y).
l l . _ . . - - - - - . - _ _ _ _ _ _ - _ _ _ _ _ _ _ _ _ _ _ _ _ _
RS-AED-87-129 PAGE 50 NOTE: The penalty for making false statemer.ts in offers is prescribed in 18 U.S.C. 1001.
(End of provision)
(R7-2003.14(b)(1)(A)1970AUG)
(R1-12.803-10(d))
52.222-22 PREVIOUS CONTRACTS AND COMPLIANCE REPORTS. (APR 1984)
The offeror represents that--
l (a) It / / has, / / has not participated in a previous contract or subcontract subject either to the Equal Opportunity clause of this solicitation, the clause originally contained in Section 310 of Executive Order Nc,10925, or the clause contained in Section 201 of Executive Order No.1111a; (b)It/ / has, / / has not, filed all required ccmpliance reports; 6hd (c) Representations indicating submission of required compliance reports, signed by proposed subcontractors, will be obtained before subcontract awards.
(End of provision)
(R7-2003.14(b)(1)(B)1973APR) 52.222-25 AFFIRMATIVE ACTION COMPLIANCE. (APR 1984)
The offeror represents that (a) it / / has developed and has on file, / /
has not developed and does not have on file, at each establishment, affirmative action programs 60-1 andrequired 60-2), or by(b) it /the/ has rulesnot and regulations hadofcontracts the Secretary of Labor l
(41 CFR previously subject to the written affirmative action programs requirement of the rules and regulations of the Secretary Endofprovision)
(of Labor.
(R7-2003.14(b)1979SEP)
(Rl-12.805-4) 52.230 COST ACCOUNTING STANDARDS NOTICES AND CERTIFICATION (NONDEFENSE). (APR1984)
Note: This notice does not apply to small businesses or foreign governments.
(a) Any contract over $100,000 resulting from this solicitation shall be subject to Cost Accounting Standards (CAS) if it is awarded to a business unit that is currently performing a national defense CAS-covered contract or subcontract, except when--
(1 The award is based on adequate price competition; (2 The price is set by law or regulation; (3 The price is based on established catalog or market prices of connercial items sold in substantial quantities to the general public; or (4) One of the exemptions in 4 CFR 331.30(b) applies (also see Federal AcquisitionRegulation(FAR)30.301(b)).
(b) Contracts not exempted from CAS shall be subject to full cr modified
' coverage as follows:
(1) If the business unit receiving the award is currently performing a national defense contract or subcontract subject to full CAS coverage (4 CFR 331), this contract will have full CAS coverage and will centain the clauses from the FAR entitled Cost Accountin and Administration of Cost Accounting Standards (52.230-4)g Standards (52.230-3) 1 8 '
4 .
RS-AED-87-129' PAGE 51 (2) If the business unit receiving the award is currently performing a national defense contract or subcontract subject to modified CAS coverage (4 CFR 332), this contract will have modified coverage and will contain the clauses entitled Disclosure and Consistency of Cost Accounting Practices (52.230-5) and Administration of Cost Accounting Standards (52.230-4).
A. Certificate of CAS Applicability The offeror hereby certifies that--
/ / The offeror is not performing any CAS-covered national defense contract or subcontract. The offeror further certifies that it will immediately notify the Contracting Officer in writing if it is awarded any national defense CAS-covered contract or subcontract subsequent to the date of this certificate but before the date of the award of a contract resulting from this solicitation.
(If this statement applies, no further certification is required.)
/ / The offeror is currently performing a negotiated national defense contract or subcontract that contains the Cost Accounting Standards clause at FAR 52.230-3.
/ / The offeror is currently performing a negotiated national defense contract or subcontract that contains the Disclosure and Consistency of Cost Accounting Practices clause at FAR 52.230-5.
B. Additional Certification--CAS Applicable Offerors
/ / The offeror subject to Cost Accounting Standards further certifies that practices used in estimating costs in pricing this proposal are consistent with the practices disclosed in the Disclosure Statement where it has been submitted pursuant to CAS Boaro regulations (4 CFR 351).
C. Data Required--CAS Covered Offet ors The offeror certifying that it is currently performing a national defense contract containing either CAS clause (see A above) is required to furnish the name, adaress (including agency or department con.ponent), and telephone number of the cognizant Contracting Officer administering the offeror's CAS-covered contracts.
i Nane of Contracting 0ffice r: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I Ad d re s s : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Telephone Number:...............................................
(Cndofprovision)
(R1-3.1203-3(b))
Section L - Instructions, Conditions, and Notices to Offerors or Quoters L.1 Acceptance Period Because of the time required by the Government to evaluate proposals and make an award, offerors are instructed to specify on the SF-33 a prcrosal acceptance period of not less than 120 days. ,
j l
l
RS-AED-87-129 PAGE 52 1 L.2 Small Busiress Size Standard and Product Classification.
The Standard Industrial Classification code for supplies / services l described herein is 7379. The smell business standard is average I annual receipts of $12.5 million over the past three years. l L.3 Award Notification and Comitment of Public Funds All offerors will be notified of their selection or nonelection as soon as possible. Formal notification of nonelection for unrestricted i awards will not be made until a contract has been awarded.. Pursuant to J the requirements of Section 15.1001(b)(2) of the Federal Acquisition Regulation, prelininery notification will be provided prior to award for small business set-aside procurement.
It is also brought to your attention that the Contracting Officer is i the only individual who can legally commit the Government (i.e., the !
NRC) to expenditure of public funds in connection with this procurement. This means thet unless provided in a centract document or specifically authorized by the Contracting Officer, NRC technical personnel cannot issue contract modifications, give informal contractual comitments or otherwise bind, commit, or obligate the NRC ;
contractually. Informal contractual comitments include such actions as: ,
- a. Encouraging a potential Contractor to incur costs prior to receiving a contract,
- b. Requesting or requiring a Contractor to make changes under a contract without formal contract modifications,
- c. Encouraging a Contractor to incur costs under a cost-reimbursable contract in excess of those costs contractually allowable, and
- d. Comitting the Government to a course of action with regard to a potential contract, contract change, claim, or.
dispate.
L.4 Disposition of Proposals After award of contract, one (1) copy of each unsuccessful proposal will be retained by NRC's Division of Contracts. Unless return of proposals is requested by the offeror upon submission of proposal, ell' other copies will be destroyed. This request should appear in any-cover letter accompanying the proposal.
RS-AED-87-129 PAGE 53 L.5 Proposal Presentation and Format
- a. Proposals must- be typed, printed or reproduced on letter-size paper and each copy must be legible,
- b. Proposals in response to this Request for Proposal must be submitted in the following three (3) separate and distinct parts:
1). Two (2) original signed copies of this solicitation package.
' All applicable sections must be completed by the Offeror.
2). One(1)originalandseven(7)copiesofthe" Cost Proposal" shall be submitted.
3). One (1) original and seven (7) ccpfes of the " Technical and Management Proposal" shall be submitted,
- c. Cost Proposal The Offerer must utilize the Star.dard Form 1411, Contracting Pricing Proposal Cover Sheet, in submitting the Cost Proposal. A copy of the form and instructions are attached to this solicitation. The information must include pertinent details sufficient to show the elements of cost upon which the total cost is predicated. The Cost Proposal must be submitted separately from the Technical and Management Proposal.
- d. Technical and Management Preposal The Technical and Management Proposal shall not contain any reference to cost. Resource information such as data concerning labor hours, and categories, materials, subcontracts, travel, computer time, etc., shall be included in the Technical and Management Proposal so that the Offeror's understanding of the scope of work may be evaluated.
The Of feror shall su'; nit with the Technical and Management Proposel full and complete inferraation as set forth below to permit the Government to make a thorough evaluation and a sound determination that the proposed approach will have a reasonable likelihood of meeting the requirements and objectives of this procurement.
I l
PS-AED-87-129 PAGE 54 Statements which paraphrase the statement of work withnct communicating the specific innovation proposed by the Offerer or-statements to the effert that the Offeror's understanding can or will comply with the statement of work may be construed as.an indication of the Offeror's lack of understanding of the statement of work and objectives.
The Technical and Management Proposal shall set forth as a mini m m the following:
1). Discussion of the statement of work to substantiate the Offeror's understanding of the requirement.
2). Discussion of the proposed method of approach to meet the objective.
3). Indicate potential problem areas and the approach to be taken to resolve said areas.
4). Statenents of any interpretations, requirements, or assumptions made by the Offeror.
5). Discuss support personnel and facilities available to assist the professional personnel.
6). Identify " Key Personnel", and for the person (s) so identified, specify the percentage of time currently committed to other projects over the course of the proposed contract period of performance.
7). Include resumes for all professional personnel to be utilized in the performance of any resulting contract. Include educational background, specific pertinent work experience and a list of any pertinent publications authored by the individual.
8). Describe the source of personnel required for perfonnance of each task including those not presently employed by the Offeror. If any of the personnel are under. consnitment, describe the terms of the commitment (s). Note specifically the personnel that will be employed at time of contract award.
9). If the Offeror plans to obtain consultant services, explain-the need for such services. List the proposed consultants by name, describe the work they will perfonn under this contract, and include related past experience. Individuals who are employees of the Contractor or of the U.S. Government are prohibited from being paid as a consultant under this .
contract.
,4 q
-" 7 I e s
1e ,
- RS-AEil-87-129 ]
.. PAGE155 10). 'If the Offeror plans to' subcontract anfbf the whek to be performed, list proposed subcontractors, 'if known, by name.
Provide a detailed. description of tte work to be performed by #. 3 ,l ;
the subcontractor. ,' / J i
.q , t 11). Provide 'a detailed schedule for work _to Lc perfonned and , .
identify significant milestones andeqmpletion dates for each , j subpart or task. } 4' 12). Project scheduling andl contingency plarnirs demonstrating 'a j logical progression and integration of the. tasks to insure . y completion within the performance period andaithout program 'l slippage. ,
'131. Describe the management organization.1 structure delineating j al areas of responsibility and authority tinc'er the proposed . y yi effort. Describe the relationship of'the project . .
4 fl organization to corporate manage m nt and to subcontractors, if any. Discuss the functions and authorities of the Project Manager.
Wl !:
14).Procedurestoperiodicallyreviewin-hpuse$ organizational functions, program reviews and contral's 'and subsequent
)[
'7 coordination with the NRC. -
15). Management controls expected to 14 utilized to preclude a ,
contract cost growth. ;
16). The Offeror shall list eny commitunts.with cther organizations, Government and/or coxiercini for the same of ' i similar effort, e
}
L.6 Nondiscrimination Because of Age (FAR 2P. 901) t ,
-t g,
It is the policy of the Executive Branch of the Goveredent that' (a) . , +
Contractors and Subcontractors engaged in the performance of Federal ' ,
', 'h contractsshellnot,inconnectionyfththeemploymeht, advancement,xob -! '
discharge of employees or in connection with the tent.s4 conditions, or- i privileges _of their_ employment,' discriminate against persbns,because'of y their age except upon the bt!.is of n' bonafide occupational- y , ^ ' , ,
qualification, Contractors andretirement plan, Subcontractors or statutory requirement, -and (ff,LHdat -
r or persons acting onltheir beho
! shall not specify, in solicitations or advertiserentsMor employees to "
- H L
l~
work unless on Government the specifiec' maximum contracts, egn limit is a based' maximum updra bonafide- age limi.t ffnrsuch e l
occupational c; qualification, retjrement p1an, or statutory, requirements ' -
\\
- S 1 f'
' y I
-(
4 - ( (
- ! -l r _N .
b
RS-AED-87 129
, e PAGE 56 i i L.7 j Referenceo Documents Available from the NRC PnR.
t
- s I
( , 4. The following documents were referenttd in this solicitation:
' /
[ (See Section C.1.5 herein) s
<b.
The documents are available for review at the (.3. Nuclear s, , 5 Regulatory Conrnission Public Document Room which is located in the
" icbby of 1717 H Street, N.W. in Washington, DC-. Copies of the documerts may be made for a fee.
i.8 Data' Univasal Numbering System (DUNS) Number 8
t All offercrs are requested to provide their DUNS number code, (e.g.,
01-001-0001) in the box marked " code" in item ISA of the SF 33. In the a event the code is unknown, enter *NA." in the box.
c j L.9~ engineering Chuge Certification The efferor certifies that all Engineering Char.ges (ECs) that have been annouuced by the Originel Equipment Manufacturer (0EM) on or before the issud date of this solicitation shall have been made to the equipment acquirce' u.; a result cf this solic4tation prior to the installation mte(s) specificc herein. These ECs shtli also be incorporated into the offered equipr: cat used for any benchmark or dst,ctstration required i ; '
' 1 5'l(Ideh under'this solicitation.
L.16 ification of Restricted Rights Corputer Softvere The offeror's attention is called to the requirement in the
- Rights in Technical D6ta and Computer Sof'tware" clause that any restrictions on r
t!,r Government concerning use or disclosure of coraputer sof tware which was developed at private expense and is to be delivered under the contnct must be set forth in nn agreedent rude a part of the s
contract, either negetf ated prior, to 6 ward or included in a modification of the certract before such delivery. Therefore, the
, y; offeror is requested \:o identify in his proposal to the extent feasibic any such' upon ,tke' qomputer(nftware which was develeped at private expense and use of wbjch he desires to negctiete restrictions, and to
', staje the 'oature of the proposed restHctions. If no such computer software is identified, it will be assumed that all deliverable cc'nqiter software will be subject tu un11rnited r1ghts.
\ , l ,
/L.11 ! Solicitation Pipsisio d i
i t '
\ i
/
I . alt. >
-Y
3-s RS-AED-87-129 PAGE 57 52.215-10 LATE SUBMISSIONS, MODIFICATIONS, AND WITHDRAWALS OF PROPOSALS. (APR1984)
(a) Any proposal received at the of fice designated in the solicitation after the exact time specified for receipt wffil not be considered unless it is received before award is made and it--
(1) Was sent by registered or certified mail not later than the fifth calendar day before the date specified for receipt of offers (e.g., an offer l submitted in response to a solicitation requiring receipt of offers by the 20th of the month must have been inailed by the 15th); ;
(2) Was sent by mail (a telegran if authorized) and it is detennined by the Government that the late receipt was due solely to mishandling by the Government after receipt at the G1vernment installation; or (3) Is the only proposhi Tnceived.
(b) Any modification of a prepoul' or quotation, except a modification resulting f rom the Contracting Offic#s request for "best and final" offer, is subjen to the same conditions as in subparagraphs (a)(1) ana (2) above. >
(c) A rrodification resulting from the Contrawing Officer's request for "best ar.c final" offer received after the time and date specified in the request' will not be considered unless received before award and the late receipt is due solelu rto mishandling by the Government after receipt at the Covernment instal lation. '
L (d) The only acceptable evidence to establish the date of mailing of a late proposal or acidification sent either by registered or certified mail is the U.S.
or Canadian Postal Scrvice postmark on the wrapper or on the original receipt ,
from the U.S. or Canadian Postal Service. If neither postmark shows a legible cate, the proposal, quctatica, cr modification shall be processed as if mailed letE. " Postmark" means a printed, stamped, or otherwise placed impression (exclusive of a postage meter machine impression) tnat is readily identifiable without further acticn as having been supplied and affixed by empicyees of the U.S. or Canadian Postal Service on the date of mailino. Therefore, offerors or quoters should request the postal clerks to place a hand cancellation bull's-eye postmerk on both the receipt and the envelope or wrapper.
(e) The only acceptable evidence to esteloiish the time of receipt at the Covernment installation is the time /date stamp of that-installation on the proposal wrapper or other docurertary evidence of receipt maintained by the installation.
(f) Notwithstanding paragraph (a) above, e late modification of an otherwise successful proposa7 that makes its terms nore favorabie to the Government will be considered at u.y time it is received and may be accepted.
(g) Proposals may be withdrawn by written notice or telegram (including mailgram) received at any tire before awardi Proposals may be withdrawn in person uy an offeror or an authorized representative, if the representative's
~
idertf ty is made known and t+ie representative signs e receipt for the proposal before awart ' '
(End of ^ proiision)
(R 7-2002.4 1979 MAR)
(1-3,802.1) l I l , E
_ - - _ _ _ - _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ._. _. _ ._ _ _ _ _ _ __ _ A
l l
l:
RS-AED-87-129 l PAGE 58 52.216-1 TYPE OF CONTRACT. (APR1984)
The Government contemplates award of a Cost Plus Fixed Price contract L resultin9 from this solicitation.
l (Endofprovision) l (R 3-501(b) Sec L (iv))
52.233-2 SERVICE OF PROTEST (JAN1985)
Protests, as defined in section 33.101 of the Federal Acquisition Regulation, shall be served on the. Contracting Officer by obtaining written and dated acknowledgement of receipt from the Division of Contracts; U.S. Nuclear Regulatory Commission; 4550 Montgomery Avenue; Suite 2223; Bethesda, Maryland 20814.
(EndofProvision) 52.252-1 SOLICITATION PROVISIONS INCORPORATED BY REFERENCE. (APR 1984)
This solicitation incorporates the following solicitation provisions by reference, with the sene force and effect as if they were given in full text.
Upon request, the Contracting Officer will make their full text available.
I.FEDERALACQUISITIONREGULATION(48CFRCHAPTER1)SOLICITATIONPROVISIONS Section L 52.215-5 SOLICITATION DEFINITIONS. (APR1984)'
52.215-7 UNNECESSARILY ELABORATE PROPOSALS OR QUOTATIONS. (APR1984 52.215-8 ACKNOWLEDGMENT OF AMENDMENTS TO SOLICITATIONS. (APR 1984) ).
52.215-9 SUBMISSION OF 0FFERS. (APR1984) 52.215-13 PREPARATION OF 0FFERS. (APR1984) 52.215-14 EXPLANATION TO PROSPECTIVE OFFER 0RS. (APR1984) 52.215-15 FAILURE TO SUBMIT OFFER. (APR1984) 52.215-16 CONTRACT AWARD. (APR1985) 52.222-24 PREAWARD ON-SITE EQUAL OPPORTUNITY COMPLIANCE REVIEW. (APR 1984)
Section P Section M - Evaluation Factors for Award l M.1 -Contract Award and Evaluation of' Proposals.
- a. By use of numerical and narrative scoring techniques, proposals will be- l evaluated against the evaluation factors specified in the paragraph l below. These factors are listed in their relative order of importance.
Award will be made to the offeror (1) whose proposal is technically acceptable and (2) whose technical / cost relationship is most !
advantageous to the Government; and who is considered to be responsible within the meaning of Federal Acquisition Regulation Part 9.1.
E-*
a .
RS-AED-87-129 PAGE 59
- b. Although cost will be a factor in the evaluation of proposals, technical merit in the evaluation criteria set forth below will be a (nore significant factor in the selection of a Contractor. Further, to be selected for an award, the proposed cost must be realistic and reasonable,
- c. Tha Government may:
1). Reject any or all offers if such action is in the public interest.
2). Accept other than the lowest offer.
3). Waive informalities and minor irregularities in offers received.
- a. The Government may award a contrect on the basis of initial offers received, without discussions. Therefore, each initial offer should contain the offeror's best terns from a cost or price and technical standpoint.
- e. A separate cost analysis will be performed on each cost proposal. To provide a commen base for evaluation of cost proposals, the level of effort data shall be expressed in staff hours.
- f. In making the above determination, an analysis will be perf6rmed taking into consideration the results of the technical evaluation, cost analysis, and ability to complete the work within the Government's l required schedule. ,
1 1 M.2 Evaluation Criteria Technical Qualifications (70%) 1 1
J 20% Demonstrated experience with and knowledge of: electronic / computer data handling and storage techniques, hardware, and software.
15% Demonstrated expu ience with and knowledge of: electronic data transmission techniques, hardware, and software.
15% Demonstrated experience with and knowledge of: nuclear power processes, and basic nuclear power plant designs as they relate to the variables to be transmitted and dispicyed.
5% Demonstrated experiento with ano knowledge of: commercial avail-ability and capabilities of a variety of hardware and sof tware.
1 b% Demonstrated experience with and knowledge of: information ,
display techniques and strategits especially related to dynamically j changing displays (e.g., familiarity with Safety Parameter Display 1 Systems).
1 l
. 1
PS-AED-87-129 PAGE 60 5% Demonstrated experience with and knowledge of: NRC incider.t response role and responsibilities especially related to data needs.
5% Experience with and knowledge ef: process instrumentation such as that used in nuclear power plants.
Program Management Qualifications (30%)
10% Realism of the schedule and time required to complete the work scope, considering the approaches specified. Ability to accelerate the completion of the project if required.
10% Cost estimation and control procedures, particularly the ability of the project manager to promptly identify and limit areas of over-expenditure to obtain specific objectives within budget allocations.
10% Assured availability of qualified personnel, addressing.
capebility for continued execution of the project after loss of one or more key individuals.
l l
l t 4
ATTACMENT 1 PART 20-1 -- GENERAL Subpart 20-1.54--Contractor Organizational Conflicts of Interest Sec.
20-1.5401 Scope and policy.
20-1.5402 Definitions. )
20-1.5403 Criteria for recognizing contractor organizational' 1 roaflicts of interest. j 20-1.5404 Representation.
20-1.5305 Contract clauses. i 20-1.5405-1 General contract clause.
20-1.5405-2 Special contract provisions.
20-1.5406 Evaluation, findings, and contract award..
20-1.5407 Conflicts identified after award.
20-1.5408 (Reserved) j 20-1.5409 (Reserved) 20-l'.5410 Subcontractors.
20-1.5411 Waiver.
20-1.5412 Remedies.
AUTHORITY: Sec. 8, Pub. L.95-601, adding Sec. 170A to Pub. L.83-703, 68 Stat. 919, as amended (42 U.S.C. ch.14) 520-1.5401 Scope and Policy (a) It is the policy of the U.S. Nuclear Regulatory Commission (NRC) to avoid, eliminate or net.tralize contractor organizational conflicts of interest. The NRC achieves this objective 'uy requiring all prospective ,
contractors to submit infonnation describing relationships, if any, with J organizations or persons (including those regulated by NRC) which may l give rise to actual or potential conflicts of interest in the event of )
contract award.
(b) ' Contractor conflict of interest determinations cannot be made automatically or routinely; the application of sound judgment on virtually a case-by-case basis is necessary if the policy is to be applied so as to satisfy the overall public interest. It is not possible to prescribe :
in advance a specific method or set of criteria which would serve to i identify and resolve all of the contractor conflict of interest situations !
which might arise; however, examples are provided in these regulations to guide application of the policy. NRC contracting and program officials j must be alert to other situations which may warrant application of this policy guidance. The ultimate test is: Might the contractor, if awarded l the contract, be placed in a position where its judgment may be biased, or where it may have an unfair competitive advantage? i (c) The conflict of interest rule contained in this subpart applies to contractors and offerors only. Individuals or firms who have other relat-ionships with NRC (e.g., parties to a licensing proceeding) are. not covered by this regulation. This rule does not apply to the acquisition of consulting services through the personnel appointment orocess, NRC
7590-01 agreements with other government agencies, international organizations, or state, local or foreign governments; separate procedures for avoiding conflicts of interest will be employed in such agreements, as appropriate.
520-1.5402 Definitions (a) " Organizational conflicts of interest" means that a relationship exists whereby a contractor or prospective contractor has present or planned interests related to the work to be performed under an NRC contract which: (1) May diminish its capacity to give impartial, technically I
sound, objective assistance and advice or may otherwise result in a biased work product, or (2) may result in its being given an unfair competitive advantage.
(b) "Research" means any scientific or technical work involving theoretical analysis, exploration, or experimentation.
(c)
- Evaluation activities" means any effort involving the appraisal of a technology, process, product, or policy.
(d) ' Technical consulting and management support services" means internal assistance to a component of the NRC in the formulation or administration of its programs, projects, or policies which normally require the contractor to be given access to information which has not been made available to the public or proprietary information. Such services typically include assistance in the preparation of program plans; and preparation of preliminary designs, specifications, or statements of work.
1 (e) " Contract" means afiy contract, agreement, or other arrangement with the NRC except as provided in Section 20-1. 5401 (c) .
(f) " Contractor" means any person, firm, unincorporated association, joint venture, co-spons.or, partnership, corporation, affiliates thereof, or their successors in interest, including their chief executives, directors, key personnel (identified in the contract), proposed consultants 1
or subcontractors, which is a party to a contract with the NRC.
(g) " Affiliates" means business concerns which are affiliates of each other when either directly or indirectly one concern or individual controls or has the power to control another, or when a third party controls or has the power to control both (41 CFR 51-1.606-1(e)).
(h) " Subcontractor" means any subcontractor of any tier which l performs work under a contract with the NRC except subcontracts for I
supplies and subcontracts in amounts of $10,000 or less.
(i) " Prospective contractor" or " offeror" means any person, firm, unincorporated association, joint venture, partnership, corporation, or affiliates thereof, including its chief executive, directors, key personnel (identified in the proposal), proposed consultants, or subcontractors, submitting a bid or proposal, ss licited or unsolicited, to the NRC to obtain a contract.
g' 4
)
7590-01
)
(j) " Potential conflict of interest" means that a factual situation exists that suggests '(indicates) that an actual conflict of interest may-arise from award of a proposed contract. The term " potential conflict i of interest" is used to signify those situations which merit investigation prior to contract award in order to ascertain whether award would give rise to an actual conflict or which must be reported to the contracting officer for investigation if they arise during contract perfomance.
520-1.5403 Criteria for recognizing contractor organizational conflicts of interest (a) General. Two questions will be asked in detemining whether actual or potential organizational conflicts of interest exist: (1) Are there conflicting roles which might bias a contractor's judgment in relation to its work for the NRC? (2) May the contractor be given an unfair competitive advantage based on the performance of the contract?
The ultimate determination by NRC as to whether_ organizational conflicts :
of interest exist will be made in light of conrnon sense and good business judgment based upon the relevant facts disclosed and the work.to be performed. While it is difficult to identify and to prescribe in advance i a specific method for avoiding all of the various situations or relationships l which might involve potential organizational conflicts of interest, NRC personnel will pay particular attention to proposed contractual requirements which call for the rendering of advice, consultation or evaluation activities, or similar activities that lay direct groundwork for the NRC's decisions on regulatory activities, future procurement, and research programs.
(b) Situations or relationships which may give rise to organizational conflicts of interest. (1) The offeror or contractor shall. disclose information concerning relationships which may give rise to organizational conflicts of interest under the following circumstances:
(i) Where the offeror or contractor provides advice and recommendations to the NRC in a technical area in which it is also providing consulting assistance in the same arec to any organization regulated by the NRC.
(ii) Where the offeror or contractor provides advice to the NRC on the same or similar matter in which it is also providing assistance to any organization regulated by the NRC.
(iii) Where the offeror or contractor evaluates its own products or services, or the products or services of another entity where the offeror or contractor has been substantially involved in their development or marketing.
(iv) ,'here the award of a contract would otherwise result in placing the offeror or contractor in a conflicting role in which its judgment may be biased in relation to its work for the NRC or may otherwise result in an unfair competitive advantage for the offeror or contractor
o 7590-01 (2) The contracting officer may request specific information from an offeror or contractor or may require special contract provisions such as provided in $ 20-1. 5405-2 in the following circumstances:
(i) Where the offeror or contractor prepares specifications'which are to be used in competitive procurement of products or services covered by such specifications.
(ii) Where the offeror or contractor prepares plans for specific approaches or methodologies that are to be incorporated into competitive procurement using such approaches or methodologies.
(iii) Where the offeror or contractor is granted access to information not available to the public concerning NRC plans, policies, or programs which could form the basis for a later procurement action.
(iv) Where the offeror or contractor is granted access to proprietary information of its competitors.
(v) Where the award of a contract might otherwise result in placing the offeror or contractor in a conflicting role in which its judgment-may be biased in relation to its work for the NRC or may otherwise result in an unfair competitive advantage for the offeror or contractor.
(c) Policy application guidance. The following examples are l illustrative only and are not intended to identify and resolve all contractor organizational conflict of interest situations. (1) Example.
The XYZ Corp., in response to a request for proposal (RFP), proposes to undertake certain analyses of a reactor component as called for in the RFP. The XYZ Corp. is one of several companies considered to be technically well qualified. In response to the inquiry in the RFP, the XYZ Corp.
advises that it is currently performing similar analyses- for the reactor manufacturer.
Guidance. An NRC contract for that particular work normally would not be awarded to the XYZ Corp. because it would be placed in a position in which its judgment could be biased in relationship to its work for NRC. Since there are other well-qualified companies available, there would be no reason for considering a waiver of the policy.
(2) Example. The ABC Corp., in response to a RFP, proposes to perfonn certain analyses of a reactor component which are unique to one type of advanced reactor. As is the case with other technically qualified companies responding to the RFP, the ABC Corp. is performing various projects for several different utility clients. None of the ABC Corp.
projects have any relationship to the work called for in the RFP. Based on the NRC evaluation, the ABC Corp. is considered to be the best qualified company to perform the work outlined in the RFP. l l
7590-01 Guidance. An NRC contract normally could be awarded to the ABC Corp. because no conflict of interest exists which would motivate bias with respect to the work. An appropriate clause would be included in l
the contract to preclude the ABC Corp. from subsequently contracting for work during the performance of the NRC contract with the private sector which could create a conflict. For example, ABC Corp. would be precluded from the performance of similar work for the compary developing the .
advanced reactor mentioned in the example. [
(3) Example. As a result of operating problems in a certain type of commercial nuclear facility, it is imperative that NRC secure specific ;
data on various operational aspects of that type of plant so as to assure adequate safety protection of the public. Only one manufacturer has extensive experience with that type of plant. Consequently, that company is the only one with whom NRC can contract which can develop and conduct the testing programs required to obtain the data in reasonable time. That company has a definite interest in any NRC decisions that l might result from the data produced because those decisions affect the {
reactor's design and thus the company's costs. !
f Guidance. This situation would place the manufacturer in a mle in which its judgment could be biased in relationship to its work for NRC. .
Since the nature of the work required is vitally important in_ terms of NRC's responsibilities and no reasonable alternative exists, a waiver of the policy may be warranted. Any such waiver shall be fully documented and coordinated in accordance with the waiver provisions of this policy with particular attention to the establishment of protective mechanisms to guard against bias.
(4) Example. The ABC Co. submits a proposal for a new system for ;
evaluating a specific reactor component's performance for the purpose of developing standards that are important to the NRC program. The ABC Co.
has advised NRC that it intends to sell the new system to industry once )
its practicability has been demonstrated. Other companies in this business are using older systems for evaluation of the specific reactor j component. l Guidance. A contract could be awarded to the ABC Co provided that the contract stipulates that no information produced under the contract will be used in the contractor's private activities unless such information has been reported to NRC. Information which is reported to NRC by contractors will normally be disseminated by NRC to others so as to preclude an unfair competitive advantage that might otherwise accrue. When NRC furnishes information to the contractor for the performance of contract work, it shall not be used in the contractor's private activities unless such inforTnation is generally available to others. Further, the contract will stipulate that the contractor will inform the NRC contracting officer of all situations in which the information developed under the contract is proposed to be used.
l
7590-01 (5) Example. The ABC Corp., in response to a RFP proposes to assemble a map showing certain seismological features of the Appalachian fold belt. In accordance with the representation in the RFP and
$20-1.5403(b)(1)(1), ABC Corp. informs the NRC that it is presently doing seismological studies for several utilities in the Eastern United States but none of the sites are within the geographic area contemplated by the NRC study.
Guidance. The contracting officer would nonnally conclude that award of a contract would not place ABC Corp. in a conflicting role where its judgment might be biased. The work for others clause of 520-1.5405-1(c) would preclude ABC Corp. from accepting work during the term of the NRC contract which could create a conflict of. interest.
(d) Other considerations. (1) The fact that the NRC can identify and later avoid, eliminate, or neutralize any potential organizational conflicts arising from the performance of a contract is not relevant to a detennination of the existence of such conflicts prior to the award of a contract.
(2) It is not relevant that the contractor has the professional reputation of being able to resist temptations which arise from organizational conflicts of interest, or that a follow-on procurement is not involved, or that a contract is awarded on a competitive or a sole source basis.
520-1.5404 Representation (a) The following procedures are designed to assist the NRC contracting officer in determining whether situations or relationships exist which may constitute organizational conflicts of interest with respect to a particular offeror or contractor.
(b) Representation procedure. The following organizational conflicts of interest representation provision shall be included in all solicitations and unsolicited proposals for: (1) Evaluation services or activities; (2) technica" consulting and management support services; (3) research; and (4) other contractual situations where special organizational conflicts of interest provisions are noted in the solicitation and would be included in toe resulting contract. This representation requirement shall also apply to all modifications for additional effort under the contract except those issued under the " changes" clause. Where, however, a statement of the type required by the organizational conflicts of interest representation provision has previously been submitted with regard to the contract being modified, only an updating of such statement shall be required.
7590-01 ORGANIZATIONAL CONFLICTS OF INTEREST REPRESENTATION I' represent to the best of my knowledge and belief that:
The award to of a contract or the modification of an existing contract does ( ) or does not ( ) involve situations or relationships of the type set forth in 41 CFR520-1.5403(b)(1).
(c) Instructions to offerors. The following shall be included in all NRC solicitations: (1) If the representation as completed indicates that situations or relationships of the type set forth in 41 CFR 5 20-1.5403(b)(1) are involved, or the contracting officer otherwise determines that potential organizational conflicts exist, the offeror shall provide a statement in writing which describes in a concise manner all relevant facts bearing on his representation to the contracting officer. If the contracting officer determines that organizational conflicts exist, the following actions may be taken: (i) Impose appropriate conditions which avoid such conflicts, (ii) disqualify the offeror, or (iii) determine that it is otherwise in the best interest of the United States to seek award of the contract under the waiver provisions of 5 20-1.5411.
(2) The refusal to provide the representation required by 5 20-1.5404(b) or upon request of the contracting officer the facts required by 's20-1.5404(c), shall result in disqualification of the offeror for award. The nondisclosure or misrepresentation of any relevant interest may also result in the disqualification of the offeror for award; or if such nondisclosure or misrepresentation is discovered after award, the resulting contract may be terminated. The offeror may also be disqualified from subsequent related NRC contracts and be subject to such other remedial actions provided by law or the resulting contract.
(d) The offeror may, because of actual or potential organizational conflicts of interest, propose to exclude specific kinds of work from the statements of work contained in a RFP unless the RFP specifically prohibits such exclusion. Any such proposed exclusion by an offeror will be considered by the NRC in the evaluation of proposals. If the NRC considers the proposed excluded work to be an essential or integral part of the required work and its exclusion would work to the detriment i of the competitive posture of the other offerors, the proposal must be rejected as unacceptable.
(e) The offeror's failure to execute the representation required by subsection (b) above with respect to invitation for bids will be j considered to be a minor informality, and the offeror will be permitted I to correct the omission.
5 20-1.5405 Contract clauses 5 20-1.5405-1 General contract clause 7590-01 All contracts of the types set forth in 520-1.5404(b) shall include '
the following clauses:
(a) Purpose. The primary purpose of this clause is to aid in ensuring that the contractor: (1) Is not placed in a conflicting role because of current or planned interest (financial, contra .ual, organizational, or otherwise) which relate to the work under this contract, and (2) does not obtain an unfair competitive advantage over other parties by virtue of its performance of this contract.
(b) Scope. The restrictions described herein shall apply to performance or participation by the contractor as defined in 41 CFR 520-1.5402(f) in the actitities covered by this clause.
(c) Work for others. Notwithstanding any other provision of this contract, during the term of this contract, the contractor agrees to forego entering into consulting or other contractual arrangements with any firm or organization, the result of which may give-rise to a conflict of interest with respect to the work being perfonnecf15& this contract.
The contractor shall ensure that all employees who are employed full time under this contract and employees designated as key personnel, if any, under this contract abide by the provision of this clause. If the contractor believes with respect to itself or any such employee that any
, proposed consultant or other contractual arrangement with any firm or i
organization may involve a potential conflict of interest, the contractor shall obtain the written approval of the contracting officer prior to execution of such contractual arrangement.
(d) Disclosure after award. (1) The contractor warrants that to the best of its knowledge and belief and except as otherwise set forth in this contract, it does not have any organizational conflicts of interest, as defined in 41 CFR 520-1.5402(a).
(2) The contractor agrees that if after award it discovers organizational conflicts of interest with respect to this contract, it shall make an imediate and full disclosure in writing to the contracting officer.
This statement shall include a description of the action which the contractor has taken or proposes to take to avoid or mitigate such conflicts. The NRC may, however, terminate the contract for convenience if it deems such termination to be in the best intere$ts of the government.
(e) Access to and use of information. (1) If the contractor in the performance of this contract obtains access to information, such as NRC plans, policies, reports, studies, financial plans, internal data protected by the Privacy Act of 1974 (Pub. L.93-579), or data which has not been released to the public, the contractor agrees not to: (i) Use
'such information for any private purpose until the information has been released to the public; (ii) compete for work for the Commission based
7590-01 1
] ;
on such information for a period of six (6) months after either the completion of this contract or the release of'such information to the j public, whichever is first, (iii) submit an u'1 solicited proposal to the government based on such information until one year after the release of such information to the public, or (iv) release the information without prior written approval by the contracting' officer unless such information has previously been released to the public by the NRC. ,
l (2) In addition, the contractor agrees that to-the extent it '
receives or is given access to proprietary data, data protected by the Privacy Act of 1974 (Pub. L.93-579),.'or other confidential or privileged technical, business..or financial information under this contract, the .
contractor shall treat such information in accordance with restrictions placed on use of the information.
(3) The contractor shall have, subject to patent and security provisions of this. contract, the right to use technical data it produces under this contract for. private purposes.provided that all . requirements of this contract have been met.
(f) Subcontracts. Except as provided in 41 CFR 5 20-1.5402(h), the contractor shall include this clause, including this paragraph, in subcontracts of any tier. The terms " contract," " contractor," and
" contracting officer," shall be appropriately modified to preserve the !
government's rights.
(g) Remedies. For breach of any of the above proscriptions or for intentional nondisclosure or misrepresentation .of any relevant interect required to be disclosed concerning this contract or for such erroneous representat'.:3 as necessarily imply bad faith, the government may terminate th, conteact for default, disqualify the contractor from subsequent contractual efforts, and pursue other remedies as may be permitted by law or this contract.
(h) Waiver. A request for waiver under this clause shall be directed in writing through the contracting officer to the Executive Director for Operazions (EDO) in accordance with the procedures outlined in 5 20-1.5411.
I20-1.5405-2 Special contract provisions.
(a) If it is determined from the nature of the proposed contract that organizational conflicts of interest exist, the contracting officer j may determine that such conflict can be avoided or af ter obtaining a ;
waiver in accordance witn 320-1.5411, neutralized through the use of an appropriate special contract provision. If appropriate, the offeror may negotiate the terms and conditions of these clauses, including the extent and time period of any such restriction. These provisions include but are' not limited to:
i (1) Hardware exclusion clauses which prohibit the acceptance of production contracts following a related nonproduction contract previously performed by the contractor; (2) Software exclusion clauses; (3) Clauses which require the contractor (and certain of his key personnel) to avoid certain organizational conflicts of interest; and (4) Clauses which provide for protection of confidential data and guard against its unauthorized use.
(b) The following additional contract clause may be included as section (i) in the clause set forth in 20-1.5405-1 when it is determined that award of a follow-on contract would constitute an organizational conflict of interest.
(i) Follow-on effort. (1) The contractor shall be ineligible to participate in NRC contracts, subcontracts, or proposals therefor (solicited or unsolicited) which stem directly from the contractor's performance of work under this contract. Furthermore, unless so atrccted in writing by the contracting officer, the contractor shall not perform any technical consulting or management support services work or evaluation activities under this contract on any of its products or services or the products or services of another firm if the contractor has been substantially involved in the development or marketing of such products or services.
(2) If the contractor under this contract prepares a complete or essentially complete statement of work or specifications, the contractor shall be ineligible to perform or participate in the initial contractual ;
effort which is based on such statement of work or specifications. The (
contractor shall not incorporate its products or services in such statement I of work or specifications unless so directed in writing by the contracting officer, in which case the restriction in this subparagraph shall not apply, i
(3) Nothing in this paragraph shall preclude the contractor from offering or selling its standard commercial items to the gcvernment.
! 20-1.5406 Evaluation, findings, and contract award The contracting officer will evaluate all relevant facts submitted l by an offeror pursuant to the representation requirements cf i20-1.5404(b) l and other relevant information. After evaluating this information l against tne criteria ofJ 20-1.5403, a fincing will be mace by tne contracting l officer whether organizational conflicts of interest exist with respect to a particular offeror. If it has been determined that conflicts of I interest exist, then the contracting officer shall eitner:
(a) Disqualify the offeror from award, ,
4 i 7590-01 (b) Avoid or eliminate such conflicts by appropriate. measures; or
-(c ) Award the contract under the waiver provision of f20-1.5411.
I20-1.5407 Conflicts identified after award.
If potential organizational conflicts of interest are identified' after award with respect to a particular contractor, the contracting officer detemines that such conflicts do, in fact, exist and that. it would not be in the best interests of the government'to terminate the contract as provided in the clauses required by 120-1.5405,.the contracting l officer will take every reasonable action to avoid, eliminate, or, after obtaining a waiver in accordance with 520-1.5411, neutralize the effects of the identified conflict.
520-1.5408 (Reserved) 520-1.5409 (Reserved) 520-1.5410 Subcontracts The contracting officer shall require offerors and contractors to submit a representation statement in accordance with !20-1.5404{b)from J subcontractors and consultants. The contracting officer shall require ;
the contractor to include contract clauses in accordance with !20-1.5405 in consultant agreements or subcontracts involving performance of work under. a prime contract covered by this_ subsection.
5 20-1.5411 Waiver In the first instance, determination with' respect to the need to.
seek a waiver for specific contract awards shall be made'by the contracting officer with the advice and concurrence of the program office director and the Office of Executive Legal Director. Upon the recommendation of the contracting officer, and after consultation with the Office of the General Counsel, the EDO may waive tM policy in specific cases if he determines that it is in the best interest of the United States to do so.
Such action 'shall be strictly limited to those situations in which: -)
(1) The work to be performed under contract is vital to the NRC program; {
(2) the work cannot be satisfactorily performed except by a contractor 1 whose interests give rise to a question of conflict of interest; and (3) ;
contractual and/or technical review and supervision methods can be j employed by NRC to neutralize the conflict. For any such waivers, the 1 justification and approval occuments shall be placed in the Public~ l '
Document Room.
-I l ;
7590-01 920-1. 5412 Remedies .
In addition to such other remedies as may be permitted by law or contract for a breach of the restrictions in this subpart or for any intentional misrepresentation or intentional nondisclosure of any relevant interest required to be provided for this section, the NRC may debar the contractor from subsequent NRC contracts.
Dated at Washinaton, Dithis 27th day of March 1979.
For the fluclear Regulatory Commission l
bJJJ '
Samueijl- A lk k '
Secretary ofl the- Commission
\
l
-12 1
s
4 g ATTACHf4Ef1T 2 (REVISED 4/87)
BILLING INSTRUCTIONS FOR NRC COST-TYPE CONTRACTS General. The contractor shall submit vouchers for cost-reimbursement in the manner and format described herein and as illustrated in the sample voucher.
Number of Copies.. An original and two copies should be mailed to the NRC office identified below.
I Frequency. The contractor shall submit claims for reimbursement once I
each month unless otherwise authorized by the Contracting Officer.
Form. Claims shall be submitted on the Form DC-3 " Voucher for Purchases and Services Other Than Personal." These forms are available from the Contracting Officer. (The instructions for preparation and itemization of the voucher are shown on the form.)
-)
Billing of Costs Afte'r Expiration of Contract. If costs are incurred during the contract period and claimed after the contract has expired, the period during which these costs were incurred must be cited.
Currency. Billings may be expressed in the currency nornelly used by the contractor in maintaining his accounting records; payments will be made in that currency. However, the U. S. dollar equivalent for all invoices paid under the contract may not exceed the total U. S. dollars authorized in the contract. ;
l Supersession. These instructions supersede all previous billing instructions.
_ _____-_m_-____ _ _ . _ _ _ _ _ . . . _ _ _ _ _ _ _ _ _ _ _ _ _ . _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ . -
l j
INSTRUCTIONS FOR PREPARING COST INFORMATION FOR NRC CONTRACTS I
Preparation and Itemization of the Voucher. The contractor shall furnish the information set forth in the explanatory notes below. These notes are keyed to the entries on the sample voucher.
Payor's Name and Address. (i) Address the original voucher (with 2 copies) to: U.S. Nuclear Regulatory Comission, Division of Accounting and Finance, ATIN: GOV /00M Accounts Section, Washington, DC 20555 Any questions regarding vouchers yet to be paid by the NRC sh'ould be addressed to Division of Accounting (301-492-an30). Any questions ,
regarding vouchers for which payment has been received (either in full or partially with suspensions or disallowances) should be ad-- '
dressed to the Contracting Officer.
Payee's Name and Address. Show the name of the contractor as it appears in the contract and its correct address; except when an approved assign-ment has been made by the contractor, or a different payee or addressee has been designated, then insert the name and address of the payee.
Indicate the individual responsible for answering any questions NRC may have regarding the invoice (name and phone number).
)
(a) Contract Number - Insert the NRC contract number.
(b) Title of Project - List the full title of the project being performed under this contract.
(c) Voucher Number - Insert the appropriate serial number of the voucher j beginning with 001 for this contract. Contractors may also include- ;
individual internal accounting numbers in addition to the three digit i number. !
(d) Date of Voucher - Insert the date the voucher is prepared.
(e) Contract Amount - Insert the total estimated cost of the contract, exclusive of fixed-fee. i (f) Fixed Fee - Insert total fixed-fee (where applicable).
(g) Billing Period - Insert the beginning and ending dates (day, month, and year) of the period in which costs were incurred and for which reimbursement is claimed. ;
i s
(h) Direct Costs - Insert the major cost elements.
(1) Direct Labor - This consists of salaries and wages paid (or accrued) for direct performance of the contract itemized as follows:
Labor Labor Hours Cumulative !
Category Negotiated Hours Billed Rate Total Hours Billed
'(2) Fringe Benefits - This represents fringe benefits applicable to direct labor and billed as a direct cost. Where a rate is used, indicate the rate. Fringe benefits included in direct labor shoJ1d not be identified here.
(3) Direct Equipment - For educational institu-tions list each item costing 5500 or more, and having a life expect-ancy of more than one year. For contractors other than educational institutions list each item costing $200 or more, and having a life expectancy of more than one year. List only those items of. equipment for which reimbursement is re A reference shall be made to the following (as applicable): quested.
(1) the item number for the specific piece of equipment listed in the property schedule of the contract; (2) the Contracting Officer's approval letter if the equipment is not covered by the property schedule; or (3) be preceded by an ast-erisk (*) if the equipment is below the approval level. Further itemization of vouchers shall only be required for items having specific limitations set forth in the contract.
(4) Materials, Supplies, and Other Expendable Items - These are consumable materials and supplies and equipment other than that described in (3) above.
(5) Premium Pay - This is remuneration in excess of the basic hourly rate. (Requires written approval of Contracting Officer.)
(6) Consultants' Fee - The supporting information must include the name, hourly or daily rate of the consultant and reference the NRC approval (if not specifically approved in the original contract).
(7) Travel - Domestic travel is travel within the United States, its territories, possessions, and Canada; it should be billed separately from foreign travel . Travel costs billed will provide for individual Per Diem, and all supporting infonnation for each trip taken.
l l
e 4 m a a All costs associated with each trip must be shown in the following ;
format: (Unless the organization's travel policy has been negotiated and approved by NRC) j
(
Da te Traveler Des tina tion Purpose Cost i From To From To
- 1. Airfare
- 2. Rental Car
- 3. Local Travel
- 4. Per Diem Days 9 =
- 5. Meals :
- Date Breakfast Lunch Dinner
- If not included in Per Diem.
- 6. Tips, Misc.
(Itemize if more than 510,00)
(8) Subcontracts - Include all costs paid to approved subcontractors during billing period. This includes the details of the subcontract terms (i.e.,
cost-plus-fixed-fee, direct labor, indirect costs, travel, profit, etc.)
(9) Other - List all other direct costs by cost elements and dollar amount separa tely.
(1) Indirect Costs--Overhead - Cite the formula (rate and base) in effect during the time the cost was incurred and for which reimbursement is claimed.
(j) Fixed-Fee - If the contract provides for a fixed-fee, it must be claimed as provided for by the contract. Cite the formula or method of computation.
Contractor may bill for fixed fee only up to 85% of total fee.
(k) Amount Billed for Current Period - Insert the amount billed for the major cost elements, adjustment, and adjusted amounts for the period.
i l
l
(1) Cumulative Amount from Inception to Date of this Billing - Insert the cumulative amounts billed for the major cost elements and adjusted amounts claimed during this contract.
(m) Total Amounts Claimed - Insert the total amounts claimed for the current and cumulative periods.
(n) Adjustments - This includes amounts conceded by the contractor, outstand-ing suspensions, and disapprovals subject to appeal.
(o) Grand Totals l
l l
1 i
5 e e
VOUCHERS FOR PURCilASLS AND SLRVICES OTHER lilAN PERSONAL SAMPLE VOUCHER Payor's Name and Address (a) Contract Number NRC-10-81-624 {
The U.S. Nuclear Regulatory Comission i Division of Accounting and Finance (b) Title of Project " Study of Nuclear Waste I' Attention: GOV /OJM Acets Section Concepts" Washincton; DC 20555 Payee's Name and Address (c) Voucher Number 003 ABC CORPORATION The National Bank (d) Date Voucher Prepared 10/18/82 l 100 Main Street or Anywhere U.S.A. ,
Anywhere U.S. A. Assignee for ABC CORP. (e) Total Estimated Cost of Contract Anywhere, U.S.A. $350,000.00 (When Payments Assigned)
Indiividual to Contract (f) Total Fixed-Fee ,
$17,500.00 Regarding This Voucner:
,Name: Harry Murphy i
'Tel. No.: 215-321-8654 l(g) This voucher represents reimbursable costs from 3/1/82 thru 3/30/82 Amount Billed l(h) Direct Costs (1) Direct Labor * $2.400 $6.800 _
- (2) Fringe Benefits @ l6.5 l (if computed as percentage) 600 1.200 ~
J (3) Direct 5,000 8.000 Equipnent
- _ _ _
(4) itaterials, Supplies and
- Other Expendable Items
- 2.000 4.000 (5) fremium Pay 100 150
! (6) Consultants
- 100 100 i (7) Travel - Domestic
- 200 200 ~
l Foreign
- _
l l ! (8) Subcontract
- 200 200 .
! (9) Other Costs
- 3.000 9.000
- " 55 '
l(i)
INDIRECT COSTS I
')
A Overhead 700 L of Total Direct Costs $13,600 $29.650 (Indicate Base) , _
! Subtotal $27.200 $59.300
- 0) General & Administrative Expense 3.264 6.450 12 L of Cost Elements Nos.1-9. A Total Costs $30.464 $65.750 (j) FlXED-FEE EARNED (formula) 1.523 3.400
$31.987 $69,150 (m) Total Amounts Claimed (n) Adjustments Outstanding Suspensions
- 1.700 1.700 (n) Grand intalf, $30.787 $67.4!0 l * (RitJtilRES SUN'OR11NG INf 0Rt1AT10N.)
(SIL A1TACilED.)
l ,
DC-3 ;'/n;' l l
l 1
~
\
l l
SAMPLE SUPPORTING INFORMATION
- 1) Direct Labor - $2400 Labor Labor Hours Hours Cumulative Category Negotiated Billed Rate Total Hours Billed Senior Engineer I 2400 100 $14.00 $1400 975 Engineer 1500 50 $10.00 $500 465 Computer Analyst 700 100 $5.00 $500 320 374W
- 3) Direct Equipment Spectrometer - General Electric (as approved in Property Schedule) $5,000
- 4) Materials, Supplies & Other Expendable Items i
10 Radon Tubes 9 $110.00 = $1100.00 l 6 Pairs Electrostatic Gloves 9 $150.00 = $900.00 52000.00 1
- 5) Premium Pay Walter Murphy - 10 hours1.157407e-4 days <br />0.00278 hours <br />1.653439e-5 weeks <br />3.805e-6 months <br />.9 $10.00 Per Hour = $100' (This was approved by NRC in letter dated 3/6/82.)
,6 ) Consultants' Fee Dr. Carney - 1 hour1.157407e-5 days <br />2.777778e-4 hours <br />1.653439e-6 weeks <br />3.805e-7 months <br /> 9 $100 = $100
- 7) Travel Date Traveler Destination Purpose Costs From To From To i 1
3/1/82 3/6/82 William King Chicago, Wash., Meeting with 1) Airfare $80.00 Il DC Project 2) Rental Car 515.00 Officer 4) Per Diem - 2 Days 9 $50.00 = $100.00
- 6) Tips, Misc. $5.00
' TOTAL: $200
8 4 a i
8). Subcontracts !
I XYZ CORP. (CPFF)
Direct Labor: - 80 hours9.259259e-4 days <br />0.0222 hours <br />1.322751e-4 weeks <br />3.044e-5 months <br /> 9 $20.00 per hour = $1600.00
-9 50%- = $800.00 0/H .
1 Travel.- 2 Trips - Wash., DC 9 $200 = $400.00 i to Boston, MA i Profit 9 7% = $200.00 TOTAL: 53000.00 l j
(j) Fixed-Fee (Formula)
(5%)
i i $350,000 X 5% = $17,500 Total Fixed Fee for this Contract' 1
$27,200 X 5% = $1360 Fee Billed for this Period j
, I l 1 (n) Adjustments '
$1700 - Indicates amount withheld from voucher #001, now approved by Contracting Officer letter 3/10/82.
q 1
l 1
i l
l
O s s ATTACHMENT 3
^
CONTRACT PRICING PROPOSAL COVER SHEET Y " " ^ ' " " " ' ' * " "
Eff8"""*'"
3090-0116 I feOTE: This form is used in contract actions if submission of cost or pricing data is required. (See FAR f 5 60defb))
2, N AME AND ADDRESS OF OF F E ROR ginclude /IP code) 3A, N AME AND 161 LE OF Of F E HOR'S POIN1 3D.1 ELEPHONL NO.
l OF CONT ACT l
- 4. TYPE OF CONTRACT ACTION (Check)
A. NEW CONTR ACT D. LETTER CONTRACT B. CH ANGE ORDE R E. UNPRICE D ORDE R F, OT HE 54 (Specify)
C. PRICE REVISIONf RE DETE RMINATION
- 5. TYPE OF CONT R ACT (Check / 6. PROPOSE D COST (A +B-ci ffP CPFF CPlF CPAF A. COST B, PROFIT /F EE C. T OT AL
] FPI ] OTHER (specify; $ $ $
- 7. PLACE (S) AND PE64100(S) OF PERFORMANCE
- 8. List and reference the identification, quantity and total price proposed for each contract line stem. A line item cost brealsdowo supporting this recap is re-l Quired unless otherwise specified by the Contracting Otlicer, (continue on reverse, and then on plain paper, if necessary, t/se same headings.)
A. LINE ITEM NO B. IDENTIF ICATION C. QU ANTITY O! TOTAL PRICE E.REF.
- 9. PROVIDE N AME, ADDRESS, AND TELEPHONE NUMBER FOR THE FOLLOWING tif available)
A. CONTR ACT ADMINISTR AT ION OFFICE B. AUDIT OFF ICE 10.WILL YOU REQUIRE THE USE OF ANY GOVERNMENT PROPERTY 11 A DO YOU REQUIRE GOVERN. Alp. TYPE OF FINANCING (v one)
IN T HE PERFORMANCE OF THIS WORK 7(if "Yes," identify) MENT CONT RACT FINANCING TO PE RFORM THis PROPOSED ADVANCE PROGRESS
[,U,"$;CT 7 (if "Yes " comptes' PAYMENTS PAYMENTS
]YES NO 12, HAVE YOU BEEN AW ARDED ANY CONTRACTS OR SUBCONT RACTS YES NO O Ou^RANTEED EO^NS 13,15 THt5 PROPOSAL CONSIST E NT WIT H YOUR EST ABLISHE D EST t-FOR THE SAME OR SIMILAR ITEMS WITHIN THE PAST 3 YEARS? MATING AND ACCOUNTING PRACTICES AND PROCEDURES AND (if "Yes," iden tsfy item (s), customer (s) and con tract number (s)) F AR PART 31 COST PRINCIPLEst (if "No," explaJn)
]YES ]NO O vES ONo
- 14. COST ACCOUNTING STANDARDS BOARD (CASB) DATA (Public Law 91379 as amended and FAR PART 30)
E WILL THIS CONTRACT ACT 80N BE SUBJECT TO CASB REGULA- B. HAVE YOU SOHMITTED A CASD DISCLOSURE ST ATEMENT F IONS 9 (if "No," explain in proposal) (CASH US 1 or 2I* (11"Yes."specify m proposal the office to whnch submitted and it determined to be adequate)
O vES NO O vES ONO C.HAVE YOU BEEN NOTIFIED THAT YOU ARE OR M AY BE ?N NON- O,IS ANY ASPECT OF THIS PROPOSAL INCONSISTENT WITH VOUR COMPLIANCE WITH YOUR DISCLOSURE ST ATEMENT OR COST DISCLOSED PR ACTICES OR APPLICABLE COST ACCOUNTING ACCOUNTING ST ANDARDS?(if " Yes," explain in proposall ST ANDARDS? (if "Yes ** explain in proposal)
]YES ONO OVES- NO This proposal is submitted in response to the RFP contract, rnodification,etc. in item 1 and reflects our best estimates and/or actual costs as of this date.
- 15. N AME AND TITLE (Type) 16. NAME OF FlRM
- 17. SIGN AT U R E 18. DAT E OF fpOBMISSION NSN 7540-01-142-9645 3431101 STANDARD FORM 1411 (10 th Prescribed by GSA l
- U.S. GOVEIGIMDfT PRINTING OFFICE 1984 0 - 421-526 (37) r AR g4s Cr R) 53.g35.ptc) ,
1 i
o .:
ATTACHMENT STANDARD FORM 1411 WITH INSTRUCTIONS
- 1. SF 1411 provides a vehicle. for the offeror to submit to the Government. a pricing proposal of estimated and/or incurred costs by contract line item 'j ~
with supporting information, adequately . cross-referenced, suitable . for- '
detailed analysis. A cost-element breakdown, using . the applicable format -
prescribed in 7A, B, or C below, shall be attached for 'each' proposed line {
item and must reflect any specific requirements established by the Contracting Officer. - Supporting breakdowns must be furnished for each' cost ~ j element, consistent with offeror's cost accounting. system. l When more than one contract line item is proposed, summary total amounts j covering all line items must be . furnished for each cost element. . If 1 agreement has been reached with Government representatives on use of forward pricing rates / factors, identify the agreement, include a copy, and describe its nature. Depending on offeror's system, breakdowns shall be provided for ,
the-following basic elements of cost, as applicable: l Materials - Provide a consolidated priced summary of individual material-quantities included in the- various tasks, orders, or contract line items being proposed and the basis for pricing (vendor quotes, invoice prices, etc.). .i Subcontracted items - Include parts, components, assemblies, and services i that are to be produced or performed by others in accordance with offeror's <
design, specifications, or direction and that are applicable ' only to the prime contract. For each subcontract over $500,000, the support should provide a listing by source, item quantity, price, type of subcontract, degree of competition, and basis for establishing source and reasonableness, of price, as well as the results of review and evaluation of subcontract proposals when required by FAR 15.806.
Standard Commerciai Items - Consists of items that : offeror normally fabricates, in whole or in part, .and that are generolly. stocked 'in inventory. Provide an appropriate explanation of the basis for pricing. If price is based on cost, provide a cost breakdown; if priced at other than cost, provide justification for exemption from submission of cost or pricing data, as required by FAR 15.804-3(e).
Interorganizational Transfer (at other than cost)' - Explain pricing method-used. (See FAR.31.205-26).
Raw Material - Consists of material in a form or state that requires further ,
processing. Provide priced quantities of items required for the proposal. l Purchased Parts . Includes material items not covered above. Provide priced quantities of items required for the proposal.
Interorganizational Transfer (at cost) - Include separate breakdown of cost by element.
_ - --__________._i___________.___
g
/
, , l' 4 Direct Labor - Provide a t we-pha sed (e.g., mcathly, quarterly, etc.) ' ~
breakdown of labor hours, ra tes ., and cost by appropriate category, and furnish bases for estimates.
Indirect Costs - Indicate how offeror has compu'ed and applied of feror'F indirect costs, including cost Dreakdowns, and sh(winn trends and budgetary data, to provide a basis for evalwtint 'the reasonableness of proposed rates. Indicate the rates used and prc. ride an appropriate explanation. ,.,
Other Costs - List all other costs not otherwise includeo in the categories '
described above (e.g., special tooling, travel, computer and consultant services, preservation, packaging and paceing, spoilage end rework, and federal excise tax on finished articles) and ' provide bases for pricing.
Royalties - If more than 5250, provide the following information on separtte x >
J page for each separate royalty or license fee: name ar, W ddress of 6 licensor; date of license ageewent; patent numbers, jatent application serial numbers, or other basis on which the royalty is payable;' brief description (including any par s or model numbers of each contract item or component on which the royalty is payable); percentage or dollar rate of ,
royalty per unit; unit price rf contract item; number of,, unity, and total i doller amount of royalties. In addition, if specifically requested by the 3 Contracting Officer, provide a copy of the current license agrsement and identification of applicable claims of specific patents. (See FAR 27.20f -
and 31.205-37).
Facilities Capital Cost of Money - When the offeror elects to 'lajm facilit,ies capital cost of money as an allowable cort, the offerow lauM submit Form CASB-CMF and shou the calculation of the proposed amount ;(fee FAR31.205-10). ,
b
- \
- 2. As part of the specific infctmation reauired, the . offeror must submit with offeror's proposal, and clearly identify-as such, cost or pricing data (that is, data that are verifiable and f actual and otf erwise as defined at; YAR 15.801). In addition, submit with ef fe ror's broposal any dnformatim reasonably required to explain o'fferor's estimating process, inclut.og;
- a. The judgmental factors applied and the matttmatical or other methods used in data; andthe estimate, incNding those usec .1n projecting frog known m
\
- b. The nature and amount of sny contingencies incleded in the propbsed price. ~
- 3. There is a clear distinction betw en submitting cost or pricing data and merely raaking available boo.k s , records, and other , documents without identification. The requirement for submission of cost c pricing data is met when all accurate cost or pricing data nasonably available to the t offeror have been submitted, either actually or by specific identification, to the Contracting Officer or en authoriceo' representative. As later information comes into the of fcror's possess.on, it should be promptly i a' submitted to the Contracting Officer. The N au t rement for submission of cost or pricing data continues to the time of final agr emnt on price. -
t t.
- l. -
\
i-l r
- '. f'
. =. ?, , L 'I ;_
i 4,
\ I k 'i
, i
, i f 4. In submitting of fero r 's popc' sal, of f ere r must include an index, appropriately referenced,; r f . all the cost or pricing data and information
/ I acc mpeyirq or iden'tificJf ni the p roposal . In addition, any future adq'tions and/or revishug, up to the date of agreement on price, must be annotated on a supplementbg lndex.'
(,
, t f
S. By . submitting 'cn feror's proposal,' rh offeror, if selected for negotiation, grants,'thc Contr c;rng Officer or 'en atthorized representative the rigM to examine the_,e books; records, docun.t!'ts , and other supporting data that wiil p2rmit adequate evaluation cf 'tre p roposed price. This right may be
.elercised at' any tirie before o-ard. *
- 6. As soon as practicable afteh final agreement on price, but before the award resulting from tLe r/onosal, the offeror shall, under the conditions stated in FAR 15.804-4. scu.it a Certificate of Current Cost or Pricing Data.
- 7. headings for Sublnission of Line-Its Summaries:
A. New Contracts (including Lettet contracts).
Proposed Contract Proposed Contract Cc'st Elements Estimate-To.tal Cost Estimate-Unit Cost Reference (1) '(2) (3) (4)
Under CWmn (1) - Enter appropriate cost elements.
Under ,aiumn (2) - Enter those necessar[ end reasonable costs that in oGeror b judgment will properly be incurred in efficient contract performance. When any of the costs in this column have already been incurred (e.g. , unde a letter contract cr unpriced order), describe them on an attaches supporting schedule. When reproduction or startup costs are significant, or when specifically requested to do 50 by the Con tracting Off'!cer, provide' 6 full identifice. tion and explanation of them.
Under Column (3) - Optional, unleks required by the Contracting Officer.
Under Column (4) Jo'en t i fy tn'e a Nchraent in which t hr- information supporting the specific cost element, may be found. At 't e c). separate pages as necessary, i
s
Change Orders (modifications).
B.
t s
[, Cost 0?
Estimated Deleted Cost of All Work .
Cost Work Already Net Cost To Cost Of Net Cost Of Elements Deleted Performed Be Deleted Work Added Change Reference t
(1) (2) (3) (4) (5) (6) (7) m Under Column (1) - Enter appropriate cost elements.
Under Column (2) - Include (i) currenttestimates of what the cost would have been to complete deleted work not yet performed, and (ii) the cost of deleted work already performed.
l Under Column (3) - Include the incurred cost of deleted work already performed, actually computed if possible, or estimated in the Cont.oaor's accounting records. Attach a detailed inventory of work, ma t4.'ri a l s , parts, components, , and hardware al ready purchased, manufactured, or performed and deleted by the change, indicating the cost and proposed disposition of each line item. Also, if offeror desires to retain these items or any portion of them, indicate the amount offered for them.
Under Column (4) - Enter the net cost to be deleted which is the estimated cost bf all deleted work less the cost of deleted work already performed. Column (2) less Column (3) - Column (4).
Under Column (5) - Enter the offeror's estimate for cost of work added by the changt. When nonrecurring costs a re significant, or when specifically requested to do so by the Contracting Officer, provide full identification, and explanation of them.
l Under Column (6) - Enter the net cost ot' change which is the cost of work added, less the net cost to le deleted. When this result is negative, place the amount in parentheses. Column (4) less Column (5) =
Column (6). i' Under Column (7) - Identify the attachment in which the information i supporting the specific cost element may be found. Attach sepa rate pages as necessary.
1.
l 91
)
C. Price Revision / Redetermination Number of Number of Redetermine-Units Units To Be Contract tion Proposal Cutoff Date Completed Completed Amount Amount Difference (1) (2) (3) (4) (5) (6)
Incurred Incurred Incurred Cost- Cost- Cost- Total Estimated Cost Preproduc- Completed Work In Incurred Cost To Estimated Elements tion Units Process Cost Complete Total Cost Reference (7) (8) (9) (10) (11) (12) (13) (14)
Under Column (1) - Enter the cutoff date requi red by the contract, if applicable.
Under Column (2) - Enter the number of units completed during the period for which experienced costs of production are being submitted.
Under Column (3) - Enter the number of units remaining to be completed under the contract.
Under Column (4) - Enter the cumulative contract amount.
Under Column (5) - Enter the offeror's redetermination proposal amount.
Under Column (6) - Enter the difference between the contract amount and the redetermination proposal amount. When this result is negative, place the amount in parenthesis. Column (4) less Column (5) = Column (6).
Under Column (7) - Enter appropriate cost elenents. When residual inventory exists, the final costs established under fixed-price-incentive and fixed-price-redeterminable arrangements should be net of the fair market value of such inventory. In support of subcontract costs, submit a listing of all subcontracts subject to repricing action, annotated as to their status.
Under Column (8) -
Enter all costs incurred under the contract before starting production and other nonrecurring costs (usually referred to as startup costs) from of fferor's books and records as of the cutoff date.
These include such costs as reproduction engineering, special plant rea rrangement, training program, and any identifiable nonrecurring costs such as initial rework, spoilage, pilot runs, etc. In the event the amouqts are not segregated in or otherwise available from offeror's records, enter in this column offeror's best estima tes . Explain the basis for each estimate and how the costs are charged on offeror's accounting records
(e.g., included in production costs as direct engineering labor, charged to manufacturing overhead, etc. ).. Also how the costs would be allocated to the units at their various states of contract completion.
Under Columns (9) and (10) - Enter in Column (9) the production costs from offeror's books and records (exclusive of reproduction costs reported in Column (8) of the units completed as of the cutoff date. Enter in Column (10) the costs of work in process as determined from offeror's records or inventories at the cutoff date. When the amounts for work in process are not available in Contractor's records but reliable estimates for them cen be made, enter the estimated amounts in Column (10) and enter in Column (9) the differences between the total incurred costs (exclusive of reproduction costs) as of the cutoff date and these estimates. Explain the basis for the estimates, including identification of any provision for experienced or anticipated allowances, such as shrinkage, rework, design changes, etc.
Furnsih experienced unit or lot costs (or labor hours) from inception of contract to the cutoff date, improvement curves, and any other available production cost history pertaining to the item (s) to which offeror's proposal relates.
Under Column (11) - Enter total incurred costs (Total of Columns (8), (9),
and (10)).
Under Column (12) - Enter those necessary and reasonable costs that in Contractor's judgment will properly be incurred in completing the remaining work to be performed under the contract with respect to the item (s) to which Contractor's proposal relates.
H*" eg nmn 33; ;m w i.a i ca nno wa cost (lotal of Columns (11) and (12)).
Under Column (14) - Identify the attachment in which the information supporting the specific cost element may be found. Attach separate pages as necessa ry.
- 9
> e (e.g., included in production costs as direct engineering labor, charged to manufacturing overhead, etc.). Also how the costs would be allocated to the units at their various states of contract completion.
Under Colunins (9) and (10) - Enter in Column (9) the production costs from offeror's books and records (exclusive of reproduction costs reported in Column (8) of the units completed as of the cutoff date. Enter in Column (10) the costs of work in process as determined from offeror's records or inventories at the cutoff date. When the amounts for work in process are not available in Contractor's records but reliable estimates for them can be made, enter the estimated amounts in Column (10) and enter in Column (9) the differences between the total incurred costs (exclusive of reproduction costs) as of the cutoff date and these estimates. Explain the basis for the estimates, including identification of any provision for experienced or anticipated allowances, such as shrinkage, rework, design changes, etc.
Furnsih experienced unit or lot costs (or labor hours) from inception of contract to the cutoff date, improvement curves, and any other available production cost history pertaining to the item (s) to which offeror's proposal relates.
Under Column (11) - Enter total incurred costs (Total of Columns (8), (9),
and (10)).
Under Column (12) - Enter those necessary and reasonable costs that in Contractor's judgment will properly be incurred in completing the remaining work to be performed under the contract with respect to the ite.. (s) to which Contractor's proposal relates.
Under Column (13) - Enter total estimated cost (Total of Columns (11) and (12)).
l Under Column (14) -
Identify the attachment in which the information supporting the specific cost element may be found. Attach separate pages as necessa ry.
l l
l
. s ATTACHMENT 4 NUREG/CR-4902 a
l i
i i
l Emergency Response Data System Requirements Analysis Report i
Final Report March 1987 Prepared by M. D. Birnbaum, J. L. Eberle / Phoenix G. W. Bethke, D. H. Schult1/ COMEX Prime Contractor Phoenix Associates, Inc.
l 4720 Montgomery Lane, Suite 600 Bethesda, MD 20814 Subcontractor COMEX Corporation ,
15118 Starr Place, S.E.
Olalla, WA 98359 Prepared for Incident Response Branch Division of Emergency Preparedness and Engineering Response Office of Inspection and Enforcement U.S. Nuclear Regulatory Comission Washington, D.C. 20555 l NRC-05-85-163
o e .
Contents
1.0 INTRODUCTION
TO THIS REPORT . . . ....... . . . . . . . . 1- 1 1.1 GOALS OF THIS REPORT WITHIN THE PROJECT . . . . . . . . .. . . 1- 1 1.2 ORGANIZATION OF THIS REPORT . . . . . . . . . . . .. .....1-1 1.3 CONVENTIONS FOR DEFINITIONS AND TYPOGRAPHY .... . . . . . . 1- 3 4
2.0 INTRODUCTION
TO THE CONCEPTS OF ERDS ...... . . .... . 2- 1 3.0 COMPUTER POINT SELECTION AND OTHER PARAMETER-RELATED DATA ISSUES 3- 1 3.1 USES OT DATA BY NRC . . . . . . . ...............3-3 3.2 THE SITE SURVEY PROCESS . . . .. ...............3-4 3.2.1 Administrative Tramework for surveying ... . . . . ... . 3- 5 3.2.2 Selection of Teeder Computer Systems ..... . . .... . 3- 5 3.2.3 Selection of Computer Points . ....... . . . . . .. . 3- 6 l 3.3 SURVEY INSTRUCTIONS TOR COMPUTER POINT SELECTION . . .... . 3- 6 3.3.1 Discrete versus Processed . . . ....... . . . .....3-6 3.3.2 Survey Checklist Structure . . ....... . . . .....3-8 l 3.3.3 Computer Point Selection . . . ... .... . .. .....3-8 1
3.4 ISSUES RELATED TO INCIDENT-ANALYSIS USAGE OF DATA BY NRC .. . 3-10 ,
3.5 DATA AVAILABILITY AT SITES .. ...... ..... . . . . . 3-13 j 3.6 SURVEY TINDINGS ON SELECTED TECHNICAL AND ADMINISTRATIVE ISSUES . 3-14 3.7 STANDARDIZATION OF DATA POINTS ...... ... . . .... . 3-17 3.7.1 How Computer Points Represent Parameters .. . . . . . . . . 3-18 j 3.7.2 Concept of Standardized Points ..... .. . . . . . . . . 3-18 i 3.7.3 The Recommended Alternative to Standardization: l The Data Point Library .. . . ...... . . . . . . . . 3-22 3.8
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS .. . . . .. .. . . 3-22 ,
4.0 DESIGN CONCIPTS FOR DATA IN ERDS ... ........... . . 4- 1 l 4.1 PARAMETERS, DATA POINTS, DATA POINT IDENTIFIERS AND VALUES . . . 4- 3 1 l
4.2 QUALITY TAGGING OF DATA POINT VALUES ... ... . ..... . . 4- 7 4.3 UPDATE FREQUENCIES; TIME STAMPING OT DATA POINT VALUES . . . . . 4- 9 1 4.4 DATA POINT DESCRIPTORS AND OTHER PLANT-DESCRIPTIVE DATA . . . . . 4-14 i 4.5
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS .. . ...... . . 4-17 I
5.0 DATA TRANSMISSION TROM SITES DURING INCIDENTS . . . . . .. . . . 5- 1 5.1 ISSUES IN STEADY-STATE TRANSMISSION OT A SINGLE TIED STREAM . . . 5- 1 5.1.1 Data Formats of Scalars . . . . . . .. . . . . . . . . . . . . . S- 1 5.1.2 Underlying factors Affecting Data Stream Tormat . . .... . . 5- 8 5.1.3 Data Tormat of a custon-Built communication Stream . . . . . 5-16 5.1.4 Handling a Pre-Existing Stream Tormat . ... ... .... . . 5-18 ,
5.2 MULTIPLE TIEDIRS AT A SITE
. .. ... ..... . . . . . . . 5-20 '
5.3 PROBLEMATICAL (SPECIAL-CASE) TEEDERS ......... . . . . . 5-24 5.4 INITIATING THE CONNECTION: COMMUNICATION TACILITIES FOR ERDS . . 5-26 5.5
SUMMARY
OT CONCLUSIONS AND RECOMMENDATIONS .. . . . . . . . . . 5-29 toc-1 l
l
3 i
I (Table of Contents, continued) 6.0 DATA POINT LIBRARY, CONCEPT AND IMPLEMENTATION . . . . . . . . . 6- 1 6.1 DATA POINT LIBRARY CONCEPT . . . . . . . . . . . . . . . . . . . 6- 1 6.2 DATA POINT LIBRARY CONTENT AND USE . . . . . . . . . . . . . . . 6- 3 6 . 3. DATA POINT LIBRARY RETERENCE SHEET STRUCTURE . . . . . . . . . . 6- 4 6.4 SUKKARY CT CONCLUSIONS AND RECOMMENDATIONS . . . . . . . . . . . 6- 4 ,
7.0 USERS AND USES OF ERDS-ACOUIRED DATA . . . . . . . . .. . . . . 7- 1 7.1 ERDS DESIGN CRITERIA . . . . . . . . . . . . . . . . . . . . . . 7- 1 7.2 TEATURES SPECIFICALLY EXCLUDED TROM ERDS DESIGN CRITERIA . . . . 7- 3 !
7.3 MANUALLY INPUT VARIABLES, PREDETERMINED AND ADHOC . . . . . . . . 7- 3 !
7.3.1 Input and Display of Manually Input Variables . . . . . . . . . 7- 6 1 7.4 SUKMARY OF CONCLUSIONS AND RECOMMENDATIONS . . . . . .. . . . . 7- 7 I l 8.0 TUNCTIONS, REQUIREMENTS, AND TACILITIES FOR DATA STORAGE AND INTERTACES TO USERS . . . . . . . . . . . . 8- 1 8.1 INCIDENT-TIME RECEIVING AND STORAGE OF DATA . . . . . . . . . . 8- 1 8.2 STANDARDIZED AND OTHER ERDS-COMPUTED DATA POINTS . . . . . . . . 8- 3 8.3 AUDIT TRAIL TOR DATA POINT VALUES . . . . . . . . . . . . . . . . 8- 4 8.4 MANUAL ENTRY OF DATA POINT VALUES (ADDITIONS, CORRECTIONS) . . . 8- 5 8.5 INTERTACES FOR DATA RETRIEVAL . . . . . . . . . . . . . . . . . . 8- 7 8.6 TACILITIES FOR DATA STORAGE . . . . . . . . . . . . . . . . . . 8- 8 8.7 DATA DISPLAY IN THE OPERATIONS CENTER . . . . . . . . . . . . . 8-11 8.7.1 Tabular Alphanumeric Display .. . . . . . . . . . .. . . . . 8-11 8.7.2 Pressure versus Temperature Display . . . . . . . . . . . . . 8-22 8.7.3 Data Point versus Time Display . . . . . . . . . . . . . . . 8-25 i C.7.4 Data Point Library Display . . . . . . . . . . . , .. . . . . 8-25 l 8.8 DATA ACCESS FOR NRC REGIONAL OTTICE AND OTHER REMOTE JSERS . . . 8-29 8.9 SYSTEM MAJAGEMENT TOR DATA STORAGE AND RETRIEVAL . . . . . . . . 8-29 8.10
SUMMARY
OF CONCLUSIONS AND REC 0 EMENDATIONS . . . . . . . . . . . 8-31 1
10.0 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . .. . . . . 10- 1 FIGURES 2-1 PVR Parameter List . . . . . . .. . . . . . . . . . . . . . . . 2- 3 2-2 BVR Parameter List . . . . . . . . . . . . . . . . . .. . . . . 2- 4 6-1 Data Point Library Reference File . . . . . . . . . .. . . . . 6- 5 8-1 Organization of Parameters by Critical Safety Tunction . . . . 8-13 8-2 Example of Recommended Multi-Column Tabular Display Tornat . . 8-15 8-3 Example of Recommended 1-Column Tabular Display Tornat . . . . . 8-16 8-4 Pressure vs Temperature Display . . . . . . . . . . . . . . . . 8-23 :
8-5 Data Point vs Time Display . . . . . . . . . . . . . . . . . . . 8-26 8-6 PVR Data Point Library Reference File . . . . . . . . . . . . . 8-27 8-7 BVR Data Point Library Ref erence File . . . . . . . . . . . . . 8-28 Toc-2
i'
1.0 INTRODUCTION
TO THIS REPORT 1.1 GOALS OF THIS REPORT WITHIN THE PROJECT This ERDS Requirements Analysis Report presents the design concepts and requirements of ERDS, the Emergency Response Data System for the NRC Operations Center, as they have emerged in this project. Analysis of the data collected by the site survey phase of the project is complete, and conclusions drawn have been used in the development of this report.
This' report is intended to serve several purposes:
i 1. It introduces the important concepts and requirements of ERDS, and i
discusses design issues, to serve as a description of the system as it is l currently conceptualized. l l
1
- 2. It includes a discussion of percentages and estimates of licensee computer i and telecommunications system attributes affecting the ERDS design, based on analysis of all the information collected in surveying roughly 80% of the 120 operating and NTOL (Near-Term Operating License) plant units ir. J the U.S.
- 3. It sets forth the assumptions and basis upon which the ERDS requirements analysis has been completed.
- 4. It presents the decisions and recommendations of the project team l regarding various design issues of ERDS, to provide a basis for ERDS l detailed design and implementation'n.
1 The site survey portion of the project ended in November 1986. Efforts between December 1986 and March 1987 have concentrated on survey data extraction and computer-assisted data analysis. Since some readers may not be familiar with the survey portion of the project, some overview material ,
describing the survey is presented in chapter 3 of this report.
l 1.2 ORGANIZATION OF THIS REPORT The topics and issues which need to be discussed to characterize ERDS are wide-ranging. The most intuitive axis for organizing them is based on the flow of the data that ERDS will collect: from its origin in plant instrumentation and software, through licensee data systems to a. data communications interface, transmission to the NRC Operations Center, 1-1
receiving and storage in a database there, and usage by NRC people and l software.
There are several other factors which have influenced our organization of the material. Firstly, in the description of available licensee data, there is the need to include some discussion of the data needs of NRC users, in order to form a basis for selection of the limited amount of data that ERDS will acquire. Aspects of the data needs of users also influence some of the conclusions about the requirements of the ERDS data transmission facilities.
Secondly, there is the pragmatic fact that technological details of two distinct expertise areas, nuclear. plant systems and computer systems, need to be discussed to present the justification for various design decisions. In our project team, these specialties were concentrated in different people, and we suspect that most readers will likewise be specialized toward one area or the other. This led us to organize two of the topical areas on the data flow axis -- description of the data that ERDS will collect, and the users /uses of the data in the Operations Center -- with material in nuclear engineering terms first, followed by the computer system design abstractions and computer technology issues. Throughout the report, the terms
" parameter-related" and " computer-related" are used as verbal abbreviations for these specialized viewpoints or expertise areas.
Chapter 2 of this report presents a brief introduction to the concepts of ERDS as they were presented at the beginning of this project. This is intended to (1) describe the starting point and the direction provided to this ERDS requirements analysis and design project, (2) present an overview of ERDS for readers unfamiliar with its goals, and (3) introduce a few (
concepts and issues that would otherwise need forward references within I the data-flow sequencing of topics, i
Chapter 3 discusses, in nuclear engineering terms, data availability at plant sites and the process of computer point selection in licensee data systems, as it was conducted in our site surveying activities. Some discussion of data needs of NRC users is included in this chapter.
Chapter 4 presents the design concepts for data in ERDS. In this chapter are the generalizations and abstractions drawn from the situations and examples described in Chapter 3.
Chapter 5 discusses the various issues involved in data transmission from ,
sites during incidents. This material is primarily in the domains of computer system and data communication toples. Site survey findings about
]
licensee data systems are included in this chapter.
1-2
__m
)
Chapter 6 discusses plant-descriptive data acquisition and management.
This is data whi'ch does not change during an incident, which ERDS will need to store and provide to users (people and software) to facilitate understanding of the parameters that ERDS is receiving. The focus in this chapter _ is on the mechanisms and procedures that will be needed to acquire and manage this data, accompanied by recommendations concerning what should be included in' this category of data.
Chapter 7 discusses users and uses of ERDS-acquired data, from a~ user requirements perspective. There are two main categories of users: people (in'the NRC Headquarters Operations Center and elsewhere) and software (such as computational models).
Chapter 8 describes the functions and facilities of the Operations Center part of ERDS from a computer systems perspective. Yithin the data flow -
topical organization, this chapter begins with the receiving of transmissions i from a plant during an incident. The data undergoes initial processing and is stored in a database facility. Functions and' capabilities needed _ to j provide for the consumers of the data are characterized. Specifle display subsystems and display contents are recommended.
Chapter 9 provides .a cost estimate for the implementation of ERDS, based upon the characterization in this report guidance provided by NRC, and extrapolations from the surveyed set of reactor units to all units.
Each of chapters 3 through 8 ends with a section that summarizes the conclusions and recommendations discussed in earlier sections of that chapter. These summaries are not intended to be intelligible without prior reading of the entire content of the chapter.
1 1.3 CONVENTIONS FOR DEFINITIONS AND TYPOGRAPHY l 1
Definitions of terms used with special. meaning are d highlighted >> in' the I text by underlining and bracketing with double asterisks.
Chapter 10 is a glossary of all highlighted terms, acronyms, and- ,
abbreviations used in the text.
1-3 .
, o .
2.0 INTRODUCTION
TO THE CONCEPTS OF ERDS This chapter presents a brief introduction to the most important concepts of ERDS. Two purposes are intended.
Firstly, there are a number of basic premises, principles, and decisions about what ERDS should and should not be, which were made by NRC before )
this project began. These concepts were presented at the beginning of the project, in two sources:
- 1. the project's Request for Proposal [RS-OIE-85-163];
- 2. an NRC staff paper submitted to the NRC Commissioners, entitled j
" Upgrading the NRC Operations Center's Emergency Data Acquisition Capability", dated 12/21/84.
As such, these concepts underlie all the work done in this project. Many of them are not discussed further in later chapters of this report, but they need to be understood as part of the conceptual underpinning of ERDS. I Secondly, there are some design issues (which were a focus of this project) )
which may be mentioned or referred to in subsequent chapters but before j the place where they are discussed in depth. These issues receive an i introduction here, so that their subsequent mentions will not have to dii;ress for an introduction. l l
- 1. ERDS will receive data electronically from a licensee's computer (s) during incidents. It will reduce the need for voice transmission of parameter values on the ENS phone line.
- 2. ERDS is not NDL: it will transmit parameter values only during incidents.
This concept is considered important by NRC because of the controversies associated with its Nuclear Data Link initiatives in the early 1980s.
Corollary to this concept is the idea of << The Feed Switch >>, a licensee-controlled switch which enables / disables the flow of data from licensee computer (s) into ERDS.
The Feed Switch should be thought of as a conceptual entity, not a physical toggle switch, which may be implemented by a licensee in whatever functional form it chooses, consistent with other aspects of the licensee /NRC interface for ERDS. The two key points of that sentence are:
2-1
(a) The NRC will not include an implementation of The Feed Switch in its part of ERDS. (b) A physical switch is not necessary to implement The Feed Switch, so the physical and procedural arrangements for the licensee /NRC data interface and its initiation (turn-on) should not be constrained by the need for physical access to such a switch.
- 3. ERDS will provide '" automatic transmission' of selected parameters from licensee's existing electronic data systems" [ Commissioners Paper, page 3).
Two lists of parameters selected by. NRC were included in the Commissioners Paper, one for BWRs and one for PWRs. As a general concept, these two lists are' called << the BWR Parameter List >> and
<< the PWR Parameter List >>, or collectively << the ERDS Parameter List (s) >>. Their elements are called << ERDS Darameters >>. Figures 2-1 and 2-2 show the contents of-the PWR Parameter List and the BWR Parameter List.
Licensee data systems generally have a formalized set of data entitles we.
will call << data points >> or << computer points >> (synonymous),
variables whose values indicate plant operating conditions, radiological measurements, or meteorological conditions. For at least some of the ERDS parameters, plant data systems generally have multiple. data points that can provide the information being sought by NRC. For a given plant, therefore, the selection of the one or more data points to '<< represent >>
each parameter on the ERDS Parameter List must consider plant engineering details and judgments reflecting the information needs of the NRC Incident Response teams, as well as the availability of means for transmitting data from the hosting computer.
For a particular plant, the set of data points to be transmitted by ERDS will be predetermined. ERDS will not have any mechanism for changing this set of data points during an incident.
Two important design issues arise from the concept of ERDS receiving a fixed pre-determined set of plant-specific data points to represent the ERDS Parameter List:
a) How will NRC receive (know) the plant-specific meaning associated with -
each of these data points? What happens.when changes in plant -
engineering (or plant computer systems) cauees the meaning to change?-
b) To what extent should the data point values received by ERDS be
<< standardized >> across plants (in terms of the definition of the quantity being measured and the engineering units) before being used i by NRC?
2-2
- c; - _ ._________- _ _
1
.ll l
FIGURE 2-1 PWR PARAMETER LIST Primary Coolant System Pressure Tempt.ratures - hot leg Temperatures - cold leg l i Temperatures - core exit thermocouple l Subcooling margin Pressurizer level RCS charging / makeup flow Reactor vessel level'(when available)
Reactor coolant flow Neutron flux - all rangest Secondary Coolant System Steam generator levels Steam generator pressure 2 Main feedwater flows ,
Auxillary / Emergency feedwater flows Safety inleetion High pressure safety injection flows Low pressure safety injection flows Safety injection flows (Westinghouse) ,
Borated water storage tank level I i
Containment j Containment pressure Containment temperatures l
Hydrogen concentration i Containment sump levels Radiation Monitoring System Reactor coolant radioactivity Containment radiation level condenser air removal radiation level Effluent radiation monitors Process radiation monitor levels Meteorological Wind speed Wind direction Atmospheric stability
- Changed during this project from "startup range" to "all ranges".
8Added during this project.
2-3
FIGURE 2-2 BWR PARAMETER LIST Reactor Coolant System Reactor Pressure Reactor vessel level Feedwater flow Neutron flux - all rangest Safety Irtlection RCIC flow HPCI/HPCS flow Core spray flow LPCI flow Condensate storage tank level Containment Drywell pressure Drywell temperature Hydrogen & Oxygen Concentration Drywell sump level Suppression pool temperature Suppression pool level Radiation Monitoring Systems Reactor coolant radioactivity level Primary containment radiation level Condenser off gas radiation levels Effluent radiation monitor Process radiation levels Meteorological Wind speed Wind direction Atmospheric stability 8 Changed during this project from "startup range" to "all ranges".
2-4 L E* _ _ _ _ _ - - - - _ _ __ - - _ - - - - - _ - _ - _ - -
. , e .
These design issues received a great deal of attention during this project and are discussed at length in the chapters which follow.
- 4. ERDS will use voice transmission on the ENS to receive "those few parameters which are not included in any particular licensee's system ....
thus avoiding backfitting requirements on the licenseo to include ;
additional parameters on their electronic data systems." [ Commissioners Paper, page 3-4) (ENS is the Emergency Notification System, a private voice network of leased telephone channels between each plant site and the NRC Headquarters Operations Center, used for continuous voice communication during an incident.)
- 5. " Data would be accepted in whatever format the licensee uses 'and reformatted at the Operations Center, as necessary." [ Commissioners Paper, page 4] The meaning of the word " format" in this sentence can have several interpretations, arising from the numerous possible electronic and i symbolic conventions for representing a number within a computer system, in communication between computer systems, and in communication between a system and its users. Arising from the possible interpretations of
" format", the following design lasues are among those which are addressed j
in later chapters (primarily in chapter 5).
(a) D'ata definition in terms of engineering units versus digital signal values (sensor readings) -- Should ERDS be able to accept data values resulting from analog-to-digital conversions before their processing in a licensee computer system converts them to an engineering units scale, or should the policy be that ERDS will only accept data points defined in engineering unit terms? See section 5.1.1. l l
(b) Number formats in terms of character strings versus internal binary l representations -- Should ERDS be able to accept numerical data values in l the internal binary representations of the licensee computer system, or should the policy be that ERDS will accept only character-string representations of number values? See section 5.1.1. l (c) Formats of Individual data point values (as character strings) -- If ERDS is to receive character-string representations of number values, how j should the variability which might be seen in the formatting of the values j for one data point be determined and described to establish a specification between ERDS and a particular licensee data system? See section 5.1.1. ;
(d) Formats of multiple data point values in terms of a stream of ,
characters -- Should ERDS be able to accept a stream of characters
'I 2-5 I
l
a . .
formatted the way an existing licensee data system sends it to an on-site printer or terminal, as long as the data needed by ERDS is embedded in the stream, or should the policy be that the formatting of the stream of characters above the level of individual data point values must conform to some ERDS standard conventions? See sections 5.1.3 and 5.1.4.
(e) Formatting of a character stream into a bit stream for data transmission (selection of character code, stop bits, parity, transmission speed, transmission protocol) -- What range of choices should ERDS be able to accept? See section 5.1.2.
l 6. "The best means for extracting the NRC's parameters from each system would be determined on a case-by-case basis." [ Commissioners Paper, page 4) The implication of this concept is that the ERDS design.must acknowledge and tolerate the diversity in licensee data systems. On the other hand, it would arguably not be best, from NRC's viewpoint, for ERDS to contain customized software for each 11censee data system. So the ERDS design must impose some standardization onto the diversity of licensee data systems. Any ERDS design decision which causes difficulty from the viewpoint of any particular licensee data system should be accompanied by sound justification.
- 7. ERDS should allow and promote more effective voice communication between NRC and the licensee on the ENS line. The transmission of data values electronically by ERDS will substantially reduce the burden of that function on the ENS communicators. Other implications of this objective are:
(a) In selection of data points for a particular. plant,'ERDS should transmit I
I to NRC the data points being seen and used by licensee emergency response staff, so that NRC/ licensee voice communica'.lon need not review i j the variations in the versions of the data being used by the two sides. '
l Technical details of a licensee data system may oppose this goal, creating
) a choice for NRC between a costly arrangement that provides NRC with the licensee's emergency response data points versus a less costly arrangement that provides other data points covering The Pararieter List.
(b) In data display facilities at the Operations Center, ERDS should allow i data to be viewed with the same definitions as used by the licensee, in I addition to whatever standardization (across licensees) are imposed by operations Center software. There is an intrinsic conflict between the i standardization and the view of the licensee. A computerized data system I can at best offer multiple views of the same data.
2-6
< , a .
l (c) In data display facilities at the Operations Center. ERDS should provide to NRC users adequate descriptive information about the definitions of the data they are seeing (and about the underlying plant I engineering), so that the mere presence of this data at NRC does not generate additional question / answer load on the ENS voice conversation and its communicators.
- 8. NRC intends to implement ERDS on a voluntary basis. In order to bypass j the delay associated with regulatory actions, connection to ERDS by a
!!censee will be voluntary. The . design of ERDS should therefore strive to minimize the costs imposed on licensees in preparing for ar.d maintaining their connection to ERDS.
Because of the wide diversity in computer systems and data definition among the licensees, and in their views toward the effort required to establish a capability for data transmission to ERDS, this concept has a variety of significant impacts on the design of ERDS. We use the terms
<< voluntary >> or << non-regulatory >> (synonymous), contrasted with I
<< prescriptive >> or << regulatory >> (synonymous), in discussing the j design implications of the two extremes in environment under which ERDS may be implemented. t
- 9. ERDS will not obtain << pre-initiation data >> (indicating conditions before !
the licensee enables ERDS data transmission). The design for the implementation of ERDS should not consider the possibility of obtaining l pre-initiation data from licensee data systems, even though many licensee l data synems keep recent history data available. However, NRC recognizes that pre-initiation data is often crucial to enable the interpretation of )
post-event data that ERDS will transmit. It is important that the design !
of ERDS does not preclude the possibility of a future ERDS enhancement to obtain pre-initiation data.
- 10. The facilities of ERDS need to support transmission from only one plant at i any given time. However, the design must allow for the possibility that, !
while one plant is transmitting data to ERDS, a second plant may attempt to begin transmission. This case may be a situation in which a real i incident occurs during an exercise, so the design must provide for a l rapid shift in the identity of the licensee using ERDS facilities. 2
- 11. At the NRC Operations Center. ERDS will include a data logging and storage facility, with long-term archiving. l
- 12. ERDS will provide tabular displays of data for NRC response personnel, and the ability for users to request trending plots of parameters vs time 2-7 ,
i
and pressure vs temperature. The data displays will consider the i different functions and needs of the Reactor Safety Team (RST) and the Protective Measures Team (PMT). The data displays will address the issues associated with standardization of format and meaning of data from different types of reactors and differences among licensees operating the !
same reactor type.
The availability of ERDS data at the Operations Center may lead to future consideration of many uses for the data. The concept of automatic extraction of data from the storage facility for input te ether software is necessary to allow such uses to be considered without concern for the burden on a human intermediary. In other words, the generalized needs of other software applications should be viewed as an important constituency of the ERDS-collected data, in addition to the human needs of the NRC response personnel.
- 13. ERDS data should be made available to users at the affected NRC Regional incident Response Center and at other locations away from the NRC '
Headquarters Operations Center. These users must have display access :
which is independent of the actions of the Headquarters Operations Center ,
analysis teams. j 1
l i
I l
l i
2-8
- c. .o. .o. _ , _ ----_
. e o .
3.0 COMPUTER POINT SELECTION j AND OTHER PARAMETER-RELATED DATA ISSUES Much of the work in the first part of this project went into a survey of the operating nuclear power plants in the U.S.' This survey had two focuses: '
collecting information about the availability of computer points that provide the information sought by the NRC-specified parameters, and about the 4 computer system and data communication issues associated with establishing data transmission paths from existing licensee data systems that can )
transmit the computer points. This chapter discusses the parameter aspects of the plant survey.
Included in this chapter are several sections which present discussions and conclusions regarding expected and potential NRC usage of ERDS-collectible data in incident analysis activities. These views and conclusions provide answers to ERDS design questions about various aspects and attributes of the data that ERDS will seek to obtain.
1 There are a number of terms that took on special specific meanings in our
~
discussions of parameter-related data and licensee dats, systems during the i course of the project. The following paragraphs explain their usage in this and subsequent chapters of this report.
Nbelear plant instrumentation and data systems generally consist of a sequence of processing steps that successively transform the. output of a transducer into a data point value. (A transducer is a sensor, a device that converts a physical phenomenon into an electrical-signal.) This sequence I typleally begins with an analog voltage output from the transducer, may pass through more than one computer system, and may involve algorithmic combination of multiple data points into a new one. We speak of this sequence of processing steps as a flow, referring to << upstream .>> as being closer to the transducer instrumentation and << downstream >> as being farther from it (and closer to NRC).
In this flow sequence of handling and processing of a data point value, there may be more than one computer system which could connect to ERDS to transmit the value. We use the term << feeder >> for a licensee data system that .wlli connect to ERDS to transmit at least one data point: << the !
ERDS feed >> refers to the movement of data from a feeder across a i licensee /NRC interface (non-voice) to ERDS. The meaning and attributes of a -
data point as it exists on its feeder system are a major focus of interest to ERDS. The details of the processing of a data point upstream of its feeder 3-1
)
are of inttrest to the extent they affect the meaning of the data point's values, but these details are of limited relevance to the computer-system aspects of ERDS. The important points are that there may be multiple licensee computer systems upstream of the feeder, that certain attributes of a data point (including details of its meaning) may change as it moves downstream, and that the update frequency often gets slower as the values move downstream.
Feeders generally receive updates of data point values from upstream computers and analog instrument loops at regular frequencies, although one feeder may receive different data points at different update frequencies.
This leads to the concept of a feeder transmitting to ERDS a group of data points' values at the same time, periodically. Such a group of values, representing a snapshot in time, will be called an << update set.>>. The important aspects of an update set are: (a) All its values can share the same time stamp, within the time precision available on that feeder; they are the most recent values available for those data points on that feeder at that time. (b) Each data point being sent to ERDS will, with fixed (possibly I
point-specific) periodicity, contribute a value to an update set.
- We found during the project that the data point relationships between reactor units and feeders, and their geographic relationships, were of great relevance to ERDS. The following terminology conventions were adopted to avoid confusion:
<< unit >> is one nuclear power plant, synonymous with << plant unit >> and
<< reactor unit >>.
<< olant site >> or << reactor site >> (synonymous) is a nuclear power plant -
site containing one or more units.
<< plant >> is ambiguous; it may refer to a plant site or a unit.
<< feeder site >> ls the location of a licensee computer system that will j transmit data to ERDS. It may be a plant site, corporate headquarters, or ;
some other location of licensee facilities. No geographic precision is intended beyond identification of a site operated by a licensee. Although it is conceivable that a licensee /NRC interface might be at a location other than the feeder site (e.g., via a licensee's remote communications ;
controller), a feeder site can generally be regarded as the likely location !
of the data transmission connection.
I'
<< survey site >> is a location visited during surveying activities, where meetings were held with licensee technical staff. Some survey sites (i.e., i 3-2 i
^ ^ _ _ _ _ _
some corporate headquarters sites) were neither a plant site nor a feeder site, and thus are not of interest to ERDS except in discussion of surveying activities.
3.1. USES OF DATA BY NRC Throughout the planning, survey development and conduct, and design phases of this project, the role and mission of the NRC have been a primary basis for decision-making about what ERDS should seek to do. The five statements which summarize the mission and role of the NRC are provided here for reference: I
- 1) Monitor the licensee to assure appropriate protective action recommendations are made to off-site authorities.
- 2) Support off-site authorities, including confirming the licensee's recommendations to off-site authorities.
- 3) Support the licensee.
- 4) Keep other federal agencies and entities informed of the status of the incident.
- 5) Keep the media informed of the NRC's knowledge of the status of the incident, including coordination with other public affairs groups.
Based on the mission and role of the NRC, and on our having observed the NRC Operations Center in numerous incident simulations, the NRC's need for ,
data and use of data received can be summarized as follows: I 1
Sufficient detail and frequency of thermal-hydraulic data are required to allow NRC to ascertain the actual failure of or the challenges to fission product barriers so that the probability of future radiological releases can be predicted and the appropriate, anticipatory protective actions l determined.
Suffielent radiological and meteorological data is needed in order to perform dose projections based on releases actually in progress.
Drawing a parallel between the NRC's use of data and the similar use of data by reactor licensees, the following can be stated:
3-3
Licensees' primary monitoring of the failure of and challenges to fission product barriers still occurs through the periodic monitoring of the control board instrumentation and supporting trend analysis in the TSC (Technical Support Center). The frequency at which human scan rates of data sets occurs in both of these cases is on the order of once every 1 to 5 minutes. The new SPDSs (Safety Parameter Display Systems) at reactor sites, with their nearly instantaneous update rates, are viewed by most licensees as an alerting tool and a convenient, automated trending device.
Licensee dose projection calculations are usually not performed more often than once every 15 to 30 minutes and are based on faired data (e.g.,15 minute averages of meteorological and radiological conditions).
Based upon the preceding points, the concept of electronic data transmission to NRC via ERDS should easily enable the NRC to perform its intended mission. While ERDS will not provide as many discrete data points or updates as frequently as what is available directly to licensees, it will provide approximately 30 to 50 times the influx rate of data available today in the Operations Center by voice communications.
3.2 THE SITE SURVEY PROCESS The site survey portion of the project ended in November 1986; subsequent efforts concentrated on survey data extraction, data analysis, and ERDS design. Since the audience for this report may include personnel not familiar with the survey portion of the project, an overview will be provided here.
Survey planning began in October 1985 with the development of survey instruments (checklists describing sought information) covering the areas of parameters, computers, and telecommunications. A pilot survey visit was conducted in November 1985 to test the survey instruments, and the results were incorporated as revisions in December 1985.
Site survey visits began to occur as fast as they could be scheduled <
beginning in April 1986. Initially, survey visits consisted of a nuclear operations engineer and a computer specialist. In June 1986, the computer and telecommunications survey instruments were further revised, to enable the surveying to continue without the presence of a computer specialist from the project team. NRC staff were available at all survey visits to explain the purpose of the project and to answer any polley-related questions.
3-4
e n .
' The survey visits encompassed 59 plant sites representing 92 reactor units. ]
For the approximately 30 reactor units which were not field surveyed, J partial or mail surveys were conducted for.19 units and no surveys were I conducted for 11 units. The results of the mail survey have just recently begun to arrive back at NRC and hence are not included in this report.
The concepts of ERDS presented in Chapter 2 were generally available at the start of the project and formed most of the basis for the design.of the survey. The following additional basic principles coalesced during the design and planning of survey activities.
3.2.1 Administrative Framework 'for Surveying l
a) The survey was conducted in a non-confrontational and non-regulatory mode, with voluntary licensee cooperation, b) Except for selection of feeder computer systems, the survey did not attempt to obtain authoritative pronouncements or commitments from' licensees about what they would do to support ERDS implementation.
Licensee opinions and preferences regarding specific ERDS-design choices :
were solicited, but not design commitments. This was a consequence of the survey's exploratory nature and its focus on obtaining technical infornfation from technical staff of licensees, without the compilation. of passing technical information through the licensees' established channels for formal interfacing with NRC.
c) The survey sought to describe the situation in licensee computer systems as of the time of surveying, except that: for 11censees having firm plans to make major modifications to potential ERDS feeders over the next 2 to 3 years, the survey sought to describe the situation after ecmpletion of modifications.
d) Selection of the feeder computer systems (that will supply ERDS data for a plant unit) had to precede the collection of both parameter-related survey data and computer-related survey data because the parameter-related surveying sought information describing the~ computer points avaliable to ERDS as they exist on a particular feeder system.
3.2.2 Selection of Feeder Computer Systems The following items were the criteria for selection of feeder computer systems:
3-5 i
a) A feeder must be capable of providing a serial data communication port for transmitting ERDS data. If a potential feeder has no unused serial ports and its configuration limits prevent addition of a new one. It is not a feasible candidate.
b)- A feeder must be capable of providing data points that are denominated. in engineering units (as opposed to a digital sensor reading value).
c) NRC currently considers a 15-minute update frequency as the threshold of acceptability, and 15-second update frequency as the ceiling of desirability.
I d) It is desirable that the data point versions sent to NRC be a subset of i those available to utility TSC staff, so that oral communication between-NRC and utility analysis teams is based on common underlying data. l j e) Within the above criteria, feeders were selected to minimize the number of j
l feeders needed to provide parameter-representing data points for all of a licensee's plant units.
3.2.3 Selection of Computer Points a) The survey sought to identify the plant-specific minimum set of most composed, most validated, widest-range computer points which fully describe each of the parameters on the ERDS Parameter List.
3.3 SURVEY INSTRUCTIONS FOR COMPUTER POINT SELECTION Since the primary function of ERDS will be to transmit computer points representing ERDS parameters, a basle understanding of the computer point selection process is useful in interpreting the overall ERDS design conclusions. The guidance provided to surveyors is summarized here. The l
following sections will familiarize those not directly involved in the ERDS !
project with important survey-related processes and definitions. l 3.3.1 Discrete versus Processed The terms " discrete" and " processed" are used to categorize the way in !
which a computer point is generated. The following explanation should clarity the intended meaning of these two terms:
l 3-6 I l
__ t e 3 - _ _______________J
r . . ,
DISCRETE:
The computer point represents a single analog or digital input from an instrument loop or sensor. Examples of discrete points include:
.= BWR HPCI flow or PWR cold leg injection flow where the point is a simple digital representation of 'a single flow sensor on a single pipe.
= Reactor Power where the point represents a single channel of power range instrumentation.
= Discrete points representing effluent gaseous concentration and stack flow (which, had they been processed within the feeder, could have produced a single variable representing release rate: see example below under Processed).
PROCESSED:
- The computer point is composed of 2 or more other computer points in the feeder's database. Examples of this include:
= radioactive release rates (using.a point representing activity l concentration multiplied by a stack flow rate point).
= auctioneered high core exit thermocouple.
= averaged suppression pool temperatures.
The computer point represents a single input from a remote computer system or microprocessor where the information has already been processed. Examples of this include:
= subcooling margin monitor inputs.
= 15 minute averages of wind direction computed in the met tower computer.
= radioactivity releases in C1/see or uC1/see computed in a separate dose assessment computer.
/
Many composed points are the result of processing performed on multiple points to create special points for use in SPDS displays (where SPDS and '
DAS share a common host computer). Information for composed or 3-7
i i
processed data which is only used to drive displays and which'is not ,
archived in a retrievable form in the feeder data storage medium was not used.
If a composed point, such as radioactivity release rate, exists only in a separate dose assessment computer (i.e., not sent to the ERDS feeder),
while only discrete points for concentration and flow exist on the j preferred ERDS feeder, then data for the discrete points versus data for the composed point was used to reduce the total number of feeders. If, however, there was a plan to input the composed point to the ERDS feeder at some future date (within about 2 years), the composed point was selected.
I 1
3.3.2 Survey Check!!st Structure The parameter-related survey instrument (checklist) was organized by 1 parameters. Each parameter (e.g., T-hot) had a generic checklist section . I and a parameter-specific checklist section. The generic checklist underwent some degree of customization for each parameter in an attempt to eliminate generic questions which did not apply (e.g., questions on reference point were eliminated for most parameters involving temperature and flow, since this question is only applicable to parameters involving levels, wind direction, etc.). Some of the questions in the generic checklist were l answered one time, if all computer points are being taken from the same computer system. Questions concerning licensee system response to failure of range and validation checks, instrument in test, and questionable data is an example of a category typically global to all parameters on a given computer system. The generic portion of the checklist for each parameter was followed by a 1 or 2 page parameter-specific checklist. The parameter-specific checklist contained detailed, plant- and computer point-specific questions.
3.3.3 Computer Point Selection The survey instructions cautioned surveyors to thoroughly understand the' following point selection criteria before proceeding with the survey:
The main theme of the computer point selection process is to identify the minimum set of computer points, svallable on the fewest (preferably one) number of feeders from a site, which fully describe each of the parameters on the ERDS Parameter List.
1 3-8
_= -- -- -
- - ~ - -
.y 7j
~ .- - . y :t 2 ,,
- /
Y
~
When multiple computer points' exist to describe a cartain parameter, there is f i j
usually one point or a small subset of points which met the follsy/ntf '
desirability criteria: )
F
(
a.
- For fiulds systems (e.g., HPCI. Building Ventilatl6n, Main feedwater, etc.) _ ,,
the points representing the farthest location downstream in the system arep.. ' '
most desirable. Examples: ', -l r 3 ._
= If the ventilation system exhausts from all buildings in tht po'rer block converge and ascend up a single plant vent stack, then in'.y the; effluent process radiation raonitors on the plant stack need be \ ,:
described under " gaseous offluent"'versus describing the Wdlyidual j
effluent monitors which may exist for each of the exhaus'tdines which "
f converge.
- o., ,
. .A 7
= If an injection or feedwater system has a set of points availabMahich include flows measured at the. pumt, dischargas, at a combined hinder and at the point in the system just prior to. injection into the loops o(
steam generators then the points which should be selected ar potential j ,
ERDS feeds are the furthest downstream points (flop measured jus't j prior to injection into loops or steam generators). /
k u
s J
Computer points which have undergono the maximum amount of range g4, checiang and other data point validation.schen.es should be selected. We.
are aware that many utilities are in the process of upgrading computer '
system validation techniques and that what exists not may tir replaced at p some future date. i Computer points representing the widest expected range of the parameterk should be selected. For example: If there is a choice of cemp(ter points i
('
A for " Containment Pressure" with one representing the range!- 5 f.o +5 PSIG and another representing the range to +100 PSIG, the vf tdd-rarde -5 to l
+100 PSIG computer point should be selected; even thou@ its ac'eupey s .
may not be as great near the normally expected pressure [of -1 to +1 PSIG.
M[ 4$
_ 1e e 3 The point composed of the maximum number of inputs should be used. '
The desirable point may be composed (processed) within the feeder computer or may be composed by. a separate nilerobrocessor outside the feeder as in the case of PWR Reactor Vessel Level Indication (RVLIS),
Subcooling Margin Monitors (SMM) and meteorologleal tower systems. The philosophy of selecting the most composed points should not be applied in the case of parameters associated with PWR coolant loops (e.g.. T-hot,
T-cold, S/G Pressure, S/G Level Main Feedwater Flow, etc.) to the extent 9
i w ,
- y. 'q 3-9 f (I'
. t :s ., )
lI l
Y1
S
' 4 If
\
- of selecting points such as " Average T-hot", beet.use loop-specific parametsis aro preferable for use it coolant-loop-specifle accidents rich as Stears Generator Tube Breaks. cow,)os;ed points such as " Average T-hot Lep 1", " Average 'T-hot ' Loo'p72", etc. should be selected.
h I
, /g , \
3.4 ISSUES RELATED TO PJgGEFT-ANALYl!S USAGE OF DATA BY NRC '
l in this section are discussloris of several issues affecting the ERDS design which were ralt.ed at various project status meetings withgRC. , The unifying thsme of these issues is the usefulness of data obtained by ERDS in assisting %RC In its treident analysis activities. The djated resolutions contributed ta the design recommendations for ERDS preserted later in this report. -
, e g 1) ELL CRDS ALLOV; NRC TO DETECT, SP!KES IN PARAMETERS?
e ,
One of the disign conclusions, dur'ag the project wil jaat the ERDS feeds i
from plants wil!'be sought by N3C su: a rate no more 7cequent than every 15 seconds. (This ' k ' discussed furGer in section 4.3.) la other words, if a particular dant data set consists of 55 compyter points, each cf those 55 points will have a new value sent to EMS every 15 seconds. During the 15 seconds aetwen updates, the licensee computer systems may have scanned each parameter as many as 30 times and may have updated !!censee display systems tu many as 15 times (more typically 2 to 5 times). With some \
degiae of prescr*.ptive implementation rules, updates will be made available i
tf 'NRC as frequently as every 15 seconds from over 80% of the licensee ,
sites surveyed. The licenseer are able to obtain their very rapid update s
'fraquincies ar 11cerbee-owted'remots urminals through the use of high /
$rior,ty data pumping rovdines and'the use of dedicated high speed data l; links s!.c5 as 19.2K bits /second optical fiber. 't x j So, the answer to the question on NRC's ability to detect spikes is a I
qualified No. The actual answer is of course dependent on how one defines a spike. Spikes in t'nerinal-hydraulle parameters, such as the I to 2 second j
- oritainment press (re spike which occurred at Three Mlle Island, would be !
transparent to the NRC unlesr; ,the data set update happened to coincide 1 with the spike. We are deallnU'here with probabilities, with the probability being roughly the durcion of tQ spike divided by the interval between
% data . set updates. Some licensee systems dess than 5%) produce screen updpes or vallf atien alarms base,d on rate pf change for t/.e parameters I
which haves changed by some predetormhed Jelta. This capsfhty is usually associateddith's s
downstream data izser, sucT l<s SPDS, rather than with Ve i
l i i '
I '
3-10'/ '
s N N g, ,, ,
? -
l
. ,. o \
_. x ,
\ *
!. J. 2 , ,
- b. '
< e g .
\1 ; $U ,
( Data Acquisition Systems (DAS) from which ERdS ylli receive its feed. Thus h urder a non-prescriptive implementation program, such rate-of-change i detection capability is not available to NRC at the licensee feeders. NRC will only receive a simple periodic update cf all the points representing parameters e i the ERDS Parameter List.
L ,
i 2) WILL ERDS BE DESIGNED TO GO BACK IN TIME (FROM TIME OF DATA l TRANSMISSION INITIATION) AND RECOVER ARCHIVED LICENSEE DATA FOR
( THE PERIOD .FROM INITIATION OF THE TRANSIENT TO INITIATION OF THE ERDS DATA FEED?
While this feature was not addressed in this project's. Statement of Work, the benefits of recovering archiv.ed data were discussed during the first several technical project meetings .with NRC representatives. We received clear direction from NRC project technical management that retrieval of arcMved data was not to be a feature of ERDE. While such a feature is te3hnically feasible, the requisite plant-sp,6fic and feeder-specific information necessary to make any meaningful design decisions was not l purposely collected during the surycy portion of the project. Therefore.
such a feature has not been conr!dored in the design requirements for ERDS: in particular, the need for the NRC/ licensee computer-to-computer interface to be commandhesronselinteractive, and so share the data link for transmission' of few and arcMved data, has not been .provided for.
Therefore, retrieval of archivedilicensee data is net being considered in the initial ERDS desigIt]' recommendations. 3
- 3) TILL THE NRC DE SEEiNG EXACTLY THE SAME DATA AS THAT BEING VIEWED AND US8D BY LICENSEE MANAGEMENT?
There is no simple answer to this question, but based upon ERDS being implemented with approximately the plant-specific data sets determined during the. site surveys, the answer can be bounded both generically and on a plant-specific basis. Recall that the computer point data selected
, represents the most concise, composed, downstream, wide-ratige, minimum set of points available on the least number and most convenient set of licensee computer systems (feeders). Therefore, whether NRC will be viewing exactly the same c'nta as the licensee is deict<dient on the following factors:
^
a)iThe licensee computer systems selected as feeders may be different than
~
the r,ystems driving displays at some locations within Alcensee facilities. If l
K3C is communicating with personnel at a facility served by a computer system different than the selected ERDS feeder then differences in viewed 3-11 i
._______..m.m_.m._ _ _ _ . _ _ _ __m_m_ _ _ _ _ _ _ _ _ _ _ . - . _ _ _ _ . - - - -
data will result.
b) During the course of an event, the NRC may be talking to a changing cast of licensee personnel, whleh would typleally start in the control room and then shift to the TSC and then possibly shift to the Emergency Operations Facility (EOP) or licensee corporate offices. Licensees, in general, do not usually have the same set of data available to each of their organizational levels: consequently, NRC may have access only to the exact set of data available to one level of licensee management. In over 80% of the plants surveyed, NRC will be looking at a set of points available to the TSC, largely because the TSCs have been the first recipient of terminals tied to newly installed data acquisition systems.
c) Because minimum sets of wide-range parameters have been selected as the potential points to be sent to ERDS, the licensee would have access to the same subset of points, but would additionally have access to 5 to 10 times as many total points. The total set of points available to the licensee contains numerous narrow-range and discrete instrument points which will not be sent to ERDS. Because of this, even if licensee staff is using the same database, they may choose to focus on narrow-range or discrete parameters unavailable to NRC to obtain a more accurate indication than that available in wide-range and composed points. Internal to licensee organizations, there is frequently a 2 to 3 % difference between data system points and the control room analog instrumentation (caused by time lags, data smoothing techniques, update rates, etc.).
Differences of as much as 15% have been observed on occasion.
The largest errors likely in the selected ERDS data set are for cold-calibrated, wide-range, uncompensated level detectors (reactor vessel, steam generators, and pressurizer). The only way in which close to 100%
agreement could have been obtained between data being viewed by the licensee and the NRC would have been to send ERDS virtually all licensee computer points (as many as 4000 computer points per reactor unit) and to have pre-established agreements between each licensee and the NRC as to which points they would monitor for each range of each parameter. This requirements analysis of ERDS assumed no agreements would be executed between licensees and NRC to "Look at the Same Computer Point Representing a Parameter"; thus some differences will exist.
d) In many instances, where NRC and the Licensee will be viewing exactly the same computer point to monitor a parameter, the actual meaning or true value of the parameter will be constantly changing. Example: for lleensee systems where radiological data, such as main stack gaseous effluent, is sent in unprocessed units such as Counts Per Minute (CPM), the true value of the parameter is determined by a hand calculation or nomogram, using a licensee procedure, and Is based on the most recent fission product mix (which is 3-12
. . . . l recalculated as often as weekly). Over an 18 month fuel cycle or several years of plant operation, the conversion factors may change by as much as 100%. In this example, the NRC and the licensee would be looking at the same number, but the number's meaning may be interpreted differently depending on the frequency at which licensees are required to submit changes in such factors to NRC.
In summary, initial ERDS design recommendations are based on the selected set of computer points and licensee feeders determined during the surveys.
Many factcts will contribute to relatively small differences in a licensee's perception of a parameter's value and the NRC's perception of the same parameter.
- 4) WILL THE ERDS DATA BE QUALITY-TAGGED, VALIDATED, INDICATE SUSPECT DATA. ETC?
ERDS should allow NRC users to see all data it receives, always accompanied i by a quality tag showing a plant-independent standardized data quality indication. The displayed quality tag is derived by a standardization function from plant-specific quality information received by ERDS with the data, .l 3.5 DATA AVAILABILITY AT SITES An earlier report produced in this project, entitled "ERDS Plant Survey Report", presented detailsd findings and results of survey data reduction.
The following results were extracted from that survey report concerning availability of points representing the ERDS Parameters: !
l (Note: The term " applicable parameters" as used below means those l parameters from the ERDS Parameter List which are applicable to a speelfic reactor unit. The best example of a case where a parameter is not applicable to a specific reactor unit is: RCIC Flow is not applicable at a BWR where there is no RCIC system installed.) I The average availability of points for applicable parameters at BWRs l surveyed is 78.7%. No BWRs had 100% of the applicable parameters available as transmittable computer points.
The average availability of points for applicable parameters at PWRs surveyed is 92.6%. Of note is the fact that eleven PWRs surveyed had 100% availability.
3-13
1 i
The parameters most often totally missing, with percent unavailability .j shown, for those with unavailability of at .least 10%, by plant NSSS type, are:
PWRs:
- Containment Susp Level 36%
Liquid Effluent Radiation 31%
High Pressure Safety Injection Flow 25%
Steam Generator Blowdown Radiation 20% '
Reactor Coolant Radiation (Letdown Rad) 19%
Reactor Vessel Level 13% .
BVST or RVST Level 13% 4 BWRs:
Drywell Floor Drain Sump Level 83%
Intermediate Range Nuclear Instruments 61%
Air Ejector Post Treatment Radiation 55% ;
Main Steam Line Radiation 50%
Liquid Effluent Radiation 43%
Drywell Oxygen Concentration 37% i Condensate Storage Tank Level 29%
Note: The reader should be aware that, because of the greater number of PWRs surveyed, 30% unavailability for PWRs represents about 25 reactor units while 30% unavailability for BWRs represents about 9 reactor units.
Sections 7.3 and 8.4 discuss the design requirements of manually inputting parameters at the NRC Headqua.-ters Operations Center which are not available for electronic transmission, d 3.6 SURVEY FINDINGS ON SELECTED TECHNICAL AND ADMINISTRATIVE ISSUES The percentages below provide the findings of the survey in selected areas of interest. The percentages reflect findings based on data from surveys ;
and surveyors representing about 80% of the reactor sites in the U.S. I
- 1) When is the appropriate time in an incident to initiate the ERDS data feed?
Approximately 80% of licensees believe that the data link should be established following declaration of an ALERT and within the same time 1 constraints as required for notification of off-site authorities (15 minutes 3-14 ;
after declaration). The remaining 20% indicated that they did not believe that ERDS should be activated until the TSC or EOF was declared manned and activated (approximately 1 hour1.157407e-5 days <br />2.777778e-4 hours <br />1.653439e-6 weeks <br />3.805e-7 months <br /> after declaration of an ALERT for the TSC). In summary, licensees should design their end of the ERDS link to provide the functional ability to initiate the ERDS data feed promptly upon recognition of an ALERT condition, and within existing event reporting requirements.
- 2) Where is the Feed Switch" to initiate ERDS most likely to be located at reactor sites?
Approximately 20% said control room, SO% the TSC and 30% the EOF. This does not necessarily mean that the desired location is the location of the ERDS feeder, but it is the desired point from which a licensee representative would initiate the process which would start the data feed j (by means of a switch, a telephone call, etc). ERDS implementation should ]
assume that the feed is functionally activated from plant control rooms, so l that the time for activation criteria can be met.
l 3) Who should be responsible for turning on the ERDS data feed (by l
direction of the action, not necessarily personally performing the task)?
l i About 9S% of licensee representatives were in agreement that the Shift l Supervisor or Emergency Director should control and direct the initiation of ERDS. The ERDS design requirements should be based on activation of ERDS transmission being under the direct control of the Control Room Shift Supervisor, who becomes the Site Emergency Director. Plant administrative procedures should be revised to dictate this responsibility.
- 4) Should the ERDS data link be interactive (beyond simple handshaking to establish communications)?
Over 90% of the licensee personnel contacted do not desire ERDS to be interactive. The reasons given were primarily associated with the unknown loading which NRC could place on their computer systems with multiple and frequent queries. Based on these responses, the design recommended here for ERDS is not interactive, except to the extent necessary to support data transmission.
l 3-IS l
- 5) What is the single biggest, ongoing problem likely to be associated with ERDS after it is implemented?
)
Almost 100% of the licensees stated that configuration management would be an ongoing effort requiring a formal program.
Although not a true ERDS design requirement, the post-implementation configuration management issue, when combined with other engineering i judgements, influenced at least one major ERDS design decision. That was j the decision to recommend against computer-based ' computation of new j standardized computer points in the NRC ERDS data host (see section 3.7 below). NRC should ensure that a configuration management plan is in place by the time that about 10% of the reactor units are implemented.
- 6) What are the approximate 'lleensee software, testing, and documentation costs of implementing ERDS at the most straightforward units?
For reactor units with new computer systems and a willing attitude, the i costs per reactor unit to the utility are estimated in the $20,000 - 850,000 ,
range. This estimate includes labor costs associated with software ]
development, design change notice documentation, testing, and procedure I development. This estimate is based on the licensee providing a custom-formatted ERDS data feed, consisting of the data points selected during the ERDS surveys. These most simple of ERDS connections would require no new hardware at the licensee end, except for a modem and cabling. They also represent cases where the programming talent necessary l
to write the feed-generating application software resides on the plant or i corporate utility staff.
The ERDS implementation cost estimates in chapter 9 of this report do not include the cost of licensee labor, nor any costs associated with system hardware or software changes on the licensee's side of a feeder's serial port '
output connector. They do include the cost of communication hardware (e.g., cables, modems, multiplexors) that will be needed to transmit data feed streams from multiple feeders' serial port connectors, assumed to be co-located in one room, to NRC Headquarters. The issue of multiple data 3 feed streams which are not co-located in one room is discussed in section 5.1.2.
- 7) How many licensee computer systems are at peak capacity now and could i not tolerate the addition of additional workload, such as generation' of a '
feed to ERDS?
3-16
l i
l Approximately 5 to 10% of licensee systems are running at close to 100%
processing capacity now in the post trip or incident environment. j Approximately 10 to 15% of the licensee systems are hardware limited (e.g., 1 no available output port for an ERDS connection).
- 8) What percentage of the data points selected as potential ERDS inputs undergo validation within the licensee systems? ,
i Based upon survey-collected data. 33% of the points selected undergo some type of sophisticated validation checking (e.g., divergence checks between companion points, standard deviation checks, rate of change limits, etc.).
58% of the points selected undergo only a simple range check (usually to determine if the analog input signal falls within the max / min output range of the instrument loop detector). The remaining 9% of the points have no validation or range-checking applied. It should be noted that even though l these percentages were computed across all plants surveyed, individual plants do not have these mixes (i.e., one plant might have all validated points and another have no validation or range-checking). Although approximately 91% of the points selected receive range-checking or validation within the licensee systems, not all of the resulting " Quality Tag" information is stored or transmittable to NRC. The percentages of selected computer points which are both quality tagged and capable of having their quality tags transmitted to NRC are 65% for BWRs and 70% for PWRs. In )
actual computer point numbers, this means that approximately 1200 of the !
4000 computer points selected, for all units surveyed, will not have a quality tag transmitted to NRC. l 3.7 STANDARDIZATION OF DATA POINTS During the ERDS survey, considerable thought was given to the need and desirability for standardization of data to be transmitted from the plants and utilized within the Operations Center. It was initially anticipated that at least some standardization would be possible and beneficial. The survey uncovered the fact that there is little standardization of parameter sensor location, data format, or engineering units even among plants of the same type and NSSS supplier, or between plants operated by the same ut!!!ty.
Trying to force such standardization at the licensee sites was quickly rejected as an unrealistic alternative. Standardization of data by the ERDS computer within the Operations Center was also considered potentially beneficial and was examined.
3-17
Our eventual conclusion was to recommend that ERDS should not attempt standardization at all, but instead should provide online structured " help" text that users can read to obtain information about plant-speelfle meanings of data points. The following sections discuss the pros and cons of standardizing and elaborate on this recommendation.
3.7.1 How Computer Points ReDresent Parameters For each reactor unit, there is typleally a single point or a small set of points which convey the numerical or relative value of the somewhat generic points on the ERDS Parameter List. The exact manner in which the unit-speelfic computer point sets have evolved is dependent on unit-speelfic factors such as reactor system design, building design, computer system selections, SPDS design, task analysis of user needs, instrument locations, instrument loop design, etc. The unique set of computer points at each unit is inextricably related to the licensee's system drawings, operating procedures, emergency procedures, training program, surveillance procedures, regulatory commitments, etc.
The computer points make sense to the licensees and convey information to them with a minimum need for auxillary descriptive information about each point. For example, when licensee personnel view a computer point such as "RHR FLOW LOOP 2B WR", they know that the flow !s sensed at a point in the B train of RHR on unit 2 and that the analog sensor is located outside containment on the piping just downstream of the 2B RHR heat exchanger.
They further understand that the measured flow represents total flow in the 2B RHR loop and that they need to know the system downstream valve lineup in order to know where, out of 4 possible paths, the flow is being directed. This level of detall will not be conveyed to the typical NRC user by a simple 1-line textual description, nor will the Incident Response Center personnel using ERDS parameters know the precise meaning of each computer point without amplifying information about the point.
3.7.2 Concept of Standardized Points Even though the set of points describing the ERDS parameters is unique and different for each reactor unit, they could be standard! zed in some cases. It is assumed that any standardization schemes would be !!mited to using the currently available set of points resident in licensee computers
]
(i.e., without any installation of new sensors or addition of inputs to the computers from existing sensors). Standardization of some computer points, '
such as PWR loop temperatures, would involve a process as simple as 3-18
Implementing a standard computer point identification and description scheme (because all loop temperatures are always expressed in degrees Fahrenheit, a range of at least 200 to 700 degrees is always available, and the number-of l' oops for each PWR is a known quantity).
The wide variety of point identifiers and descriptions could be made generic by, for example, always referring to the first, "A" or "1" loop, as "A/l". All
- first loop T-hots could then be standardized as shown below
POINT ID . DESCRIPTION RANGE ENG UNITS TH1/AU1 7 HOT LOOP 1/A VR 200 - 700 DEG T l Beyond standardizing point ID and ' description, the process grows more complicated. Standardizing all Main Feedwater Flows with respect to engineering units involves only converting the various plant-specific engineering units into a preferred engineering unit, probably " Millions of Pounds Mass Per Hour" or MLB/HR, to eliminate the use of GPM, KLBM/HR, KGAL/HR, etc. However, standardizing the point ID and description for Main Feedwater is not so straightforward because existing licensee databases may carry only one of the following point (s) describing feedwater flow: TOTAL FEEDWATER FLOW, FLOW TO EACH STEAM GENERATOR, or FLOW AT THE DISCHARGE OF EACH FEED PUMP. While it is desirable in the accident analysis environment to know the Feedwater Flow to each steam generator, the only possible, but unfortunately undesirable, standardization which i would fit every plant is TOTAL FEEDWATER FLOW. If, for the benefits of l standardization TOTAL FEEDWATER FLOW were deemed acceptable, then a standard point as shown below could be developed for nearly all plants: -
POINT ID DESCRIPTION RANGE ENG UNITS TVT07U1 TOTAL MAIN TEEDWATER TLOW 0 - 15 MLB/HR The next more complex case of standardization would include level points such as Condensate and Borated Water Storage Tank Levels. These level points would require standardization of engineering units .(as described 4 above for Main Feedwater Flow), but would in many cases require standardization of the zero reference (e.g., many of these points are expressed in terms of feet or inches above site grade or above an ECCS system standpipe). Some sites also have more than one tank per unit or l have two tanks shared by two units. The information of interest to the NRC is total volume of water or percent of design volume remaining available to the safety injection systems. Therefore a standard point such as that shown below could be developed:
\ \
l l 3-19 l
1.
____________a
POINT ID DESCRIPTION RANGE ENG UNITS MUV70TU1 TOTAL MAKEUP VATER 0 - 1E+6 GAL MUVTOTU1 TOTAL MAKEUP VATER 0 - 100 %
Beyond the fairly simple cases presented above, the problem gets more complex. All of the cases above involve the use of standard engineering conversion factors (e.g., MLB/HR = KLB/HR X 0.001) or plant design data (e.g.,1 FT = 52,342 GAL for CST contents). Some examples of the difficult or impossible cases are presented below:
TOTAL GASEOUS RADIOACTIVE EFFLUENT: The number of effluent points (monitored and unmonitored) varies widely among plants. To arrive at a standard engineering unit such as microcuries per second (ucl/see), one needs to know flowrates, detector placement, calibration factors, and assumed nuclide mix. The ventilation system and stack flowrates are often not available on licensee systems (they assume a worst case default). The calibration factors change over time and with accident severity.
REACTOR VESSEL LEVEL: Some BWR level instruments are cold calibrated.
Differential pressure type detectors are dependent on running coolant pump combinations. The zero references in use are very diverse. Heated Junction Thermocouple (HJTC) detectors provide several discrete points versus a continuous output. Some systems use percent-full convention while others use percent-empty convention.
CONTAINMENT SUMP LEVELS: The sump total capacities vary widely from a few hundred gallons to several thousand gallons. Some PWRs only have available the containment reelreulation sump levels and not the normal floor drain sumps. Some detectors are of the discrete float switch or HJTC type while others are continuous reading. Many plants only have fill and pumpout rates available (i.e., no level indication). Some PWR sump level detectors transition directly to containment level indications while others employ independent detectors with different reference points. '
The benefits to the NRC of standardization are many and include:
standardized displays of data, less need to access plant-specific drawings, less need to understand computer point relationship to positions within plant engineered systems, ease in developing peripheral user software, less need to perform manual normalization of data, and conciseness of a top level display for recipients such as the Executive Team. The benefits of full standardization, if it were prictical, to both the licensees and the NRC would be that both parties to an incident would be conversing in mutually understood terms, thus eliminating questions about the real meaning of the shared data.
3-20
However, the elimination of plant-specific points is not believed to be within the realm of possibility. Individual licensees have too many procedures, references, and trained personnel that are tied to the existing data point sets, and there are no sites with identical configurations. This rationale dictates that any standardization occur on the NRC side of the licensee /NRC ERDS data interface and exist to assist the NRC team in carrying out its duties in an incident situation.
It is possible to design software to standardize (or normalize) each plant's specific data to a specific set of engineering units and to display them on call-up or in conjunction with the plant-specific data and units. However, this complication is not considered justified, especially when the problems of maintaining configuration control of the software among all plants is considered. Upon close examination of ERDS survey results, it was noted that standardization would result in many selected points being converted based upon less than desirable common denominators (e.g., Total Main Feed Flow, Gaseous effluents expressed in concentrations, etc.). This would contribute to a very high cost of building and maintaining the standardization database and software. in addition, mistakes discovered in a software-implemented standardization scheme during an incident would be difficult or impossible to correct in a timely fashion, as compared to making corrections to a text-oriented reference.
Because of the problems of full standardization among plants discussed above and because of the desire that during an incident the Operations j Center and licensee Emergency Response personnel " speak the same j language" (essentially rendering a computer point standardization feature {
within the Operations Center redundant and unnecessary), it is recommended that the ERDS data be both stored and displayed only in the form and in the units which are used at the particular plant being monitored. This is j the most straightforward, most easily implemented, and least expensive l method. It is recognized that this decision places an additional burden on the Operations Center personnel, as they must now acellmate to the system i found at each individual plant. However, training should minimize the problem, and it is beyond comprehension that multiple serious incidents at more than one reactor unit will occur at the same time to confuse the response team. Conversely, the incident response teams' intensity of purpose would rapidly acquaint them with the relative meanings of plant-specific points. In addition, as discussed in sections to follow, it is recommended that the Operatione ; enter personnel be provided with a " Data Point Library" resident in ERDS which will assist them in rapidly interpreting the ERDS data and "getting in syne" with the licensee's team.
3-21
l 3.7.3 The Recommended Alternative to Standardization: The Data Point Library We recommend that the NRC Headquarters-ERDS computer 1nclude a
~
unit-specific, text-oriented, descriptive database which is organized by data points. This << Data Point Library >> should be capable of rapid access by.
all ERDS users. It is analogous to online help text in other computer systems, except that it provides information about data points rather than system commands. The recommended content, organization, and utilization of the Data Point Library is discussed in chapters 6 and 8.' Examples of suggested screen displays of the Data Point Library are shown in section 8.7.
3.8
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS These are selected highlights of the conclusions and recommendations presented in this chapter:
(3.2.2) Feeder selection during surveying was based on potential availability of a serial data communication port, data points denominated in engineering units, and value updates no less often than every IS minutes.
Within these criteria, feeder selection sought to minimize the number of feeders needed to provide parameter-representing data points for all of a licensee's plant units.
(3.2.3) Data point selection during surveying sought to identify the minimum set of most composed, most validated, widest-range data points which ' fully describe each of the ERDS parameters.
(3.4) ERDS will not, in its initial implementation, seek to obtain data-from feeders describing the period before initiation of data transmission.
(3.6) Each licensee should implement the ability to initiate ERDS data transmission promptly upon recognition of an ALERT condition, and within existing event reporting requirements.
(3.6) The plant Shift Supervisors / Emergency Directors should be responsible for directing the initiation of the ERDS data feed.
(3.6) A configuration management plan should be in effect at the time that about 10% of the plant units have functional ERDS data feeds.
3-22
- (3.7) ERDS should not attempt data point standardization at all, but instead should provide online structured " help" text, specific to each data point of each plant unit, that users can read to obtain information about plant-specific meanings of data points.
- -(3.7.2) ERDS should receive, store, and be able to display data point j values without transformations which change the plant-specific meaning of )
licensee-defined data points. The initial implementation of ERDS should display values only in the engineering units which are used at the particular plant being monitored, without any ERDS-computed conversions.
l l
)
1
(
l l
l l
)
l l
i i
3-23' i
. c . .
l l
4.0 DESIGN CONCEPTS FOR DATA IN ERDS l 1
1 This chapter presents and discusses conceptual abstractions that will characterize various kinds of data objects of interest in ERDS. Chapter 3 began to characterize details of ERDS by discussing many observations, issues, and conclusions regarding availability of data from licensees and potential uses of data by NRC, primarily from the perspective of nuclear j engineers and health physicists doing accident analysis. This chap %r begins a process of distilling those user-perspective conclusions in:o computer-perspective design abstractions that can serve as the conceptual ]
underpinning of the implementation of ERDS as a computer system. '
It should be apparent by this point in the flow of this report that we {
i regard the characterization of parameter-related data as the primary source of conclusions about requirements for and design of ERDS. Accordingly, our development of computer perspective design abstractions begins with concepts of parameter-related data, in this chapter. Avolded in this chapter I are issues regarding how data moves from a plant site to the NRC Headquarters Operations Center; those are the unifying focus of chapter 5.
]'
The pattern of user-perspective conclusions leading to computer-perspective design abstractions is repeated in chapters 6-8 for ERDS functions that reside at NRC Headquarters. The focus in the current chapter is on data I objects that are part of the licensee /NRC data interface; other data objects, such as those relevant only in NRC users' interfaces to ERDS, are not j' discussed until chapter 8.
1 An important attribute of the computer-perspective material in this and <
l subsequent chapters is its parameter-independent generality. The l
! discussions in chapter 3 included many mentions of specific ERDS parameters and specific aspects of nuclear plant engineering. There will be very little of that in this chapter. Forever into the future life of ERDS, there will be l nuclear-oriented people and computer-oriented people playing various roles relative to ERDS: few will be conversant with both areas of technical expertise at a level comparable to a specialist in one or the other. As ERDS evolves through implementation, usage, and enhancement (as all systems do),
it will be desirable for less breadth of technical expertise to be required in playing an active role, so that staffing of these roles does not require rare combinations of knowledge and experience. With these thoughts in mind, we have in this project given high priority to the distillation of computer-perspective design abstractions from nuclear-perspective requirements conclusions.
4-1 l
l
Besides generalization from the discussions in chapter 3. there is another j set of influences that shaped the material in this chapter: computer-related findings from plant surveying activities. The computer-related surveying in this project began with the goal of collecting information describing licensee j feeder computer system environments and telecommunication facilities, based j on a broad and hazy sense of what ERDS was to be and do, as it was '
understood at the beginning of this project. Specific kinds of descriptive information were sought under the rationale that they might be relevant to ERDS requirements analysis and design activities. As the conceptualization of ERDS facilities and functions (what ERDS should be and do) evolved during this project, some of the collected information lost its potential relevance. The findings which remained relevant are scattered throughout this chapter and chapter 5, serving as rationale for stated design conclusions and as the basis for selection of various numbers in ERDS requirements, i Getting a " handle" on the extent and aspects of diversity in licensee feeder system environments was an important unifying theme in the descriptive information sought in the survey. NRC emphatically articulated at the beginning of this project the basic principles that a) ERDS should be designed under the assumption that implementation will be within a voluntary, non-regulatory framework, b) NRC will want ERDS to be able to connect to as many willing licensees as possible.
c) ERDS should, within limits of reasonableness, be able to accept whatever l
diversity in data formatting and transmission attributes that licensees are willing to provide.
An extremist interpretation of these principles is that ERDS implementation should be able and willing to custom-engineer any aspects of its licensee /NRC data interface to conform to the needs or preferences of a willing licensee.
However. ERDS design decisions need to consider these multiplication factors on the potential costs of customization:
- 1) 76 plant sites are the locations of 120 plant units now operational or in active construction.
- 2) To represent the ERDS Parameter List (27 parameters for BWRs, 35 for PWRs), up to 70 data points will be obtained from each plant unit.
4-2
i
- 3) Computer-related surveying of 97 units (80% of 120 units) led to selection of 93 feeder computer systems at 52 different feeder sites. Extrapolating linearly from the 80% findings,120 units can be expected to require connections to 115 feeders at 64 feeder sites.
The strategic approach we adopted for ERDS design decisions, to reconcile the non-regulatory implementation principles with the assured complexity and cost of unconstrained customization, can be called " limited generality".
The basic metaphor is well-defined menus of choices for licensees. For any significant technical aspect of the 11censee/ERDS data interface on which i there is significant diversity among licensees, ERDS should offer licensees a precisely defined, limited set of choices, designed to be acceptable to roughly 90-95% of all licensees (or feeders or feeder sites or data points, as l appropriate), on a take-it-or-leave-it basis. In this chapter and chapter 5, the findings from the survey are used to sketch recommended menu choices for a variety of technical issues. However, a basic premise of this approach is that the final detalling of the menu choices occurs as part of the detailed design activities that occur early in the implementation phase of ERDS, so that the requisite precision of definition can be offered to all licensees.
The goal of NRC should be to provide ranges of menu choices which will facilitate implementation of ERDS.
4.1 PARAMETERS DATA POINTS. DATA POINT IDENTIFIERS AND VALUES The fundamental distinction between parameters and data points (computer points) was introduced in chapter 2 and discussed at length in several l sections of chapter 3. A few more observations about them deserve explication:
l a) A << data Dolnt >> ls a formally identified (cataloged) variable in a licensee data system. A << data Dolnt value >> ls a single reading of that variable, representing the value of the underlying measurement at some moment in time.
b) Based on the voluntary approach to ERDS implementation, standardization of data points (toward independence from plant-speelfic engineering details), to the extent it occurs in ERDS, will occur at the Operations !
Center. Consequently, all arrangements between NRC and a licensee regarding description of the data to be transmitted to ERDS will be in terms of specific data points in that licensee's data system (s).
c) The concept of parameter does not exist in the parts of the ERDS system that licensees interface with. It is a conceptual tool to assist NRC users 4-3 l
I
in grouping related data points (related by virtue of representing the same parameter).
I d) Independent of the extent to which there is standardization of data points, NRC users will need an explicit mapping from parameters on the ERDS Parameter 1.ist into the set of data points for a plant unit. So the ERDS system will need an explicit representation (formalized identification) of parameters as well as data points, e) The relationship in which a data point represents a parameter will also be referred to as a daughter / parent relationship. A << parent parameter >>
is represented by a << daughter data point >>.
f) In nearly all cases, a data point is the daughter of only one parent. j However, a few special cases of plant instrumentation engineering give j rise to situations in which one data point represents two parameters (e.g.,
RCS Charging Flow and High Head Safety injection Flow). The design of displays for users and software data structures which show the parent / daughter relationship must allow for these special cases.
The concept of an update set was introduced at the beginning of chapter 3; it is a group of data point values transmitted from a feeder to ERDS in a batch. The concept of a update set is discussed further below in section 4.3, in connection with Time Stamping. The concept is mentioned here to provide the setting for the issue of how data point values are identified in their transmission to ERDS.
There are two basic alternatives for how ERDS could identify each data point value in an update set. In computer systems terminology, the terms are " positional" and " keyword". In a << keyword >> scheme, each value is accompanied by an explicit tag which provides its identity-(names it). In a
<< positional >> scheme, there is an implicit agreement between sender and receiver that defines the identitles of the elements based on their position (first, second ...) in the sequence. For example:
(Positional) (Keyword)
NRC Operations Center NAXZ= NRC Operations Center Washington, DC 20555 ADDRESS = Washington, DC 20555 1 212/951-0550 PHONE = 212/951-0550 t In this example, the content of the data fields provides additional !
1 identification to an English-reading human which would survive scrambling.
If all the data fields were numbers formatted identically, this content-clued identification would not be present. 1 4-4
_-____~_ -
, 4 g, ,q We strongly recommend an explicit, keyword-oriented scheme for identification of data point values in an update set. Confinement of the l effects of data transmission errors is not the issue, because explicit l separators between values will be need_ed with either type of scheme.
Rather, keyword-oriented identification provides a greater degree of explicit i structure which can be used by ERDS software to detect unreported changes in the set of data points being transmitted to ERDS (the configuration management issue). Keyword-oriented identification also offers the flexibility that each update set need not contain all the data points from that feeder.
It is possible that in some feeders the implementation of a keyword-oriented transmission protocol will require additional software development work by licensees. Another potential objection by licensees is that each update set, being longer, will require more computational load for its formatting.
However, we have concluded that if either of these relatively negligible added burdens become issues of contention in the connection of a feeder to ERDS, it should be considered as predictive of an absence of the resiliency (in either programmer capacity or computational capacity) which should be available to allow successful completion of the work involved in implementation. Therefore, although a positional scheme will work fine in ,
the absence of human and machine errors, we recommend that ERDS not include it in the menu choices for custom-generated feeds, i Licensees generally .aaintain a formal compendium of the data points in their !
data systems. It is often called a << data point catalog >> or a << data
. l p_oint dictionarv >>. In such catalogs, each data point typically has a relatively short (8-10 characters), non-mnemonic << data point identifier l OD) >>, which is its formal identification for plant administrative purposes.
These data point identifiers should be the official names for data points in ERDS, to facilitate identification without ambiguity in written communication ,
with licensees concerning the implementation of the ERDS interface. These l Identifiers are not a practical choice for the names to be used in voice conversations during an incident, because they are not mnemonic nor l pronounceable (e.g.,1R039F). These data point identifiers are the logical !
choice for the keyword identifiers in an update set.
In some multi-unit utilities where the reactor systems have the same engineering, the utility has assigned one character position in the data ;
point identifler to convey the identity of the unit. In other such utilities, I though, the same data point identifiers are used for each of the plant units.
This focuses on the issue How will NRC know what site and unit is sending to ERDS*t Our conclusion is that, in all cases, ERDS should receive an 4-5
explicit identification of the plant site and plant unit at least once, as part of the initialization of an ERDS connection during an incident. Without licensee human hands involved in the process of initiating the connection.
NRC cannot assume that an initiation of transmission is from the site / unit that is calling on the ENS phone. (This requirement for explicit identification means that no licensee can use existing report- or screen-generation software to generate the ERDS feed without any custom-created software for ERDS.) We generalize this identification into an u initialization packet >> which can be structured to contain a variety of useful information needed only once during an incident's transmissions.
l l
The last topic for this section is some generalizations about data point l values. The survey found that, although a large majority of data points received by ERDS will be numeric, there will be some whose datatype is boolean (i.e., true/ false). Among numeric data points, the survey found no useful purpose for distinguishing between integer and real (floating-point) values: all are reals. Based on these findings, we recommend that the ERDS design not emphasize the concept of datatype.
The definitions of data points should include a distinction between boolean and numeric, and for booleans should include a clear indication of the meaning associated with "true" and " false", so that nuances such as the distinction between "open"/"not open" versus " closed"/"not closed" are emphasir,ed. (A useful technique'is to define each boolean data point in terms of a true/ false question, such as "Is the valve open?" or "Is the j valve closed?") However, for the handling of boolean values in data transmission, storage, and display, we recommend the simpilfication of representing "true" as a numeric 1 and " false" as a numeric 0, so that all data point values in ERDS are numeric.
Regarding precision of numeric data points, we recommend that ERDS not attempt to include a designated precision in the definition of each data point; instead, ERDS should uniformly treat all numeric values as deserving of 4 significant digits in transmission, storage, and display. Values received with fewer significant digits should be right-extended with zeroes for storage and display. Issues associated with the formatting of values are discussed later, in section S.1.1.
4-6 l
4.2 QUALITY TAGGING OF DATA POINT VALUES Analysis of survey-collected information indicates that there is virtually no ,
existing commonality or standardization in licensee conventions for displaying the results of quality tests on data point values, nor even in the categories of judgements or meanings being represented. Licensee I validation schemes varied from no validation being performed to as many as 19 levels of quality tagging being applied.
Similar diversity was seen in the data structures of the quality tags available to ERDS. In many feeders a quality tag is one selection from a small set of symbols (i.e., an enumerated datatype), but in some feeders it is a bit vector in which more than one bit can be on. Also, some feeders substitute a quality code for the data point value itself when the value is suspect (e.g., "99999" or "NO DATA"), instead of using a separate symbol.
We use the term " quality tag" to refer to all of these possible representations of judgments made by the licensee data system software about the trustworthiness of a data point value.
Some licensee data validation programs only validate the data as it is transferred from a database to displays. This quality tagging would not be available to ERDS, under the expectation that custom-created software to generate a custom-formatted feed is the NRC-preferred approach to implementation.
For all plant units for whleh the survey obtained information about quality tags, the conventions for representation and display of quality tag information were found to be uniform within a single feeder for all data points that were validated. The conventions thus are feeder-specific, not data-point-specific.
Because even suspect data can have value during an accident sequence and I thus be useful to NRC users, it was concluded in section 3.4 that ERDS should seek quality tags along with data point values from feeders, to the extent they are available and the licensee is willing to include them in the feed stream. However, there is potential confusion in permitting users to see the quality tag information exactly as it was received from the licensee feeders. (Multiple feeders for a plant unit may use different quality tags.)
Therefore ERDS users should always see a standardized rendition of the quality tag on each data point value. ERDS should include an algorithmic function defined for each licensee-speelfic or feeder-specifle domain of possible quality tag values, which maps it into a standardized (feeder-Independent) function-range set of ERDS quality tag values.
4-7 l
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ J
A recommended standardized quality tag set (with suggested symbols for displaying them) is the following:
- 1) Point is suspect: ? (question mark)
- 2) Point is good: G
- 3) . Point has no assigned or transmittable quality tag: N
- 4) Point was manually inserted by licensee (control room) operator, or point was received at NRC by voice: M With standardization such as this, the logical time to perform the standardization is immediately upon NRC receipt of each update set, before the received data is stored in the ERDS data storage facility. In this scheme there is no use of quality tag information to discard suspicious data point values. In cases where a special data value like "99999" conveys quality information, the appropriate standardized quality tag should be generated, and then the received data value should be transformed (before permanent storage) into an NRC-standardized " dummy" numeric value such as "-99999" (numeric because of the recommendation in section 4.1 that all ERDS data values be handled as numerics). It is important that one of the standardized tags mean "no quality information was received", so that every data point value stored in ERDS can have a standardized quality tag. There is no need to store the 11censee-provided quality tags after the standardization conversion, other than archiving for post-incident analysis.
ERDS should altsys display the standardized quality tag adjacent to each data point value shown on tabular alphanumeric displays and printouts. In trending plots and other graphical displays, showing quality tags is a substantial complication and not always feasible, so the software which generates such displays should impose filtering of suspect data values (so that they are not seen by users) as part of its default-mode behavior.
Users should be able to override this filtering by request, for situations when conversation with licensee staff has provided an explanation of a suspect quality tag which restores the credibility of the subject data point value; if a graphical display shows (uses) any suspect values because of this user override of filtering, the display should include the legend, "This display contains Suspect data".
Independent of how standardization of quality tag information is handled by ERDS facilities at NRC Headquarters, the desirability of NRC receiving quality {
tags in the ERDS feed stream means that the protocols for data transmission will have to include space for this information. Analysis of quality tag representation and display details collected in the survey found that no internal quality tag representation was more than 32 bits, and no displayed 4-8
l I
quality tag symbol was more than 4 characters. J Most of the more complex licensee data validation schemes are in a constant
]
state of development and change. Many plants surveyed (over 40%) 1 indicated that their data validation schemes will be changing for the next 2 or 3 years. It can be stated with certainty that validation schemes are
)
likely to change more than computer point descriptions over the next 3 l
years. Since ERDS implementation may start as early as late 1987 NRC i should be aware of the increased burden in the configuration management I area that is being created by receiving and standardizing quality tags. l l
l 4.3 UPDATE FREQUENCIES: TIME STAMPING OF DATA POINT VALUES l In this section several distinct but related issues are discussed, all related l l to the time associated with a data point value:
1 What update frequencies were found to be available? '
Should individual data point values have their own timestamps?
Is timestamp information available for individual data point values with greater precision (finer granularity) than their update frequency? ,
l Should each update set from a feeder have a timestamp?
How should the possibility of clock time discrepancies between computer systems (between different feeders at a site, between a feeder and NRC
{
~
ERDS) be handled? Does ERDS need an absolute time standard?
The concept of an update set -- periodic batched transmission of data point ,
values -- was introduced in chapter 3 and mentioned again in section 4.1. l Batched transmission of values can be contrasted to U difference l reporting >>, a scheme under which a feeder transmits to ERDS only the data point values it receives which differ from the preceding value of that data point by a pre-determined delta. We considered the possible desirability of difference reporting early in the project, but the survey .
found that only about 20% of the feeders now have the software capability to provide it.
More importantly, there now does not appear to be any need to economize on bandwidth of the ERDS data channel from the feeder site to the Operations ;
j Center. Our initial estimate was a maximum of 65 data points from a plant unit, with a rough maximum of 20 characters per data point for value, 4-9
identifier, and quality tag. This requires roughly 11 seconds to transmit at 1200 bits /second asynchronous.
The findings from the survey enlarge those estimates s!!ghtly, as follows:
maximum of 70 data points from a plant unit.
maximum 12 characters for an E-notation-formatted value having 4 significant digits.
maximum 12 characters for data point identifier.
maximum 4 characters for quality tag.
worst case total of 31 (12+12+4+3) characters per data point, including 3 characters as separators between adjacent items.
worst case total of 2170 (70 x 31) characters for the data point values of an update set. This requires roughly 18 seconds to transmit at 1200 s bits /second asynchronous (without allowance for time needed to retransmit blocks due to data transmission errors).
Despite the enlargement, the conclusion remains that bandwidth of the ERDS feed channel will be ample enough to dismiss consideration of a difference-reporting scheme.
Within the framework of data point values being transmitted in periodic update sets (all the data points of a feeder being in some update set), a feeder's y available update frecuency >> ls the frequency at which a feeder can transmit new update sets to ERDS. This will never be more frequent than the feeder's << internal update frecuency >>, the frequency at which its internal storage of data point values is updated from systems ,
upstream of it. In most feeders these will be the same. However, in a few
]
cases the feeders are already loaded with computational work, and licensee {
respondents in the site surveys expressed unwillingness to provide an ERDS l update frequency as often as the feeder's internal update frequency.
Survey findings of available update frequencies ranged from 0.1 second to i 60 minutes. Feeders providing reactor data typically had available update frequencies under 5 seconds. For radiological parameters, the update frequencies were typically 1-60 seconds. For meteorological data, typical were 5-15 minutes.
Until late in the project, we had been making the assumption that NRC was l
interested in an update frequency no more often than once a minute. !
Discussions with NRC staff then led to reconsideration of this assumption; see the discussion of detection of spikes in section 3.4. Because of the relatively modest data volume of an update set even with the worst case (largest) number of data points, data communication technology does not I i
4-10 l l
provide any significant limit on update frequency. (A transmission speed of 9600 bits per second asynchronous can send a 2170-character update set in j under 3 seconds; transmission speeds of 56K bits per second can be )
supported by mature technology.) Nor does data storage technology for the Headquarters data storage facility. So it is important, from a computer ;
systems design viewpoint, to find some upper limit on desirable update l frequency in the nature of the NRC's needs for and ability to use data. I The limit being used in this report, based on the most recent discussions with NRC staff, is (that ERDS will receive updates at intervals no shorter than) 15 seconds. Based on this, we recommend that ERDS always represent time to the nearest second.
Should ERDS seek from feeders a timestamp on each data point value? Our conclusion is No. The primary reason is that few feeders have such
]
timestamps available. In principle, NRC users could make use of the time of J an instrument reading with as much precision as is available, in order to see the distance in time between two data point values in the same update set. However, feeder systems generally do not receive the time of an instrument reading from upstream hardware. Generally, the most that can be inferred from a feeder's update set is that each data point value in it was sensed at some moment within the interval implied by its internal update frequency, not necessarily at the same moment for each data point in the feeder.
It is important that all the values in an update set come from the same internal update cycle in the feeder. Recognizing that data transmission of an update set to a serial interface may take time equivalent to several internal update cycles of the feeder, licensees should be told explicitly that ERDS does not want the feeder software to read each data point value at the moment before its transmission in the update set.
Is a feeder-provided timestamp needed on each update set, or is it sufficient for ERDS to provide the timestamp when it receives the (beginning l of the) update set? Our conclusion is that feeders should always provide {
the timestamp. The survey found that software in all feeders could access a l time-of-day clock. There is a potential cause of irregular delays between feeder emission and receiving at the Operations Center: handshaking in an error-correcting modem. Another reason for wanting feeder-provided timestamps is the possibility of later enhancement of ERDS to receive pre-initiation data intermixed with current data. Another reason is the potential need to identify specific data point values, in conversations with licensee staff, using " coordinates" of data point identifier and (the licensee's) time of the value. !
4-11
How should ERDS handle the possibility of clock time variations among feeder systems and its own data host at NRC Headquarters? The simplest l way is for each feeder to include its current date and time in its initialization packet, when it sends ERDS the identity of its utility, site, plant unit, feeder, etc. (once per incident or upon reboot of the feeder). !
Then the ERDS receiving computer could compute and store each feeder clock's delta from its own time clock. However, these computed deltas would l be subject to inaccuracy caused by delays (irregular or regular) in data l transmission. Also, this simple approach is not suffielent to handle some complications which may occur: (a) What if the timestamps in a feeder's internal data storage are from the clock of some upstream computer, not the feeder? (b) What if a feeder site is in a different time zone from the plant site? (c) What if the " fall-back" ending of daylight savings time occurs during an incident, causing 2 different hours' values to receive overlapping timestamps?
In situations where an upstream computer's clock is providing the timestamps in a feeder's internal storage, conversation between NRC and lleensee staffs will not be able to identify data point values by the utility's time coordinates, because the timestamp being received by NRC is that of the feeder, not the upstream computer. This situation is expected to be too i rare to be worth complicating the ERDS design, but it should be inquired about during ERDS implementation e.t a licensee, so that NRC will know whether or not the time coordinates ERDS is receiving are exactly those that l
licensee staff are seeing.
It is desirable that ERDS users be able to regard all ERDS-received values l as having been timestamped by one consistent clock representing " plant site i time", so that usage of an ERDS-stored value need not look up the identity of the data point's feeder in order to interpret the value's timestamp. This goal is deemed to have greater priority than fidelity to timestamps being seen by licensee staff. This conclusion leads to these recommendations:
For each plant unit, one of its feeders should be designated the
" site-time-determining" feeder. ERDS would have this designation pre-stored.
l Por each plant unit ERDS would have pre-stored, for each feeder serving l the unit, a " fixed time correction factor", which is an unvarying signed time difference to be used to convert the timestamps of that feeder to plant site time. This would accomodate time zone differences between the feeder's timestamps and plant site time. ERDS would use this difference to adjust the timestamp in each update set from that feeder, to convert it to plant site time before applying it to each data point value in the 4-12
. n .
o
update set. Note that the signed time difference is a property of a unit-feeder pairing; the same feeder may have different differences for two units it serves, if they are at different plant sites.
This concept of the site-time-determining feeder reflects the survey finding that; for most plant units, one feeder supplies a large majority of a plant unit's data points. It also reflects a conclusion that a few minutes' difference (apart from time zone. differences) between NRC's own clock and plant site time will not be a problem for ERDS users if all user interaction )
involving time is based on plant site time (as defined by the I time-zone-corrected timestamps of the site-time-determining feeder).
However, this concept does not provide a solution for the possibility of inconsistencies (apart from time zone differences) among the clocks of multiple feeders serving a plant unit. With an assumption that irregular delays in data transmission are possible, we can find no simple automated approach to detecting and correcting for differences from plant site time in the clocks of other autonomous feeders (compared to the clock of the site-time-determining feeder). Our recommendation is for a 'nple non-automated approach (needed only for multi-feeder plant units):
- For each feeder (other than the site-time-determining feeder) that is transmitting to ERDS on behalf of a plant unit, ERDS should be able to accept (from an authorized user) a " manual time correction factor", which is a signed time difference to be used (in addition to the fixed time correction factor) to convert the timestamps of that feeder to plant site time.
A timestamp in each feeder's initialization packet is compared with its time of receipt in the ERDS receiving computer to generate an " estimated feeder-time versus ERDS-time delta".
Each feeder's fixed time correction factor and estimated feeder-time versus ERDS-time delta are used to derive, for each feeder, an " estimated feeder-time versus site-time delta". This delta is, by definition, zero for ;
the site-time-determining feeder.
Each feeder's estimated feeder-time versus site-time delta is displayed upon request to ERDS users. One of the operational management responsibilities on NRC staff will be to request display of these values, evaluate the seriousness of their magnitude in the context of the incident at hand, and decide whether and when to request that the licensee provide orally a manual time correction factor for each feeder.
l l
l 4-13 l
l l
'y
't Each input of a change to the manual time correction factor of a feeder (initially zero for all feeders), besides affecting future processing of update sets, will be able to specify (optionally)'that the chang (i bhould be i applied retroactively to all timestamps on that feeder's data peints' values which are already stored in ERDS, or to all such 7f nests.mps, which ?
3 are greater than some prompted-for time. This ability will have great potential for creating messes, so its use should be tightly controlled. To '
minimize the extent to which user-generated data displays are invalidated by this changing of already stored timestamps, NRC operational staff should try to obtain manual time correction factors as early as possible in an incident's evolution. >
l This concept of manual time correction factors provides a solution for the T l (obviously low probability) problem of daylight savings time fall-back i
occurring during an incident. If a licensee insists on changing its feeders'
- clocks during an incident NRC can manipulate the manual time correction
! factors to cancel the effect of the change, to prevent the t'wstamps stored l in ERDS from re-traversing the same hour of plant site time (at the cost of l creating an idiosyncratic ERDS-only concept of plant site gme). This usage for the mechanism of manual time correction facto.T e.2ggest:, thm they should be available for all feeders serving all units, not just the non-site-time-determining feeders serving multi-feeder units.
4.4 DATA POINT DESCRIPTORS AND OTHER PLANT-DESCRIPTIV_EM 3 sl We use the term u plant-descriptive data >> for data.tnat must b l available in ERDS, having the following characteristics:
It describes some aspect of a licensee's systems (reactor, meteorological, radiological, computer, or other) and logically originates with the 11:ensee.
It doesn't change during an incident, except in very unusual circumstances (e.g., neglecting to change it before the incident).
, s 5 j It may need to be changed to reflect underlying changes in licensee systems' engineering. '
The seed of this concept is the need for ERDS to have available, for display to users, the engineering units and a short textual name or description for each data point that tells the quantity being measured in human-readable terms. In licensee data systems, these descriptions are typteally about 40 characters in length. This is 200% of our early rough estimate that 20 i characters would be sufficient for all the other information needed with a [,'
4-14
}
l
-- I
i J
data point value (value, identifier, quality tag). This was e:nsidered too large an increase in transmission oyerhead to allow it to be sent along with each data point value update. The survey findings did not change these h\ '
estip:teb enough to , undermine this canclusion.
, / .
y (
So ERDi nesds a way to acquire 'and'sdre r,uch information before an .
!ncident begins. Once the concept was planted, it became apparent that it '
could grow to support various o'ther k! ads of useful information:
, / s '
,- other descriptive information i,ssokated'with a data point's definition,
\ such as range linilts.
information descrBing the formatting or data point values and quality teg values, needed by the ERDS software that receives and processes trardsthud values into ERDS-Internal form. .,
qhier descriptive information associated with plant nuclear systems, nieded by software applications that will try to use plant-specific data s point valuen in standardized contexts.
6 The hst of these categories should be considered open-ended: as new applications using ther EADS-acqt: Ired data point values emerge, they may need to request additionsi to the plant-descriptive database. This category is obviously closely relt,ted to the istne ce standardization of data points, disemsed in sect 1on 3.7.
The acquisition and managemerit'of thMe' plan.t-descriptive datP.basert is potentf ally a very large headache for NHC. The term u configuration
- nanagement >> r,s used in section 3.6 (" sir.fje biggest ongoing problent is likely to be") refers to management of opdates to this data, and indhates awareness by the lleensees of the potntial russ! ness of it.
t As we began the project, we naively envisioned trat each licensee could be h
responsible for maintaining a machine-readabh col)y of this data in a uniform structure on one of their feeders, so that,it would W transmittable to NRC over the ERDS data link. Under the volunW/ 4?rcuch to ERDS, the more realistic expectation is, "We'll send you a Jsper listhg of our data point dictionary and you can use whatever you wsnt from it." Substitute ,
" magnetic tape" for " paper listing" in that sentence anc' you have the cooperative end of the spectrum. It was also found ths.t some licensees do not now keep their de,ta point dictionary on-line on their feeder system. So at this time it appears that NRC should expect to llave to devote some degree of on-going effort toward keeping its plant-descylptive databases ,
current. Consequently, chapter 6 below is devoted to a discussion of issues 4-15 '
\
, :r , . ,, ,. , + . .
qu t' ,I1, (
,; 3 L
N{
\
s 1 surrouM)ng; this part of ERDS. Tse remainder of this section! ntroduces i some say definitions and some of the requirements. l 4 '
A << data po)2t descriptor')) is a ret of fields of plant-descriptive information that can be collected to de.tcribe each data point (the same~ set of.fleids for each data point). Licensees' typically maintain 4 formal compendium of such hiformation for' all data points in thelf systems, usually called a:4 g,gst. point dictionan. >>. We have concluded that only the followinit fields from licensee dita point dictionaries s're useful for the initial
.' implementation of ERDS. The two lengths shown are the maximum and most connu,n (mode) lengths seen for thete fields in the survey findings:
Identifier - mex ,12 (mode 8) characters, non-mnenonic.
Description - sax 42 (mode 32) characters, human +rindable Engineering units - max 11 (mode 6) Eharacters, the denomination of the value '
Value range - max 16 (modn 10) characters, typleally two values with 'a separator. )
1..,
It is important to realin ?that the value range does not have consistent meaning across all licenshs. Usually, the value range tells the normal limits of the instrumentation, rather than~ giving any information about setpoints or normal operating ranges. Despite the non-uniforrnity of its. definition, we recommend that one value range be obtained for each data point, for display on request to users. In tne absence of a codificatlhn of its possible meanings, which we reurd as too complex an undertaking for the-initial implemeritation of ERDS, we recommend that the vrdue ringe not be used
, computationally by ERDS, but rather only as supplementary explanatory
! Information for users, s The ERDS data point descriptor will need additional fields to hold information to be used by the ERDS software that receives and processes (parses) data point values into ERDS-Internal foita. Examples: the value's datappe (boolean versus numeric), the feeder that supplies it, the parent-panmeter(s), the expected frequency of updates from the feeder. The final conaguration of this data will be an outcome of the deta!!ed implementation design of ERDS. This information is typleally not Available in licensee data-point dictionaries; their focus is on the upstream instrumentation rather
~
- than the soft.sare in the feeders. L
< ; , l .
( The concept of plant-descriptive databases. maintained ,by NRd brin'gs a non-tridal possibility of << 1 Ddate asynchrony >>, changes! being installed ln the described plant systeas before (or afterl the' descriptive information being held by NRC to changedi ' We can think of no way in general for 4-16 '
t ' 4 W y, 'Q -
'{'
programmed tests to detect small changes in plant systems which cause only a change of value (versus an existence change) and do not cause an attention-attracting problem in some software that uses the data point.
Nonetheless, we recommend that the implementation of ERDS software include programmed tests designed to check for symptoms of update asynchrony.
Examples: wrong number of data points in an update set: data point value is outside the range in the data point descriptor.
4.5
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS These are selected highlights of the conclusions and recommendations presented in this chapter:
- (4.0) ERDS should accomodate diversity among licensees in the licensee /ERDS data interface by offering limited well-defined menus of choices for licensees, designed to be acceptable to roughly 90-95% of instances.
1 (4.1) Each data point value in an update set should be keyword-Identified, using licensee data point identifiers as keywords.
- (4.1) Initiation of transmission from a feeder should include the transmission of an initialization packet, which contains identification of the plant unit and other non-varying information.
(4.1) ERDS should be designed to handle two datatypes for data point values, numeric and boolean. All numerie values should be handled as reals. All boolean values should be represented as reals in transmission, storage, and display, using the convention that I represents "true" and 0 represents " false", with the meaning of "true" and " false" stored in the non-varying data structures used to define the meaning of data points.
(4.1) ERDS should uniformly treat all numeric values as deserving of 4 significant digits in transmission, storage, and display. Values received with fewer significant digits should be right-extended with zeroes for storage and display.
(4.2) ERDS should receive information indicating.the validation quality of each data point value, in feeder-speelfle representation, whenever it is available. ERDS should use a feeder-specific standardization function to convert each received quality indicator (or its absence) into one of a small set of NRC-standardized quality tags, which would be stored for retrieval with the value. The quality indicators received by ERDS then do not need 4-17 s
to be available for retrieval. j (4.2) ERDS should always display a value's quality tag adjacent to the 1 value itself in non-graphical displays. In graphical displays ERDS should j impose filtering of suspect data values as part of its default-mode behavior.
{
(4.3) ERDS should receive data point values in batches, each constituting an update set. An update set is one value for each of a predetermined set of data points (not necessarily all the data points supplied by a feeder), each value of which is current in the feeder at the same moment ;
in time and therefore able to share one feeder-supplied timestamp on an update set.
(4.3) ERDS should receive a new value for each data point as frequently as a feeder can provide it, up to a maximum frequency of once every 15 ;
seconds.
(4.3) All feeder-supplied timestamps and other ERDS representations of time should be to the nearest second.
(4.3) ERDS users should be able to regard all ERDS-received values as having been timestamped by one consistent clock representing " plant site time" independent of the identity of the feeder that supplies a data point's values to ERDS.
(4.3) ERDS should use a predetermined " fixed time correction factor" and a user-specifiable " manual time correction factor", each a signed time difference associated with a unit-feeder pairing, to convert every feeder-supplied timestamp to plant site time. 1 (4.4) ERDS should maintain a structured database of plant-descriptive information, which normally does not change during an incident, organized by plant unit.
(4.4) The plant-descriptive database should include, for each data point i that will be received in transmissions from a plant unit, a data point descriptor that includes the following licensee-provided fields:
=
Identifier - maximum 12 characters, non-mnemonic, used as keywords for identification of values in update sets.
= Description - maximum 42 characters, human-readable, describes (together with Engineering units) the meaning of the data point.
4-18 '
.r . ... .
= Engineering units - maximum 11 characters, indicates the (fixed) denomination of values of the data point.
= Value range - maximum 16 characters, indicates some expected range of values of the data point.
l f
I l
1 I
i i
4-19 i
._______._____j
l
, .a .. y 1
1 I
5.0 DATA TRANSMISSION FROM SITES DURING INCIDENTS- ..
1 This chapter discusses the various issues and requirements involved it getting ERDS data out of a feeder system and transmitted to the NRC Headquarters Operations Center .and the. design conclusions that have been made thus far. Relevant findings from the project's surveying activities are.
included where appropriate in the discussions of speelfic topics.
The material in this chapter covers a wide range of toples. They are organized in roughly top-down (simple case first) fashion. First are issues involved in the steady-state (i.e., ignoring issues of initiating the i connection) transmission of data from a single feeder:
1 '
5.1.1 data formata of scalars (Individual . values)-
l 5.1.2 underlying factors (speeds .and' protocols) affecting the. formatting of a feed stream 5.1.3 formatting of a custom-built feed - stream 1 5.1.4 handling a pre-existing feed stream l Next are issues that arise under various conditions which complicate'the situ'ation:
i 5.2 Multiple feeders at a site !
5.3 Problematical (special-case) feeders Lastly, section 5.4 discusses issues associated with initiating the connection, requirements for telecommunication facilities, and possible telecommunication arrangements. -
l l
l 5.1 ISSUES IN STEADY-STATE TRANSMISSION OF A SINGLE PEED STREAM 5.1.1 Data Formats of Scalars In Chapter 2's introduction to ERDS concepts, the. Issues introduced under the item. "whatever format the licensee uses". gave an indication that we view the ambiguity in this tenet.of ERDS with some concern. These are the issues that were introduced there:
a) Engineering units versus digitalized sensor readings as the meanings of the numbers that ERDS accepts.
5-1~ j 1 ..
l b) Character strings versus internal binary representations as the bit patterns representing numerical data values, c) How should value-sensitive variability in character string representations of individual number values (their syntax) be determined and described?
d) How should the structure and punctuation (the syntax) of a stream of data elements be determined and described?
The first three of these relate to the data format of scalars; the last concerns the data format of a stream of data (which will be discussed in section 5.1.3 below).
The first two of these issues are germane only for a small percentage of licensees and feeder systems. Nonetheless, they did arise in the site surveys, and they illustrate extremes to which the "whatever format" tenet I l
can be taken.
l l
Sensor Readings The issue of engineering units versus sensor readings arises when the best feeder system for a plant (best in terms of the selection criteria for data points, as discussed in chapter 3) has no available communication ports, and its configuration limitations prevents the addition of a new one. in such a case. the choices are:
a) Move upstream to the first system that allows a communication interface to be added, and take a feed stream from that system. This is the situation that creates the question of whether ERDS will accept sensor readings.
b) Move upstream to the first system that allows a communication interface to be added, and acquire new systems that will reside at the licensee site and will replicate the data transformations now being performed by the licensee's systems downstream of that point, in order to create an available communication port that can provide data to ERDS in engineering units.
c) Select a less desirable feeder that provides less d,pstrable data points but has an available communication port (if such a feeder exists).
It seems clear that the choice among these undesirable alternatives should be sought not as a general principle but instead based on the actual details of the situation. This illustrates the kind of difficult and complex decisions that l
A NRC will have to be prepared to face during the implementation of ERDS.
However, the circumstances of this situation are not the reason why this issue is being raised here.
The point we wish to make is that the acceptance by ERDS of sensor readings will require ERDS to replicate the software maintained by the licensee for converting those values into engineering units. This software can be arbitrarily complex and may require perio@ adjustment of calibration constants to be provided as input. data. We strongly recommend that the possibility of accepting such valuec should NOT be part of the ERDS interface capabilities offered to all licensees.
If/when the actual situation described above is confronted with a licensee willing to connect to ERDS, the situation should be evaluated as an isolated case. This issue was encountered in the survey of two plant sites (Crystal River and Diablo Canyon) which use a Babcock and Wilcox computer system in their emergency response procedures. The details of these situations are l described in section 5.3 below.
1 Internal Binary Representations The issue of internal binary representations as the data format of numbers 4 arises from licensee concern about the additional computational workload, on an already heavily loaded feeder system, of converting data point values to I a formatted character-string representation. The survey encountered .
explicit suggestions that ERDS accept a feeder's internal binary format only at 3 plant sites: Palo Verde, Surry, and North Anna (the latter two are operated by the same licensee). However, concerns about overload of ileensee systems under incident-mode workload were voiced informally at a few other sites, as mentioned in section 3.6 (item 8). Since computer systems' workloads in general tend to increase more often than they decrease, this issue can be expected to arise at other plant sites during ERDS implementation.
Survey findings that provide background for this issue are the following:
All data point values of interest to ERDS are floating-point numbers.
(This is not spriori true -- they could be integers with implicit scale factors -- but the survey found no cases where they were not 4 floating-point numbers.)
The following distinct computer architectures and models were seen in the population of licensee feeder systems:
5-3
DEC PDP-11 DEC VAX Foxboro FOX -1 A, FOX-3 Gould (formerly SEL) 32 Hewlett Packard 1000
'Hewlett Packard 9826 Honeywell 4400, 4500, 45000 IBM 370 IBM PC/XT Modcomp Classic Motorola System 2000 Perkin-Elmer 3200 Prime 750, 9955 Rolm MSE/14 Sperry V77 Westinghouse P250, 2500 In all feeder systems for which information was provided, the syri tem software environment provides the service of converting numbers to formatted character strings. So this issue is only about computational time load and does not interact with the problem of limited memory being available for residency of new software or the issue of licensee software development costs. [
Ploating-point numbers are stored internally in a binary format which is speelfic to a computer manufacturer's architecture. Different computer models in the same compatible family always use the same floating-point format, but there is never an expectation that the format of one computer j family is compatible with that of another. (The IEEE has in the last few years established a standard for floating-point formats and arithmetic operations, but it is pre-dated by virtually all the computer architectures that ERDS will have to interface with.)
l If ERDS sere to accept internal floating-point formats. ERDS software would j have to have the ability to convert them to the internal format of the ERDS data host. The software development effort required to create this conversion capability for just one conversion path would be measured in ;
weeks; for the number suggested by the list of architectures above, it l would be enormous. Testing such conversion capability would require, for each feeder architecture to be supported, access for software testing on a compatible computer system.
5-4
j I
We strongly recommend that the possibility of accepting internal binary representations of numbers from a feeder should NOT be offered by ERDS.
ERDS should offer to accept only formatted , character-string representations i of numbers in the two dominant industry-standard character codes, ASCII and EBCDIC. (All feeders seen in the survey can supply characters using one of these code sets. Only 3 use EBCDIC, but providing character code j translation is a relatively trivial requirement for ERDS.)
Unfortunately, we cannot offer a universal technical solution to the issue of how to respond to licensees worried about additional load on their feeders.
Offering to accept data at a lower update frequency could be a solution in ;
some cases, but it would not help in feeder software environments that let a task run to completion without preemption once it has begun execution.
This is a common practice in the application software environments on i feeders. (The survey told licensees that the minimum acceptable update frequency would be 15 minutes. That should be seldom enough to provide whatever amelioration can be obtained from a lower update frequency.) I Approaching the problem cases of this issue on a case-by-case basis (i.e.,
being willing to accept internal representations in isolated cases) at present appears to be technically feasible, because the number of them seen in the survey is small. However, it would certainly undermine the presumed NRC goal of evenhandedness toward licensees, because all licensees can be assumed to care about the computational load on their feeder systems.
Syntax of Formatted Numbers The third of the issues mentioned at the beginning of this section was: How should the syntax of (character string representations of) scalar data values be determined and described? On this issue, the survey provided some surprising results. We had expected that PORTRAN would be the likely programming language for new software to generate an ERDS feed in nearly all feeders, and that there would be substantial uniformity among the exponential notation formats (i.e., E-format) (e.g., "1.234E+02" for 123.4) of the various PORTRAN runtime environments. Not so.
PORTRAN was named as the likely programming language for 85% of the feeders that provided an answer. Other languages named were: assembler, BASIC, C, COBOL, and PL/1. BASIC and COBOL are notable because they cannot force output to use E-format: COBOL does not provide it at all, and BASIC uses it only if the value (expressed in non-E-format) will not fit in the programmer-defined field width.
5-5
l To assess the degree of uniformity among E-formats, the survey asked for the exact characters that would be generated for the value -0.1234 in the shortest possible E-format representation. The responses are shown below.
"(*: )" shows the number of respondents for each response. Embedded blanks in the responses are as they were reported.
l 1) .1234E 00 (f: 3) l
- 2) .1234E+0 (f: 1)
- 3) .1234E+00 (f: 3)
- 4) .1234E0 (f: 1)
- 5) -0.1234 (No E-FORMAT) (f: 2)
- 6) -0.1234E+00 (f: 2) l 7) -0.1234E0 (f: 3)
- 8) -1.234 E -01 (f: 1)
- 9) -1.234-1 (f: 1)
- 10) -1.234E-01 (f: 8)
- 11) -1.234E-1 (f: 5)
- 12) -1.23E-01 (f: 1)
- 13) -12.XE-1 (f: 1)
- 14) -1234.E-04 (f: 2)
- 15) E .1234+00 (f: 1) l One other survey finding is relevant to the issue of formatting.of scalar
, values. The survey asked whether powers of ten in a value ever cause the prefix of an englnoering unit to change (e.g., 186000 feet /see becomes 186 K-feet /see or 0.186 feet / microsecond). All answers were that this never happens.
Our recommendations regarding this issue are based on the observation that, despite the number of different responses for the example, all are easily understandable by a human reader (except perhaps response 13, which apparently signifies -12 times E-1). We conclude that the rules for parsing all these value representations can be codified relatively easily, and that it is feasible for ERDS to have a " number recognizer" software module that will be able to interpret all of these samplo values without any prior knowledge l
of which format is being used. Eng!!sh is not a suitable language for describing character processing, but the informal program which follows should provide some reassurance of the practicality of this approach:
l 5-6
- l_________________
- 1. Look for "E" as a boundary. It it is not present, goto 2.
If it is present as the first character, throw it away and goto 2.
If it is present internally, it splits the value into 2 numbers, a signed real on the left and a signed integer on the right; goto 4.
- 2. Look for an internal "+" or " " sign. If it is not present, goto 3.
If it is present, split the value into 2 numbers just before the internal sign, and handle them as in step 1. Goto 4.
- 3. (More cases if necessary. None are needed by the shown example values.)
- 4. Delete all blanks and letters. Evaluate the signed real (left side) and the signed integer (right side). Do the multiplication by the power of 10 that is indicated.
/
An important aspect of this approach is that the recognizer should be able i to handle non-E-format real values and integer values as sub-cases which-have a left-hand side but no power-of-ten exponent. Other aspects of this approach:
Each value will have to be bracketed by separator characters that could never be in a value. The identity of the separator characters can bo 4 feeder-specific (i.e, it can be */" for one feeder and "$" for another).
either pre-stored in ERDS at NRC Headquarters or provided at a l designated place in the feeder initlailzation packet sent upon feed startup.
This approach does not require all values to be the same length.
- The recognition capabilities of the recognizer can grow (if necessary) as ,
implementation of connections to new feeders discovers new value formats. !
If a feeder is encountered during implementation whose values cannot be recognized by extending the primary recognizer while retaining compatibility, an " alternative value language" (i.e., a new recognizer) can be established. To allow for this possibility, the feeder initialization packet (of all feeders) should have a field which declares which "value language" it will speak. We would be amazed if more than 4 incompatible value languages were to be necessary.
Licensees requesting guidance for the formatting of a custom-generated data stream should be told that ERDS will make use of at most 4 significant digits in each number. Less than 4 is acceptable. The first 4 digits of any number (excluding leading zeroes) will be assumed to be significant. (See section 4.1.)
5-7
1 The ERDS implementation planning procedure should request that a licensee generate a hardcopy output with some prescribed test values ,
printed by each feeder's language of choice, so that the recognizer can be extended, if necessary, before the licensee's programmers need to test their implementation (s) of feed generation software.
5.1.2 Underlying Factors Affecting Data Stream Format A large percentage of the licensees in the site surveys expressed a preference for handling the ERDS data interface on a write-only basis at the appilcation software level. From their perspective, having to read and respond to inputs from the NRC side of the interface is a significant increment in work. Except for a notification that initiation of transmission has successfully completed, we see no need for inputs to a feeder from the NRC side of the interface, except in situations where a licensee insists upon using existing report-generation software to generate the feed stream and this software requires inputs.
All feeders seen in the survey can supply characters using either ASCII or EBCDIC as the code set. Only 3 use EBCDIC. but providing character code translation is a relatively trivial requirement for the ERDS receiving computer, so the choice between these two code sets should be left to the licensee, but specified as a predetermined attribute of each feeder.
All but one of the feeders surveyed can provide an asynchronous serial feed. The exception was the one feeder for all of the plant units of Northeast Utilities; this feeder is an IBM mainframe that uses synchronous SDLC protocol. It is discussed further in section 5.3.
With this uniformity and simplicity of protocol available at the feeders' serial ports, the following general approach is recommended for data transmission to preserve that simplicity:
For sites having only one feeder, use a 2400 bits /second asynchronous ;
modem that provides error detection / correction.
For sites having more than one feeder, require the licensee to bring the asynchronous feed streams together to one geographic location at the site, but not necessarily into one computer. (If the licensee prefers to bring them into one computer, the site becomes a 1-feeder site). Use a statistical multiplexer to bring the multiple feed streams to NRC Headquarters, with error detection / correction provided by the multiplexer.
5-8 c .
e C O One plant site, San Onofre, mentioned in the survey that bringing the multiple feed streams together to one geographic location might be a problem.
However, we see no way that NRC can solve the problem of creating wire paths within a site more easily than the operator of the facility.
The MNP asynchronous protocol (Microcom Network Protocol, trademark of Microcom, Inc.) has in the last two years emerged as an industry standard i for providing error detection and correction at the modem-to-modem level. l This approach bypasses all the difficulties inherent in a software-to-software level attack on transmission error protection. A typical retail quantity-one list price is $700, for an external (stand-alone) 2400 bits /second modem having MNP. l With the MNP protocol, the receiving modem requests retransmissions if it detects an error. The sending modem has a buffer in which it saves recently sent data, so the sending modem does not have to ask the sending computer to retransmit (very important for ERDS). The size of the buffer is different in competing products; typical offerings are 1K or 2K bytes. With the presence of this buffer, these modems can and typically do offer the feature of " speed conversion" each end's computer / modem speed can be different from the modem / modem speed. Also significant for ERDS, the l
sending modem must be able to invoke some flow control protocol to tell the I
sending computer to stop sending (typically when the modem's buffer gets I
l 80% full).
l The speed conversion feature will be useful in ERDS, to hide differences among feeders' transmission speeds from the ERDS data receiving hardware (modems and computer ports). The survey found 2 feeders whose maximum available transmission speed is 300 bits /second, and 4 with maximum of 1200.
The maximum transmission speed of all other feeders is 2400 or higher. All the feeders with higher maximum speed can provide 2400. The speed conversion feature will accomodate feeders needing 300 or 1200 bits /second transmission speed, while the modem / modem speed and the ERDS receiving ports can standardize on 2400. Because 2400 bits /second allows transmission of 2400 characters per update set (see section 4.3 for derivation of 2170 character estimate) in roughly 10 seconds, this will allow 15-second update frequency from feeders talking at 2400 speed to be transmitted with ample safety factor.
In asynchronous communication, there are three available industry conventions for flow control (the way a receiver tells a sender to pause or resume). All of these should be present in the ERDS modem (as they are in all the candidate products we have inquired about):
5-9
l XON/XOFF: control characters in the transmission, meaning " pause" and
" resume", both sent by the receiving entity (e.g., computer or person). ;
RTS/ CTS: control signals in the RS-232C connection (Request to Send, Clear to Send) between sending computer and sending modem, forming a handshake initiated by the sending computer for each character to be f
{
sent. DTR (Data Terminal Ready) is sometimes used instead of RTS. i 1
' ENQ/ACK: control characters in th'e transmission, forming a handshake j initiated by the sender, meaning "Did you receive the last block OK7" and "yes". This is used only in Hewlett Packard computers but is widely supported by modems, terminals, and other peripheral equipment.
The survey asked whether the operating system of a feeder supports XON/XOFF. There were 19 responses of "No" (vs 43 "Yes"). The design implication of that many No answers is that the ERDS stream-receiving I computer at NRC Headquarters must be tested to assure that'it can receive l and store data at the nominal baudrate (bits /second) without having to use
) XON/XOFF to ask the sending feeder to pause. The RTS/ CTS flow control j convention is found in every RS-232C serial port having " modem control" l capabilities. The survey did not ask whether the serial ports declared to be '
available for ERDS were modem-control ports versus direct-connect ports. 1 Based on an assumption that at least some ERDS feeder ports will not have !
modem-control logic, the implementation design should strive to allow j connection to non-modem-control ports in at least some combinations of i circumstances, recognizing that other combinations will necessitate the j presence of modem-control logic. Licensees should be told that use of a port ;
with modem control is preferred; a feeder port without modem control may necessitate reducing its frequency or duration of transmissions, as described in the next paragraph.
In order to tolerate the widest feasible range of variation in feeder capabilities, we recommend that the ERDS sending modem's buffer be specified to be at least 2K bytes, This will allow ERDS to tolerate failures i l or absence of RTS/ CTS (and of all other flow control capabilities) in the
) serial' ports for ERDS. That amount is a compromise, based' en the maximum I
available modem buffer size we are aware of, a worst case of 2170 characters per uptlate set for the data point values (see section 4.3), plus at most 100 characters for a header and trailer on the update set, plus an assumption -
that all the worst case factors will not occur in the same situation, plus the realization that it's tolerable to lose a whole update set occasionally when all the worst case factors do occur concurrently. If the modem procurement activities in ERDS implementation find difficulty in obtaining 2K byte buffer 1
5-10
. o.
size, or a feeder is found with worst case conditions that make 2K-byte'
~
buffers chronically non-functional. .the solution is to ask the licensee to program the feeder to split each update set into 2 transmissions, each-transmission containing half of the set of values. (It is still one update set, with all values snapshotted at the same time, but the feeder's stream generation software would hold half of the values until some programmed ., '
tiine delay, has elapsed.)
In talking to ' modem manufacturers, we found that these MNP modems usually come with a different model identity for use on leased lines than for use on dial-up lines. Usually the leased-line version can be, used on dial-up lines,
~
but not vice versa. Because we are. recommending (in section 5.4 below) l that ERDS not use the public dial-up network, that needs to be specified in :
the modem's requirements. However, another issue comes into relevance here: how the data paths from these MNP modems will terminate at the Operations Center at a compatible . modem attached to an NRC computer' port.
For reasons of economy, the arrangements at Headquarters should not have
~
I to dedicate a computer port to each 1-feeder site (each modem at a site).
Further, it is desirable that Headquarters should not have to dedicate a '
modem to each communication channel coming in from a site. The current design basis for ERDS is that it needs to handle only one incident at s' time, although it must be able to tolerate transmission attempts from other plant j units at any point in the evolution of the incident of interest. We believe that NRC may in the future decide that FRDS should be able to handle more than one incident simultaneously, but we do not believe that NRC would ever .
want ERDS to be able to receive from an unlimited number of plant units (or more than 5) simultaneously. In summary, it can be assumed that the hardware at NRC Headquarters that terminates communication channels from sites will never have to support concurrent . transmission from. more than a small number of sites (currently one).
This conclusion suggests the appropriateness of. contention among plant' units wanting to transmit. It further suggests that the most economical locus of that contention is for channels comir)g from sites to contend for a small number of available sets of channel termination hardware, unless contention can occur upstream of that point. In other words, NRC may choose to implement a regional hubbing arrangement for channels from sites,. ;
but if a dedicated. channel will exist from each feeder site to.NRC Headquarters, the termination hardware at Headquarters that is dedicated- to each channel should be minimized. In the rest of this chapter until section 5.4, discussion will be in terms of a star topology of dedicated channels from sites (i.e., without hubbing) rather than 'a. hierarchical topology (i.e.,
with hubbing).
q 5-11
l i
The most economical way of providing contention among incoming channels from sites is to use the switching capabilities of the existing PBX serving the Operations Center. So, for the 1-feeder sites, the recommended approach is that the communication line from each site (if it exists as such; see section 5.4) terminate on the Operations Center's PBX as an in-house telephone station, and that dialing within the PBX by the sending end of the line (as part of ERDS link initiation) be the way that a connection is made to a small number of auto-answer modems (each dedicated to a computer port). The rationale for this recommendation is cost: if MNP modems were less expensive than PBX station ports, the communication lines should terminate on modems, with a switching device (e.g., a " data PBX" or a " port contention unit") placed between the line-dedicated modems and the few 1 allocated computer ports.
This recommended approach has implications for the requirements on the I modems, on the software to be created by licensees in the feeders, and on I the software in the receiving computer at NRC. The dialing is within the NRC PBX which is assumed to reliably offer a dialtone to any sta, tion line which goes off-hook. To accomplish the dialing, the modem at the site must have autodial capability, and the feeder must send it an impetus to initiate the action.
I There are two possible ways that a feeder can initiate dialing by a modem:
by sending it a command composed of characters in the normal data channel from computer to modem (which the modem intercepts rather than passes on), or by signalling using the " control" wires of the RS-232C interface (typically using the Data Terminal Ready -- DTR -- wire). With l << signal-initiated dialing >>, the phone number to be dialed must be pre-stored in the modem; with << command-initiated dialing >>, the phone number could be pre-stored in the modem, or it could be included in the command from the feeder. Not all modems offer signal-initiated dialing, but it is a frequently available feature.
Many modems can store phone numbers in a battery-1s ked internal memory as a convenience. However, the finite lifetime of such batteries would be a significant inconvenience to ERDS system maintenance, so they should be avoided. Instead, non-volatile memory (e.g., read-only memory, but read-only is not necessary) should be specified for the internal phone-number memory of the modems. (The phone numbers will be internal extensions within the NRC PBX, which we assume NRC can leave unchanged in perpetuity.)
5-12
- a. _ ._. _ _ _ _ _ _ _ _ - _ _ _ _ _ _ -
We believe that command-initiated dialing, with the phone number included in the command from the feeder, would be slightly more straightforward and simpler to debug than signal-initiated dialing. However, command-initiated dialing would have to be implemented in licensee-created software in the feeder, and minimization of requirements on licensee software is a strong theme of ERDS. Signal-initiated dialing, with the phone number unchangeable stored in the modem, would offer a fringe benefit of implementing in hardware the concept that the ERDS data transmission equipment is dedicated to ERDS and not to be borrowed for other purposes.
We recommend that ERDS implementation offer both choices to licensees, supplying modems that can implement either choice after suitable set-up.
We see no specific need for Hayes command compatibility in the modem's autodialing commands, although there is nothing wrong with it.
With reliance on contention and dialing by sites seeking connection to ERDS data-receiving hardware, the design must consider the details of how that contention would work. For purposes of this discuselon, assume that there is only one auto-answer modem and computer port for receiving data at NRC Headquarters. It is possible that, at a time when a site R wants to initiate transmission as part of a Real incident, another site T has an improperly Talkative feeder that is also trying to initiate transmission. If site T got the connection to the receiving modem first, site R would get a busy signal from the NRC PBX. The software in the NRC receiving computer could be told by some user (e.g., the Headquarters Duty Officer in the Operations Center) that NRC wants to receive only from site R: the software then could, after re'ceiving identification from site T (or any site other than R), hang up )
the connection, but then site T might again win the race for the l re-initialized auto-answer modem. ]
I The recommended solution for this possible problem is to provide two auto-answer receiving modems and computer ports, with the PBX providing a j
" hunt group" to access them (so that a caller dialing the first number will, j upon seeing it busy, be connected to the second number). The software in ;
the NRC receiving computer would assist in mediating contention, as follows: I
- The Headquarters Duty officer interacts with the receiving computer to ;
maintain a list of " eligible caller" sites. Any changes to the list happen upon the initiative of the Duty Officer (not the system) and can be done at any time.
The Duty Officer is notified by the receiving software when any caller I attempts to initiate a connection, and when an eligible caller site is beginning transmission.
5-13 l
l l
The Duty Officer can, at any time when transmission is occurring, command the software to stop receiving.
The receiving software maintains the following states and state transitions for each receiving port (modem and computer port):
Poised = The port is ready to answer a call.
-> Transition to Hello when modem receives a ring.
Hello = The port answers the call and receiver the initialization packet from the feeder. The software notifies users of an initiation attempt and checks if the calling site is eligible.
-> Transition to Goodbye if not eligible.
-> Transition to GetComfortable if eligible.
Goodbye = The software forces the port to hang up the connection, re-initialized data structures, re-initialized the modem and port.
-> Transition to Poised when re-initialization steps are finished. I GetComfortable = The software notifies users that transmission is beginning, changes the other port (s) to Asleep state, and sets up data structures for receiving and storing data.
-> Transition to Coupled when set-up steps are finished.
Coupled = Steady-state receiving and storing of data. !
-> Transition to Cleanup upon a user command to stop receiving or I when transmission stops unexpectedly (loss' of connection or long silence). '
1 Cleanup = The software does an orderly closing of data structures, re-initialized data structures to be ready for a new caller, changes the i' other ports to Poised state, and re-initialized the used modem and port to be ready for a new caller.
-> Transition to Poised when clean-up steps are finished.
Asleep = Same as Poised plus Hello plus Goodbye states, without regard for the eligibility of the caller. (The software answers each call, receives the identity of the caller, notifies users of an initiation attempt, hangs up, and re-initialized the used, port.) l I
Each feeder (in partnership with its sending modem) is programmed to retry dialing if it receives busy from the NRC PBX, or ringing with no answer, or loss of connection (e.g., due to hang-up' by the receiving computer).
5-14
^ . ..
In this framework, an improperly talkative feeder would be made ineligible by the Duty Officer. Any ineligible caller can tie up a receiving port only for the duration of the Hello and Goodbye states, during which time the other receiving port remains (in the Poised state) able to accept calls. The states and transitions are designed so that the users (i.e., the Headquarters Duty Officer) can exercise corrective control but need not respond immediately to any reported situation. The responsibility on each feeder to retry dialing ensures that, after the Duty Officer eventually modifies the eligible caller list to exclude all improperly talkative feeders, the first legitimately initiating feeder will eventually see the Getcomfortable state rather than the Asleep state. The semantics of the Cleanup and GetComfortable states need to be enhanced so that an unexpected stoppage of transmission, followed by a successful re-initiation by the feeder, would be .seen by NRC users as a recovery within a single incident that produces a seamless store of data, rather than two separate incidents.
l If all 1-feeder plant sites will contend for the same ports in the ERDS receiving computer, and any feeder's initiating transmission must be
! intelligible before the identity of the feeder is known, then all feeders' f serial ports must be configured to use asynchronous communication parameters matching those used to configure the receiving computer's ports (except for transmission speed, which will be accommodated by speed converdon capability in the remote modem). These should be 8 data bits per character, without an additional parity bit, and I stop bit. For feeders using ASCII code, which is '7 bits per character, the eighth (high-order) bit of each character should be zero (i.e., " space" parity). (This is not necessarily the same as "no parity", which has no industry-standard meaning.) The 8-bit EBCDIC code should use all 8 data bits.
With predetermined knowledge of each feeder's character code, and a predetermined set of feeder identification names, the software in the ERDS receiving computer should be able to recognize any feeder's initialization packet, even though it does not know beforehand which character code is being transmitted. It would compare the received feeder identity against EBCDIC-coded names of EBCDIC-transmitting feeders and against ASCII-coded names of ASCII-transmitting feeders.
If the ERDS receiving computer allows software to dynamically change the communication parameter settings of a serial port, the implementation design may choose to relax the requirement that each feeder must use the same communication parameters. The design could specify that each feeder should transmit its initialization packet a fixed number of times (say 4) with a programmed delay between each repetition: the receiving software would load 5-15
different parameter settings into the serial port between each repetition and then check which settings produced intelligible results.
5.1.3 Data Format of a Custom-Built Communleation Stream of the 93 feeders encountered in the survey, only for 36 did we obtain any information about an existing software entity that generates a stream which the licensee thought might be suitable for an ERDS feed. For all the other feeders, licensees will have to create software that formats a stream designed on a custom basis for ERDS. An important part of the ERDS design will be specifications for such streams which readily accommodate the variability needed by licensees while still being easy to process at the i receiving end. ;
The following are attributes and goals we recommend for the specifications for custom-generated ERDS feed streams. These recommendations will allow i update sets to arrive in non-chronological order, which will facilitate later !
enhancement of ERDS to accept pre-initiation data. I
- a. To the extent possible, the transmissions' structure should be I
l self-descriptive enough to minimize the need for the NRC end's receiving
- computer to have pre-stored speelfications of the feeder's stream l structure.
- b. Each normal transmission has 3 sections: a fixed-length header, a set of self-identifying data point packets, and a fixed-length trailer. An initialization transmission is non-normal: it contains an initialization packet !
instead of data point packets,
- c. An initialization transmission is sent upon initiation of the ERDS link. It repeats periodically until the NRC end sends back positive acknowledgement. This can come back to the feeder either over the data link (if the feeder will accept remote input from NRC) or by voice to a licensee staff person at the site who notifles the feeder software (if the '
licensee insists upon the " expediency" of the feeder not accepting remote input from NRC). Then the feeder starts sending periodic normal transmissions,
- d. The initialization packet contains identifying information and parsing information that will not change during an incident. This includes:
Identification of the plant unit, identification of the feeder, identity of separator characters used in normal transmissions, identity of the data value " recognizer" to be used (see last subsection of section 5.1.1). In 5-16
the survey, we established a coding scheme that uniquely identified each plant unit with 3 characters and each feeder with 4 characters.
- e. Implementation could choose to include the initialization packet as part of the header of each normal transmission. That would make each normal transmission fully self-documenting and therefore eliminate the need for the initialization transmission and positive acknowledgement. The choice l
depends on what other uses are found for the initialization packet during implementation design.
- f. A transmission is always a whole update set, except when the special case mentioned in section 5.1.2 requires splitting an update set into multiple transmissions. A whole update set is not necessarily all the data points supplied by the feeder.
- g. The data format need not implement error detection / correction, because lower-level hardware will provide it. However, feeder software can with trivial overhead include a character count to provide a software check on the hardware checking. So it should.
- h. The header includes the date (YYMMDD) and time (HHMMSS) of the update set's timestamp. (An update set by definition shares one timestamp.)
- 1. Each data point packet contains 3 fields (identifier, value, quality) in fixed sequence, with a field separator character after each of the first two fields. Each field is arbitrary length, up to a ceiling maximum (for each field) agreed to during site implementation. A quality tag field can be zero length (but still has a separator): other fields are never zero length.
A value must be numeric; booleans and other non-numeric datatypes must be represented as numbers (see section 4.1). After the third field is a packet separator character.
J. The sequence of data point packets within a transmission is arbitrary.
The transmissions include only data points wanted by NRC.
- k. A section separator character comes after the transmission header, before the transmission trailer (i.e., after the last data point packet's packet separator character), and after the transmission trailer.
- 1. The transmission trailer consists of 6 decimal digits giving the total number of characters in the transmission (including from the first character of the header to the section separator after the trailer) in base ten. Example: "002170" for 2,170.
5-17
l t
5.1.4 Handling a Pre-Existing Stream Format The " limited generality" approach to licensee /NRC Interfaces (discussed in the beginning of chapter 4) leads to the conclusion that there should be some clearly stated criteria for acceptability to ERDS of (the output of) pre-existing stream-generating software. The survey phase of this project sought descriptions of various attributes of such software, sufficient to draw some conclusions about what attributes would cause major difficulties for software processing on the NRC end. We were not able in the survey to gather enough information with enough specificity to be able to make firm judgments about the acceptability of many of the existing situations. We did, however, gather enough information to be able to form some conclusions '
about acceptability criteria.
Significant findings from the survey include the following:
There were 36 feeders having candidate software. It should not be assumed that all of the licensees who provided information in this category would prefer to use this software (rather than creating new software that conforms to the recommendations in section 5.1.3). It should be assumed that some will prefer to use their existing software, and at least a few of them are 11kely to insist on it as a condition for their voluntary participation in ERDS.
21 of the candidate software programs' output is designed to drive a display screen (to show data point values to users).
7 of these use hardware-specific terminal commands for cursor positioning.
13 of the 36 candidates require inputs from their user (i.e., from ERDS) to trigger the generation or continuation of output.
Indications of the character length of an update set were provided only j for 5 of the candidates. 3 were under 4K characters, I was 30K .j characters, I was 80K characters. i l
There are several possible approaches that ERDS could take for the i challenge of extracting the data of interest from anaexisting stream of characters designed for display to humans on a terminal screen or paper.
- a. ERDS could have pre-stored, using a row-column coordinate system (based on the way the report format appears to human viewers), the locations-and lengths of fields of characters that it wants to keep. Also pre-stored 5-18
would be cut-and-paste instructions for how to use these extracted fields i together with string constants to. build a new update set that conforms to l the "ilmited generality" protocol's specifications recommended above in section 5.1.3. The cut-and-pasted update set would then be handled as if it had just been received from the feeder,
- b. A sequence of pre-defined character strings could be pre-stored in ERDS.
Each would be the locator prefix in the stream for a field of interest to i ERDS. Successively, ERDS would retrieve the next of these from its I control files and scan the stream (after it has 'been received into a storage buffer) looking for it.
- c. The specifications recommended in section 5.1.3 could be extended to include concepts of junk fleids in a data point packet, which would be :
discarded by the NRC end of the ERDS link. The extension would have to l explicitly identify each field in a data point packet, since the 3 fields there now are positionally identitled. l l
l Approach (c) seeins undesirable, because it complicates the transmission for ;
all feeders without being able to handle all the cases of existing formats.
Approach (b) would probably work, but it would require a great deal of text scanning by ERDS. Approach (a) is what we recommend (for feeders whose licensees insist upon using pre-existing software to generate a feed stream that does not conform to the specifications recommended in section 5.1.3),
with these criteria on the candidate feed stream:
- 1. The stream must contain, somewhere, all the non-separator information sought in the stream described in section 5.1.3. In psrticular: data point identifiers, date and time, plant unit identifier, feeder identifier.
- 2. The licensee must pre-define the set of row terminator characters. Any one of these causes ERDS to start a new row in its row-column coordinate system.
1
- 3. The stream must contain only printable characters, no control characters (in the ASCII code set, no character whose code value is less than that of blank). The implementation contractor may choose to relax this constraint, after the ERDS communleation hardware has been selected and its capabilities determined. We recommend that the concept of " transparency" (ability to transmit control characters as part of a data stream) should not be allowed to complicate the data communication procurement requirements.
- 4. There should be a ceiling on the percentage of junk characters that ERDS will receive, so that implementation has some worst case specification to 5-19 l _ _ - _ _ _ _ _ _ _ _ _ - _ _ - _ -
design to. We recommend a ceiling of roughly 24 x 80 characters per 20 I data points, which represents an information density of one data point per I line on 20 lines of a fully packed 24-line screentul. We caution that, in the absence of such a ceiling. NRC is likely to receive many data points it does not want, simply because they are in the software now.
- 5. The NRC end of the link should not be expected to provide any inputs to drive the licensee software. This could perhaps be relaxed to allow the NRC side to transmit a pre-stored (licensee-specified) fixed string of characters periodically (every N seconds, licensee-specified), independent of the rate or content of what NRC receives.
5.2 MULTIPLE FEEDERS AT A SITE These are the design alternatives for situations where there are multiple feeder computers at a site and more than one must transmit data during an incident affecting cne unit:
a) Rely on the licensee to coalesce the data on a single feeder.
b) Send multiple feed streams to the Operations Center on separate l
communication channels.
c) Place an NRC-provided computer at the site to coalesce the data into a single stream for transmission to the Operations Center.
d) Place an NRC-provided multiplexer at the site to coalesce the data onto a single communication channel for transmission to the Operations Center.
The survey encountered 52 feeder sites, housing 93 feeders, in surveying 97 plant units. Of the 52 feeder sites, 29 (56%) had only one feeder, and 23 (44%) had more than one feeder. Of the multi-feeder sites surveyed,1 had 6 feeders and all the others had 4 or less feeders. At the one 6-feeder site, no more than 4 feeders support any one plant unit. Linearly extrapolating to 120 plant units (the number now operational or in active construction) produces an expectation of 64 feeder sites for 115 feeders, of which 28 sites (44% of 64) will be multi-feeder.
With an expectation of that many multi-feeder sites, we recommend that the ERDS design should include some alternative other than (a). The sites where this situation arises are too numerous, and too few licensees will be willing under the voluntary approach to provide (a), to rely on the eventual possibility of regulatory action for this many cases.
5-20
Consideration of the human factors of equipment management leads to the conclusion that altern,ative (d), the multiplexer, is more attractive than (c),
the computer. The multiplexer alternative will complicate requirements on the Operations Center facilities for ERDS. It will require a companion multiplexer at the Operations Center, and will require that the data receiving computer in the Operations Center be able to handle multiple concurrent input streams. However, these complications are purely technical and in-house, and inconsequentially negligible compared to the admlaistrative and management issues associated with NRC putting a general purpose computer at many feeder sites. The concept of a site link control computer could probably be justified if there were a strong technical need.
Fortuitously, there is not.
The details of the multiplexer approach need some attention. Error correction at the communication hardware level is highly desirable, to match the error correction provided by MNP modems for 1-feeder sites. This suggests use of statistical multiplexors, which always provide error correction as part of their multiplexer-to-multiplexer protocol (which in turn means that no error correction is needed in the modems sitting between the two multiplexors). However, there is a complication here. A statistical multiplexer (stat mux) generally expects to have a permanent connection via a dedicated channel to a companion stat mux, with two compatible modems as part of the dedicated channel (unless a modem is integral in each stat mux, as in some newer models). As was discussed in section 5.1.2 in the context of 1-feeder sites, it is desirable that the Operations Center not have to dedicate a modem and multiplexer to each multi-feeder site. So the question arises, How can the contention among sites that was suggested in section ,
5.1.2 work when stat muxes are provided for multi-feeder sites?
In talking about stat muxes, the terms " client side" and " link side" are generally used; the << client side >> faces the multiple computer ports being multiplexed, and the << link side >> faces the modems between the multiplexors. In sophisticated stat muxes, the client side can support a variety of protocols, both synchronous and asynchronous, but ERDS will require only simple asynchronous communication on the client side with no special proprietary protocols. The link side of a stat mux is always synchronous, requiring a synchronous modem. The link side can can generally be conflgured to talk at any standard speed up to 9600 bits /second, sometimes higher, to match the capabilities of the modems and the channel between them. For ERDS, in principle no more than 2400 bits /second should be required on the link side (i.e., the same as required for a 1-feeder site), since the multiple feeders will be transmitting on behalf of only one plant unit at a time, and their total data transmission rate 5-21
1 I
u should be no more than one feeder would send for that plant unit. '
The difficulty with the site contention approach of section 5.1.2 in the .j context of stat muxes is how a feeder would trigger dialing by the modem. j Modems having auto-dial capability and synchronous transmission are readily a obtainable for 2400, 4800, and 9600 bits /second speeds. However, a stat mux must successfully handshake with its companion stat mux (go through a i
" synchronization sequence") before it will pass data from the ellent side to
.{
the link side. Therefore, command-initiated dialing (a feeder sends a dialing j command to the modem in the data stream) cannot work, because no stat mux will open the path to the modem before the connection between the stat j muxes is established. l The solution to this difficulty is to use a modem that will perform signal-initiated dialing (dialing a permanently stored number in response to I a false-to-true transition on one of the RS-232C control wires), and to bring l one of the RS-232C control wires from one of the feeders around the stat mux to provide the needed impetus for the modem. In this approach, one of the feeders at each multi-feeder site would be designated the u lead feeder >>, responsible for triggering dialing by the modem. Assume for the sake of discussion that the modem requires assertion of DTR to trigger /
dialing. Then the modem's input of DTR, instead of coming from the stat mux (as all its other inputs do), would come from whichever RS-232C control wire is being used by the lead feeder to trigger dialing. This approach would, we believe, require only custom-built cables, not custom-built hardware.
As described thus far, this approach requires designation of cne lead feeder to initiate dialing for any incident at a site, independent of the plant unit involved. There are a few multi-feeder multi-unit sites where the feeders constitute disjoint sets for each plant unit. In these cases, the lead feeder 1 would have to initiate dialing even when it would not be responsible for j transmitting data. The implementation design could relax this requirement of I a single lead feeder by providing a simple custom-built hardware box that ;
would accept dialing impetus signals from multiple feeders and output the !
logical OR of them to serve as the DTR Input of the modem.
In order for all multi-feeder sites to use (contend for) the same ports in the ERDS receiving computer, possible differences irr the feeders' transmission speeds must be accommodated. The most desirable method would be a feature in the stat muxes analogous to the speed conversion feature specified for modems at 1-feeder sites, so that a feeder could talk to its stat mux at 300 bits /second (or 1200) while its channel in the NRC Headquarters stat mux talks to the receiving port at 2400. Fortunately, this 5-22
s y
capability, typically called " unbalanced rates", is available in some stat muxes. We recommend that it be specified for the ERDS stat muxes, to avoid l the need for ERDS receiving software to dynamically adapt a receiving ,s port's speed to the speed of the transmitting feeder. The other asynchronous communication parameters (data bits, stop bits, parity. 3 character code) of feeders at multi-feeder sites (and their receiving ports at .{ '
NRC Headquarters) should be specified like tliose for 1-feeder sites, as ,
discussed at the end of cection 5.1.2. A The use of signal-initiated dialing with the ec$ trol signal goinhuund the stat uux will require careful engineering durinx implementation design.
Although all the features of communication hardware that are needed for it to be successful are readily available, we frequen'ly encountered skepticism
("It can't work") in discussing it with tales engineey/of stat mux manufacturers. We attribute this to several factors ,
Firstly, the concept of acquiring dedicated communication channeis (" leased "
lines") and terminating them on a PBX, to provide d!aling-implemented -
contention for a limited number of receiving ports, is unusual. A frequently heard comment was, "There is no dialing on a leased line," even afto: <
acknowledgement of the feasibility of acquiring a 2-wire leased line for a l long-distance voice extension on a PBX. ;
Secondly, a frequently found feature in stat muxes is " port contention", and /
this feature was often suggested in response to the goal of using contention j to economiza on the receiving facilities needed for ERDS. With port I contention in an 8-channel pair of stat muxes, some number fewer than 8 (say 6) computer ports would be connected to the client side of one of the i stat muxes. That stat mux then allows any 6 of the remote 8 clients to access the 6 computer ports: the seventh remote ellent would get a "no port available" response from the stat muxes until one of the first 6 clients relinquishes its port. This feature is not appropriate for ERDS. In ERDS, when any site wants to transmit, all the feeders serving one plant unit s should be allowed to transmit simultaneously (limited.only by the statistici1 multiplexing of the stat mux). This may be only some of the ' feeders at the site, or it may be all of them, but there should be no port contention between the iaeders that want to transtr.it.1 The appropriate place for ^
contention in ERDS is between several sites that"vant to transmit at the same time, leading to the conclusion that the NRC PBX is the appropriate device for providing that contention.
(Actually, port contention capability in a stat mux could be useful in ERDS, for multi-feeder sites having more than one plant unit, to reduce the ,. .
number of ports to be dedicated (in the NRC receiving computer) to th l j
5-23 ,
)
i 4 ;
'n i
kf
\ ;h /
l' ,. ,
(
..t highest number needed Dr aiiy one plant unit. For example, without port l contention, a 6-feeder site would have 6 feeders permanently attached to its
! stat mux, and they would require dedication of 6 receiving ports at NRC Headquarters. With port /hontention and the knowledge that no more than 4 of the 6 feeders would ever transmit on behalf o!' a single plant unit, only 4 receiving pMts would have to be dedicated. We recommend this feature be conWdeM desirable but no'; required in stat mux procurement; it should be3 cor,sidered less valtlable than the " unbalanced rates" feature that will %
l prwide speed conversion. We will continuw to use 6 as the number of recEvirg
^ ports that must be dedicated to each stat mux.)
.j:
o, Thirdly, saler engineers for stat mux manufacturers are not prepyred to evaluate the feasibility of domplex proposals requiring non-stanqird interfacing involving computers, stat muxes, modems, and PBXs. They promote simple solutions, and. thery promote the sale of large stat muxes
~
which elin'inate the need for contention.
s- 2 We remain convinced that ERDS receiving fdllities at NRC Headquarters for rece,$ ting from multi-feeder sites should not require more than the number of bademe, stat muxes, or computer ports needed for the worst case design basis of simultaneous receiving (currd::tly one site, one modem, one stat
{
mux, and 6 computer ports), plus an 3dditional set of facilities for one worst-caso site (one modem, one stat' mux, 6Eomputer ports) to handle the improperly talkative site problem desertbed in section 5.1.2. The receiving faeliltles for multi-feeder sites will 2 ave to be separate from On addition to) those for 1-feeder sites, even if the same model of modems is used at both "
sets of sites, in order to avoid the expense' of unneeded stat muxes at the 1-feeder sites.
t 5.3 PROBLEMATICAL (SPECIAL-CASE) FEEDER $
( '
The survey encountered 12 feeders which, at the time of surveying, did not have a serial port nvallable for dedication to ERDS, but which could provide l
' an asynchronous feed if hardware were added to provide a new port. ,
l Except for the Babcock & ,Wilcax ' system discussed later in this section, the !
survey found no candidate feeders which lacked a serial port and could not have one added.
The survey encountered two special cases' of feeders that are likely not to
- s be ERDS-implementab'e within the data communications strategy described thus far. Their details will be described 'here.
Northeast tJtilities is a licensee thit' operates (or will operate) 4 plant units.
1 5-24 r
/
a P
, . j l
1 1
at Miihtone artd Haddam Ne:k. The selected feec'er for all these units is an l lBM c.alnframe at corporate headquarters which, as currantly configured, can generate only synchronous communication using SDLC protocol and l therefore cannot provide an asynchronous feed to ERDS. It it the only feeder encountered for which thi.t is the esse.
Because of tha uniqueness of this case, and the greater devel of specialized expertise needet to maintain and debug synchronous communication pictocols, we recommend that ERDS should not attempt to bring synchronous comraunication irito the Operations Center. Instead, ERDS .<hould acquire a stand-alone protocol converter ?. hat will listen to and talk to the feeder's SDLC interface and provide ERDS with a read-only asynchronous interface that looks like ever:*one else (i.e., with an MNP modem on the asynchronous side of the protocol ecnverter). A reasonable budgetary price for such a protocol converter at quantity-one retdl is $1500 (without a modem).
Babcock and Wilcox (B&W) has created a Mensee data system that goes by several names: "NUREG-0696 Data System" or "SPD5/ Recall System" or " Data Acquisition and Display System" It has a flexible ccinfiguration corsisting of several interconnected microprocessor-based computers, data recording capsbility, color grapMeh. for an SPDS display, and optionally some analog signal input capability. This system is used in the Emergency Response Pacilities of two 'icensees, Crystal River and Diablo Canyon. At another two
!!censees M is prtrent but not a candidate feeder.
There are twrproblems associated with its candidacy as a fecder at the two mentioned plant sites. Firstly, among all the Display Computers (one of the roles for the microprocessor-based computers) in the system conf!guration at Diablo CrAyco there are ao artilah!s serial !nput/ output ports and no
, possibility of adding any. ?nese CtampuC AS computers are 280-based products of Ithaco, Inc. that cannot be configtred Wth more than one board having 4 serial ports. Secondly, tne application sonware provided by Babcock & Wilcox transforms input signals (dimensionken 0-4095 ranged numbers) into data points with engineering units only for 4 user-selected groups of 10 data points each (which explains how it can accomplish this on a 280 microprocessor). This means that even if a port were available (as one is at Crystal River), the contents of the feed streut would not be dedicated to the ERDS paranieters but instead might var.v as the licensee users changed their focus of attention during an incidenL After analyzing the survey result.s, we contacted Babcock & Wilcox to inquire about the possibility of NRC s2 quiring some parts of the B&W system to serve as a feeder dedicated ';o ERDS for these two lleensees, and obtained the following infonnation:
5-25
4 One CompuDAS computer can be expected to handle the workload of transforming up to 64 data points (which is adequate for these plant units) if the update frequency needed is 10 seconds or more seldom and the only output device to be driven is a modem.
The serial ports in the compuDAS computer are software configurable for speed and communication parameters, support XON/XOFF flow control, and are otherwise normal-looking asynchronous input / output ports.
The only other hardware required from B&W is a Lear-Siegler ADM-31
" dumb" terminal, for control of the dedicated feeder system. However, hardware would also have to be added upstream of the B&W system to replicate, for the new system, the inputs now going into the existing B&W systems. This would create the possible need for repeating the !!censee's IE electrical isolation verification.
Custom software development by B&W would be required to create the new system.
Because B&W's on-going relationship is with the licensee, any request for a cost estimate or quotation would have to come from the licensee rather than NRC.
In the absence of any cost information from B&W or licensees, we estimate the cost of a newly acquired feeder to be $150K for each plant site, not including the costs of NRC, ERDS implementation contractor, and licensee staff time that would be needed to set up a custom system development effort through a contractor / NRC / licensee / B&W condult.
5.4 INITIATING THE CONNECTION: COMMUNICATION FACILITIES FOR ERDS We began this project with the understanding that we were to consider the possibility of ERDS using the public switched telephone network to provide the long-haul communication channel from sites to the Operations Center. ;
We have concluded that this possibility is not viable. The possibility of congestion in the telephone central office nearest a plant, arising from high calling demand from people in the area of the plant .means that straightforward dlaling from the plant into the public network cannot be relled upon to provide the channel. Although it can be assumed that the ERDS connection would be made before public awareness led to saturation of public telephone switching facilities, there la the possibility that the ERDS connection would be lost and have to be re-dialed.
5-26
l We considered the possibility of using.the corporate telephone network of a licensee to obtain a dial tone from a central office that is geographically distant from the plant. The strategy would be to have a sequence of dialing attempts, through various central offices reachable by the corporate network, programmed in an NRC-provided computer. The survey found that this strategy would require special administrative arrangements with the telecommunication departments of many of the licensees, and in some cases would require custom programming of a licensee's. PBX system. We concluded that the complexity and site-specificity of the arrangements made ]
the strategy unrealistic, particularly since it could not provide certainty of being able to escape congestion in the public switched network.
Our conclusion is that the long-haul communication channels for ERDS must
' be available without reliance on the public switched network. A separate related conclusion from the site surveys is that human intervention at the site should not be needed in the establishment of the connection. This leaves a variety of possibilities: ;
i
- dedicated telephone lines, directly to sites or through regional hubs; 1
- various means of sharing the ENS lines: data over voice, time-division 1 multiplexors, intermittent interruptions of the voice channel; j l
satellite-implemented channels.
l l
Intermittent interruptions of the ENS voice channel, although technologically feasible, are considered by NRC to be an unacceptable degradation of the usability of the ENS for voice conversations. All the other possibilities are functionally acceptable alternatives for providing 2400 bits /second data channels. Besides that baudrate capacity ERDS requires only the functional )
equivalent of 2-wire leased voice-grade lines, capable of being tarminated on !
a voice PBX at NRC Headquarters, and capable of transmitting audible dial I tone from the FBX and audible dialing tones from remote auto-dial modems.
We are aware that NRC is in the process of initiating changes to the telecommunication facilities that provide the ENS. The requirements for ERDS have been completed with a strategy targeted for unconditioned voice-grade channels that includes these elements:
- a. Each feeder will communicate with a local modem or statistical multiplexer at 2400,1200, or 300 bits /second asynchronous.
l 1
5-27
l l
1
- b. All long-haul communication will occur at 2400 bits /second, asynchronous for 1-feeder sites and synchronous for multi-feeder (stat mux) sites.
- c. The modems or stat muxes will provide data transmission error detection and correction on the long-haul communication channels.
- d. Speed conversion features in the modems and stat muxes will allow feeders transmitting at 300 or 1200 to talk to ports in the ERDS receiving computer that operate at 2400 bits /second asynchronous.
NRC may have the option to acquire telecommunication channels that can provide digital data communication. In that case, DSU/CSU devices (Data Service Unit / Channel Service Unit) would be required instead of voice PBX station ports or modems at the ends of each long-haul channel. Although I these devices are simpler and less expensive than modems at speeds of 4800 bits /second and above, it may not be possible to find models that provide the error correction and speed conversion features required for the strategy described above. Also, avoidance of the need to dedicate a receiving port (in the ERDS receiving computer) to each feeder will require another device, such as a data PBX. capable of providing contention among digital channels.
In short, many facets of the above-described strategy would not be applicable.
j In considering the possibility of ERDS feed channels being piggy-backed on new ENS telecommunication facilities, which would link NRC Headquarters with all plant sites, NRC should keep in mind that this project's plant survey selected feeders with the goal of minimizing the number of feeders needed by a licensee for all its units. This goal led to selection of feeders at corporate headquarters sites, not plant sites, for these 4 licensees:
Commonwealth Edison, Duke Power, Northeast Utilities, Philadelphia Electrie.
With the assumption that ERDS connections will use a dedicated channel not available to the public, the need for log-in becomes less crucial. The i survey activities in the project left the impression that some licensees w!!! l want a programmed handshake between NRC and licensee computers as a form of authentication, so ERDS should have the capability to do this as l part of connection initiation. The important point, though, is that with dedicated ERDS channels, feeders which cannot support a log-in are not a '
problem.
5-28
5.5
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS These are selected highlights of the conclusions and recommendations presented in this chapter:
(6.1.1) All data points received by ERDS should be denominated in some engineering unit, not a voltage or current or other transducer output representing a digitized sensor reading. ERDS should not replicate the software maintained by licensees for converting transducer output into engineering units.
(5.1.1) All data point values received by ERDS should be formatted character strings, not feeder- specific internal binary representations of numbers.
(5.1.1) The data receiving software in ERDS should include one or more
" number recognizer" modules, each able to parse a variety of different character-string representations of numbers. Each should tolerate variations which do not affect meaning to a human reader, such as embedded blanks, leading zeroes, optional "+" signs, absence of a decimal point and fractional digits, absence of a power-of-ten multiplier. More than one such module will be needed only if incompatible variations in the representations of numbers are discovered during ERDS implementation; if so, the recognizer module to be used should be a predetermined attribute of a feeder.
(5.1.2) Except for a notification that initiation of transmission has successfully completed ERDS should not require feeders to recognize or respond to inputs from the NRC side of the licensee /NRC interface.
(5.1.2) ERDS should be able to receive transmissions using either ASCII or EBCDIC character codes, with the choice specified as a predetermined attribute of each feeder.
(5.1.2, 5.3) ERDS should be designed to accept only asynchronous transmissions from feeders. For the one feeder that can only provide -
synchronous communication as now configured, a protocol converter that converts it to asynchronous should be placed at the site. I (5.1.2) For each 1-feeder site ERDS should use a 2400 bits /second asynchronous modem that provides transmission error correction.
(5.1.2, 5.2) For each multi-feeder site, ERDS should require the licensee to bring the asynchronous feed streams (one per feeder) into one room at 5-29
the site. ERDS should then use a statistical multiplexer to transmit the multiple streams with error correction on one communication channel to NRC Headquarters. The modems between the stat muxes should be 2400 bits /second synchronous.
(5.1.2, 5.2) The modems used for 1-feeder sites should include a speed conversion feature, to allow a feeder to transmit at 300 or 1200 bits /second while the port of the ERDS receiving computer operates at 2400. The stat muxes used for multi-feeder sites should include a similar feature to provide the same capability. Licensees should be offered the choice of 300,1200, or 2400 for each feeder but should be encouraged to select 2400 bits /second.
(5.1.2) The ERDS receiving computer should be able to receive the worst case number of multiple streams from a plant unit (4) at the ' nominal transmission speed (2400 bits /second) without use of XON/XOFF to ask the sender to pause.
(5.1.2) Licensees should be encouraged to provide feeder ports with modem control logic (RTS/ CTS handshaking). If a feeder offers no flow control possibilities (RTS/ CTS, XON/XOFF, or ENQ/ACK) to the modem or stat mux that connects to it, the stream-generating software in the feeder may have to include special provisions to avoid overrun of the modem or stat mux.
- (5.1.2) The error-correcting modems used for 1-feeder sites should include a buffer of at least 2K bytes. Capacity up to 3K bytes is preferable.
(5.1.2) With a design basis of handling transmissions from only one plant unit at a time. ERDS receiving facilities at NRC Headquarters should establish contention among plant units to avoid the need for receiving hardware (modems, stat muxes, computer ports) dedicated to each plant unit and feeder. If one dedicated communication channel from each feeder site comes into NRC Headquarters, the recommended approach for providing this contention is to terminate each channel as a station on an NRC-operated voice PBX, using dialing within the PBX by auto-dial modems to seek connection to a limited number of receiving stations. j l
(5.1.2, 5.2) The modems for all feeder sites shouW have auto-dialing capability, with the phone number held in non-volatile storage and the dialing able to be initiated by a signal (logical state transition) on one V the RS-232C control wires (e.g., DTR). For 1-feeder sites, the modems could also offer command-initiated dialing: then the licensee should be allowed to choose between signal-initiated and ' command-initiated dialing.
5-30 i
- D
- (5.2) At multi-feeder sites, the preferred approach for initiation of dialing would allow any feeder to generate the triggering signal on its designated RS-232C control wire, with a custom-built hardware box generating the 1 logical OR of these wires from all feeders for input to the modem. If implementation design cannot achieve this, one feeder at each site would be assigned responsibility for generating the triggering signal. (
- (5.1.2) Software in the ERDS receiving computer should assist in mediating '.
contention for the auto-answer receiving stations, to prevent misbehaving -
feeders from tying up the receiving ports. The recommended approach I requires one extra PBX station + modem + computer port, a l PBX-implemented hunt group for.all receiving stations, a user-maintained I list of eligible caller sites, and ability by the software to hang up on an ineligible caller. Each feeder should be programmed to repeatedly retty !
dialing until it successfully establishes communication.
- (5.1.2, 5.2) All feeders' serial ports should be configured to use asynchronous communication parameters matching those used in the receiving computer's ports: 8 data bits per character, without an additional parity bit, and 1 stop bit. For feeders using ASCII code, the high-order bit of each 8-bit character should be zero (i.e., " space" parity).
- (5.1.3) Licensees should be encouraged to create feeder software that generates update sets which are custom-formatted for ERDS, containing only the data points that NRC wants to receive. See section 5.1.3 for details of the recommended formatting.
- (5.1.4) ERDS should be able to accept data from feeder software that does not transmit the ERDS-preferred stream format, but only if ERDS can construct the ERDS-preferred stream format from the contents of the.
received stream, together with predefined " cut-and-paste" instructions and predefined literal strings. The cut-and-paste instructions would use a row-column coordinate scheme to identify contents to be extracted from the received stream.
- (5.1.4) In case feeder software needs periodle inputs from ERDS to trigger the generation of output to ERDS, ERDS should be able to transmit a licensee-specified fixed string of characters at a licensee-specified fixed periodicity, independent of the rate or content of what ERDS receives.
(5.2) Port contention capability in stat muxes is not appropriate for providing the desired contention between plant units trying to transmit, 5-31
i I
I but it is -desirable because it allows NRC to reduce the dedicated number of receiving computer ports (per stat mux) to the largest number needed .i for any one plant unit, instead of the largest number of feeders at any I one feeder site.
.(5.4) The long-haul communication channels for ERDS should be available -
without reliance on the public switched telephone network. The 4 implementation can use any channels which provide the functional I equivalent of 2-wire leased voice-grade lines,' capable of being terminated ~
on a voice PBX at NRC Headquarters.
'i u
i I
l 1
1 I
l I
l 5-32 l l
j i
o 6.D DATA POINT LIBRARY. CONCEPT AND IMPLEMENTATION Section 4.4 introduced the concepts and important definitions associated with the need for plant-descriptive data to be stored in ERDS. This chapter i expands on the concept of the Data Point Library and presents i recommendations for its implementation, i
6.1 DATA POINT LIBRARY CONCEPT l
With or without standardization of computer points, there is a need for either a hard-copy or ERDS-resident site-specific database which expands upon the basic information in the typical data point dictionary. There will be a need for NRC personnel to have access to information such as engineering conversion factors P&ID-type information (Piping and Instrumentation Drawings) indicating the location within systems from which data points originate, setpoint data, normally expected ranges of point values, etc. There was not a heavy emphasis on the collection of this type of data during this project's site survey process, but site-specific examples of this engineering and system data weie collected at many plants. It will be far better to collect the remainder of this type of data as ERDS is implemented than to expect to look it up or receive it from a specific licensee during the course of an incident.
{
As previously discussed in section 3.7, the recommended ERDS design will not include the standardization of data points as to format or engineemt ]
i units among the population of nuclear power plants or even among plants of j the same type (PWR, BWR). The data will be displayed in the Operations l Center with the same value and time stamp, and in the same engineering )
units, as it is accumulated by the plant's Emergency Response Team at the scene of the incident. This requires that the Operations Center personnel adjust their thinking to accommodate the plant in trouble, functioning in l terms of that plant's unique design and communicating with the plant's l Response Team in the latter's own unique engineering and operational
" language".
The data stream received by ERDS, by itself, will not convey all of the necessary information for the Operations Center personnel to effectively function in their supporting role. The Operations Center teams must have rapid access to additional information which relates the data to both the plant's design and to the manner in which the plant's team utilizes and reacts to the data. Providing this information is the function of the ERDS Data Point Library ("DPL").
l 6-1
i i
The Data Point Library 'is-conceived as an ERDS computer-resident, plant-unit-specific, text-oriented, descriptive database which is. readable on-line by Operations Center personnel. Each data point will:have a' Data Point Library " Reference Sheet". The Reference Sheet contents will be formatted for. the convenience of the _ user. _ Any or. all' of the Reference -
Sheets for a given reactor unit can' be displayedor printed on request.
The implementation may elect to ' confine' access during an incident to 'only the Reference Sheets for data points of. the plant unit that is the subject of the incident. Reference Sheets'E contents should be changeable (editable) during an incident by a limited group of authorized users, possibly with.the limitation of only one at a time: changes 'made should become visible to all users after the change-making operation is completed.
Replacing the concepts of computer-implemented standardization, normalization, and engineering unit conver,sion 'with an ERDS-res.ident Data Point Library concept will achieve several " low tech" but highly beneficial-purposes including:
The DPL concept will shorten the time required to implement each new -
reactor unit added to ERDS during implementation.
The DPL concept will benefit the newest' members of'the' NRC Response l Teams most by providing a readily accessible explanation'.of.the unique-data set being received during an incident. It is assumed that' NRC will continue with the concept of three Response Teams consisting of available '
specialists in each discipline and that a full range of experience could be represented on any one team. For data points which lacif self-explanatory descriptions or which are presented in ambiguous engineering unite, the DPL concept will require Response Team members to access the DPL Reference Sheets which, as a byproduct, will convey additional important plant system information to the user. This forced access to explanatory information should reduce the ~ need for initial' system-oriented, information-seeking calls to a licensee. The reader should not construo ,
this discussion to mean that all data presented will be confusing to the l NRC. Over 80% of the data points selected' during the survey will be l meaningful and unambiguous to an experienced nuclear engineer or health physicist in their plant-specific form.
Implementing the DPL concept in no way precludes the later addition' of automated conversion and manipulation of ERDS data points. ' The DPL-concept in fact replicates the first step that would be required in any-implementation of automated data point conversion. The text version of-conversion factors which will reside in the DPL' provide the basis for 6-2 1
i t________ _ _ _ _ _ _ . _ _________________________m______ __ _ . . _ _ . _ _ _ . _ _ _ . _ _ _ _ _ _ _ _ _ . _ _ ___._...___b
4 -a i
a developing software algorithms to perform automated conversion of data.
Implementing the DPL concept will force the development and fine-tuning of procedures for periodic updates of DPL-held information, thereby addressing issues of configuration management, with some flexibility
.provided by the fact that the DPL is text to be used only by human eyes, rather than (the greater rigidity of) data to be used by computational software. Implementation of automated data point standardization should !
not be attempted until the difficulties of maintaining a text-based DPL have been confronted and, to at least some extent, surmounted.
6.2 DATA POINT LIBRARY CONTENT AND USE l Upon user request, the Data Point Library will immediately display the data point identifier, description, engineering units, range, alarms and/or technical specification limits, engineering system data, etc. associated with the point.
Because the points selected for transmission to ERDS are indicative of plant
" health" and associated with critical Safety Functions, they are the indicators which the plant's Response Team uses to determine the proper actions to take to mitigate an incident. Where required and useful, the Data Point 1;ibrary will present textual information to the Operations Center user to provide information supplementing the point's value, which will be useful in understanding how the Plant Team interprets the data. For instance, associated with a transmitted data point representing reactor vessei level, the Data Point Library should contain the physical zero reference point, conversion factor for height above top of active fuel, type of detectors, effects of running reactor coolant pumps, effects of cold calibration, effects of elevated containment temperature, etc. Associated with a reactor water storage tank level transmitted as a percentage should be the capacity of that tank in gallons, number of reactor quality water storage tanks at the plant site, zero reference point, conversion factor from percent to gallons, etc.
The Data Point Library will be particularly useful to the Operations Center user when evaluating the plant's actions in predicting off-site radioactive releases. The ERDS survey shows that there are wide disparities among plants in the methods of computing release rates and the types of data used in these computations. Associated with an effluent gaseous release data point expressed in CPM (a less than desirable engineering unit), the Data Point Library Rcterence Sheet should indicate the assumptions regarding isotopic mix, the current calibration factors of detectors, the discharge point 6-3
or points for monitored releases, expected stack flowrates under various fan combinations, and any default values used by the Plant Team in their calculations.
The information for the Data Point Library should be gathered during the ERDS implementation phase. The ERDS survey results provide approximately 50% of the data needed for the Reference Sheets. The remainder of the information to be included should be collected from existing databases and by quallfled personnel involved in the implementation. A suggested format for the Data Point Library Reference Sheet is contained in section 6.3 and specific examples are provided in the discussion of displays in section 8.7 of this report. An enhanced form of the DPL Reference Sheet format should be the instrument on which DPL input data is collected during implementation and should also serve as the primary instrument for the submission of periodic DPL updates. (The enhancements should include typical good practices of paper form design, such as explanations of acceptability criteria for specific fields, instructions for stylistic conventions regarding uppercase and spacing, printed boxes for solicited answers that show character count limits, etc.) DPL updates are recommended annually and upon the occasion of changes to licensee data point sets.
6.3 DATA POINT LIBRARY REFERENCE SHEET STRUCTURE A recommended structure for the individual DPL Reference Sheets is provided in this section as Figure 6- 1.
6.4
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS These are selected highlights of the conclusions and recommendations presented in this chapter:
(6.1) Data Point Library Reference Sheets' contents should be changeable (editable) during an incident by a limited group of authorized users.
(6.o Enhancement of ERDS to provide ERDS-computed data point standardization should be deferred until the difficulties of maintaining a textual DPL have been confronted and, to at least some extent, surmounted.
(6.2) Information for the Data Point Library should be gathered during the ERDS implementation phase. i
.6-4 o _ _ _ _ _ _
TIGURE 6-1 DATA POINT LIBRARY REFERENCE TILE REACTOR UNIT: LAST UPDATED:
NRC ERDS PARAMETER: POINT ID:
PLANT SPECITIC POINT DESCRIPTION:
GENER!C POINT DESCRIPTION:
MIN INST RANGE: MAX INST RANGE: ENG UNITS:
ZERO REF:
REFERENCE POINT NOTES:
ENGINEERING UNIT CONVERSION:
PROCESSED / DISCRETE: 'f SENSORS: HOV PROCESSED:
LOCATIONS SENSED:
ALARM SETPOINTS:
l TRIP / AUTO INITIATE SETPOINTS:
UNIQUE SYSTEM DESCRIPTION:
l NOTE: THIS DATA POINT LIBRARY TILE IS AN 80 CHARACTER BY 44 LINE FORMAT 6-5
7.0 USERS AND USTj OF ERDS-ACQUIRED DATA l
A project for NRC was completed u 184 which studied the data acquisition and display needs of the Reactor SWty Team in order to characterize a Reactor Safety Analysis and Display System (RSADS)- The conclusions of ,
that project formed the starting point for the recommended design of the ERDS display facilities and for other uses of data in ERDS. The process involved a comparison of the design criteria for each system, the elimination l of features which were not common to each system, and the addition of l requirements unique to ERDS. The details of this effort will not be i discussed in this report. l I
j 7.1 ERDS DESIGN CRITERIA 1
The following ERDS design criteria are the bases for the recommended )
capabilities and requirements for ERDS facilities at the Operations Center. I
- a. ERDS will be an electronic data link to licensee computer systems employing modems and voice grade telephone lines.
- b. The maximum ERDS data set will consist of approximately 70 computer points, with update frequencies no more often than every IS seconds.
- c. ERDS will have online (random-accesr) storage capacity for at least 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />' worth of incoming data. All incoming data will be saved
(" archived") on an offline permanent m Achine-readable storage medium, to be available for post-incident analysis. For longer-lasting incidents when data exceeds online storage capacity, alder data can be deleted (" purged")
from the online storage medium (after archiving). There is no need to l restore purged data to online media until after ERDS data transmission for l an incident has stopped (i.e., until the 11censee has entered the Recovery )
Phase of the incident). '
- d. ERDS will provide menu-driven access to Parameter versus Time and i l
Pressure versus Temperature plotting capability without regard to the fact '
thr.t such features may be duplicated on other Operations Center systems (e.g., expert system).
- e. ERDS will present data in the same format and in the same engineering units as used at the Plant being monitored.
7-1
- f. ERDS will store and display the validity (where available) of the data it receives from the licensees' feeders.
- g. ERDS will have a manual data input capability.
- h. ERDS will allow for the training of system users including the entire Incident Response Center. This capability will include the ability to load an accident scenario (parameters) in the ERDS computer to permit running, stopping, and resuming the " scenario" in simulated real-time for the Incident Response Center and/or any other desirous peripheral users.
Licensees should be encouraged, during their onsite software development efforts. to make drill and exercise data sets loaded in site ERDS feeders -
i transmittable to the NRC.
l l
- 1. ERDS will be capable of time-tagging data based on time of data, not time of data entry.
- j. ERDS will be capable of storing a site-specific, text-oriented descriptive library which is data-point-oriented to assist the Operations Center users in coordinating their activities with the site.
- k. The initial ERDS implementation will display each plant-specific data set using a limited number of standardized tabular display formats.
- 1. The computational resources for ERDS data retrieval and data display.
functions will support the following list of independently acting users:
1 l -
PMT DIRECTOR PMT DEPUTY DIRECTOR & TEAM RST DIRECTOR RST DEPUTY DIRECTOR & TEAM ONE ELECTRONIC STATUS BOARD FOR THE RST (NRC HQ)
DIRECT CONNECT TO IDAS (may be in same computer)
DIRECT CONNECT TO EXPERT SYSTEM REGIONAL BASE TEAM (assume 1 multi-tasking mini or micro)
REGIONAL SITE TEAM (assume 1 non-multi-tasking micro) 3 ADDITIONAL REMOTE USERS TOTAL NUMBER OF INDEPENDENT USERS = 12 I
7-2 l
-__A-_---_____ - _ - - _ _ . . . _ _ _ _ _ _ _ _ _ _ _ - _ - _ _ . _ _ _ - _ - _ _ _ _ _ _ _ _ _ _ _ . _ _ _ - _ . . . - - - - _ _ . . . - - . - - _ _ - _ _ - - - . _ . - -
)
7.2 FEATURES SPECIFICALLY EXCLUDED'FROM ERDS DESIGN CRITERIA
- a. ERDS initial implementation will not include a provision for superimposing parameter data on fluid or electrical schematics.
b.. ERDS initial implementation will not consider a custom logsheet display for each of the approximately 120 reactor units. However, the tabular displays will contain a degree of standardization through the use of the following techniques:
- Each site-specific computer point selected for transmission has a daughter-parent (s) relationship to one (or more) ERDS parameter (s). '
These relationships will be shown in ERDS displays.
- A generic set of BWR and PWR Critical Safety Function (CSF) groupings of parameters have been recommended for the tabular displays. These CSF displays will show the generic parameters, supported by their daughter site-specific computer points.
Licensee feeder-specific quality tags will be received by ERDS and converted to standardized quality tags for display.
- c. ERDS initial implementation will not support the writing of data to machine-readable input files for use by calculational models (e.g., mass j balance equations), i 7.3 MANUALLY INPUT VARIABLES. PREDETERMINED AND ADHOC Footnote 1 of this project's Statement of Work (its section C.1.1.2.1) discusses the fact that the parameter data not available electronically from licensees will be relayed to NRC by voice. The footnote words, "... It is felt that the addition of one or two additional parameters can be accommodated by the voice line without unacceptable degradation of reliability," are interpreted to imply that NRC would want to manually insert these voice-transmitted points into the ERDS database. The capability to insert these U by-voice data points >> from each plant can be accommodated relatively easily by storing in advance in ERDS a point descriptor (i.e.,
identifier, description, engineering units, and value range) for each of these data points, identical in structure and function to those that will be pre-stored for electronically transmitted data points.
The survey results highlight the parameters for which computer points are l
" missing". If an ERDS parameter had no associated data points available at j 7-3 1
the time of the surveys, the surveyor moved on to the next parameter without exploring the analog devices measuring a parameter. During ERDS implementation, the analog instrumentation that will be used as the source of -
the by-voice points for each plant must be determined and a corresponding data point descriptor created in the NRC ERDS data host.
To fulfill NRC's desires to input by-voice data points to ERDS, the capability is included in the ERDS requirements. The software design for inputting known by-voice data (the word "known" is important here and implies a predetermined data point) should be developed such that manual input is menu-driven and that the values can be stored, retrieved, and displayed in the same manner as electronically _ transmitted values (except for their much slower update rate).
A potentially useful extension of the concept of by-voice data points is the capability to input variables of interest, not predetermined, which are specific to the incident in progress. The following examples are provided to clarify this concept:
Had ERDS been available during the incidents at Three Mlle Island and Browns Ferry, in addition to tracking, archiving, and analyzing the computer points available under the ERDS Parameter List, it is believed that NRC may have found it desirable to be able to input the following additional types of parameters to ERDS:
I
= PORV position
= Containment Sump Pump flow
= Several Auxillary Building Area Radiation Monitor readings
= Quench Tank level
= Reactor Building Area Temperature Monitors
= Major 4160 and 480 VAC Electrical Bus status / voltage
= Fire Suppression Header Pressures
= Equipment IN Service /OOS Status While many of the parameters suggested above are on/off or data logging in nature, the value of an electronic logging of such data is obvious. Allowing ERDS to receive the manual input of by-voice data points representing l
7-4 !
i
parameters not contained in the ERDS Parameter List is a capability which we believe NRC should consider.
The capability for ERDS to accept the manual input of incident-specific U adhoc by-votee data points >> (not predetermined) can most easily be prov.ided by creating (before an incident) a fixed number (approximately 10) of " wild-card" data point descriptors. Their pre-assigned point identifiers should be a simple scheme, not likely to replicate any licensee data point identifiers, such as ADHOC01, ADHOCO2 .... ADHOC10. (Because the data point descriptions, not identifiers, are expected to be the vehicle for conversation about data points during incidents, the actual licensee identifier of an adhoc data point need not be obtained during an incident. It is possible that some adhoc data points will even not have formally designated licensee point identifiers.)
Upon NRC's decision to track a non-ERDS parameter, one or more of the ADHOCxx point descriptors would have to be made ready by a user who fills in the point description, engineering units, and range. Only after that explicit make-ready operation would ERDS allow an adhoc by-voice data point l
to receive manually entered values or be used in data displays.
l Requirements elsewhere in this report specify that each use. of a data point .
description in user interface or data display functions should show its parent parameter (s) to supplement the conveyed meaning. To allow consistency in implemented software, all adhoc by-voice data points should be considered daughters of a dummy parameter such as "ADHOC".
ERDS should allow the creation and changing during an incident of a Data l Point Library Reference Sheet for each adhoc by-voice data point, but this activity should not be necessary as part of the make-ready activities that must be performed before values can be entered. If the implementation lets a DPL Reference Sheet pre-exist (without content) for each pre-existing (without a description) ADHOCxx data point, the function of filling in these Reference Sheets' contents should not neEd any special operations besides those available for incident-time editing of pre-existing contents of Reference Sheets for predetermined data points.
l 1
Even after a DPL Reference Sheet has been filled in for a new adhoc by-voice data point, it should be expected that woYd-of-mouth exchanges among users will be the primary means for users learning about its meaning and purpose. We do not recommend that ERDS provide anything beyond the DPL Reference Sheet for the purpose of supplanting these human exchanges.
7-5 l
1 I
l 7.3.1 Input and Display of Manually input Variables The predetermined by-voice variables discussed above should be input from an ERDS menu whose content is pre-established, based upon the reactor-unit-specific set of predetermined variables supporting the ERDS Parameter List. Each licensee should be given a copy of its unit-specific set (s) (one set per plant unit) of predetermined by-voice data points, to maintain in its primary ERFs. This would reduce the time involved in fine-tuning the desired voice update set during an incident.
The ERDS mechanism for manual entry of by-voice parameters should require that the user provide t'he time tag associated with the update set of 4 voice-received values. Licensees' voice update sets typically consist of variables which were all scanned (by humans) within a small time interval (typically 1 minute or less). It is important that the NRC data keyer be trained to input the time of the update set scan, not the time of receipt of l the update set over the phone (typically 5 to 10 minutes in the past). The input mechanism should allow the input of only some (versus all) of the predetermined points..
Aftet input, the new by-voice data point values would be available for display (intermingled with electronically transmitted values) on the CSF tabular displays, user-defined tabular displays, and trend plots. The manually input points should not be available for P vs T plots, since the time tag of the Pressure or Temperature may vary from the electronic time tag of the Pressure or Temperature against which it would be plotted (see further explanation below). The tabular and trend-plotting features recommended for ERDS will display data based upon "most recent values received" and should not present a problem when the by-voice points' time tag varies from the electronically transmitted set. All by-voice values will receive a standardized quality tag of " Operator-inserted" to alert the user that values were human-provide and may only be updated every 10-15 minutes.
The adhoc by-votee data points should have a separate, dedicated input menu similar to that described above for the predetermined by-voice points. l The major difference in the menu will be that the points will need to be l assigned a description, engineering units, and range on the first pass l through the menu. Additionally, the adhoc points' input menu should allow the user to add and delete data points from the set of currently inputtable adhoc by-voice points. The user should be allowed to edit ,the previously entered contents of description, engineering units, and range fields, but the user should be warned that ERDS data display functions assume unchanging meaning for a single data point over the life of an incident (i.e., all its 7-6 1
A
i i
'i values are assumed to be commensurate).
Like the predetermined by-voice points, the adhoc points should be available for display, but on a separate tabular display rather than on one of the ]
pre-established CSF displays. The formatting of this adhoc display should j be automatically performed,' based on the values input to ERDS having time -
stamps within the user-specified time range of interest. Adhoc points should be available for trending (if numeric), but not for P vs T plots.
The reason that manually input variables (both predetermined and adhoc) are not recommended for use in P vs T plots is as follows: In a case where temperature and pressure.are decreasing (a typical case.during transients when ERDS would be activated), assume that temperatures are arriving at ERDS electronically and that pressures are arriving by voice. There will be a natural tendency for licensees to pass (and NRC data keyers to enter) a time tag which is later in time-than' the actual time the data was . scanned at the plant (e.g., NRC data keyer mistakenly enters time of receipt' of data versus the time licensee states as the data collection time tag). In this-example situation, plotting an accurately time-tagged, electronically transmitted temperature against a manually. entered, time-late pressure would result in a' P vs T plot showing a larger subcooling margin than:what actually exists. If you reverse pressure and temperature .in the above example, the result is a display indicating less subcooling than the ' actual, or even a false indication of a superheat situation. . It is .not reasonable to believe that these misleading situations can be prevented by j software-imposed limits, such as only plotting points with time tags falling within a 1-minute time band. ,
I 7.4
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS-These are selected high!!ghts of the conclusions and recommendations !
presented in this chapter:
. - 1 (7.1) ERDS should have online storage capacity for at least 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />' ,
worth of data point values. All data will be archived .to an offline permanent machine-readable storage medium, for post-incident analysis. l When data exceeds online storage capacity, older data can be deleted from l the online storage, without need for an ability to restore it during the - )
incident. l l
- (7.1) Licensees should be encouraged to create, in their feeder software, !
an ability to transmit to ERDS the drill and exercise data sets' they load ;
into their plant data systems.
1 7-7 I
(7.1) ERDS should provide data retrieval and data display functions for 12 independently acting users.
(7.3) ERDS should allow authorized users to manually input timestamped values obtained orally for predetermined data points (representing ERDS parameters but not available by electronic transmission from licensee data systems) and for adhoc data points (not representing ERDS parameters but which emerge as important during an incident).
(7.3) ERDS should allow authorized users to create during an incident all forms of plant-descriptive data describing an adhoc data point which would pre-exist for a predetermined data point. ERDS should require an authorized user to create a data point descriptor for an adhoc data point before allowing manual input of values.
(7.3.1) Each licensee should be given a copy of its unit-specific set of-predetermined by-voice data points, to maintain in its primary ERFs. This would reduce the time needed to fine-tune the desired voice update set during an incident.
(7.3.1) The mechanism for manual input of values should employ the concept of an update set (values for a set of data points, all sharing the same timestamp). The manually input timestamp should be the time of scanning of instrumentation by plant staff.
(7.3.1) Manually input values should be available for all data display functions except Pressure vs Temperature plots.
(7.3.1) Manually input values should all receive the same system-defined standardized quality tag, which indicates the presence of humans in the creation of the value.
7-8
8.0 FUNCTIONS. REQUIREMENTS. AND FACILITIES FOR DATA STORAGE AND INTERFACES TO USERS This chapter describes the functions and facilities of the Operations Center part of ERDS, from a computer systems perspective. The chapter begins with the receiving of transmissions from a feeder site during an incident.
The transmitted data undergoes initial processing and is stored in a database facility. The database facility provides data retrieval functions to data consumers, who are humans looking at the data, software creating displays for users, and software that is using the data as input for computations. Section 8.7 includes details of data display requirements.
8.1 INCIDENT-TIME RECEIVING AND STORAGE OF DATA The requirements and design of these functions are necessarily dependent on aspects of the final design of data transmission facilities 'and the composition of the data feed streams. The conclusions and recommendations presented in this section are thought to be consistent with the recommendations in earlier chapters (particularly 4 and 5).
If the site ends of the ERDS communication channels use mul'tiplexo'rs at multi-feeder sites, the NRC end will need multiple receiving ports capable of s receiving concurrently, enough to accommodate the highest number of feeders at a site (found in the survey to be 6). Sections 5.1.2, 5.2. and 5.4 i discussed the issues of how communication channels arrive at a receiving computer port in the Operations Center. Based on the recommendations in those sections, the NRC receiving computer will need (to be able to receive data from at most one plant unit at a time):
2 ports, each with a 2400 bits /second asynchronous auto-answer MNP-protocol modem, dedicated to the 1-feeder sites.
2 sets of 6 ports, each with a statistical multiplexer and a 2400 bits /se:ond synchronous auto-answer modem, dedicated to the multi-feeder l sites. ]
j ability of ERDS software to force hang-up of the line coming into any modem and re-initialization of the modem to ready-to-answer state. (See section 5.2 for description of how this can be accomplished with the i statistical multiplexors' modems by routing a port's DTR' signal around the !
side of the multiplexer; forcing a modem to hang up when DTR goes false ,
l 8-1 ,
1 l
l - - - - - _ _ _ _ _ _ _ _ _ _ - -
_ = - _ - _ _ - _ _ - _ _ _ - _ _ - - -
is a commonly found feature of modem behavior.) i l
All further discussion in this section will talk in terms of a single data stream being received.
The incoming stream must be received and stored faster than it arrives, because a substantial number of feeders have no software support for XON/XOFF (receiver-initiated) flow control (see section 5.1.2). This implies that the design should employ a storage buffer (main memory or disk) j between receiving and << reception Drocessinst >> the processing needed to i prepare the received data for long-term storage and retrievability.
The incoming stream, as received and buffered, should 'be permanently saved l by ERDS, to allow posthoc diagnosis and finger-pointing about misunderstood -
transmission format conventions and other problems that may show up in ,
reception processing.' However, we do not believe there is a need for formally archiving this version of the data, or for keeping it beyond the 4 period of incident / exercise posthoc problem-solving, or for tools to display f
this data to anyone other' than system maintenance staff.
Once the connection has been initiated, the recommendations in section 5.1.3 for custom-generated ERDS feed streams do not require the Headquarters end of the ERDS link to itself do any talking. The recommendations in section 5.1.4 for pre-existing stream formats suggested the possibility of offering to transmit a pre . stored (licensee-specified) fixed string of enaracters periodically (every N seconds,11censee-specified), independent of the rate or content of what NRC receives. To do this would require only a
" broken record" output process with a periodic wake-up timer.
As currently envisioned, reception processing comprises the following basic sequence of steps:
Check that the transmission length in the trailer matches the number of characters received. If it does not, throw away the whole transmission and report that the hardware-level error protection is not working.
Extract and parse the timestamp for this update set, from the header of the transmission. Convert it to plant site time (see section 4.3).
Delimit within the stream the inputs constituting each data point value (point identifier, value string, and quality tag value).
Do the remaining steps for each data point value in the update set.'
8-2
~
c <
l l
- Check that the point identifier is within the set expected from this feeder. i If not, there is a surprise.
i
- Convert the value string to internal representation, using the value recognizer declared by this feeders initialization packet.
I Standardize the quality tag value (see section 4.2).
- Store the resulting value and quality tag in a permanent storage container determined by the point identifier. The timestamp of this update set must somehow be associated with each stored value. Each data point value should be able to have its own timestamp, to allow the possibility of different update frequencies for different feeders (or for different data points on the same feeder).
- Trigger all actions which need to occur upon availability of a new value I I
for this data point (e.g., computing standardized variables, notifying data consumers).
It is desirable, for efficiency of reception processing, for stream formats to be structured in a way that allows reception processing to proceed front to back through the stream, rather than being driven by a stored list of data points to be found and processed. However, this is not mandatory, given the assumption that the stream representing an update set will be buffered.
Stream formats will necessarily be feeder-specific, so reception processing will require feeder-specific knowledge. The recommendations in section 5.1.3 sought to make the ERDS-preferred (custom-built) stream format self-documenting, with some consideration for minimizing the overhead due to unchanging content. The recommendations in section S.1.4 for pre-existing stream formats did rNulte a set of pre-stored " cut-and-paste instructions" and definition of row terminator characters, so there will have to be a feeder-indexed storage file for these.
8.2 STANDARDIZED AND OTHER ERDS-COMPUTED DATA POINTS ERDS should have some generalized mechanism which allows a set of additional << ERDS-computed data points >>, not transmitted from the site, to be computed from site-transmitted data point values and stored plant-descriptive data, and any other stored data that might be needed for a particular computation. The set of ERDS-computed data points may include both site-specific data points and some which are computed for every plant.
The mechanism should allow the computation process for any ERDS-computed 8-3
i data point to be triggered by the arrival of a new update set from a feeder (if the update set contains all the inputs needed for a new ERDS-computed data point).
The recommendations in this report regarding standardization of data point i values -- that there not be any standardization computed by ERDS -- mean that the concept of ERDS-computed data points is not needed in the initial implementation of ERDS. However, it is a truism of computing that the i presence of data stimulates the development of uses for it. We strongly recommend that the absence of need for standardization in the initial implementation of ERDS should not cause the implementation design to ignore the possibility that ERDS-computed data points will eventually be l implemented. An implementation design often needs to expend some effort or 1 cost to defend the future viability of concepts that are not part of its immediate mandate. We recommend that be explicitly acknowledged in this case.
In this chapter, when we speak of U data consumers >>, we will be referring to two categories of entitles: humans looking at display screens or paper output, and software. The software data consumers can be further subdivided, into " display-generating" software that generates the displays, plots, and printouts versus " computational" software that seeks to use the ERDS-stored data point values as inputs to computations. Although the I initial implementation of ERDS will not have any computational software consumers of data, an important conceptual distinction should be understood.
Display-generating software does not need to know anything about the 1 meaning of the numbers; computational software does. An important corollary is: any changes over time in the meanings of a plant-specific data point may require changes to all computational software data consumers of that data point. ERDS-computed standardized data points offer the potential benefit of serving as a barrier to the fan-out of software maintenance requirements. I 8.3 AUDIT TRAIL FOR DATA POINT VALUES The storing of a feeder-transmitted data point value after reception processing can be regarded as an outcome of a transaction with the feeder.
Recognition of the general concept of " transaction" in ERDS transmission receiving and reception processing suggests the applicability of the companion concept of " audit trail", a sequentini log of the outcomes of transactions that provides back-up data for later recovery from various possible (anticipated and unanticipated) system failures (or other events) that create loss of trust in the integrity of the primary copy of the data.
8-4 a .
This, we believe, is the place in the data flow where the data point value becomes suitable for long-term archiving by NRC. Whether an audit trail mechanism receives individual data point values as they are stored, or all at once receives the results of reception-processing an entire update set, is an implementation design decision.
The audit trail mechanism should receive, in addition, manually entered data point values (discussed below) and any changes made to plant-descriptive data during an incident. It should also receive any ERDS-computed data point values. Although it could be argued that archiving of ERDS-computed data points is not necessary if all the software and data needed to recompute them is preserved, that approach would require a special mechanism in ERDS to recompute them from playback of archived data: ERDS would be simpler if they were archived along with the licensee-provided data point values.
The audit trail mechanism can play a role in providing fast restoration of database contents after a data disaster, but it need not. This is a system implementation decision.
8.4 MANUAL ENTRY OF DATA POINT VALUES (ADDITIONS. CORRECTIONS)
The concept of ERDS includes the premise that the Operations Center will continue to receive by voice over ENS those parameters which a licensee cannot easily transmit electronically. ERDS should allow these parameters to be entered manually into ERDS' data storage facility and thereafter be displayed and otherwise used with the same mechanisms that are provided for licensee-transmitted data.
A number of design issues accompany the concept of manually entered data point values. Here we give our recommendations regarding them:
a) Should these values be identitled in data displays as having been manually entered? They should be identified as having been human-touched. They can be shown in the same category as licensee-operator-inserted values, b) There should be a pre-created data point descriptor for each data point to be entered manually. It should have the same structure as other data point descriptors.
c) The data point identifier should either be some precise identifier that is meaningful to the licensee, or some synthesized value that will be 8-S
(J
> (
obviously not meaningful to the licerisee (e.g. "NT/0!CE001"). (The, roughly 40-character description is recommended. as the sole means of {
identification of data points in oral incident >zime interaction between NRC ]
and licensees. The roughly 10-character non-mnemonic identifier is I recommended for use in licensee /NRC electron 10 data specification, so it is not necessary in this context. Also, some predetermined bydroice dat'a points may not have !!censee-designated data faint identifiers.)
d) The mechanism for installing updates (changes) from licensees to data ('
point descriptors should be able to modify these data point descriptors.
e) ERDS will have available to its software the daughter / parent relationships i between data points and parameters, for use-in the user interfaces of ERDS. The data point description (roughly 40 characters) will be the usual handle for identifying data points in ERDS interactions with users.
Any use of the data point description in interaction with users should be accompanied by showing the parent parameter (s) of the data point, because the licensee-created descriptions are often ambiguous. The , ,
parent / daughter relationships .for manuar.y entered data points should be ,
I treated in just the same way. J I f) The mechanics of user interaction for dats, entry should recognize the likelihood that by-voice values will usually be received in batches having the same timestamp. The user should only' have to key in this timestamp once. The user should be able to point or daove a cursor to a dat'a point identification, without having to type. it. The software should a'!!ow the .
user to enter values for all the data points pre-designated as,by,-vrise 'in , I one batch, or any rubset of them, within the same interactionifinsworb
.{
The software should recognize which data points had values entered by the user, and form an update set coitcaining only those data points. k g) The concept of an update set ("I'm done entering the values I have at this time") should be explicit in the mechanism for manually entering data point values, so that whole batches can be made available to the ', )
ERDS-computed data point computation mechanism, the way ' I licensee-transmitted values are. t h) Manual correction capability is needed for manually entered dat[ point l values. The audit trail should receive the old value, new value, timestamp of the value being changed, time of the chany,e.
%v i
- 1) Should this manual correction capability be usable on licensee-transpF.ted data point values? We recommend yes, with the same authorization ' !
limitations as are imposed on manual entry of values. I I
8-6 >
ii j
. ,- )
. . s s
The concept of manually entered data points, as described here, differs in one important way from the currently used ENS votee procehres. These manually entered data pointe are predetermined, with stored data point descriptors. This allows display mechanisms downstream to be designed with ;
them in mind. The difference is that there is no ability to change the {
identity of the data points ueing received, during the cevrse of an incident, j to reflect the focus of attention of the incident analysis. ;
l The concept of adhoc by-voice dsta points, introduced in section 7.3, is !
included to support this aspect of existing ENS practices. Manual entry of values for these adhoc data points should be able to use all the same !
meettenisms as ERDS implements for pre-defined data points. It should be a j requirement that some authorized user creates a data point descriptor for a j new adhoc data point before anyone can do anything else with it. 1 8.5 INTERFACES FOR DATA RETRIEVAL The design of ERDS' interfaces for data retrieval should make available all i data point values received by ERDS, without hiding any values having quality tags indicating suspicion.
The following access methods should be availeMs br each data point's ;
values: i s
Newest value before time DD/MM/YY:HH:MM:SS.
~
Newest value before time DD/MM/YY:HH:MM:SS with quality-tag nct Suspect.
Oldest value after time DD/MM/YY:HH:MM:SS.
Oldest value after time DD/MM/YY:HH:MM:SS with quality-tag not Suspect.
The access methods and ather 1spects of the retrieval mechanism should be the same for data points rece!ved electronically, entered manually, and ERDS-computed.
Interface mechanisms should be provided fcr software running on other computers; it should not be assumed that all data consumers will be coAputer system that hosts the ERDS data. These supported by rp[tums'should cifer two data formats for the scalars, an interface mechg internal binary format (for computers of the same compatible architecture) and a formatted character-string representation.
A mechanism is needed to broadcast the availability of a new spdate set, after reception processing, to software on the data host and on other 8-7
J 1
computns. This mechan.!si should be sufficient, together with user-specified retrieval requests, to allow another computer to obtain and maintain, a 'sA* tellite copy of a subset of the ERDS databaseis).
NRC might wish to' consider the unfulness of a usage accouM!ng capability on the mechanisms which will support requests from oth'er computers.
8.6 FACI.EITIES FOR DATA STOLA_G_E t
Storage capacity till be needed for ' plant-descriptive data: data point values-
~
received electronl? ally, entered manuaHy. and ERDS-computed; buffering of the audit trail.
The online storage requirements Nr data point values can be tstimated as follows:
72-!wu: ca.pacity vs needed (see se:11on 7.1).
Worst case data point volume is 70' data points received electronleally per plant unit, at IS second update frequency. To allow for 'by-voice and ERDS-computed data points, use 100 instead of 70.
Stomge per data point value is 8 bytes, based on:
=
4 bytes for the numerical valua. (This could sbe less, if the limited precision of the incoming "2.1ues is exploited.)'
=
3 byte for a timestamp, represented 'ns the integer numby of seconds since sow convenient zerc--time (e.g., the midnight startir.g the day the incle.ent began). 2 bytes would provide values up to 64K, sufficient for only 18 hcurs while 3 bytes provides capacity for 189 days (16,384K seconds).
=
.\ byte for the standardized quality tag (currently recommended to require onir 2 bits) and other useful bits that might emerge during implementation design. #
Total required for 72 ho.trs 18: (f bytes) x (100 points) A (4 updttes/ minute) x (60 minutes / hour's x (72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />) = 1:1524 KBytes.
Since this 14 MB total is relatively medest-stzed compared to present-day computer hardware, we recommend uso. et an ample safety f actor (e.g.,
200%) in sizing of hardware.
{
t 8-8 j ,
l ,i; "u___ *.__ _--
i l
In the event of a multi-day incident, the data accumulated by ERDS will eventually exceed the online storage capacity. In that case, we believe, it will be desirable that ERDS retain, in online storage media, data from the beginning of the incident for all data points, but at a coarsened time frequency for the old data. No averaging, interpolation, or other smoothing operations that modify or synthesize data point values are being suggested, only selective deletion of values based on time-nearness to other values of the same data point. The ability to implement this coarsening of the data would be a requirement of the data management software. ERDS does not have to be able to restore online accessibility (during an incident) for data older than'72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br /> which has been removed from online storage.
The workload for retrieval of data from the ERDS database can be ]
worst-case-characterized by the following: All 12 users (see section 7.1) '
requesting data for parameter-vs-time plots (see section 8.7.3) that each span the entire 72-hour online residency of the database. A reasonable maximum frequency for such requests is once per minute. The ,
implementation design should, if hardware resources are not ample, include a 2-level priority mechanism, which would give a lower priority to users whose I retrieval requests define a time interval of interest which is longer than 1 hour1.157407e-5 days <br />2.777778e-4 hours <br />1.653439e-6 weeks <br />3.805e-7 months <br />.
The issues of system hardware redundancy and computer manufacturer
-implemented support for fault-tolerant processing deserve some discussion at this point. Currently in the Operations Center, the computer system hardware facilities and features that support redundancy are the following:
(" CPU" is used as an abbreviation for " independent computer system".)
Two independent Data General MV/6000 CPUs, each running the AOS/VS operating system, in the same room, without removable disks.
One magnetic tape drive on each CPU. ,
Terminals are connected to devlees that allow each terminal to select the l CPU lt talks to. l Many available serial ports that can be connected between the CPUs.
i The strategy for use of these facilities in incident-time appileations includes I the following elements: ;
Both CPUs are used as hosts of incident-time application load.
l -
If one CPU falls during an incident, part of'the load of each host will'be abandoned administratively, and the remaining load will be coalesced onto the surviving CPU.
8-9
This strategy requires that all data created during the incident by all applications running on each CPU must be " audit-trailed" (i.e., written) ,
onto the single magnetic tape drive of that CPU in a form that allows it to be easily and quickly loadable onto the other CPU.
Software and data required during an incident, which does not change during an incident, is either resident on both CPUs or stored on magnetic tape in a form that allows it to be easily and quickly loadable onto the other CPU.
There is great temptation to say that this strategy cannot effectively support the redundancy needs of ERDS data hosting. However, we do not believe that assertion is supportable. This strategy probably could effectively support ERDS, with about the same probability of effectiveness that it has been providing over the past few years to existing applications.
The bare minimum of hardware tools are there: all that's needed is effective use of a set of rules and procedures for software and operations.
What can be said unequivocally is that, in the years since this hardware environment was established in 1982, the services offered by some vendors of multi-user minicomputers in support of redundancy and distributed (multi-computer-based) databases have grown substantially in sophistication and usefulness. The fully redundant hardware approach used by Tandem computers Inc. continues to represent the extreme of sophistication (and cost) in redundancy that is fully supported by the manufacturer's software products. They now have several competitors in the transaction processing market niche; there were none in 1982.
More significantly, though, you no longer have to turn to this market niche to buy a dual-ported disk drive. The huge commercial success of DEC's VAXcluster architecture can be attributed in part to the many user environments that want some manufacturer support for redundancy without paying for all the technological overhead and sophistication involved in Tandem's super security blanket. These few supported system features of a VAXcluster -- I Hierarchical Storage Controller: Disk and tape drives are shared among CPUs.
Mirroring of selected files: The operating system maintains backup copies i
online on different disk drives.
l 8-10
- Terminal servers: The intelligent asynchronous controller for terminals is a separate box that connects to all CPUs via Ethernet, allowing any terminal to access any CPU without moving a cable. 1 I
provide, on day 1 of system usage, more and better services for redundancy than the most ideally effective operational procedures possible with the existing Operations Center hardware resources.
The preceding paragraph should not leave the impression that DEC is the only vendor offering these services. It was not a focus of this project to examine redundancy services available in the minicomputer marketplace, so I we are not prepared to describe what the major players do and don't offer. l but there are other major suppliers of comparable capabilities. We do want l to leave the impression that we think it is futile to expect to achieve a high level of reliable redundancy of computing capability with both a manpower-lean system environment maintenance staff and weak tools. l l
We recommend that the ERDS data storage and retrieval facilities be specified to provide access to all online ERDS data (incident-created data, and plant descriptive data for all plant units) with an outage of at most 10 minutes for any failure of one disk drive, CPU or operating system, and requiring no special response by human users (except patience) to restore accessibility after an outage.
8.7 DATA DISPLAY IN THE OPERATIONS CENTER We use the terms << display format >> and << display facilities >> to distinguish between information content or layout conventions (format) and hardware or system software capabilities (facilities). For example, a tabular display format can be generated by alphanumeric display facilities and does not require graphical display facilities.
8.7.1 Tabular Alphanumeric Display All data electronically transmitted to or manually input to ERDS should be displayable in tabular form on alphanumeric (i.e., non-graphical) display screens. The recommended organization of the data is based on groupings of parameters into several " Critical Safety Function" (CSF) groupings. The CSFs are the most frequently used method for organizing the parameters presented on Safety Parameter Display Systems ("SPDS") at the plant sites.
The CSF grouping is recommended because it tends to bring interacting parameters of concern onto the same display for incidents postulated by 8-11
\
plant casualty analyses. '
This organizational scheme is shown in Figure 8-1. As shown in this illustration, each parameter is placed in only one CSF grouping. However, NRC could decide during ERDS implementation to place a parameter in more than one CSF or to modify the assignment of parameters to CSFs. In-
~
addition to the 6 CSF groupings, an "Other Parameters" heading is provided for meteorological data and tank levels.
Each predetermined by-voice data point should be displayed with its parent parameter under a CSF or in the "Other Parameters" grouping, no differently than electronically transmitted data points (except for the standardized quality tag value). As mentioned in section 7.3.1, adhoc by-voice data points should be shown as a separate "Adhoc Data Points" grouping (not in the "Other Parameters" grouping).
The CSF-oriented grouping approach, with each data point on its own row of a display format, will need more than 24 rows of display height to accomodate the number of data points provided by some plant units for some of the recommended CSF groupings. (Some parameters' are represented by as many as 8 plant-specific data points.) Recognizing that 24 rows by 80 columns is a traditional industry standard for alphanumeric display terminals' screen capacity, we considered the possibility of further subdividing the CSF groupings, but we ultimately concluded that the CSF-oriented approach could not be shoe-horned into a 24-row display format for all possible cases.
l The next larger number with any semblance of industry-standardness for rows of display capacity is 43, found in one of the " display modes" of the Extended Graphics Adapter (EGA) architecture for IBM-compatible personal computers. The EGA is a printed-circuit board, initially an IBM product, now widely available from other manufacturers as well, which defined new limits for dot resolution and character resolution in display facilities for. the IBM PC family. It currently provides the highest resolutions having multi-vendor compatibility, and is the graphics adapter of choice for IBM PC app!! cations in which high information content in displays is an important consideration. In light of the need for graphics capability in display devices (for plotting; see next two sections), the presence already of IBM PCs in the Operations Center, and the absence of any industry standard for more than 24 rows in non-programmable display terminals, we recommend that 40 rows be the requirement for row capacity. of ERDS display facilities.
The recommendation for 43-row display formats is accompanied by recognition that they may be difficult for some users to read. Therefore, 8-12
e TIGURE 8-1 ORGANIZATION OF PARAMETERS BY CRITICAL SATETY TUNCTION q CRITICAL SATETY TUNCTION PVR PARAMETER BVR PARAMETER REACTIVITY CONTROL NI - SR NI - SR NI - IR NI - IR NI - PR NI - PR i
RX CORE COOLING / HEAT REMOVAL TROM PRIMARY RX VSL LEVEL RX VSL LEVEL TEMP - HOT LEG MAIN TEED TLOW TEMP - COLD LEG RCIC TLOW TEMP - CET SUBC00 LING MARG RX COOL TLOV S/G PRESSURE S/G LEVEL MAIN TEED TLOW AUX TEED TLOW RX COOLANT SYSTEM INTEGRITY PRESSURE PRESSURE PRZR LEVEL HPCI TLOV RCS CHG/MU CORE SPRAY TLOV HP SI TLOV LPCI TLOW LP INJ TLOV DV TD SUMP LVL CONT SUMP NORM CONT SUMP VIDE RADI0 ACTIVITY CONTROL MN STEAM LN RAD KN STEAM LN RAD A/E RAD A/E RAD ETT GAS RAD ETT GAS RAD ETT LIQ RAD DV RAD RX COOL RAD ETT LIQ RAD l S/G BLOVDOWN RD CONT RAD CONTAINMENT CONDITIONS CONT PRESS DV PRESSURE ,
DV TEMP- I CONT TEMP H2 CONC H2 CONC i 02 CONC 1 SUPP POOL TEMP ;
SUPP POOL LYL I OTHER PARAMETERS BVST LEVEL CST LEVEL .;
VIND SPEED VIND SPEED 1 VIND DIR VIND DIR STAB CLASS STAB CLASS i
i 8-13
ERDS software should use a 24-row display format when a CSF grouping can fit within it, and a 43-row for;nat only when necessary. Also, a large (roughly 36-inch diagonal) flat screen display device is recommended for the Reactor Safety Team room. This display device would be easily read by users from anywhere within the room.
Different users, in the contexts of different incidents, may. prefer different groupings of parameters into CSPs. To support individual preferences, ERDS should allow each user to define some number of personally customized tabular displays. These would be defined during an incident and would be specifle to a plant unit's set of data points. The user would specify, for each row of the display format, either an 80-character comment (e.g., CSF or parameter heading) or a data point. The user would not have any control of the composition of the rows allocated to data points: their horizontal format would be as described under Figures 8-2 and 8-3 below.
These customized tabular displays.should have a concept of user ownership and be modifiable only by the owning user, but they should be freely copyable by other users. . (This is the first explicit requirement for a concept of user-owned storage in ERDS, but other needs for user identity as a basis for authorization to perform certain operations have been centioned in various preceding sections.) Each user should have the ability -
to define at least 15 of them (because 15 plus the system-defined CSF groupings makes a reasonably sized menu of groupings choices). ERDS should provide a menu-oriented mechanism for the maintenance of these customized tabular display definitions, which allows them to be created, modified, copied (from another user, from a- system-defined CSF grouping, or from the user's own displays as a precursor to modirleation), or deleted.
Addition and deletion of data points should be possible using only cursor movement, without the need to type an identification of a data point.
Figure 8-2 and 8-3 are examples of 2 suggested display formats for CSF-organized tabular displays. These figures represent.2 different display-generation software " engines" (to supply the dynamics of putting data values into a tabular display), which differ in the way they use horizontal character positions. Each engine.should be usable with any l tabular " chassis" (allocation of rows to data' points or comments),
system-defined or user-defined.
l 8-14 .
___.____E .. ,.
,j
TIGURE 8-2 EXAMPLE OF RECOMMENDED MULTI-COLUMN TABULAR DISPLAY TORMAT XYZ UNIT 1 CST: RX CORE COOLING /EIAT REMOVAL FROM PRIMARY TIMESPEC: T1=(T2)-00:20:00, T2=02/0CT/87.00:05:00, T3=(T2)+00:10:00 PLANT DATE: 01/0CT/87 02/0CT/87 02/0CT/87 (NRC HQ= PLANT + O2:07:23) PLANT TIME: 23:45:00 00:05:00 00:15:00 PARAMETER / DATA POINT------------ UNITS------ T1YALUE--Q T2VALUE--Q T3VALUE--Q
) REACTOR VESSEL LEVIL DYNAMIC HEAD % 100 M 100 E l
> TEMPERATURE - HOT LEG l LOOP A TH DEGT 460.7 G 461 G 460 G l LOOP B TH DEGT 461 G 461.1 G 461 G l
> TEMPERATURE - COLD LEG LOOP A TC DEGT 440.3 N 440.3 N 440.3 N I LOOP B TC DEGT 440 N 440 N 440 N l l
> TEMPERATURE - CET CORI EXIT TEMP DEGT 465.8 M 467.1 M
>SUBC00 LING MARGIN i SUBCOOL G MARG DEGT -52.6 ? -52.9 ? -52.6 ?
> REACTOR COOLANT TLOW ;
LOOP A TLOV % 100 G 100 G 100 G LOOP B TLOW % 65 ? 65 ? 65 ?
>STIAM GENERATOR PRESSURE STM GEN A PRESS PSIG 600.5 G 600.5 G 600.5 G STM GEN B PRESS PSIG 602.2 G 602.2 G 602.2 G
> STEAM GENERATOR LEVIL STM GEN A VIDE RN % 70 G 70.2 G 70.23 G STM GEN B VIDE RN % 68.78 G 69 G 69.01 G
> MAIN TEID TLOV STM GEN A TEID TL LB/HR 2.951E+6 G 2.95E+6 G 2.953E+6 G STM GEN C TEED TL LB/HR 2.92E+6 ? 3.0E+6 ? 2.9E+6 ?
> AUXILIARY TEID TLOV STM GEN A AUX TL GPM 0 'N ON ON STM GEN B AUX TL GPM 0N ON 0N NOTES:
- 1. The ">" subheadings should be reverse-video on displays.
- 2. The following alternative versions of the "TIMESPEC:" row would all produce equivalent results in the display contents:
TIMESPEC: T1=(T3)-00:30:00, T2=(T3)-00:10:00, T3=02/0CT/87.00:15:00 TIMESPEC: 71=(72)-00:20:00, 72=02/0CT/87.00:05:00, 73=(T2)+00:10:00 TIMESPEC: T1=01/0CT/87.23:45:00, 72=02/0CT/87.00:05:00, T3=02/0CT/87.00:15:00 1
8-15
FIGURE 8-3 EXAMPLE OF RECOMMENDED 1-COLUMN TABULAR DISPLAY TORMAT XYZ UNIT 1 CST: RX CORE COOLING / HEAT REMOVAL TROM PRIMARY TIMESPEC: NOV-00:20:00 (01/0CT/87.23:44:17) TO NOW(AUTO-UPDATING)
PLANT DATE: 02/0CT/87 (NRC HQ= PLANT + 02:07:23) PLANT TIME: 00:13:42 PARAMETER / DATA POINT----------- UNITS------ VALUE----Q .
> REACTOR VESSEL LEVEL DYNAMIC HEAD % 100 #
> TEMPERATURE - HOT LEG LOOP A TH DEGT 460 G LOOP B TH DEGT 461 G
> TEMPERATURE - COLD LEG LOOP A TC DEGT 440.3 #
> TEMPERATURE - CET CORE EXIT TEMP DEGT 467.1 #
>SUBC00 LING MARGIN SUBCOOL G MARG DEGT -52.6 1
) REACTOR COOLANT TLOW LOOP A TLOV % 100 G LOOP B TLOW % 65 ?
> STEAM GENERATOR PRESSURE STM GEN A PRESS PSIG 600.5 G STM GEN B PRESS PSIG 602.1 G
> STEAM GINERATOR LEVEL STM GEN A VIDE RN % 70.23 G STM GEN B VIDE RN 4 69.01 G
> MAIN TEED TLOV STM GEN A TEED TL LB/HR 2.95JE+6 G .
STM GEN B TEED TL LB/HR 1.SE*6 ?
> AUXILIARY TEED TLOV STM GEN A AUX FL GPM 0#
STM GEN 8 AUX TL GPM 0#
NOTES:
- 1. The ">" subheadings should be reverse-video on displays.
- 2. Fields that are italles in this figure are displayed without visual emphasis but are automatically updated.
l 1
l 8-16 l 1
i i
1 I
1 FIGURE 8-2: MULTI-COLUMN FORM AT -
\
l This figure shows a high information density because of the presence of 3 values for each data point. Three value columns were the most that could be squeezed into 80-character-wide rows, and were considered sufficiently many 'for user needs: if wider display facilities become available and additional value columns are considered desirable, the semantics described below for user choices and display content generation are general enough to !
accomodate additional value columns.
This multiple value column format is defined only for fixed time intervals !
(i.e., without automatic updating). The user would specify the number of value columns wanted (up to the maximum of 3) and a matching number of precise time (with date) values. The system will allocate these to value columns chronologically, with oldest on the left and newest on the right.
l Each column will thereby represent a time interval, which ends at its own l time and begins just after the time of the column to the left. The begin time for the leftmost column is a system constant, recommended to be the earliest data point value timestamp in the ERDS database.
For each data point (row) to be shown, a value column will receive the most recent data point value whose timestamp is within the time interval of the ,
value column. For example, with column times of 109:00:00, 09:15:00. 09:30:001 I and data point value timestamps of.107:15:01, 08:15:01, 09:15:01), the left column would get the value for 08:15:01, the middle column would get no value, and the right column would get the value for 09:15:01. If the last data point value timestamp were 09:15:00 instead of 09:15:01, that value i would go into the middle column, and the right column would get no value, i These data retrieval semantics require a display convention (blanks are suggested) for when there is no value to show. These retrieval semantics implement the concept that the values shown in a column were most recent l at the time on that column and are more recent than the time on the !
preceding column.
The following requirements are recommended for the user interaction to ;
specify the time and date of each value column: I All time values (in the user interaction and in the tabular values display) i are the time at the plant site, not at NRC Headquarters. This eliminates j the need to specify one or the other, and recognizes that remote users !
may not know or care about the time at NRC Headquarters.
1 In any system output that shows or asks for time values (in the user interaction and in the tabular values display), the system should show the 8-17 i !
time difference between plant' site time (as known by ERDS) and time at NRC Headquarters. For example: "(NRC HQ= PLANT + O2:07:23)". This time difference would be established when data transmission begins, and would only change if the system clock were changed in the ERDS data host computer or the site-time-determining licensee feeder.
The user can specify time values in seconds. This is needed to allow. this display format to retrieve and show every data point value in the ERDS database, because a data point might have several values whose timestamps are within the same minute.
All time values and time increments (in the user interaction and in the tabular values display) are in the form HH:MM:SS using 24-hour time (i.e.,
13:00:00 for 1:00pm), not HH:MM. This eliminates the question of whether 10:00 represehts 10 hours1.157407e-4 days <br />0.00278 hours <br />1.653439e-5 weeks <br />3.805e-6 months <br /> or 10 minutes. If SS is not entered by the user, it defaults to 00.
The user can specify each column's date-time value either absolutely or:
relatively (e.g., relative to the date-time value of another column). 'The recommended semantics are:
u An absolute date-time value is either a user-specified date and time (e.g., '02/OCT/87.00:15:00") or a special symbol representing a special system-defined date-time value. The special symbol "NOW" would be converted to the current date and time (of the plant site) at the moment when the system begins processing of the completed display request. The special symbol " SOD" would represent the Start Of Data time (when ERDS began receiving data transmissions). Personalized user pri'qte definitions of special symbols are not recommended.
= Each date-time value is considered to be assigned to a software register (i.e., container), whose names (e.g., TA TB, TC) can be used in the specification of relative data-time values.
= A relative date-time vs.lue is a named date-time _ register (e.g., "TA", .
"TB", "TC") or a syste a -defined special symbol (e.g., "NOW", " SOD"),
followed by a signed (i.e., "+" or_ " ") time increment (in the form "HH:MM:SS", not all zeroes, with HH possibly greater than 24).
Examples: "TA+00:01:00", "TA-30:00:00".
= Although the proposed generality could be used to specify meaningless date-time values (e.g., before start of incident or after "NOW"), we recommend that the system interpret user specifications with permissive-latitude whenever possible (e.g., times before " SOD" or after "NOW" 8-18
_. . .. _ .~
should cause no difficulty), to allow a user date-time specification to be appilcable in different time contexts.
While generating display contents, the system rearranges the date-time values (if necessary) to provide left-to-right chronological sequencing and shows in the display contents the user-specified date-time values. For example, if the user specified these assignments:
TA= TC-00:20:00 TBu TC+00:10:00 TC= 02/oCT/87.00:05:00 the system would display them as:
71= T2-00:20:00 T2= 02/0C7/87.00:05:00 ';
T3= T2+00:10:00 1
/
This display of the user's specifications would be in addition to the resulting absolute date-time values that are shown as column headings.
Note that the sequencing of the individual assignments carries no meaning in either the user's input or the system's output.
Figure 8-2 shows a multi-row display heading at the top of the display format. This heading includes (on one row each) the plant unit, the Critical Safety Function title, and the user's date-time specifications. The next 3 i rows provide column headings, showing date, time, and fixed column labels.
Each of these dates and times is the endpoint of the time interval associated with the value column. The difference between plant site time and NRC liendquarters time is also shown in these rows. Each subsequent row is allocated to either a data point or a subheading. The subheadings in system-defined CSF groupings show the ERDS parameter that is the parent of each data point, to aid understanding of the plant-specific data point descriptions. The subheadings in customized user-defined tabular displays are arbitrary user-defined. 80-character strings.
Each data point value is shown with an . adjacent indication of its quality, e using the standardized. quality tags. A "G" indicates good data, a "?"
(question mark) indicates suspect data, an "N" indicates that no quality . ~!
information was available, and an "M" indicates manually inserted data.-
These symbols were selected to avoid confusion when displayed adjacent to numeric values. Other methods of quality indication (such as a color code) l could be used, but to simplify printing without loss of information content. !
monochromatic displays and character-based quality depiction are preferred.
8-19 w_-________-________
In this display format, the available character positions on each. data point's 3 row are allocated as follows: {
l 32 Data point description I 1 blank 11 . Engineering units 12 Value column 1 12 Value column 2 12 Value column 3 80 TOTAL Each value column is composed as follows:
1 blank 10 Numeric value in E-format as "-1.234E+06" ~
1 Quality tag, one of (?,G,N,M) l The following conventions are recommended for the formatting of the 10-character field for the numeric values. These recommendations assume that all data point values are stored with 4 significant digits.
A leading sign is shown only if the value is negative; a positive value receives no sign. Examples: "-1.234", "5.678" (not "+5.678").
1 In E-format, the power of ten after "E" always has a sign ("+" or " ").
I Use "F-format" (i.e., without an explicit power-of-ten multiplier), not i E-format, if the 4 significant digits can be shown with no more than 5 l digits on either side of the decimal point (i.e., "12340" or "-0.01234" but not "123400" nor "-0.001234"), because of the difficulty of visually assessing magnitude when 6 digits are unpunctuated.
In E-format, only the first significant digit (by definition, always l non-zero) precedes the decimal point. Examples: "1.234E+56" (not "0.1234E+57" nor "1234.0E+53").
In E-format, delete rightmost significant zeroes after the first fractional (i.e., after the decimal point) digit. Examples: "1.02E+56" (not "1.020E+56"),
"1.2E+56" (not "1.200E+56"), "1.0E+56" (not "1.E+56" nor "1E+56" nor "E+56").
8-20
In F-format, delete rightmost significant zeroes afte'r the decimal point, and then delete the decimal point if no digits follow it. Examples: " 10. 4 "
(not "10.40"), "0" (not "0.00" nor "O.0" nor "O.").
In F-format, always show at least one digit to the left of the decimal point. Examples: "O.01234" (not ".01234").
In E-format, if the power of ten requires more than 2 digits (this is not expected to ever occur, since the largest values encountered in the survey were +13 for Stack E." fluent Radiation and -13 for Intermediate Range Nuclear Instrumentation), and all other character positions are being used (i.e., the value requires "~* sign and has no rightmost significant zeroes), delete rightmost significant digits (with rounding) suffielent to display the power of ten. Examples: " 6.79E+123" (for
-6.789E+123), "-6.8E+1234" (for -6.789E+1234), "6.79E+1234" (for l
+ 6.78 9E+ 1234). !
In E-format, delete leading zeroes in the power of ten. Examples:
"1.234E+6" (not "1.234E+06").
Right-Justify the value in the 10-character field, then relocate the leftmost blank (if present) to the right of the value, to provide 1-blank separation (when possible) between the value and the quality tag. Since nearly all E-format values will require only one digit for the power of ten, and all F-format values will have at least one blank, the 1-blank separation will occur in nearly all cases. This convention might result in a quality tag appearing equidistant between the value it describes (to the left) and the (unrelated) value to the right, but the vertical alignment of all quality tags in the same column should eliminate ambiguity.
This display format reflects one important compromise needed to squeeze it into an 80-character display width. The data point description is allocated only 32 characters in this format, although it is known that some licensees use up to 42 characters for their descriptions. (The 11 characters allocated to engineering units is the longest length seen in the survey) Previous sectbis of this report have recommended that the data point description be the vehicle for oral identification of data points in conversations with licensees during incidents; the underlying implication was that ERDS would display them exactly as they were displayed to licensee staff in licensee data systems. Here we conclude that visual fide 11ty will in some cases be impossible to achieve. We recommend that data point descriptions longer than 32 characters be edited to compress them while retaining pronunciation fidelity; this should be possible using industry-standard abbreviations such as "S/G" for steam generator, "RX" for reactor, "PRZR" for pressurizer, etc.
8-21
FIGURE 8-3: ONE-COLUMN FORMAT This figure shows a relatively low information density, since it only shows 1 value for each data point. As in Figure 8-2, the single value column in this display format represents a time, interval and shows the data point values most recent within that time interval. Additionally, though, this display format can be specified to be auto-updating, which would cause the system to update it automatically whenever new values are received electronically or input manually.
The user would specify a time interval by specifying 2 precise time (with date) values, using interaction features similar to those recommended for the multi-column format. If (and only if) "NOW" is the choice for. the interval's .
ending time, the user would be allowed to specify auto-updating. If the user specifies auto-updating, the system should generate new display contents by expanding the time interval (i.e., updating its ending time to the current value of "NOW"), leaving its beginning time fixed, rather than by leaving the interval width fixed and shifting the beginning time toward the future. This allows auto-updating to be implemented without having to re-retrieve data values from the ERDS data storage. Because the user might specify the begint.ing time relative to "NOW", the display contents on the "TIMESPEC:" row should indicate clearly that the beginning time is absolutized only once and is not auto-updated.
Compared with Figure 8-2 Figure 8-3 shows a different format for the "TIMESPEC:" row of the display heading. In all other respects, the structure and formatting of the 1-column format is identical to a 1-column instance of the multi-column format shown in Figure 8-2. In its data retrieval semantics, the 1-column format would be identical to a 1-column instance of the multi-column format when the user specifles no auto-updating and chooses " SOD" (Start Of Data) as the interval's beginning time.
8.7.2 Pressure versus Temocrature Disolav This display format, illustrated conceptually in Figure 8-4, has the capability of showing the intersection of selected temperatures against selected pressures and displaying the locus with an overlay of the saturation curve.
This display should be capable of plotting one selected set of P vs T. Since it does not make sense to plot any temperature against any pressure,'the user request for this display should provide a limited set of choices for 8-22 i
l
~ -
0 0
7 I
0 4
4 2
- 0 8 I M
0 0 6 7 Y m
8 A
/ L T I P C S O
/
1 0
i i g l I ht l l I l il I I l I l g g l 1 I I 8 l ' l ' 1 !
I 0
0
)
F G
E I
D E
R U
T M
5 O A
( R E
I P
1 t
E T
G P
M E
T s
v M
O E
L E R
0 T U I
0 0 S 4 1 4
S E
1 R P
P O :
E 1
I O 4 t
A L -
8 N
T E I R N 0 U U 0 G I
3 P T
N A
L P
- - - _ - - - - - 0 0
2 0 0 0 0 0 0 0
_ 0 2
0 5
1 0
1 0
5 PRI rA1 v SYS PRE 3 SORE ( PSIo) 7t fl l:!
e each. BWRs do not generally make use of P vs T plots, but the ERDS capability to use the plotting feature should be available. A recommended menu, by ERDS parameter, is shown below:
. PVR PRESSURE PVR TEMPERATURE
' REACTOR VESSEL PRESSURE TEMP - HOT LEG STEAM GENERATOR PRESSURE TEMP - COLD LEG 1 TEMP - CET
]
.BVR PRESSURE BWR TEMPERATURE REACTOR VISSEL PRESSURE SUPPRESSION POOL' VATER TEMP DRYWELL PRESSURE DRYWELL AIR TEMP The P vs T plot should have two modes, one which allows the user to. select any past time as the source of data points and a second mode which is a.
continuously updating display on which values from newly arrived update sets are displayed automatically. Historical plots of P vs T are typically confusing to the unfamiliar user, since time is not an X - Y dimension on j the plot. It is recommended that the default P vs T displays (both ;
historical and current) show only a simple intersection of the selected j pressure and temperature, rather than a plot of the moving locus of points.
Of note is the fact that In the few licensee SPDS systems which do provide i
a historical plotting of the locus of points, they do so for very short historical periods, typically 30 seconds. For the purpose of providing an I analysis tool, the historical mode of the P vs T display should allow the i user to obtain a historical trace of P vs T over a user-defined period of up I to I hour.
Again, the concept of "most recent (newest) values preceding the specified ;
time" is applicable. Both the X-axis (temperature) and the Y-axis (pressure) should be auto-scaling. A fixed saturation curve should be resident on the plot. At this time there is no recommendation that ERDS contain any of. the data to allow plotting of the typical plant-specific features of P vs T plots (e.g., NPSH curves, Pressurized Thermal Shock curves. Heatup and Cooldown curves, etc).
Users should be able to store in a user-owned data structure some number (e.g.,10) of specifications for P vs T plots, with operations available to -
manipulate the' specifications similar to those described above for customized tabular displays.
8-24
. i 8.7.3 Data Point versus Time Display This display format, illustrated conceptually in Figure 8-5, has the capability of showing any data point plotted against time. Two vertical scales (on the Y axis) are possible, one on the right and one on the left of the display screen. As many as 4 data points can be plotted on the same display (as long as only 2 vertical scales are required for all 4).
This display format should have both a fixed and a continuously updating display mode, as described for Figure 8-2 in section 8.7.1 above. The user l specifies a time range, with "Now" being a possible value for the range's ending time: if "Now" is used, the user can additionally request continuous updating. The retrieval semantics should obtain, for the requested data ,
points, the values that were current at the beginning of the time range and all values that were received with timestamps within the requested range.
In the updating mode, current time would always be represented on the l right edge of the X-axis, with the X-axis showing the full time range l specified by the user (1 minute to 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />). The display contents would be updated whenever ERDS receives a new value for any of the requested data points, with redrawing to rescale the Y-axis and/or X-axis if necessary.
Both the X-axis (time) and the Y-axis (range of specified engineering units) should be auto-scaling. Typical auto-scaling plotting packages assign numbers to the Y-axis based on plus and minus about 10% beyond the maximum and minimum numbers in the data being plotted.
Users should be able to store in a user-owned data structure some number (e.g.,10) of specifications for point vs time plots, with operations available to manipulate the specifications similar to those described above for customized tabular displays.
8.7.4 Data Point Library Display The Data Point Library is discussed in section 3.7 and chapter 6. Its purpose is to provide textual information to the Operations Center users to permit them to work .in close synchronization with the plant's Emergency Response Team, using the same plant-unique engineering and operational
" language". A conceptual Data Point Library distflay for a PWR is shown in Figure 8-6 and for a BWR in Figure 8-7.
8-25
1 ,
_ L0* I HO LEs TE"P LEGFI 0 0 0 0 0 0 0 0 0 0 0 0 7 6 s 4 3 2
- 0 0 0 1 1 4 - -
4 2 -
8 - 0 0 1 2 Y 7 - A
- L 8 P
/ ~
S T ~ ) I C , 1 0 S D O - 3 L
/ - E 1 - - A M 0
- V I
' R T
~ E T s
~ i 0 N v
~ 4 I
- T E N
,' T I
- U O N P
,' I 0
5 I
M A -
T
- - A
- 0 D 1
, (
~ I
- 0 E 5 6 M 8
- I T
, E R
_ U I G
_ 0 I
_ 7 F E -
M _
A _ -
N _
T I I
0 -
N _
8 U _
T _
N _
A _ 1 0
L _ ,
9 P , -
0 0 O 0 0 0 0 0 o s
0 0 5 0 0 s 2 2 i 1 e"I MAgY syS egESSU" ( eSI G) cdm o
l
I
)
I i
FIGURE 8-6 )
PVR DATA POINT LIBRARY REFERENCE FILE REACTOR UNIT: ABC i 1 LAST UPDATED: 23 MAR 87 NRC ERDS PARAMETER: AUX TEED TLOW POINT ID: AT105A PLANT SPECITIC POINT DESCRIPTION: ATV TLOW SG 11 ETR GENERIC POINT DESCRIPTION: ATV TLOW TO SG 11 FROM ELECTRIC ATV PUMP MIN INST RANGE: 0 MAX INST RANGE: 500 ENG UNITS: GPM ZERO REF: NOT APPLICABLE REFERENCE POINT NOTES: NOT APPLICABLE ENGINEERING UNIT CONVERSION: NOT APPLICABLE ,
i PROCESSED / DISCRETE: D # SENSORS: 1 HOV PROCESSED: NOT APPLICABLE LOCATIONS SENSED: ON LINE TO SG 11 OUTSIDE CONTAINMENT l ALARM SETPOINTS: HIGH TLOW AT 500 GPM TRIP / AUTO INITIATE SETPOINTS: NONE UNIQUE SYSTEM DESCRIPTION: THERE ARE 1 ELECTRIC AND 2 TURBINE DRIVEN ATV PUMPS. THE ELECTRIC PUMP HAS DEDICATED DISCHARGE LINES TO EACH SG.
THE FLOW ELEMENT FOR THIS POINT REPRESENTS THE LAST SENSOR PRIOR TO THE-l LINE ENTERING CONTAINMENT. THE 2 TURBINE DRIVEN PUMPS USE SEPARATE I l
PIPING TO THE SGs. MAZ RATED TLOV FOR THIS PUMP IS 450 GPM. SHUTOFT READ IS 1200 PSIG.
4 i
8-27
YIGURE 8-7 BVR DATA POINT LIBRARY REFERENCE TILE REACTOR UNIT: XYZ f 2 LAST UPDATED: 23 MAR 87 NRC ERDS PARAMETER: CST LEVEL POINT ID: C345ZO4 PLANT SPECITIC POINT DESCRIPTION: CS.TNK 1A LYL GENERIC POINT DESCRIPTION: CONDENSATE STORAGE TANK A LEVEL MIN INST RANGE: 0 MAE INST RANGE: 100 ENG UNITS: %
ZERO RIT: AT 04, 245,000 GALLONS REMAIN IN TANE RITERENCE POINT NOTES: VATER BELOV 0 IS USABLE BY ECCS PUMPS ENGINEERING UNIT CONVERSION: EACE 1% = 1692 GALLONS PROCESSED / DISCRETE: P i SENSORS: 2 50V PROCESSED: AVERAGE LOCATIONS SENSED: 2 SENSORS LOCATED 245,000 GAL ABOVE TANK BOTTOM ALARM SETPOINTS: LOV LEVEL AT 12%
TRIP / AUTO INITIATE SETPOINTS: NONE UNIQUE SYSTIM DESCRIPTION: THIS AVERAGED SENSOR READING IS FOR THE NORMALLY USED VOLUME OF THE TANK. THE REMAINING 245,000 GALLONS IS MONITORED BY 2 DISCRETE ALARMS AT 150,000 AND 50,000 GALLONS TOTAL REMAINING TANK CONTENTS. TOTAL TANK VOLUME IS 414,200 GALLONS.
NOTE: A SECOND IDENTICAL TANK NORMALLY DEDICATED 70 XYZ UNIT 1 IS AVAILABLE FOR Cross-CONNECTING TO THIS TANK AT THE BOTTON (ECCS)
SUCTION LINE.
8-28
---sa- -.ex___m__
8.8 DATA ACCESS FOR NRC REGIONAL OFFICE AND OTHER REMOTE USERS The functional capabilities described above allow non-local users to access the ERDS-hosted data either as remote users of computers in the Operations Center or by down-loading all (or part) of the ERDS-hosted data. That is, the general capabilities that allow data retrieval (and update announcement) operations by the ERDS data host computer to be requested by software running in other computers within the Operations Center will also support either form of remote access strategy. NRC should recognize an important aspect of this choice: NRC can choose to tailor the remote user support capabilities to promote their usage of a single central copy of the ERDS database (which is the choice we recommend), but NRC cannot prevent a determined remote user from accumulating and maintaining a down-loaded copy of the ERDS-hosted data. (The commercial online information publishing industry has tried, without success.)
The choice among these alternatives is really an NRC operational issue.
Supporting the downloading of all the data implies providing, to each data-swallowing site, technical and administrative leadership to the system managers that will be required to oversee the operational readiness and maintenance of each of the computers there. Supporting only online remote access to a fiendquarters-hosted database is, we believe, a much simpler burden, but the acceptability of this choice to remote users will depend in part on the magnitude and credibility of NRC-stated goals regarding continuous availability (i.e., fault-tolerance).
8.9 SYSTEM MANAGEMENT FOR DATA STORAGE AND RETRIEVAL The following special (non-steady-state) situations will need to be included in the ERDS design:
Incident startup.
Incident shutdown.
Incident changeover (one plant unit to another).
Operations Center exercising of teams.
Transition from exercise to incident startup.
Readiness testing of ERDS.
Software maintenance.
The maintenance of operational readiness of ERDS will require careful planning, well-designed procedures, and periodic tests. With the recommendations in sections 5.1.3 and 5.1.4 regarding formats of feed streams from feeders, all site-specificity of ERDS feed streams can be 8-29
i described by various ektegories of pre-stored data, without the need for any site-specific or feeder-specific software. This pre-stored feed-descriptive data will require data structures flexible enough to handle !
length differences arising in the different numbers of data points per.
feeder and the variable length of cut-and-paste instructions for pre-existing feed' streams. '
There will be many categories of plant descriptive data that will have to be I maintained as part of the system management effort. We recommend that 3
these be maintained in machine-readable form to the extent possible (i.e., for everything except diagrams and background descriptive material). This w111 enable use of computer-based tools for management of changes, generation l of summary reports, and generation of written correspondence with licensees and maintenance personnel, without having to be concerned about keying errors in the ' production of. correspondence causing failures to' communicate.
Although the data point descriptors are one category of plant descriptive data that could be obtained from licensees in machine-readable form, we I recommend that this complexity be avolded. There will be at most 80 characters of descriptor information per data point, and at most 70 data points per plant unit. The workload represented by manual keying of changes to this data at NRC from paper inputs seems negligible compared to the complexity of establishing and maintaining paths for machine-readable submissions of this data.
In general, for all categories of plant descriptive data that affect ERDS, we believe that paper is the best medium for representation of data in the interface between licensees and NRC. The appropriate structuring of this data, and limitations on choices for data being sought (including maximum number of characters, character set limitations, uppercase / lowercase . j requirements, etc.), can and should be reflected in the paper formats, so that processing of received data need not require-technical judgments. The use of forms having boxes for each solicited character of input represents the appropriate level of preciseness that'should be visible in these i interfaces.
There should be a periodic test of operability of the ERDS feed from esch feeder. We recommend roughly 4 times per year as an appropriate frequency. The testing should include the sending of actual data point .
values (not pre-stored test data) from each feeder for at least 30 minutes or 10 updates of each data point, whichever takes longer. The testing should include the use of all received data point values in the generation of all types of data displays. available to NRC users. . There should be some human examination of these displays for correctness to accompany.
8-30
i i software-implemented checks. The outcome of each periodic test should include a pass / fall result for each plant unit, together with an itemization of problems discovered.
i We estimate 2 full-time staff people as the level.of manpower required on the NRC side of the licensee /NRC interface for on-going management of ERDS system hardware, software, and data, after implementation of ERDS has been )
completed for each plant unit.
8.10
SUMMARY
OF CONCLUSIONS AND RECOMMENDATIONS These are selected highlights of the conclusions and recommendations presented in this chapter:
(8.1) ERDS should permanently save each incoming stream of characters to allow posthoc diagnosis of problems. However, this version of the data -
need not be preserved indefinitely nor made available for uses other than system maintenance.
(8.1) The online storage data structure from which each data point value will be retrieved should allow each value to have its own timestamp and i standardized quality tag.
i (8.2) ERDS should have some generalized mechanism which allows ERDS-computed data points, not transmitted from the plant site, to be computed from feeder-provided values, manually input values, plant-descriptive data, and other stored data. This mechanism sh'ould allow the computation process to be triggered by the arrival of a new update set. This mechanism is not expected to be needed'in the initial j implementation of ERDS.
(8.3) ERDS should permanently and formally archive all data point values after reception processing has created the representation to be used for ,
retrieval, together with the associated timestamp and stan'dardized quality I tag. The audit trail mechanism should receive, in addition, all manually entered data point values,- any changes made to plant-descriptive data, and all ERDS-computed data point values.
(8.4) ERDS should allow manual correction of manually entered data point values, and of feeder-transmitted data point values, by authorized users.
8-31
(8.5) ERDS facilities for data retrieval should make available all data point values stored by ERDS, allowing but not insisting upon hid-ing the existence of values having quality tags indicating suspicion.
(8.5) ERDS data retrieval facilities should provide interface mechanisms for software running on other computers. It sMuld not be assumed that all data consumers will be supported by the computer system that hosts the ERDS data. The interface mechanisms should include a broadcast of availability of a new update set.
(8.6) Online storage space needed to hold 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />' worth of data is estimated to be 14 MB.
(8.6) ERDS data storage and retrieval facilities should be specified to provide access to all online ERDS data with an outage of at most 10 minutes for any failure of one disk drive, CPU, or operating system, and requiring no special response by human users to restore accessibility after an outage.
(8.7) ERDS should have 3 kinds of display formats: tabular alphanumeric, data point vs time X-Y plots, and Pressure vs Temperature X-Y plots.
Each kind should include at least one format that is automatically updated by newly arrived data point values.
(8.7.1) Tabular alphanumeric displays should allow display of all data received by ERDS.
(8.7.1) Tabular alphanumeric displays should be organized by grouping data points under their parent parameter, and grouping parameters into Critical Safety Function groupings.
(8.7.1) Screen capacity for tabular alphanumeric displays should be 43 rows by 80 columns, but should automatically use a 24-row mode for better readability when display contents permit.
(8.7.1) A large flat-screen display device should be provided for the Reactor Safety Team room.
(8.7.1, 8.7.2, 8.7.3) ERDS should allow each user to define some personally customized tabular, point vs time, and Pressure vs Temperature displays.
(8.7.1) Data point descriptions provided by licensees which are longer than 32 characters should be edited to compress them while retaining pronunciation fidelity with the licensee version.
8-32 i
l 1
(8.7.2) A menu-selectable P vs T plot for historical and current data should be available. An overlay of the saturation curve should be.
Included on this plot.
(8.8) ERDS should allow remote users to make use of all data retrieval and display capabilities provided to local users in the Headquarters Operations Center, retrieving from one central copy of ERDS-hosted data.
(8.9)' The implementation of ERDS should avoid the crea' tion of plant-specific or feeder-specific software (in contrast with data).
(8.9) Paper is recommended as the best medium for transmission of I plant-descriptive data from licensees to NRC, including data point descriptor information.
(8.9) The operability of transmission from each feeder to ERDS should be tested periodically. roughly 4 times per year.
1 8-33
\
i~; ..
s 1 ,,
u i s.
9.0 ;
f This section intentionally omitted '
f' i
k w
t
)
\
1 1
1 2
4 I k r i l
1 v
. s ....,
! {
\ ' R I
i i
1 1
l i !
q u
10.0 GLOSSARY 5
s adhoc by-voice data points -- By-voice data poMis rnich 5 not represent ERDS parsmeters. They are selected for their relevaned to the everps of a specific incident. Contrast pith " predetermined 1
by-voice data points".
5 A/E Rad -- Air Qector Radiaticn ASCll -- American Standard Ccde foV InfrJme.tlon Interchange AT&T,. - einericsn Telephone and Tepgraph Co.
Aux Jeed Flow -- Auxiliary Feed Flow available update frequenc:. -- The most sfrequent periodicity at which a feeder is able to transmit av Waluen of a data point to ERDS.
B&W -- Babcock and Wilcox '
s BWR -- Boiling Water Reactor g BTR Parameter List -- see *ERDS Parameter L!st" s BWST -- Borated Water Storage Tank by-voice data points -- D'ata points whose values will be provided orally by a licensee rather than via electronic transmission from a feeder, but i which will be keyed into the ERDS database by NRC staff at headquarters. Subclasses are "adhoc" and " predetermined".
C1/see pCurles per second . <
client side -- The side of a statistical multipfexor that fdis the multiple .,
computer ports being r3Uitiplexed. Contjst with " link side". l
, command-Initiated dialing -- The triggering of dialing in an auto-dial modem ' !
by a command composed of characters which are sent to it as part of the data stream. Contrast wiAh "slgual-initiated dialing". i computer point -- same as " data point" g i configuration management -- The disseml}u,+1on or acquisition of updates to l l '
plant-descriptive data which are needed to describe changes in the meaning of data points. I Cont Press a- Containment Pressure '
Cont Rad 1-A Containment Radiation Cont Sump Norm -- Containment Sump Neenal '
Cont Temp -- Containment Temperature CPM -- Counts per Minute ,
^
CPU -- Central Procesting Unit CRT -- Cathode Ray Tube l CSF -- Critical Safety I' unction k CST -- Condensate Storage Tank , 4 CTS -- Clear To Send, one of the control sir,nals in the RS-232C interface (
standard.
DAS -- Data Acquisition System )
1 x s
1 10-1
i r j i data censurcers -- Humans and softnre which mako use bf ERDS rstored data point values.
data peint -- A plant-unit-speelfle time-varying data variable. The ones of interest to ERDS nre t?.use that represent ERDS parameters, data poinc catalog -- same as " data point dictionary" data point hscription -- A string of roughly 3040 characters' which describes the ?2eaning of a data point.
dara scint :f acriptor -- A cellection. of; machine-readable data entitles (not time varyirig) widch enco deseribe some aspect or attribute of a data point. -<
data point dictionary -- A licensee-maintained formal compendium of information describing an ' data rodnts specific to a plant unit.
data point I'dentiner -- A string of roughly 8-12 characters which uniquely identif!cs a data point among all dr.cn points of a plant unit or plant site. Typically non-mnemonic. Typically the search key for look-up
'in a data point dictionary. - . a Data Paint Ubrary -- The ERDS cc/nputer-resident textual descriptive Nforrnce library for all computer points transmitted by licensees to ERDS( '
data point value -- One ' time-specific s alue of 3. data poirA daughter -- A data point which reprennts en ERDS nuanner is a daughter of that parameter. See also " parent".
DEC -- Digital Equipment Corporation '
Deg P -- Degrees Fahrenheit dffference reporting -- A scheme in which a feeder tranumits to ERDS only tt,W data point values vthich differ from the last-transmitted values of the same da.tn points by a predetern/ned delta, display facilities -- Hardware or system software cr.pabilities for generation of dispicy features. Contrast with " disp;a5 format".
disp l.ay format -- Information content or' layout' icnventions of a display.
Cor,trast with " display facilities",
downstrem 4 -- In the flow of data from plant Instrumentation through licensee dat-a systems to NRC, the dhyction toward NRC.
DPL -- same as " Data Point Library" ,
DSU/CSU -- Data Service Unit / Channel Service Unit, a device that interfaces '
data terminal equipment (such as a computer) to a digital communication channel analogously to the ray a modem interfaces it i to an ' analog communleation channel. '
l DTR --" Data Terminal Ready, one of the control PMais in ths RS-232C I
interface standard.
DW -- Drywelb DW FD Sump Level -- Drywell Floor Drain Sump Level EBCDIC -- Extended Binary-Coded Decimal Intercht,nge Code ECCS -- Emergency Core Cooling System e t
10-2
-i
___m__________-.__
e- .
1 Eff Gas Rad - Effluent Gaseous Radiation Eff Liq Rad -- Effluent Liquid Radiation E-format -- same as "E-notation" EGA -- Extended Graphics Adapter, a subsystem of an IBM-compatible Personal Computer.
E-notation -- Engineering or exponential notation, which represen'ts a numeric '
value as a number times a power of ten. Contrast with "F-format".
ENQ/ACK -- A flow control convention in which the sender sends a control . i character (Enquire) and the receiver responds with a different I control character (Acknowledge).
ENS -- Emergency Notification System EOF -- Emergency Operations Facility ERDS -- Emergency Response Data System ERDS-computed data point -- A data point computed by ERDS, not transmitted from a feeder. The inputs to the computation are feeder-transmitted data point values and stored plant-descriptive data.
ERDS feed -- The movement of data from a feeder across a licensee /NRC electronic non-voice interface to ERDS.
ERDS Parameter List (s) -- The NRC-specified set of generic (non-plant-specific) data items (ERDS parameters) to be obtained electronically from licensee data systems. Really two distinct lists, a BWR Parameter List and a PWR Parameter List. See also " data point".
ERF -- Emergency Response Facility Feed Switch -- A licensee-controlled (and licensee-implemented) logical toggle switch which can enable / disable the flow of data from licensee computer (s) into ERDS.
feeder -- A licensee data system (computer) that will connect to ERDS to ,
transmit at least one data point.
l feeder site -- A licensee facility that is the location of a feeder. It may be a plant site, corporate headquarters, or some other location of 11censee j
facilities. j F-format -- Representation of a number without an explicit power-of-ten multiplier. Contrast with "E-notation".
FT -- Foot or feet 1 GAL -- Gallon (s)
GPM -- Gallons per Minute l HJTC -- Heated Junction Thermocouple HPCI -- High Pressure Coolant Injection HPCS -- High Pressure Core Spray HPSI Flow -- High Pressure Safety injection Flow H: Cone -- Hydrogen Concentration IBM -- International Business Machines Corp. '
ID -- Identification or identifier 10-3 l
l IEEE -- Institute of Electrical and Electronic Engineers IDAS -- Intermediate Dose Assessment System l initialization packet -- A collection of information that must be transmitted to l
ERDS from a feeder when transmission is initiated, but need only be transmitted once.
Internal update frequency -- The periodicity at which a feeder receives (!n !
l Its internal storage) new values for a data point from upstream I instrumentation or computers.
K -- 1:llo, indienting a multiplier of 1000 for physical units but 1024 for computer-related units.
i keyword identification -- A scheme in which a data entity is identitled by an explicit tag which accompanies it. Contrast with " positional".
KLBM/HR -- Thousand Pounds Mass per Hour lead feeder -- At a multi-feeder site, the feeder whose serial port will trigger dialing by the modem.
link side -- The side of a statistical multiplexer that faces the modems sitting between the interacting multiplexors. Contrast with " client side".
LPCI Flow -- Low Pressure Coolant Injection Flow LPSI Flow -- Low Pressure Safety Injection Flow MB -- Megabytes MLB/HR -- Million Pounds Mass per Hour MNP -- Microcom Network Protocol, a proprietary protocol in which asynchronous modems provide transmission error detection and correction.
Mn Steam Line Rad -- Main Steam Line Radiation
]
NDL -- Nuclear Data Link j NI-IR -- Nuclear Instrument, Intermediate Range NI-PR -- Nuclear Instrument. Power Range NI-SR -- Nuclear Instrument, Source Range non-regulatory -- same as " voluntary" NPSH -- Net Positive Suction Head i NRC -- (U.S.) Nuclear Regulatory Commission !
NSSS -- Nuclear Steam Supply System NTOL -- Near-Term Operating License l
l Os Cone -- Oxygen Concentration OOS -- Out of Service Operations Center -- The location at NRC Headquarters where the headquarters-based incident response activities of the ageracy are centered.
l P&ID --Piping and Instrument Diagram parent -- A data point which represents an ERDS parameter has that parameter as its parent. See also " daughter".
PBX -- Private Branch Exchange plant -- A plant site, or one or all the plant units at a . plant site.
10-4
(
. t 4
plant-descriptive data -- Data that describes some aspect of a licensee's systems (reactor, meteorological, radiological, computer, or other) or otherwise contributes to the meaning of a data point but does not normally change during an incident, plant site -- A nuclear power plant site containing one or more plant units.
plant unit -- One nuclear power plant.
PMT -- Protective Measures Team j PORY -- Power Operated Relief Valve l positional identification -- A scheme in which a data entity is identitled by j a convention based on its position within a sequence. Contrast with l "k eyword".
predetermined by-voice data points -- By-voice data points which represent ERDS parameters and would be obtained by voice in any incident at that plant unit. Contrast with "adhoc by-voice data points". j pre-initiation data -- Data from licensee data systems which indicates I conditions before data transmission to ERDS begins.
prescriptive -- same as " regulatory"
)
PRZR Level -- Pressurizer Level l PSIG -- Pounds per Square Inch, Gauge ]
P vs T -- Pressure versus Temperature (plot)
PWR -- Pressurized Water Reactor PWR Parameter List -- see "ERDS Parameter List" .
Rad -- Radiation RCIC Flow -- Reactor Core Isolation Cooung i RCS CHG/MU -- Reactor Coolant System Charging and Makeup reactor site -- same as " plant site" i reactor unit -- same as " plant unit" reception processing -- Processing of the stream of characters received by ERDS from a feeder to prepare the received data for long-term storage and retrievability.
regulatory -- An approach to implementing the plant unit connections of ERDS after rule-making regulatory actions by NRC. Contrast with
" voluntary". j represent -- One or more data points are said to represent an ERDS parameter.
RHR -- Residual Heat Removal (system)
RSADS -- Reactor Safety Analysis and Display System RST -- Reactor Safety Team RTS -- Ready to Send RVLIS -- Reactor Vessel Level Indicating System RWST -- Reactor Water Storage Tank Rx Coolant Flow -- Reactor Coolant Flow Rx Cool Rad -- Reactor Coolant Radiation Rx Val Level -- Reactor Vessel Level 10-5 l __ ______________ _ _ - _ _ _ .
SDLC -- Synchronous Data Link Control S/G -- Steam Generator signal-initiated dialing -- The triggering of dialing in an auto-dial modem by a logic state transition on one of the control wires of the RS-232C interface. Contrast with " command-initiated dialing".
SMM -- Subcooled Margin Monitor SPDS -- Safety Parameter Display System Stab Class -- Stability Class standardize -- A plant-unit-specific data point is standardized by undergoing an algorithmic conversion which changes its meaning to a more plant-independent basis.
Supp Pool Lvl -- Suppression Pool Level Supp Pool Temp -- Suppression Pool Temperature survey site -- A location visited during surveying activities in this project, where meetings were held with licensee technical staff.
Temp -- Temperature Temp - CET -- Temperature. Core Exit Thermocouple T-hot -- Temperature. Hot Leg (loop)
TSC -- Technical Support Center l uC1/sec -- Micro Curles per Second I
unit -- same as " plant unit" l update asynchrony -- The changing of the meaning of a data point without a corresponding change to the plant-descriptive data which provides the definition of its meaning. See also " configuration management".
update frequency -- The periodicity at which a feeder transmits new values of a data point to ERDS. See also "available update frequency" and
" internal update frequency".
update set -- A group of data point values transmitted to ERDS by a feeder in a batch, all of which can share one timestamp (i.e., all of which are current at the same moment in time).
upstream -- In the flow of data from plant instrumentation through licensee
! data systems to NRC, the direction toward the plant instrumentation.
U.S. -- United States VAC -- Volts Alternating Current voluntary -- An approach to implementing the plant unit connections of ERDS in the absence of prior rule-making regulatory actions by NRC.
Contrast with " regulatory".
Wind Dir -- Wind Direction XON/XOFF -- A flow control convention in which a receiving computer sends an XOFF control character to mean " pause" and then sends an XON control character to mean " resume".
10-6 l
- ATTACHMENT 5 p.nn wne za H 75)
Published in advance of incorporation in NRC Manuel Chapter 0904 File and retain in Manual until superseded.
i UNITED STATES NUCLEAR REGULATORY COMMISSION NRC MANUAL BULLETIN NO. 0904-3 DATE: January 21, 1987
SUBJECT:
NRC COMPUTER SOFTWARE POLICY This Bulletin sets forth NRC policy on the acquisition / development, )
modification, copying and distribution, use, and disposal of NRC computer i software, particularly microcomputer software. It provides overall agency I policy which should serve as the basis for Office / Region internal control !
of both microcomputer and mainframe software development and use, including development and use by both NRC staff and contractors.
s 7 1
-Yfrm.g . '
William G. Mcdonald
, Deputy Executive Director for Operations /IRM l
4 0 I. Purpose The purpose of this Bulletin is to set forth NRC policy on the acquisition /
development, modification, copying and distribution, documentation, use, and disposal of NRC computer software, particularly microcomputer software. A major goal of the policy is to encourage innovative use and sharing of software while at the same time assuring continued compatibility among software products and consistency with the NRC's long range ADP plans.
II. Definitions Corporate application: (1) The use of computer technology that involves the creation, updating, or modification of NRC corporate data; or (2) the creation or modification of a computer system that affects agency standards for computer hardware, software, electronically-stored information, or electronic information communication or delivery.
Corporate data: NRC data to which electronic access is required by more than one Office / Region or data which is deemed essential by the EDO to support NRC's mission.
Corporate Data Network (CDN): An information management concept which provides for the aggregation of NRC corporate data in shared databases. integrated with office automation systems and accessed through end-user computing.
Customized applications software: Software that is developed specifically to meet the needs.,of a particular user or organization where the development requires programing or the equivalent. Customized applications may be developed with high level programming languages such as BASIC, FORTRAN, or COBOL, with' data base management systems such as RAMIS, MARKIV, or IDMS/R, or with general purpose microcomputer software such as dBASE III or LOTUS 1-2-3, when user-written programs or macros are needed to create customized input screens or output reports. Customized applications include both scientific and non-scientific applications.
Individual application: The use of computer technology by an employee to enhance his or her personal productivity at the NRC, with no impact on NRC functions beyond its affect on the user's individual performance.
Non-scientific applications software: All customized applications software except for scientific applications software. Examples include administrative applications such as payroll, personnel, and travel systems; management information applications such as systems to provide status on office projects and budgets, and technical information applications such as systems for storage and retrieval of nuclear plant data, siting data, and reliability data.
NRC standard microcom) uter software: Vendor software supported by NRC (See NRC Bulletin 0904-1 for tie list of this software).
1 1
Organization-rique application: Any NRC computer application which is neither an individual Eplication nor a cor] orate ap)lication. Examples are (1) the use I of computer tecinology to accomplisi the worc of a small, self-contained or lower level NRC unit (usually a section, branch, or small non-program office) where the function is of a self-contained, stand-alone nature not requiring data sharing beyond the bounds of the unit; and (2) any application based on the use of corporate data (typically by querying or downloading from corporate data bases) l without the need to maintain and update a duplicate copy of the data.
l Public domain software: Free or minimal cost software available from such sources as government agencies, certain periodicals, and computer user groups.
Scientific applications software: A type of customized applications software developed by or for a program office to perform scientific calculations in support of NRC's mission. Examples are computer codes to calculate reactor plant thermal-hydraulic response in accidents, the nature and consequences of radiological releases, statistical analyses, structural response analyses, or probabilistic risk analyses.
Vendor software: General or special purpose software that is purchased or leased to be used without modification.
III. Software Acquisition / Development i
There are three major types of software that are used on NRC computers:
(1) vendor software; (2) public-domain software (sometimes called "shareware" or "freeware"); and (3) customized applications software (see section 11 for definitions). When a requirement has been identified for the acquisition or development of software, the end user, or for more complex applications, the Office of Information Resource Management (IRM), in coordination with the end user, should first determine if the application should be placed on a mainframe or on a microcomputer. If the application is appropriate for a microcomputer, it should then be determined if NRC standard microcomputer software can be used. If none of the standard software is appropriate, the use of other vendor software should be considered next. Only in the event that no appropriate vendor software is available should customized application development be considered, as it is generally more ccst-effective to use special- or general-purpose vendor software than to custom-build an application.
Vendor Software:
IRM acquires all vendor software for the NRC except where authority is delegated by IRM on a case-by-case basis.
NRC Bulletin 0904-1, " Policy and Procedures for Acquiring Microcomputer Equipment, Software, and Support Services," contains a list of standara .
software, procedures for requesting the software, and the procedure for l requesting that additional software be added to the list. IRM will also give priority consideration to the acquisition of other software for specific applications, if none of the standard software will meet the user's requirement or if the acquisition of the other software would eliminate or substantially reduce the need for programming. Standard sof tware is fully supported by IRM while the other software will not normally be supported by IRM.
2 1
I*
r
1 I
l l
IRM coordination and approval is required for purchase or lease of vendor 4 software by contractors or DOE laboratories for use in satisfying an ADP l requirement of an NRC contract. i It is NRC policy that a copy of individually-licensed vendor software be acquired for each computer on which the software will be used. For site-licensed software, IRM will supply.one copy for each computer where the software is required.
Public Domain Software:
Public domain microcomputer software (such as utilities useful with NRC l
standard sof tware available from the ITS) may be acquired for individual ,
use on NRC equipment provided there is no NRC standard software to perform the function.
l IRM will acquire analytical codes which have been developed by non-NRC 1 sources (e.g., codes available from Federal code centers or other government agencies), upon receipt of a memorandum with the_ particulars <
addressed to the Director, Division of Information Support Services, IRM. l I
All public domain software with which there is a cost associated, even if minimal, must be obtained by request from IRM.
Unless it is on NRC's list of standard software, public domain micro-computer software shall not be acquired for organization unique or corporate applications. TEis is to avoid NRC dependence on unsupported, undocumented, and in some cases harmful, products for applications which could affect critical agency functions.
Computer users should be aware that there have been numerous reports of purposely destructive public domain software which could seriously damage NRC microcomputer or mainframe systems and data. Since individuals i could be held personally responsible for such damage (See NRC Appendix '
5201, Part I, Paragraphs H and J), users would be wise to limit their use of public domain software to those programs which have been screened by ,
IRM.
Customized Application Software:
Office / Region management is responsible for monitoring end-user applications development to assure compliance with this bulletin and i to prevent the development of unnecessary or duplicative systems.
In general, customized applications software shall be developed only when no vendor software is available to meet the need or when no applications sof tware is available to meet the need through sof tware sharing.
Where possible, it is usually more cost-effective for end users to develop an application using a general purpose software package such as dBASE III or LOTUS 1-2-3 than to use a programming language such as FORTRAN or 1 BASIC. ;
3
Where possible, end users creating customized applications should first consider obtaining necessary data from the Corporate Data Network (CDN) or from other existing IRM-maintained systems, thus avoiding the need to maintain duplicate data.
Table I sunnarizes the approvals necessary for development of non- i scientific customized a)plications software depending on the class of I use, as defined in the )efinitions section of this Bulletin, and on the software developer. Note that the level of concurrence relates to the
" level of risk" associated with each class of use. Individual applications involve a very minimal risk to the agency because they do not affect agency functions; organization-unique applications have a higher level of risk because they do impact agency functions but affect only a single organi-zational unit; corporate applications have the highest risk because of their potentially wide spread impact on agency functions. Note also that' all development of non-scientific customized application software by other inan end users must be approved by IRM. This is necessary for the proper central administration, control, and sharing of software and data, and to assure that staff and contractor resources are not diverted from direct mission support. In general, IRM will develop corporate applications and l any organization-unique non-scientific applications which are either too complex or otherwise inappropriate for development by end users. Where appropriate, certain non-scientific applications may be developed by the program offices by means of contracts or DOE laboratory agreements which have been reviewed and approved in advance by IRM on a case-by-case basis.
l The "N/A" entry in Table 1 reflects agency policy that IRM and contractor resources will not be used to develop applications for individual use.
To assure that contract deliverables are portable and are compatible with NRC ADP equipment and software, it is the responsibility of offices /
regions to include Attachment 1, " Development, Submittal, Distribution and Documentation Requirements for Machine-Readable Contract Deliverables" in the statement of work for all contracts or DOE laboratory agreements which could involve the development of scientific or non-scientific applications software or other machine-readable contract deliverables. Offices / Regions shall assure that contractors and DOE Laboratories comply with the require-ments in Attachment I and shall specify any additional constraints such as memory size and specific software version and equipment configuration of the NRC machine (s) on which the applications will eventually run.
1RM coordination and approval is required for purchase or lease by contractors or DOE Laboratories of software or ADP equipment (including microcomputers, microcomputer boards, terminals and peripherals) for use in satisfying an ADP requirement of an NRC contract.
Scientific applications software is developed by or under-the guidance of the program offices. Contracts and DOE Laboratory agreements which involve the development of such software must include Attachment 1, " Development.
Submittal. Distribution and Documentation Requirements for Machine-Readable Contrect Deliverables," but require IRM approval only when:
4
- the contract or DOE laboratory agreement involves the purchase or lease of sof tware or ADP equipment (including, but not limited to, microcomputer, ;
microcomputer boards, terminals or peripherals) for use in satisfying a requirement of the contract or DOE Laboratory Agreement;
- use by the NRC of deliverables (e.g., software or data) developed under the the contract or DOE Laboratory Agreement will necessitate the purchase or lease of ADP equipment, software, or ADP services not already available to the NRC staff, including, but not limited to, timesharing services, niicrocomputers, terminals, microcomputer boards, peripherals, or vendor software;
- the contract or DOE Laboratory Agreement specifies that the NRC will provide timesharing services, or that the contractor will acquire timesharing services which could be more cost-effectively furnished l by the NRC under its own timesharing agreements; or l - any of the requirements in Attachment 1 are to be waived or modified. I It is the responsibility of Offices / Regions to obtain IRM coordination and approval when required by this Bulletin. It is the responsibility of the Office of Administration's Division of Contracts to ensure that the necessary coordination and approval is obtained before the contract is initiated.
NRC Bulletin 0904-2, "ADP Responsibilities, Planning, Management, and Delivery of System Software Services," contains procedures for requesting IRM development of customized application software.
l Table 1 l
l Required Approvals for Non-Scientific Customized Applications l Software Development Usage ----------------- Developer ----------------
Category NRC End User Contractor, DOE, IRM Staff, l
l Individual None N/A Organization- Office / Region
- Office / Region unique and IRM Corporate All affected All affected Offices / Regions Offices / Regions i and IRM and IRM l
l l *0ffice/ Regional approval or as delegated by the Office / Region to lower l
organizational levels.
1 5
l I
IV. Software Modification Vendor and Public Domain Software Modification of almost all vendor software, and some public domain software is prohibited, except as described in the installation instructions provided by the vendor or author. All microcomputer software supplied by IRM is installed in a standard way, and there are several reasons why users should only rarely modify the way that the software is installed: .
The use of all NRC standard microcomputer software, if installed according to standard instructions provided by IRM, is documented in the NRC ADP Services Guide. Changes to the installation may make use of the documentation difficult or impossible.
IRM installs software in a standard way allowing for ease of trouble shooting by the ITS, should the need arise.
Modification of the software or of the menu structure on machines with a fixed disk may make subsequent software installation or upgrades more difficult.
Modification is inconsistent with software portability and standardization, and may confuse other staff members who expect to find the standard installation when using an NRC machine.
For these reasons, users contemplating modifications should consult the Information Technology Services Support Center to discuss possible implications.
l Customized Applications Software '
All data and software created by end users may be modified as desired.
It is the responsibility of office / region management to assure that all modifications made by end users to such applications (except individual applications) are recorded in a change log and incorporated into the i application documentation.
All software maintained by IRM will be modified by IRM in accordance with the procedures in NRC Bulletin 0904-2.
l 1
i t.
~
V. Software Copying and Distribution Vendor Software IRM distributes all vendor software used by the NRC.
Copying vendor software other than for authorized back-up purposes, or using a software package on a machine for which it has not been authorized may be a violation of software licensing agreements and could lead the vendor to take legal action against the NRC. NRC employees who violate-licensing agreements by making or using unauthorized copies of NRC software or any other vendor software, risk both disciplinary action and-possible suit by the vendor. Unauthorized use or copying of proprietary software should be brought to the attention of the Office of Inspector and Auditor and the Office of Administration's Division of Security.
It is NRC policy that individually-licenced software be used only on the machine for which it was purchased and to which it was assigned by IRM.
'If software must be moved from one machine to another, users should notify IRM's Hardware and Software Acquisition Branch (Headquarters) or the appropriate regional program support staff so that software inventory 1 records can be updated.
Public Domain Software Public domain software may be copied and distributed as desired, subject to any restrictions made by the author, for use in individual applications.
Any public domain software approved for organization unique or corporate applications is distributed by IRM. I Customized Applications Software Customized applications and associated data created by end users may be l copied as required. ;
1
^
If possible, users should avoid storing non-copyrighted data or programs on the same diskettes as copyrighted vendor software. i In cases where internal or public distribution of customized applications software (including scientific applications software developed by NRC-staff or contractors either for mainframes and microcomputers) is'appro-priate, such distributions are performed by, or under.the guidance of, IRM to assure that applications receive at least. minimal review for compliance with documentation and copyright standards before release.
IRM will assure that programmatic distribution requirements are met'for-public and non-public software. NRC staff should mot distribute any software for either microcomputers or mainframes on an ad hoc basis. NRC Contractors or DOE laboratories should not distribute any NRC software for either microcomputers or mainframes without formal approvals as described.
in Attachment 1, Section 3..
7
VI. Documentation ,
Vendor Software One copy of software documentation is provided by the vendor for each vendor software package acquired by the NRC. This documentation is provided to the user with the software.
IRM fills out a Software Locator Infonnation Sheet for all vendor software acquired by the agency.
Public Domain Software Documentation for public domain software is usually provided by the author, but may be limited.
If public domain software is obtained directly by a user, he or she should send a copy of documentation (if any) and a Software Locator Information Sheet (see Exhibit 1) to IRM, since other individual users may be interested in the software. IRM will fill out a Software Locator Information Sheet for any public domain software which it acquires.
Customized Application Software Creation of written documentation is an important part of the development and maintenance process for all customized applications. There are usually two types of documentation associated with each application:
(1) user documentation, and (2) technical or programmer documentation. I The first type of documentation is needed so that staff other than the developer can effectively use the system. The second type of documentation is needed in order to effectively maintain and/or change the system. It 1 is good practice for users to document all applications that they develop, i even those limited to individual use. It is mandatory that documentation be developed for all organization-unique use and corporate use applications so that staff other than the developer can use the software and so that the software value is not lost if the developer moves to another assignment or separates from the agency. Microcomputer Application Documentation Standards, prepared by IRM, are available from the ITS Support Center.
It is IRM's responsibility to create and maintain in a documentation library, user and programmer documentation for all applications which it develops. Software modifications will be recorded in a change log and incorporated into the documentation. A copy of the user documentation will be provided to each user of the software. 3 j
lt is the responsibility of Office / Region management to assure that user and programmer documentation is developed and maintairted for organization- i unique and corporate applications developed by end users. A copy of the l documentation for each of these applications should be maintained by each '
office, preferably in a single location. Software modifications should be recorded in a change log and incorporated into the documentation.
L !
Offices / Regions are responsible for filling out a Software Locator Information Sheet for each end-user developed application and submitting new and updated sheets to IRM as part of their inputs to the yearly ADP Planning Call.
Documentation requirements for contractor-developed software are covered in Attachment 1, Section 4 VII. Software Use Software Sharing IRM actively supports software and data sharing within the agency. To encourage sharing of software, IRM maintains a Software locator directory of all software acquired or developed by the NRC. IRM maintains the software locator information for all standard NRC vendor software and all applications software maintained by IRM. It is the users' responsibility to complete and submit the Software Locator Information Sheets (see Exhibit 1) for all other software acquired or developed for their use or use by their contractors.
Personal Use of NRC Software and Hardware NRC-accessible mainframes, NRC minicomputers, and NRC microcomputers and associated software may be used only for NRC official business per NRC Appendix 2301, Part II. No personal use can or will be authorized. Employees who misuse NRC property or incur unauthorized timesharing costs may be subject to discipli-nary action.
Use of Personally-Owned Hardware and Software for NRC Work Personally-cwned hardware and software may be used at home for NRC work provided that (1) no sensitive unclassified or classified information is accessed, processed, stored or telecommunicated; (2) work products are compatible with hardware and software available to the employee at the office; (3) any use of personally-owned hardware and sof tware for purpose of telecommunication with NRC-accessible timesharing facilities or electronic bulletin boards shall be in strict accordance with the security regulations of such facilities and with NRC security regulations associated with computer access as specified in NRC Appendix 2301, Part II.
The NRC will supply any hardware and software needed for NRC work. Personally-owned proprietary commercial software may not be used on NRC computers and NRC software may not be used on personally-owned computers. A limited number of portable computers and software are available from the IRM Systems Support 4 Branch for temporary loan where necessary, j Backups of Data and Programs ;
IRM makes or sends for back-up copies for all NRC standard vendor software, and provides both the original and the back-up copy to the user. Before making additional back-up copies, users should consult the software documentation and Chapter 8 of the NRC ADP Services Guide, or call the ITS Suppcrt Center for assistance.
9 l
\
l
Both diskettes and fixed disks used on microcomputers are subject to occasional damage or failure and, hence, data loss. Users sometimes inadvertently purge data files or programs. For these reasons it is good operating practice for users to make backup copies of important datt and applications programs which they write, even those limited to individual use. It is mandatory that backup procedures be developed, documented and used for all data and programs which are in the organization-unique or corporate use categories. The system developer (whether IRM or an end user) is responsible for providing the documentation on the backup procedures.
Backup copies of critical applications software and associated data should 'De placed in the NRC archival facility, where they will be retained under appropriate environmental conditions and will meet the requirement of storing the backup copy in a separate location from the working copy. Contact the Information and Records Management Branch for further infomation.
Security No classified infomation may be processed or stored on a mainframe, word processor or microcomputer without the prior written approval, guidance and authorization of the NRC Office of Administration's Division of Security (SEC).
No sensitive infomation, including unclassified Safeguards Information (SGI),
proprietary data, information which is withholdable from public disclosure under the " Privacy Act," F0IA, or other regulations, may be stored on systems with nonremovable disks without prior approval from SEC. If a computer system contains such infonnation, it is the user's responsibility, and that of his or her supervisor, to review the appropriate security guidelines or consult with SEC for assistance. Diskettes containing sensitive information must be locked up when not in use and must be purged of all infomation before release for another purpose.
Further written guidance on the processing / storage of classified or sensitive data on NRC microcomputers, mainframes, and word processors is available in NRC Appendix 2301, Parts I and II, and in " Security Guidance Outlines" available from SEC or from the Infomation Technology Services Support Center.
Microcomputer equipment, software and data should be protected from possible damage or theft by taking reasonable precautions. Software should be con-trolled during business hours and locked up, if possible, at the end of the day. No software may be removed from NRC premises without a property pass or NRC form 119.
All applications shall be developed in accordance with requirements contained in NRC Appendix 2301, Part II, Section A.6, " Security Measures of NRC Computer Centers and Unclassified Applications Systems."
j Software Ownership All data or programs written by NRC staff for government work that are entered into word processors, or small or large computers, regardless of ownership or location of the processors or computers, are the property of the government and may be considered government records.
10
k I I VIII. Disposal of Obsolete or Unsupported Software Vendor Software i l
- Vendor Software which is owned by the NRC, but which is no longer on the q list of supported software may be retained until existing applications are converted. Users are encouraged to convert such applications to supported .
software as quickly as possible with advice from the ITS Support Center. !
IRM may provide further assistance for the conversion of critical appli-cations upon written request. No new applications should be developed with unsupported software. Once all applications have been converted, unsupported software should be returned to IRM for disposal.
Customized Applications Software Obsolete applications software, including scientific codes, should be disposed of in accordance with the applicable NRC records disposition schedule (see NUREG 0910). If the schedule requires retention, the software and documentation should be provided to the NRC Information~and Records Management Branch for storage in the NRC archival facility.
i 1
h
Exhibit 1 !
NRC SOFTWARE LOCATOR INFORMATION FORM
- 1. FY: 2. SOFTWARE TITLE:
- 3. ACRONYM: 4. VERSION #:
- 5. FULL SYSTEM (Y/N): 6. MACR 0/ SUBROUTINE (Y/N):
- 7. CLASSIFICATION: (Checkone) .
SCIENTIFIC CODES l ADMINISTRATIVE SUPPORT (Budget, Travel, Personnel, etc.)
GENERAL PURPOSE (Management Information, Tracking, etc.)
TECHNICAL INFORMATION PERSONAL PRODUCTIVITY
- 8. SENSITIVE (Y/N): CLASSIFIED (Y/N):
- 9. STATUS (A= active,1= inactive,N=not used,U=under devel/ test,P= planned):
If 9. STATUS =I or N: 9a. LAST USED YEAR: 9b. SUPERSEDED (Y/N):
If 9b. SUPERSEDED =Y: 9bl. BY WHAT? ACRONYM:
VERSION #:
- 10. REQUIRES FURTHER DEVELOPMENT, MODIFICATION, OR UPDATE (Y/N):
10a. CURR FY EFFORT: CONTRACT 5: (K NRC STAFF YEARS:
10b. NEXT FY EFFORT: CONTRACT $: (K NRC STAFF YEARS:
- 11. NRC SPONSOR: OFF DIV BR ,
SPONSOR CONTACT: LAST: FIRST: MI: !
- 12. DEVELOPER: (Checkone)
HRC DATA PROCESSING STAFF (RM/D)
NRC EMPLOYEE OTHER THAN RM/D NAME - LAST: FIRST: MI:
NRC CONTRACTOR OR DOE LABORATORY - if checked provide:
CONTRACTOR NAME: FIN #(s): , ,
CONTRACTOR CONTACT - LAST: FIRST: MI:
PHONE:
VENDOR /0FF THE SHELF PUBLIC DOMAIN, SHAREWARE, OR FREEWARE
- 13. USERS: (Check all that apply)
NRC STAFF NRC CONTRACTOR (including DOE laboratories)
APPLICANT / LICENSEE OTHER (specify)
- 14. REGULATORY APPLICATION AREA (Check all that apply to this software):
licensing application related to 10 CFR Part (e.g., 50 if reactors, 60 or 61 for waste disposal f acilities,stc.,
see instructions for further examples) operatiorici data analysis event or accident analysis emergency response inspection / enforcement research on other (Cescribe):
,. . 12 _ _
s *
- 15. PAST OR PRESENT LICENSING USE (Check all that apply to this software):
Has been used or is being used by NRC staff or NRC contractor in the licensing process-Is identified in the Standard Review Plan, Section
-"-~ Has been specifically cited by the NRC in official correspondence (e.g., Safety Evaluation Reports)
Is ioentified in an NRC Regulatory Guide, Number Is identified in a Branch Technical Position. Specify Is specified in other regulations. Speci fy Is specified in an industry code or standard. Specify Other licensing use. Describe
- 16. KEYWORDS (Seeinstructions):
- 17. DESCRIPTION (See instructions):
- 18. APPLICATION HAS RECEIVED PEER REVIEW /QA (Y/N):
If 18. PEER REVIEW /QA=Y, DESCRIBE HOW AND BY WHOM:
- 19. DOCUMENTATION:
NUREG #(s) , ,
LATEST NUREG PUBLICATION DATE (MM/DD/YY):
USER'S GUIDE (Y/N) UP-T0-DATE (Y/N':
PROGRAMMER'S GUIDE (Y/h) UP-TO-DATE(Y/Nh:
- 20. DISTRIBUTION:
By hRC/IS (Y/h): By NRC/ITS (Y/N):
IS System No: ITS Control No:
l' By NESC (Y/N): By RSIC (Y/N):
NESC No: RSIC No:
If "N" to ALL of the ebove complete the following:
20(A). BY WHOM: LAST: FIRST: MI:
ORGANIZATION: (If NRC, provide Branch abbrev.)
20(B). If NESC or RSIC is marked as "Y", please provide the following:
External Availability Category NTIS/ DOE No.
UhllMITED PB No.
U.S. ONLY DE No U.S. GOVERNMENT SPECIAL 13
- 21. COMPUTER ON WHICH INSTALLED OR TO BE INSTALLED (Check any that apply):
NRC MICR0 NRC MINI NRC-ACCESSIBLE MAINFRAME P1 (PC 256K) B1(DG6000) A1 (NIH)
P2 (PC 640K) B2(DG8000) - A2 (ORNL)
P3(XT256K) B3 (OTHER DG) A3 (BNL) i P4 (XT 640K) A4(INEL) l 0 (OTHER) Specify 1 CONTRACTOR COMPUTER:
Computer Vendor Name Model
- 22. LANGUAGES / PACKAGES (Mark Primary [P] once and any others as [S] Secondary)
BASIC RAMIS dBASEIII FORTRAN IV SYSTEM 2000 DOS FORTRAN 77 (V) WYLBUR LOTUS 1-2-3 COBOL MARKIV PL/1 - OYHER (SPECIFY)
- 23. NRC CONTACT: (Name of NRC employee who filled out this form)
LAST: FIRST: MI:
OFF DIV BR PHONE:
SIGNATURE: DATE:
l l
l 14 L_ __ _
l l
Attachment 1 Development, Submittal, Distribution and Documentation Requirements for I Machine-Readable Contract Deliverables This document provides requirements for contractors developing software, data or other machine-readable deliverables for the Nuclear Regulatory Comission (NRC). l Its purpose is to assure that any such deliverables can be readily implemented I and used on NRC equipment and can, if required, be easily disseminated or transferred to other data processing sites. This implies the use of standard software packages, programming languages, and compilers which are compatible with the NRC hardware and software environment, as well as adherence to good programming and documentation practices.
l This document applies to all machine-readable deliverables for use on micro-computers hnd to scientific applications for use on msinframes and m % computers. ;
Requirements for non-scientific applications for use on mainframes or mini- l computers are provided by IRM on a case by case basis. I All computer applications and associated data developed under contract to the NRC or ,
under a DOE laboratory agreement are the property of the NRC unless stated !
otherwise in the contract or DOE laboratory agreement. These items must be submitted to the NRC project manager in machine-readable fom at or before contract completion. Microcomputer software and data deliverables should be supplied on diskette and conform to the criteria stated in section 1 below.
Mainframe or minicomputer software and data deliverables should be submitted I on tape and conform to the criteria in section 2 below.
l All machine-readable deliverables must be accompanied by appropriate documentation as specified in sections 1, 2, and 4 below. Conversely, contractor reports citing the use of computer codes must be accompanied by said computer codes, I i
- 1. Deliverables for Use on Microcomputers I All deliverables developed for use on microcomputers must meet the following criteria unless a written waiver is obtained in advance from the NRC project manager and approved by the Division of Automated Information Services (IRM):
- a. Deliverables should be submitted on diskettes.
I
- b. All diskettes should be capable of use on an IBM PC or '
compatible microcomputer using one of the software packages i supported by the NRC Division of Automated Infomation Services (see Table 1, attached). All programs developed i for the NRC must be written using one of the standard software packages.
E
- c. In particular, documents (e.g., reports) submitted in machine-readable form should be produced with IBM DisplayWrite word processing software. This will allow them to be used both on NRC microcomputers and word processing equipment.
- d. Failing criteria b or c above, data or text only may be provided as ASCII files in standard IBM PC diskette fomat.
- e. All diskettes must be accompanied by documentation, including a printed copy of the disk directory, a description of each file in the directory and how it is to be used and installation instructions. Refer to sections 3 and 4 for software distribution and documentation requirements, respectively.
No microcomputer software or hardware may be purchased by a contractor or DOE laboratory for subsequent delivery to the NRC without written concurrence in advance by the NRC Project Manager and the Office of Information Resource Management.
Updated information about software supported for use on NRC-accessible computer facilities and microcomputers may be obtained from the NRC ITS Support Center, (301) 492-4160 (FTS 492-4160).
- 2. Deliverables for Use on Mainframes or Minicomputers These requirements apply to scientific applications softwue and associated data deliverables intended for use on mainframes or minicomputers. All such deliverables must meet the following criteria unless a written waiver is obtained in advance from the NRC project manager and approved by the Office of Infomation Resource Management,
- a. All new mainframe or minicomputer programs developed or converted for NRC shall be written in American National Standards (ANS)
FORTRAN (ANSI Standard X3.9-1978).
- b. Mainframe or minicomputer programs which generate plots must do so using the Display Integrated Software System and Plotting Language (DISSPLA). This graphics software is a standard at all DOE laboratories.
c.
The recomended mathematical / statistical subroutines are the International Mathematical Statistical Libraries (IMSL).
- d. Proprietary software packages should be avoided except where standard readily available packages exist and are supported for use at NRC-accessible computer fecilities by the NRC ITS Support Center (see Table 1, attached). Machine-dependent and installation-specific packages and features including assembly language"should not be used, e.
Deliverables should be submitted on tape according to the following tape fomat requirements:
n
- Recording: 9-track 1
- Density: 1600 BPI
- Internal Tape label: NO Label
- Character Code: EBCDIC or ASCII
- Record Size: FIXED RECORD LENGTH (80 char / record preferred for source code when possible) j
- Block Size: FIXED BLOCK LENGTH (maximum = 2048 char / block)
)
l - All files on one physical tape must each have the same number of I char / record and char / block.
1
- Tapes must not be generated using system-dependent copy routines, j Tapes must be made so as to be transportable from one computer j system to another. This is most easily accomplished by means of a FORTRAN READ-WRITE routine rather than'a system utility; however, use of IBM IEBGENER is acceptable.
- f. All tapes must be accompanied by documentation, including a copy of the job that created the tape, a list of the files on the tape, a description of each file and how it is -to be used, and installation i instructions. Refer to sections 3 and 4 for software distribution and documentation requirements, respectively.
1
- g. Tapes should include the following files:
Source Code - Compiler input records Sample Input - Test case input data. (The output generated by execution of the program using the sample input must l als. be provided in printed form.) J l
l Data Libraries - External data files required for program ,
execution (e.g., cross-section libraries, dose conversion I factors,etc.).
l 1 l Control Information - Operating systen control language statements required for compilation and execution.
Optional files include cbject or load modules. ;
Ouestions concerning the above instructions should be addressed to the NRC Information Technology Services Support Center (FTS) 492-4160.
l l
17
- 3. Distribution Distribution of contractor-developed applications software and document-ation will be performed under the guidance of IRM. IRM will assure that programmatic distribution requirements are met for public and non-public software. At present, most NRC software is being distributed by the National Energy Software Center at Argonne National Laboratory under a DOE laboratory agreement administered by IRM. Under certain circum-stances, an NRC contractor or DOE laboratory may distribute scientific applications software while in the development or maintenance stages-provided that:
- a. The required distribution activities are explicitly specified in the contract or DOE laboratory statement of work;
- b. The contract or DOE laboratory agreement specifies that the software and associated documentation will be transmitted to
, the NRC in approved fom (per sections 1-4 of this attachment) upon termination of the contract or DOE laboratory agreement;
- c. The Program Division Director has approved, in writing, the need for deviation from the standard distribution procedures;
- d. The Director, Division of Information Support Services, IRM, has approved, in writing, the contract or DOE laboratory statement of work wherein the distribution activities are described.
l l Before release for distribution, NRC-sponsored software must be appropriately reviewed, tested, documented and approved for release by the sponsorfng NRC office. It is the responsibility of the sponsoring NRC office to detemine whether or not a computer code is ready for distribution and to clearly define the limitations to be imposed on said distribution (e.g., USA only, unlimited, a specific distribution list, etc.). However, the sponsoring NRC office is advised that once infor-mation regarding a computer code has been published (e.g., in a NUREG report), members of the public may request a copy of the code and, under normal circumstances, the NRC must be prepared to distribute the code.
Thus, the preparation of a distribution submittal package for the computer code and the publication and distribution of a NUREG(s) associated with the computer code should coincide. In order to prepare to meet these requirements once the contract is complete, the statement of work should include, as a requirement, the preparation of the submittal package necessary for requesting distribution by the National Energy Software Center (NESC). Copies of the NESC submittal forms, distribution proce-dures and advice regarding submittal package preparation may be obtained by calling the ITS Support Center on 492-4160 or FTS-49?-4160. A copy of the NESC release form, signed by the Division Director of the sponsoring NRC office, should be sent to the Chief, Information Technology Services Branch, at the time the submittal package is sent to NESC.
18
l l
- 4. Documentation All reports, including applications software documentation, must conform to NRC Manual Chapters 3201 and 3202. Copies of these manual chapters are available from the NRC Publications Services Division. DOE laboratory ,
staff may obtain copies from their respective technical infonnation offices. !
In addition, the content of all scientific applications documentation shall conform to ANSI Standard N-413. " Guidelines for Documentation of Digital Computer Programs." The major documentation requirements included in the standard are:
I a Computer Program Abstract b Application Information (User's Guide) c Problem or Function Definition (Theoretical Development) d Programming Information (Programmer's Guide)
A copy of this standard may be obtained for $8.50 plus $2.00 shipping and handling from: j The American National Standards Institute 1430 Broadway New York, New York 10018 ATTN: Sales Department In addition to or instead of conforming to ANSI Standard N-413, documentation for some applications may be required to confom to NRC Microcomputer Application Documentation Standards and/or meet other requirements of the sponsoring office. Applicability of any additional requirements will be detemined by the NRC Project Manager.
Each program developed for the Nuclear Regulatory Commission should include ;
the following program title block and disclaimer in the main program:
Program
Title:
Developed for: U.S. Nuclear Regulatory Commission Office of (fill in NRC Office)
Division of (fill in NRC Division)
Date:
NRCContact(s): Phone:
Code Developer: Phone:
Title (s) of Associated Documentation and NUREG Number (s):
This program was prepared for an agency of the United States Government.
Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for any third party's use, or the results of such use, of any portien of this program or represents that its use by ;
such third party would not infringe privately owned rights. l i
19
Updated January 1987 Table 1. NRC Supported Software MAINFRAME SOFTWARE:
Idaho National Energy Laboratories Computer System NOS Operating System for CYBER 176 FSE Text Editor XEDIT Text Editor UPDATE Text Editor Utility FORTRAN 5* Programing Language DISSPLA' Graphics IMSL Math / Statistical Subroutines National Institutes of Health Computer System OS/MVS Operating System for IBM 3081 TSO Comand Language WYLBUR Text Editor / Command Language VS FORTRAN
- Programming Language.
DISSPLA Graphics TELL-A-GRAF Graphics FOILS Word Charts for Overhead Projection MARK IV File Management / Report Generator SYSTEM 2000 Data Base Management System (Reports l
and Queries only)
RAMIS II Data Base Management System (Reports and Queries only) l KERMIT Communications (PC's)
IMSL Math / Statistical Subroutines NRC Data General MV/8000 l
CLI Comand Language Interface SED Text Editor SPEED Text Editor BASIC Prngraming Language FORTRAN 77' Programming Language i SSI* CALC Spreadsheet IMSL j l
Math / Statistical Subroutines i DISSPLA Graphics 1 1
- Adheres to current Af1SI Standard for FORTRAN (FORTRAN 77)
NOTE: This list of software is changed periodically. For an updated list, call the Infonnation lechnology Services Support Center (301) 492-4160 or (FTS) 49?-4160.
20 l
l
e a r
.m
,t b
,. Updated January 1987 i NRC Supported Software (continued)
MICROCOMPUTER SOFTWARE: . r IBM PC DOS & BASIC OperatingSystem2 language COMPAQ MS-DOS & BASIC Operating Spitem, language IBM BASIC Compiler Programming Language IBM FORTRAN Compiler Programming Language /
IBM DisplayWrite Word Processor IBM DisplayComm WF Communications IBM 5520 Attachment Program 5520 Terminal Emylation Microstuf CROSSTALK Communications ^ i ,
Persoft Smarterm DG Terminal Emulation LOTUS 1-2-3 Spreadsheet ,
Ashton-Tate dBASE III, Data Base Management dBASE III Plus '
Westminster Software t, Pertmaster Project Management Decision Resources Chartmaster Graphics Decision Resources Signmaster Graphics Borland International - +,
Sidekick Multi-purpose Utility N, 4
i 4
r, i'
i
(
(
- Adheres to current ANSI Standard for FORTRAN 77.
NOTE: This list of software is changed periodically. For an updated list,,.
call the Information Technology Services Support Center (301) 492-4100 or
< t FTS 492-4160.
21 ,'
___ __ ____- ____._=_ a _ L
5 9 '
!. CONT RACT aD CODE PAGE OF PWI
, AMENDMENT OF SOLICITATION / MODIFICATION OF CONTRACT I l 8
- 2. AMENDMF.NT/MOOsFICAT SON NO. 3.EFFEdiid DATE 4. REQuiSa T aON/ PURCHASE REQ. Peo, [s. PROJECT NO. (If appJarse.r) j June 3,1987
~
One (1) AED-87-129 >
.. e55uEO ey p cOOe " ** " "' " * " *" ** /f cOocI U.S. Nuclear Regulatory Commission '
.. i '
Division of Contracts Washington, DC 20555 I ,
- e. N AMo so ADDRE55 OF CONT R ACTOR ru .. .tmee. cou.ty, si.= . wisp c 4e> g *RAMENoMENT OF SOLiC T avion NO.
RS-AED-87-129 0FFER0RS X eo.DATEursEssT M es May 12.1987
} 30A. MOD 6F BCATlON OF CCte T R ACT/ ORDER NO.
T You. DAT LD iSEE ITEht 13)
CODE lF ACILITY CODE l -
- 11. TH!S ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS .
b The above numbered solicitation is emered as set torth in item 14. Tre Aour nd date specified ior receipt of Offers b is extended, s not en-sended.
Offers must scatnow6 edge receipt of this e nendment ppor tggogrggecified in the Wicitation or as amended. by one of the following methods:
(3) By comp 6eting ste ns B and 15. a re ret 6rning copes of the dmMJreent; IN av mknowledging receipt of this amendment on each copy of the offer submitted; or (c) By neoarate letter or tetagram which includes a reference to the solicitation 4.d amendment numbers. FAILURE OF YOUR ACKNOWLEOG.
MENT TO BE RECEIVED AT THE FLACE DESIGNATED FOR THE RECElPT OF OFFEftS PRIOR TO THE HOUR AND OATE SPECIFIED MAY RESULT ,s IN REJECTION OF YOUR OF FER. If by virtue of this amendment you desire to change on offer stready submitted,such change may be made by telegram or '
6etter, prov ded each telegram or letter makes reference to t%ao isatirsn and this amendment,and u received prior to the opensng hosq.ntf date specsfied.
17, ACCC UNTING AND APPROPR6 AT TON DAT A (1/ requeredJ V l 4
N/A ,- -
- 13. THIS ITEM APPLIES ON!,P 70 MODIFICATIONS OF CONTRACTS / ORDER $; ,
IT MODIFIES THE CONTT ACT/ ORDER NO. AS DESCRIBED IN ITEM 14. ~
Y ^ ^ MEr"O ^ '$E" R N O.'s @ l'J YM. """ * " ^* * ' ' '**"'* * " '" *" * " "' ' "" * '" "' ' " * ' " ' * " * * * "' " *" '" ' "' ' ," '
ADER 45 MODIFIED TO REFLECT THE ADMINISTR ATIVE CHANGES isuch av 4*weesin payana offace, S. apprrpraetson THE ABOVE NUMBERED CONTR date, etc.J SET FORTH ACTpITEM t 14. PURSUANT TO TT AUTHORITY OF F AR 43.303(b).
C. THis suppa.EMENT AL AGREEMENT 15 ENT ERED INTO PURSUANT TO AUTHORIT Y OF s c
D. OTHER (Specufy type of moditscetson end authorstyt t
, '1 I ' withCopiesprohhe osal E. IMPORTANT: Contractor is not, b is required to sign this document and retum to issuing office.
ME5C R APT 60N OF AMENDME NT/ MOO *F eC AT aON (Organised by UCF secnon Asedsnas,incAudui.f whcussion/ con treet.o hiett m<tav ashem fassible.)
A. The due date for receipt of proposals is hereby extenped from June 15,1987 to w June 22,1987, 4:00 p.m. local time.
Office of Administration and Resources ,%nagement Mail Stop - 7717 MNBB Washington, DC 20555 ' y
.ns ., tn. aocum.nt ...s,.nc.a in ei.m ,A w n eA. .. n... .a,e n,n,.a. ,en .w.n9.. .no .n tui. vo,c.
.Emot no evt .a.o,o.io.. ne...n. .ii .... .no co. s g 11 A. NAME AND TIT LE OF SsGNER (Type or ywar) 4 6 *(N A E N '6 T LEMhN1 Rs (lt. G OF F 6CER (Type or print I i Rp O,d_D.tThov.pson ~] *
. . s _g 1 $8. CON T R ACT OR/OF F E 64 0R < _d.C DA TE $4GNED 16($ NtT E J 4T ATE 5 0F ERWA 1 16C.DATE b4GNED
($sgnature of person authnensed to eign) i '
- j l B &(W U/$h, *wrp tbsgna}JG of C introt t J (,3-q NSN V540 ol.152 6070 30 805 b AthDA4D FORM 30 (REV.10 eal
- 9EVIOtM FT)iTinN ttNO8 ARLE a f Wsetsbad tw GbA
. t 'N L __..__________.__m_
r 1 , .
3 AED-87-129 PAGE 2
- d. Program Ar.sistant (1 copy)
Divisior;of Operational Assessment Office for Analysis and Evalvation of Operational Data Mail Stop: 3302 Washington, DC 20555
- e. Chief, Incident Response Branch (1 copy)
Office ft.r Analysis and Evaluation of Operational Data Mail Stop: 3302 .
Washington, DC ,20055 C. Sectior, J - List of A' tachments, t Attachment No. 4 Emeroenc)ResponseDataSystemRequirenentsAnalysisReportishereby amended by providing Chapter 9, attached hereto, which was previously omitted from the attachment to the solicitation. This chapter, entitled "ERDS Implementation Cost Estimate" is provided for information only. The costs contained therein are estinates only and NRC does not guarantee their reliability. NRC expects offerors to use their own independent judgement in preparing their cost proposals. Cost proposals which simply paraphrase the estimates in this report without communicating their own independent judgements in the cost area may be construed as an indication of the offeror's lack of understanding of the statement of work and the objectives of this project.
D. Section L.7 - Referenced Docunents Available from the NRC Public Docunent Room (PDR): the following document has been placed in the PDR for review.
Please note that the NRC does not consider access to this document to be essential for preparation of proposals in response to this solicitation:
"ERDS Plant Survey Report" dated March 1987.
Section C.1.5, References, is also anended to include the report specified above.
E. The following questions were received concerning this solicitation. NRC's responses to the questions are provided for clarification purposes and for general information to all offerors:
AED-87-129 PAGE 3 1 Statement of Work Paragraph C.1.4.2.2 (Task 2) states that "the contractor shall determine the appropriate hardware to satisfy the design specifications in the EROS Requirements Analysis Report." Since the 50W specifies that hardware is not to be selected and approved until Task 2 of the project, it seems premature for bidders to propose (and cost) specific hardware in the ERDS Proposal. Are we correct to assume that we do not need to identify haroware in our proposal, and that we do not need to cost hardware as part .
of our bid? Who will be responsible for acquiring the hardware identified in Task 2?
l The proposal does not have to identify specific hardware to meet the design j l
specification, however, a cost estimate for such hardware should be included j in the proposal. As clearly stated in C.1.4.2.2 the contractor shall procure the hardware specified.
l l
- 2. Reference 50W Paragraph C.I.4.2.3, Requirements Analysis Report p. 3-16 and p.5-16: Please clarify the ERDS Implementation contractor's role at the licensee's facility. We assume that the licensees are responsible for !
developing / modifying their own sof tware to produce a data stream in accord-ance with EROS specifications. Is this correct?
Yes. NRC may provide guidance to licensees on their sof tware development.
3 The number of ERDS feeders has implications on sizing and costing. Since ERDS will be implemented on a voluntary, non-regulatory basis (Requirements Analysis Report p. 4-2), should proposals be based on full licensee partic-i ipation or should bidders anticipate some level of non participation?
l l
! Proposals should be based on full lie.ensee participation.
_ _ ._. _ _ _ - _ _ _ _ _ _ _ _ ~
AED-87-129 PAGE 4
- 4. Reference Requirements Analysis Report, Section 5.3, pp.5-24 and 5-25:
Who is responsible for identification, acquisition, installation and test of the specialized hardware that some licensees will need to implement ERDS (e.g., those licensees that do not have serial port available)? Do we need to cost this hardware as part of our bid?
Licensees will be responsible for specialized hardware on site.,It need not be included in the cost estimates as part of the proposals. The contractors responsibility for hardware begins with the modem on site.
- 5. Reference 52.216-1: We assume that that the contract' type " Cost Plus Fixed Price" should read " Cost Plus Fixed Fee." Is this correct?
Yes.
6 The ERDS design criteria (Requirements Analysis Report, p. 7-1) specify that ERDS "will employ modems and voice grade telephone lines." This seems unnecessarily restrictive by precluding viable alternatives such as data over-voice and packet-switched (X.25) designs. Are bidders free j to propose design alternatives that don't necessarily require use of modems, multiplexors and voice grade telephone lines?
i Yes, within limitations. The data transmission will be done'as part of i the NRC Emergency Telecommunications System which will likely consist of voice grade telephone lines without packet-switching capabilities. The l responsibility for communication lines is outside the scope of this contract. '
i 7 The Requirements Analysis Report does not address the need for positive or passive security controls. However, ti.e ERDS data transmissions during '
an incident may contain sensitive data. Does the NRC foresee an existing or potential need to prevent unauthorized and/or unintentional misuse of the ERDS data, or is data sensitivity not an issue to be addressed at this time?
i I
AED-87-129 PAGE 5
~
l Security will be provided as part of the transmission system which is l not part of this contract.
- 8. Will the NRC please provide additional information on the PBX that will receive and route incoming ERDs transmissions? Is the PBX digital or analog?
The current PBX is analog, however, during ERDS implementation the PBX may be upgraded to a digital switch.
9 The selection of the MNP protocol precludes other viable data communication !
1 alternatives (such as data-over-voice). At present MNP is not a national l or international standard, and it is incompatible with ISO.CCITT standards such as ISDN. Will the NRC relax the requirement that MNP be used and allow bidders to propose alternative solutions that satisfy the end-to-end error free requirements?
l Any protocol compatible with the data and communications conditions and satisfies the end-to-end error free requirements is acceptable.
1 1
- 10. Section 8.6 of the Requirements Analysis Report (p.8-8) suggests that the ERDS Implementation contractor will need to size the hardware at the ,
Operations Center. Does the NRC intend to use the existing DG MV/6000's at the Operations Center to host the ERDS display system? If so, what hardware sizing will be required at the Operations Center? If not, will I the ERDS Implementation contractor procure and install new computer (s) at the Operations Center to support the ERDS display system?
It should not be assumed that the DG MV/6000's are to be used for the ERDS system. The ERDS Implementation contractor is responsible for procuring any and all hardware needed by the NRC for ERDS.
- 11. Does the NRC have a preferred order in which licensees are to be brought online?
AED-87-129
, , PAGE 6' Yes, although the order has not yet been determined. The criteria will include; cost, ease of implementation, plant history of performance, and licensee cooperativeness.
l l
l 12 Reference F.6: Will the NRC please clarify the period of performance of-the Phase III ERDS contract?
l We anticipate system completion five years after initiation of work with a one year checkout period.
- 13. We understand that the ERDS Implementation contractor is responsible for maintaining all sof tware developed under this contract through expiration j of the contract. Does " ensure operability of the software" (reference 50W C.I.4) refer to operational assistance as well as software maintenance?
Yes.
l 1
. -s ;
r
]
AED-87-129 l
. . PAGE 7 l
1 1
l
- 14. Will the NRC provide the planned contract m 2rt date for personnel planning and costing purposes?
September 1987.
- 15. Will the NRC clarify the locations of the twelve anticipated ERDS users?
Will ERDS provide the same functionality for all twelve users?
4 User Location l
PMT Director HQ Operations Center PMT Deputy Director and Team HQ Operations Center RST Director HQ Operations Center RST Deputy Director and Team HQ Operations Center One Electronic Status Board HQ Operations Center Direct Connect to IDAS HQ Operations Center Direct Connect to Expert System HQ Operations Center Regional Base Team Affected Regional Office Regional Site Team Affected Plant Site 3 Additional Remote Users Near Plant Site The same data access and display capabilities will be provided to all l users except fcr the two direct connections which will provide a currently undefined download of data.
16: Will the NRC clarify which hardware will host the ERDS system at the i regional offices? Must ERDS operate on hardware resident at the regional offices, or is terminal access to the Operations Center host acceptable?
The ERDS Implementation contractor will determine the hardware required for the regional office. Terminal access to the Operations Center host is acceptable.
I
I
- AED-87-129 PAGE 8 i
- 17. Reference 50W C.I.4.2.3, F.7: Will the NRC clarify the contractor's specific responsibilities with regard to hardware maintenance at the NRC Operations Center, regional offices and at licensee plants? What, if any, is NRC's role in negotiating and paying for hardware maintenance contracts?
The contractor is responsible for the complete maintenance of all NRC ERDS hardware during the contract period. NRC ERDS hardware includes the required hardware at the NRC Operations Center, regional offices, and the modems /multiplexors at licensee facilities.
la 50W C.1.4.3 states that the contractor shall " insure that the ERDS display system is fu'lly integrated with all other programs involving data and information transfer in the Operations Center." However, the Requirements Analysis Report makes no mention of any functional or physical integration with other systems running at the Operations Center. Is the intent of this statement to ensure consistency and compliance with established standards so that the ERDS display system could be easily integrated, or does the NRC envision that ERDS will pass data to/from other existing systems? If the latter, will the NRC provide more specific information on the scope and magnitude of the EROS integration?
The integration of the ERDS system is to be consistent and in compliance with established standards for ease of integration and to be capable of providing data to other existing systems. The other systems currently envisioned to be linked with are a dose assessment code currently running on the DG MV/6000 and an expert system currently running on a XEROX AI workstation. Neither of these systems are currently configured for an automatic feed of ERDS type data so specific interface requirements cannot yet be defined.
r
.f y-
)
1 a.CONTHAC)s00000 FAbt or FAbEb AMENDMENT OF SOLICITATION / MODIFICATION OF CONTRACT 1 2
- 2. AMENOMErff/MODeF sCATION NO. l
- 3. EF F ECTIVE DAT L 4. HEQUs541 EON / PURCHASE REQ. NO. 6. PHOJECT NO. (1/ epphc.6ae)
Two(2) June 12,1987 AED-87-129 e issvEO oy
- 7. AoM NisuaEo ev ur. sher sr,m el cggg [
U.S. Nuclear Regulatory Commission l Division of Contracts !
Washington, DC 20555 l
.. NAMc AND ADOatss OF CO~T AC T O s ,u... ., ec. e .,y. 4 .., w Co.,, y, ,A. AMENOMENT OF SOUC0 AT ION NO.
4 RS-AED-87-129 I i
E
- 90. DAT EO 45LE ITLM J J) 0FFER0RS May 12, 1987 loa. MOOtt sCATION OF CON T H ACT/ORDEH 1 NO.
3 00. DAT EO f5LE / TEM JJJ CODE lF ACILIT Y CODE
- 11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS The above numbered sohcitation is emended es set forth in tiem 14. The hour and date spec.f.ed tor receipt of Offers X is esiended, is not em.
Offers must ochnouedge rece,pt of th,s amendment pr;o, to the hour and date specif.ed in tne sohcitation or es ame<ded. by one of the iollowing rnethods:
la) By competeng items 8 and 15. end returning cop.es of the amendment; (b) By eckno i.dging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram wh*ch encludes a reference to the solicitation and amendment numbers, F AILURE OF YOUR ACKNOWLEDG.
MENT IN TO BEOF hEJECTION RECEIVED YOUR OFFER.11 AT THE PLACE by virtue DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR ANO DATE sPEC of thes amendment you desire to change an offer already submitted.such change may be made by telegram or j
ietter.orov.ded e.ch teagram or actier maies reverence to the soi.c tat.on and this amendment. .no is recei e prior to ine openir, hour and date spec.'.ed.
l ugoUN,,NGANoAveuOou.AT,ONDATAau,,e,,..,a,
^$2C'i"8a"8E'a NO '." 3 PM nf
"""5"^"' ' ''*"'**"'"'"'C"^""'55 "'"'""'"8'^*'"^ "'""' I 8,epprapnetsaa THE ABOVE NUMBE date. e tc.) SETACO CONT FORTH A ACT/
IN ITE ORDER ISTOMOOlFIEO M 14. PUR5UANT THE AUTHOTO AEFLECT AITY OF FAR 43.1 THE3(t4AOMINISTR ATf.vE CHANGES (s.sch as C. T HIS $U& ELE MEN T AL AG R EE MENT e5 E NT E N E D #NT O PURSUANT TO AUT HOH8T V OF s o OT nE u <seaaay <>oa er mas,1,c.r.o. . o . asona,o E. IMPORTANT: Contractor O is noi. 8 is , ooi,eo io ign ini, occurnent ano return I dMcBWidssuingofrice.
EDESC AIPT 60N OF AMENOME NT/ MOD #F 6C AT EON forreassed 6y UCF eecason Acadmas saci.daar e.hcHeta.=/c arro<8 entverf metter w A. The due date for receipt of proposals is hereby extended from June 22,1987 to June 29, 1987, 4:00 p.m. local time.
B. See page 2 for additional text.
gg.y..... ..m. ... ..,, s . o . ,... . ., t,,.
.~.- ,. ...~.. . ..m . A o, s o A. a . ..t on,,. . na n .. c. ,.. u,,en.
an. .. ..a 4.Ng ;
J4A. N AME AND 78TLE OF atGNE A (Type .rpesagf 36A. N AME AND 7 6TLE OF CONT R ACT4NG OF FICER (75.r pnaff MaryJoMaKia k.
16a. CON T A ACT O A/OF F E RO A ASC.DATE SaGNLO 3 6 8,4tsN4 STAT 5 3 6C. DATT. SeGNED
<e<rm.swe .1oe eY 06/12/87 asme o .u,,,
asaw .1 c..o eas.a 01twer) e m o
- 2s 4cro s+ os
@CEVIOUS eof 760N Ut4WEAeLE sTAmoAno ronu so :Acv. so es) preec,ggee py ggA nnn wnrar3nnonnnn
1
- AMENDMENT TWO (2)
AED-87-129 l PAGE 2 The following additional information is provided as clarification for the benefit of the offerors: '
- 1. Refer to Attachment number 4 to the solicitation, " Emergency Response Data System Requirements Analysis Report", page 7-2, paragraph 1: The following additional information is provided:
Regional Base Team--this will be a contractor provided piece of hardware that supports dial-up access to the Emergency Response Data System (ERDS) host at NRC Headquarters. (The NRC has five regions.)
Regional Site Team--this will be contractor provided portable equipment that supports dial-up access to the ERDS host at NRC Headquarters.
3 Additional Remote Users--there is no contractor provided hardware, but the ERDS host at NRC Headquarters must be prepared to support 3 other dial-up users. 3
- 2. Refer to Attachment number 4 to the solicitation, " Emergency Response Data System Requirements Analysis Report", page 8-14, the first paragraph: This part of the report states that a large flat screen device is recommended for the Reactor Safety Team Room. The flat screen display device is not an absolute requirement for the NRC. The NRC anticipates i that the projector system will require light valve technology. For of ferors' information, the Reactor Safety Team Room is part of the Operations Center where the ERDS will be located.
i