ML20244B601

From kanterella
Jump to navigation Jump to search
Rev 2 to ERC890985, Arkansas Nuclear One Training Administrative Guideline Simulator Mod Control
ML20244B601
Person / Time
Site: Arkansas Nuclear Entergy icon.png
Issue date: 04/06/1989
From: Danni Smith
ARKANSAS POWER & LIGHT CO.
To:
Shared Package
ML20244B597 List:
References
ERC890985, NUDOCS 8906130185
Download: ML20244B601 (40)


Text

ERC890985 04/06/89

'AND TRAINING ADMINISTRATIVE GUIDELINE SIMULATOR MODIFICATION CONTROL REVISION 2  ;

APRIL 6, 1989 I

APPROVAL: __ . m - / 5 - 1 l- 99 SIMULAT@ SUPP,DRT SUPERVISOR DATE -

bm411. b SIMULATOR TRAINIlf SUPERVISOR

/ s DATE

-a -s?

/ T~ lb ~

U-1 OP$/TRG'SUPERVISo f DATE o 0. fw

~U-II OPS /TRG SUPERVISOR

, x/,,./y9

'DATE 1

OPS TRAINING SUPERINTENDENT

/ Y/7 M DATE l

3 h s_ /5h TRAINING MANAGTR DATE 8906130185 890531 ~~R PDR ADOCK 05000368 P PDC L_________________-____________--__.___ _ .-  !

.]

1 ERC890985 04/06/89 SIMULATOR MODIFICATION CONTROL TABLE OF CONTENTS

'I.0 OBJECTIVE-2.0 DEFINITIONS-

2. I' DATABASE' CHANGE RE_ QUEST (DBCR).

2.2' DESIGN. CHANGE PACKAGE.:(DCP); ,

2.3 DESIGN DATA BASE (DDB): >-

L2.4: DISCREPANCY 2.5 ' DISCREPANCY-REPORT-(DR) 2.6 LEAD SIMULATOR INSTRUCTOR 2.7 LOADUP 2.8 MODIFICATION 2.9. PLANT CHANGE (PC) 2.10 PLANT MODIFICATION (Fr.)

2.11 PROBLEM 2.12 PROBLEM VALIDATION 4 2.13 REJECTED i 2.14 SIMULATOR ENGINEER (SE) 2.15 SIMULATOR ENHANCEMENT i

i 2.16 SIMULATOR MODIFICATION (SM) 2.17 SIMULATOR TRAINING GROUP SUPERVISOR.

2.18 SM DESIGN PACKAGE 2.19 SOFTWARE. CHANGE REQUEST (SCR) 2.20 SOFTWARE MODULE .)

-2.21 SOFTWARE SIMULATION SYSTEM -

)

s 2 i I

o___________.___._.__.____ _.__-_._.__.______ _ ')

w- .

< , i .

ERC890985:

04/06/89; 2.22 SOFTWARE SPECIALIST o

'2.23 SYSTEM MODULE

~

2.24 SIMULATOR SUPPORT GROUP (SSG)-

.i 2'25 TEMPORARY MODIFICATION (TM)'

i j

.3;O REQUIREMENTS

.l t

3.1 SOURCES OF. SIMULATOR MODIFICATIONS'(SM)

'3.1.1- MODIFICATIONS TO REFERENCE PLANT ,

, j 3.1.21 SIMULATOR PROBLEMS 1 4

- 3.1. 3 '.-

' SIMULATOR ENHANCEMENTS 7

' 3.1. 4 - SIMULATOR SPECIFICATION CHANGE 3.1.5. JUMPER LOG 3.2 INITIATING DISCREPANCY REPORT-3.2.1 IDENTIFICATION OF PROBLEM 3.2.2 PROBLEM VALIDATION- ,

H 3.2.3 ASSIGNING DR' NUMBER -

3.2.4 TRAINING PRIORITY 3.2.5 SE RECEIPT OF A DR 3.3 AUTHORIZATION TO DEVELOP SM i 3.4 SM DESIGN PACKAGE .l 3.4.1 DESIGN DATA IDENTIFICATION  !

q 3.4.2 SM SPECIFICATION i

3.4.3 SM SPECIFICATION REVIEW ).

3.4.4 SM DESIGN l 3.4.5 SM IMPLEMENTATION '

i l

)

3 l j

ERC890985 04/06/89 3.5 SM TESTING 3.5.1 DEVELOPMENT OF INITIAL TEST 3.5.2 DEVELOPMENT OF PERFORMANCE TEST.

3.5.3 CONDUCT OF PERFORMANCE TEST 3.6' SM ACCEPTANCE 3.7 ' DOCUMENTATION UPDATE 3.8 SM.CLOSE0UT 4.0 RECORDS 5.0 : ATTACHMENTS

. FIG 1 SIMULATOR MODIFICATION PROCESS DIAGRAM FIG 2 DCP STATUS FILE FIG 3 SIMULATOR DISCREPANCY REPORT-FIG 4 SIMULATOR MODIFICATION

SUMMARY

INFORMATION FIG 5 DISCREPANCY REPORT LOG J

FIG 6 SIMULATOR MODIFICATION

SUMMARY

FIG 7 . SIMULATOR MODIFICATION SPECIFICATION REVIEW

]

FIG 8 SIMULATOR MODIFICATION HARDWARE DESIGN FIG 9 SIMULATOR MODIFICATION SOFTWARE DESIGN FIG 10 SIMULATOR MODIFICATION TEST PLAN FIG 11 DOCUMENTATION UPDATE PACKAGE FIG 12 JOB REQUEST j I I

'~

i 4

ERC890985 04/06/89

'1.0 OBJECTIVE To establish guidelines for the initial, design, tracking, installation and documentation for modifications to the AP&L ANO Unit I and II Simulators.

2.0 DEFINITIONS l 2.1 Database Change Request (DBCR): Request for a database change due to changes in the reference plant, usually due to a.. plant modification. j 2.2 Design Change Package (DCP): A collection of documentation providing I the specifics.of a plant modification.

f

]

~

2.3 Design Data Base (DDB): A collection of data consisting of reference plant drawings, manuals, performance data and other documents that defines.the plant being simulated.

2.4 Discrepancy

A difference between observed performance and the current data base.

2.5 Discrepancy Report (DR): A form used to identify discrepancies, problems and needed corrections and/or upgrading of the Simulator hardware and/or software and initiates the review and correction process.

+

2.6 Lead Simulator Instructor: An instructor currently certified by the NRC to conduct Simulator training and appointed by the Supervisor of Simulator .

Training as the interface between the Operations Training group and the J Simulator Support group or his appointed designee.

2.7 Loadup

The process of loading the simulation software from libraries and load modules into memory in preparation for execution.

2.8 Modifications

Any addition, deletion or change to simulation software or ,

hardware. j 2.9 Plant Change (PC): Documentation of.a change to the reference plant which does not change a plant drawing or procedure.

2.10 Plant Modification (PM): Term used to describe one or all of.the  !

following - PC, DBCR, SCR, DCP, TM. l 2.11 Problem: A difference between observed performance and expected or-desired performance.

2.12 Problem Validation: The process of ensuring the simulator problem report identifies a vclid problem.

2.13 Rejected: The proposed sotfware revision is not satisfactory.

2.14 Simulator Engineer (SE): An individual responsible for changes in the performance of the sinulators. The engirreer will be designated by the Simulator Support Str ervisor.

5  :

l ERC890985 i 04/06/89 l

2.15 Simulator Enhancement: A simulator modification which will' result in any of the following:

1. Addition of data to the Design Data Base.
2. Elimination of simulation design simplifications or assumptions.
3. Increasing the' capability of the Simulator.

I 2.16 Simulator Modification (SM): A change in the simulation software or hardware. 1 2.17 Simulator Training Group Supervisor: Individual responsible for meeting established regulations.

2.18 SM Design Package: The document that defines what the SM is to accomplish (specification or requirement) and how (design) the SM is going to accomplish it.

2.19 Software Change Request (SCR): Request for a software change due to changes in the reference plant, usually due to a plant modification.

2.20 Software Module: A unit of software whose source code is contained in one file.

2.21 Software Simulation System: The simulation system consiste of )

the software necessary to execute and control the simulation. i This shall include the job streams necessary to load, save, restore and unload the simulation system.

2.22 Software Specialist: An individual responsible for performing modifications on support software. l l

2.23 System Module: A software module that simulates a portion of a I particular plant system.

2.24 Simulator Support Supervisor (SSS): Individual responsible for hardware and software maintenance of Simulators and its perifery equipment at the training center.

2.25 Temporary Modification (TM): Modification to the reference plant that is not permanent.

l 3.0 REQUIREMENTS 3.1 Source of SM: It is intended that a Simulator modification be initiated from one of five sources. These sources as well as a discussion of each follows:

3.1.1 Modifications to the Reference Plant: As modifications to a Simulator's reference plant are made (i.e., TM, DCP, DC, DBCR, SCR), appropriate training and engineering eval-uation of these modifications may.Jesult in the necessity to implement similar modifications into the Simulator.

Discrepancy Reports initiated as a result of a plant modi-fication (PM) should normally be cleared within one year.

l 6

1 1

1 ERC890985 i 04/06/89 )

)

NOTE: This type of Simulator modification will require .

updating of the Design Data Base. J l

3.1.2 Simulator Problem: As a result of trainee or Simulator 1 Instructor feedback a problem with the current simulation i system may be identified. Once reviewed,-a SM may )

be initiated in order to resolve the problem. Discrep- )

ancy Reports initiated as a result of observed improper )

simulator performance should normally be cleared within '

i three months.

3.1.3 Simulator Enhancement: It may become desirable to enhance the simulation beyond its current capabilities.

If discussions between the LSI and the Simulation Engineer result'in an agreement to enhance the Simulator, a SM may be initiated. Discrepancy Reports initiated as a result of simulator enhancements should normally be cleared within one year.

NOTE: This type of modification may result in the addition of data to the Design Data Base, may result in the elimination of simulation -

design simplifications or assumptions, or may f extend the current scope of simulation.

3.1.4 Simulator Specification Change: From time to time it may become necessary to add, replace, or modify non-simulation  !

software such as operating system software or system J utilities, etc. Also, it may become necessary to modi- l fy the Simulator's hardware design. A SM should be l initiated in order to document these type of changes, j A Discrepancy Report initiated.as a result of simulator specification changes should normally be cleared within one year. -

NOTE: This type of SM may not require a change to the Design Data Base.

3.1.5 Jumper Log: Occasionally, plant operations requires certain logics or equipment performance to be altered by temporary methods until permanent changes can be incorporated. These changes will be monitored by the Lead Simulator Instructor and the appropriate actions taken. Discrepancy Reports initiated as a result of placement of plant jumpers should normally be cleared within three months.

3.1 Initiating Discrepancy Report (DR):

7

l ERC890985~

04/06/89

]

~

3.2.1 ~ Identification of Problem: Problems with the Simulator are generally discovered.by Instructors or Operators,in requal-ification, but may also'be identified by others. Identified-

] 4 problems shall be documented with a Simulator Discrepancy f Report (DR) (See Fig. 3). The originator of the DR shall- )

fill cut - Date, Time, Reported By,; Describe Problem, Test: 'j in Progress /IC, .0ther: Info / Reference and must provide data j to validate DR. -The originator will then submit.the DR to I a Simulator Instructor (SI). The SI shall forward the DR and

-data to the Lead Simulator Instructor-(LSI).

3.2.2 Problem Validation: Upon receipt of the DR with'the appropriate sections completed and supporting data, the LSI shall determine j if the problem is valid. If the problem is not valid, an explanation shall be attached to the DR and both shall be

~

returned to the' originator. ~ If the problem is. valid, the'LSI

-shall then check the DR Log to see if the problem has been

'previously' identified. 'If the problem has been-identified, ,

this shall be noted on the DR and the DR shall be returned -'

to the originator. If the problem has' not been previously identified, the DR shall be assigned a.DR Number and logged into the DR Log (Fig 5).

3.2.3 Logging in Simulator Problem Reports: The LSI'shall log the DR in the appropriate DR Log by doing the following:

1. Assign a DR number using the following format:

DR No XX-YYY Where XX = Year Designation-YYY = Sequential Log Number for that year

2. Enter the DR on the next'available line of the DR Log Form (Fig. 5) contained in the DR Log.

3.2.4 Training Priority: It is the responsibility of the' Lead Simulator Instructor to assign a priority to each DR. The criteria for this evaluation should be based on the training value of the DR and not cost and schedule considerations.

Upon completing the logging in process,'the original DR shall be submitted-to the Simulator Engineer (SE) for further evaluation (all 3 copies). (See1ANO Training Administrative Guideline - Simulator Discrepancy Report for a definition of priorities.)

,~

8

I ERC890985 04/06/89 3.2.5 Simulator Engineer (SE) Receipt of a DR Upon receiving a DR from the LSI, the DR and/or DCP Databases are updated.

Also, a Simulator Modification Summary (Fig. 6) should be completed. After completion of this form, the entire package is submitted to the SSS for approval.

3.3 Authorization to Develop Simulator Modification: It is the respons-ibility of the Simulator Support Supervisor (SSS)-to either approve, disapprove, or defer each SM proposed by the Simulator Engineer (SE).

This action may take place as soon as the SM is initiated or may be delayed until manpower and cost considerations have been more carefully analyzed. Approval shall be indicated by the SSS with'a signature in the appropriate processing sequence block of Figure 4, "SM Sum-mary Information."- Disapproval of a SM shall be accompanied with an explanation of why the SM is not to proceed. This explanation shall.

be filed in the DR Log and the SM shall be closed as described in Section 3.8. Deferral of the SM means that implementation should not proceed until a specified event takes place (e.g. , existing component requires replacement, final design data becomes available, etc.). Deferral shall be accompanied by a paragraph explaining the terms of the SM implementation. The word " DEFERRED" shall be printed in the date closed block of the DR Log (Fig. 5).

3.4 SM Design Package:

3.4.1 Design Data Identification: The SE shall procure enough I pertinent data to allow the design of the new or modified simulation system to proceed with as few design assumptions as possible. Care should be taken to procure only data needed during the design phase and to eliminate all  ;

extraneous data. l 1

3.4.2 This is to be used only if necessary and at the discretion of the SE with non plant mod SM packages.

SM Specification: A Simulator Modification Specification shall be developed based upon specific plant data. This shall be in sufficient detail to allow a Design Engineer (Simulator Engineer and/or Sof tware Specialist) to design the required software. Marked-up or new simulation system diagrams shall be prepared as necessary to define the new requirements. Also, assumptions and simplifications to be used in the SM desigo shall be stated. Included in the SM Specification shall be sufficient'information to allow design and installation of any hardware associated with the SM. Marked-up Simulator drawings shall be used as much as practicr.ble for this purpose.

3.4.3 This is to be used only if necessary and at the discretion of the SE with non plant mod SM pa.ckages.

9

ERC890985-04/06/89 SM Specification Review: Once the SM Specification is .

complete, a review shall be conducted; The purpose of the review is to ensure that the. specification satisfactorily addresses.the original source (s) of the SM.

~

As a minimum, this review shall be conducted by an SE and the LSI. The SSS may participate at his discretion.

The specification should be modified.as a result of. comments generated during the review. In the event that;an impasse is reached in the review, the SSS shall make the' final

determination. .Once'all comments have been resolved, the review team members shall indicate their approval'by signing the Simulator Specification Review Form'(Fig. 7) which shall be attached to the specification.

3.4.4 SM Design: It is intended that this phase be performed by the Design Engineer. A hardware' design shall be developed:

if any changes to the Simulator hardware are to be made.

This hardware design shal1~be in sufficient detail for a technician to make all changes and shall follow establish-ed conventions for wiring, labelling, component installation, etc. Fig. 8 shall be used as a cover sheet for a hard-ware design.

If the SM requires software modifications, a software design shall be developed by the Design Engineer. Fig. 9 shall be-used as a. cover sheet for a software design package. At a minimam, the software design shall contain the file names of all source code modules that are to be modified. .It should contain a description of the changes that are to be made to each section of a software module. Also, a listing of DATABASE changes shall be a part of the software design. Accepted programming conventions shall be followed.

in the software design.

3.4.5 SM Implementation:

Hardware: Installation of SM hardware may proceed, at the discretion of the SE, upon completion of the hardware design and receipt of hardware. Copies of.all hardware procurement documents shall be part of the SM design package.

Once all hardware has been ordered, the SE shall sign the appropriate processing sequence block of the SM Summary Information form.

l Software: Implementation of SM software may proceed at this-

! point in accordance with acceptable software and engineering techniques.

10

4

-).

ERC8909851 -)

04/06/89 -]

Completion of Work: Once the design work is complete and all.,

j necessary hardware and' software modifications have been performed, j the SM is ready for initial testing. .At;this point, the. U Design Engineer shall sign the' appropriate processing l sequence block of Fig. 4, "SM Summary Information". As hardware work is completed, appropriate documents should be updated.

'3.5 SMTestih

-Development of Initial' Test: Any SM that requires software 3.521

~

modificatiotas shall be tested by the hardware / software l.

designers. The test shall be designed to ensure that the modified Simulator meets the requirements'of the SM Specification. 'It is the responsibility of the person (s)l developing the test to consider, as a minimum, the necessity

~

, .of testing any of the following:

a. Digital Inputs  !'
h. Switch Check
b. Analog Inputs i. 'I/0 Override
e. / Lamp Check -j. Monitored Parameters
d. Meter Test , k. Logic Response
e. ' Recorder Functions 1. Dynamic Response
f. Remote Functi n m. Steady-State Response.
g. Malfunctions- n. Transient Response 3 . 5 .'2 Development of Performance Test: ' Software modifications shall be tested with a test developed by the.LSI. The test should consider prerequisites, if any that must be met prior to performing the test and shall indicate the necessity for updating Simulator initial conditions files. The test shall be designed to ensure that the modified simulator meets the requirements of.the SM specification.

1 Any review team member may de=(.'p additional testing which' shall be included as part of :he test with the concurrence of the complete review team. O en the test is' complete, the review team members shall indicate approval by signing I the appropriate area of the SM test plan cover sheet (Fig. 10).

3.5.3 Conduct of the SM Test: 'Once-the test has been prepared, '

reviewed, and revised, at'the SE's direction, the testing shall be conducted by the LSI and test team.

(Refer {

to the ANO Training Administrative Guideline: Simulator  ;

Training Disk Modification w

\

a 11

'ERC890985.

04/06/89 3.6 SM Acceptance:

L If rejected, remedial design efforts should' proceed. Once corrective L action has been taken, modified appropriate sections.of.the test I

previously used shall be prepared and run in accordance with Section 3.5.3 above.

'If accepted, Fig. 3, "AP&L Simulator Discrepancy Report", shall 'be used to record the SM ' acceptance or rejection as: well as . additional comments. Once accepted, the LSI shall sign the appropriate processing sequence block of-Fig. 4 " Simulator Modification Summary'Information."-

The Test Plan shall be maintained in the SM design package.

3.7 Documentation Update: The intent of the updating process is to ensure the usefulness and accuracy of the documentation associated with the Simulators. It is necessary that;the documentation employed to perform Simulator modifications reflect the current training simulation. All' previous updates shall be incorporated'in their final form on the documents used to generate au update, package or the accuracy of the update package and associated documentation cannot be' assured.

The updating shall be accomplished by the following personnel:

Document Responsible Personne1'

a. Final Design Specification /' Software Designer-Design Concept Documentation
b. Operations' Manual Software Designer-
c. Simulator Hardware Drawings Hardware Designer
d. Design' Data Base Report Simulator Engineer-
e. Simulator Test -Lead Simulator Instructor- R
f. Simulator Malfunction Cause Lead Simulator Instructor' i and Effects
g. Process / Logic Drawings Software Designer Fig. 11, " Documentation Update Package," shall be used to indicate what documents need to be updated. This form shall be maintained in the SM Design Package.

Once all the updates have been prepared, the SE shall review them i for accuracy and clarity. After the SM has been accepted and implemented into the new training pack, the remaining update packages 3 shall be incorporated into the reference documents by whatever means )

is currently being utilized (local control, Document Control, Engineering  !

Records, etc).

12 1 1

i l

ERC890985 04/06/89 1 3.8 .SM Closeout: It is the responsibility of the SSS to review the completed SM stai.us file for clarity and legibility in preparation for entry into the Configuration Management System. Once the SSS has prepared the-file, the SSS shall officially close out the SM j by signing the. appropriate processing sequence block of Fig. 4,  !

" Simulator Modification Summary Information." j After cl'osing, the SE shall enter the SM-Design Package into the Configuration Management System and the DR Log shall be dated I accordingly.

4.0 CONFIGURATION MANAGEMENT SYSTEM (CMS)

The Final Documentation, Functional Specs Unit-1 and Design Concept Documentation -

Unit II, and the model~ codes' are the final products of record keeping. The Design 3

Data Base. File provides the accountability of all data and defines the status- 1 of the simulator. The maintenance of'the DDB is not only regulated but necessary to maintain simulator fidelity. In Configuration Management, three files for each simulator unit resides to support DDB, DRs, PMs and Drawings. The DR file provides a record of all DRs and PMs written. The DDB file provides the information concerning the Design Databases. A Drawing file supplies ]

a record of all drawings currently being maintained.  !

4.1; The CMS provides the following. functions: -'

4.1.1 Establishes a baseline record (DDB) 4.1.2 Maintains a current. data base of simulator design (DDB) 4.1.3 Tracks plant changes affecting simulator design and operation (PM) 4.1.4 Tracks plant changes not affecting simulator design and operation (PM)  !

4.1.5 Tracks differences between the simulator and the simulator design bases (DR) 4.1.6 Tracks identified improvements needed in simulator design (DR) 4.1.7 Tracks Design Drawings currently maintained 4.2 The CMS consists of 3 major files per unit (DRs and PMs reside ~in the same  !

file)  !

4.2.1 Design Data Base (DDB) i j

4.2.1.1 Design Data Base (DDB) consists of the following: ,

I

a. Technical Manuals - name, vendor document. .1 identification j
b. Drawings generating body, drawing number, j drawing revision number
c. Power Plant Data process computer listings, recorder strip charts, design calculations,. i analytical data (accident analysis)  !
d. Applicable plant modifications incorporated into the simulator - identification of plant -!

modification package _,' data incorporated and '

models affected, supporting test data and verification.

I 13 l

'l ERC890985 04/06/89 i

4.2.1.2 Design Data Base (DDB) File provides accountability of the following information:

a. DOC NO .. document' number, file location:

DOC NO is designated WW.XX.m. Unit I system numbers are 4 digit, and Unit II uses-

~2 digits, to provide a consistant' format, a 3 digit number was used. ' Unit 1 system 0530 is 530, Unit II 7.0 is 070.

WW is system number. XX is used for PMs' and DRs and represents year incorporated (this will be 00 for everything else).

m is a sequential. number for. distinguishing data for each system.

b. SYS, S2,'S3, etc. - system utilizing specific information.
c. Description provides general:information or title,
d. ID No. Doc - document identification number, print, sheet (if applicable), and revision number.
e. Vendor -_ supplier and/or manufacturer
f. MOD /DATE - PM for DR) number and the date .  !

it was' incorporated (i.e. 82-2279/12/05/86)

(The DOC NO would be 000.86. m )

4.2.1.3 Design Data Base Updates )

a. Assign data appropriate Doc. No.
b. Add SM package to DDB file as per assigned 4 Doc.'No. I
c. Printout DDB for updated system
d. Replace ~ DDB printout with new printout ,

i 4.2.2 Plant Modifications (PMs) 4.2.2.1 Plant Modifications consist of any of the following:

)

1

a. *AP&L Simulator Discrepancy Report (Fig.'3) 'l
b.
  • Simulator Modification Summary Information (Fig. 4)
c. Simulator Modification Summary (Fig. 6) ,
d. Simulator Modification Specifications Review  !'

(Fig. 7) l e. SM Hardware Design (Fig. 8)'  ;

f. *SM Software Design (Fig. 9)  ;
g. *SM Test Plan'(Fig. 10)  !
h. Documentation Update Package (Fig. II)
1.
  • Design Change Package (DCP) i i
  • ITEMS ARE REQUIRED j 14-i

ERC890985 04/06/89 4.2.2.2' Plant Modification Files 6-e updated via the DR file on CMS to their related fields (Fig. 2)

a. Plant Mod - number'as written on DCP, TM, SCR,.

DBCR, PC l'. Plant Mod numbers are proceeded by the first letter of ' their particular type (i' e. DBCR - .

D-8924-3, SCR --S25-001-34,;etc.) The-exception to this criteria will be the DCP number which will'have no letter designation.

b. Description provides general information.

or title'

c. Clear Date .date DR is implemented

'd. DR NO. to implement DCP if it'affects simulator-

c. Comments -.contains-FCN#,-and'any other ~

pertinent information

f. DDB - Design Database number 4.2.2.3 Plant Modification Updates
a. PM Master File (DR File) - on a periodic-

' bases

'l. Request'PM Status' Report from Plant Data Processing:

- Doc No

- Doc Subj

- DCP Status

- Doc Activity

- Beg. Date

- End Date

- Sort by Doc No.

- Ascending (Obtain years 1982 to.present; if all PMs for a given year have been closed out or cancelled, omit that year) I

2. Compare Plant list to Master File

- Add new DCPs as necessary

- Enter " Cancelled" in the comments field if -

cancelled (close out DRs written on. r cancelled PMs) s.

15 1 1

---__ _ ___-___-___-__ - _____--_ __--_- -__---_-__2_ _ _ - -__ - - _ - _ _ _ - - - - _ - - - -_ _ _ - - - - _ - _ _ - - - - _ - . _ - - - - - - - - - _ - - - - _ _

ERC890985 04/06/89

b. PM completed
1. Add. appropriate.information. r
2. Add appropriate information to DDB'(5.2.1.3). l
3. . Place DCP in appropriate DDB' file location-
c. DCP doesLnot' affect' simulator
1. No DR # will be enetered
2. Discard DCP-4.2.3 Discrepancy Reports (DRs)' j

-I 4.2.3.1 Discrepancy Reports.(DRs) are the focal point of all, d simulator modifications. No change is done-on the-

-simulator without a DR (exception.is routine hardware maintenance) .

g 4.2.3.2 Discrepancy Reports (DRs) File provides accountability of the following information:

a. DR No.- XX-YYY I XX is year designation. l YYY is sequential log number for that year
b. WRT-DATE - date the DR-is written
c. ' REPORT-BY person writing the DR- .
d. CATEGORY - system or components affected
e. CRTPTH - XXX - Y - Critical Path XXX is "Yes" or."No" Y priority level
f. ASSIGN TO person responsible for l implementation
  • l
g. TSTREQ - retest required-  !
h. CLR-DATE - date DR implemented and tested,'if -l applicable
i. DCUPRQ - documentation update required.(must be YES if associated'with DCP)
j. VER-DATE - date documentation. update was  !

verified

k. PLA MD - Plant Modification Number
1. DESCRIPTION - describes problem or CHANGE l
m. COMMENTS - other information such as '

source code' changed, etc.

4.2.3.3 Discrepancy Report Updates'

a. Add data from DR sheet i 4.2.4 Drawings  !

l

.[

~!

16 l

~

ERC890985 04/06/89:

1 1

4.2.4.1 Drawings file provides' accountability 'of the following information:

a. DRWGNO - drawing number
b. -SHEET sheet number
c. REV - revision number
d. TITLE -'self-explanatory SYS - system affected ;I
e. '

f.. APP DATE ^ approval date

g. COMMENTS - additonal information
h. TYPE - hardware (H), process (P),

control (C) and logic (L) 4.2.4.2 _ Drawings Updates a'. Complete drawing listings are generated quarterly'

b. The listings are reviewed by the SS or SE c'. CMS'is' updated from the' reviewed-listings. .
1 3

f 17

ERC890983 04/06/8f FIG. 1 PAGE 1 0F 3 I

i i

j i

..'- l l

l

  • DENOTES SIGNATURE REQUIRED l

)'

.. 2 I

SIMULATOR MODIFICATION PROCESS DIAGRAM PLANT 4100. SIMULATOR SIMULATOR SIMULATOR ' JUMPER 3.8.1 PROSLEM ENHANCEMENT SPEC. LOG 3.1. 2 3.l.3 S. I .4 3.8.S .

t No AFFECTS I SIMf 1

YES P 1' it q. q, l

ORIGINATOR l WRITES DR 3.2.1 Fle. 3

]

LSI

(

WR TTENI

3. 2.2 NO LSI '

DR wo TigraCTORY 32.2 l Yts

' LSI ASSIGN DR #

UPDATE DR LOS 3.2.3 FIG. S j i

l' LSI l

ASS 10N l TRAINOS t moonlTV ,

\

l 3.2.4 #

  • 2 i

ERC890985 1 04/06/89 j

FIG. 1 J PAGE 2 0F 3 l

\,

I i

i i

1 i

i i

I l

l i

i l

  • DENOTES SIGNATURE REQUIRED

O e SE -

UPDATE 04 / DCP STATUS FILES

3. 2. 5
  • 1' SE CDMPLETE SIMULATOR MODIFICATION SUM 3.2.S FIO. 4, Fit. 8 SSS AUTHORIZATION Ex ANAT ON l

S.3

,YE8 '

SSS DEFERRAL y Wall POR gpggggg I EVENT.

g3 NO -

LSI/SE -

1 IsPEc eviEw 5

}SE  ! d NmDwaRE I l(tr Fl#

Scteamrl

? .

SPEC *sc 1 ORDERED E MARDudE / SOFTWARE DESIGNS (EWRATED i..,,...,,.S.

RE.untti 'ag>;

ISSUED I i 1  ;

e LSI SM TEST PL AN DEVELOPED AND .

PER9mMED 3.S St '

MOD ACCEPTED P vES i

l l

I

ERC890985 04/06/89 FIG. 1 PAGE 3 0F 3 1

i i

1

  • DENOTES SIGNATURE REQUIRED

i i

4 1

1 1

@ i e

IC'S NEED No.

. REVISIOP

/ i YES

.1 l

l i i

I UPDATE IC'S ,

I 4

n

\'

CMS' UPDATED

'i i

IP DOCUMENTATION UPDATED 3.T F IG, il s.

1r UPDATE Status FILE . CLOSE0VT MOD. .3. 3 j

END 3

I

ERC890985 04/06/89 FIG. 2 DCP STATUS FILE I i l i DATE I DATE I l l DCP NO. DESCRIPTION DR # I WRITTEN CLEARED DDB # COMMENTS I i 1 1 I-1 I i

1 I

I i 1 I i l- I

! I I I I l j

i l l I I I

I I 1  !

I 1 I I  ;

1 1

1 I

I I

  • I I
I l 1 .. %

l l l l 1 l 1 i I i l I I I I I I I

ERCS 90985-04/06/89 FIG. 3 PAGE 1 0F 2 l

l l

4

AP&L SIMULATOR DISCREPANCY REPORT s DR*

I SIM. STATUS DATE: TIME: REPORTED BY:

ONORMAL OPS DESCRIBE PROBLEM:

l lC/ SNAP

  • j G DCP1F l MALFUNCTION l N 'MALF#SEVERITY '

A -

T 2.

O S.

R ,

OTHER INFO /REF: CONT. SHT. O L SOURCE: DCP O SIM. PROB.O ENHANCEMENT O SiM.SeeC.O JUMPER LOG C f PRIORITY @ @ @ S @ CRITICAL PATH @ B H/W DEFECT TAG @@

CATEGORY ASSIGNED TO: DUE DATE :

SOFTWARE ASSIGNED TO: DUE DATE:

CORE RELATED D CORRECTIVE ACTION PRIMARY O E SECONDARY O RECOMMENDED:

N Et GEN /DiST. O G COOL wTR/ MISC.O l LOGICS /CTRLS O N PMS-COMPUTER O inst. AIDS O E SYSTEM O TAKEN:

E DATABASE D 1

R SPDS O HARDWARE 4 PANELS O COMPUTERS O l

PROGRAMS /MODELS CHANGED:

IMPLEMENTED BY: DATE:

RETEST REQUIRED: @ E E DDB*

TEST UNSATISFACTORY: DOCUMENTATION UPDATE REQ'D @E

$ DATE/INIT. DATE/lNIT. DATE/INIT.  ! UPDA,TE COMPLETED I TEST SATISFACTORY: INITIAL / DATE E UPDATE VERIFIED DATE/INIT. R INm AL /DATE DISTRIBUTION WHITE & CANARY- PERSON ASSIGNED DR PINK -MASTER DR LOG

.q i

ERC890985-04/06/89 FIG. 3 PAGE 2 0F 2 -1 I

i i

l 1

i l

i i

l i

l 1

i

ANO SIMULATOR UNIT DISCREPANCY REPORT D R.*

CONTINUATION SHEET CONTINUATION OF: O REPORT OF PROBLEM O CORRECTION COMPLETED BY: DATE/ TIME:

I l

l I

I DISTRIBUTION WHITE-PERSON ASSIGNED DR. CANARY-MAJTER DR. LOG PINK-OPEN DR. LOG

?

- ERC890985

.. 04/06/89.

FIG.<4 SIMULATOR MODIFICATION

SUMMARY

.INFORMATION..

DR.# 'DCP #

1 PROCESSING SEQUENCE SIGNATURE DATE-TRAINING PRIORITY ASSIGNED Lead Sim Inst SM INITIATED

-Sim Engr APPROVED FOR DESIGN DEVELOPMENT Sim Sup Supv HARDWARE ORDERED.

Sim Engr.

SOFTWARE WORK COMPLETE Sim Engr HARDWARE. WORK COMPLETE-'

Designer

-INITIAL TESTING COMPLETE-Sim Engr TRAINING TESTED AND ACCEPTED j Lead Sim Inst DOCUMENTATION UPDATED Sim Engr SM CLOSED Sim Sup Supv l..:

i

,+s, I

I l

I

ERC890985 04/06/89 FIGURE 5 DISCREPANCY REPORT LOG l DR/DCP l DATE l NUMBER WRITTEN l DESCRIPTION OF PROBLEM N NG I

I i

I  ;  ; I I

ERC890985 i 04/06/89 Fig. 6 Page I of 2 SIMULATOR MODIFICATION

SUMMARY

DR #  :

DCP #  :

TITLE  :

SOFTWARE MODIFICATION:

l H/W MODIFICATION:

9 i

i I

i 1

BILL OF MATERIALS  ;

ITEM QUANTITY COST Total i

'ERC890985 04/06/89 Fig. 6 ..

.Page-2 of 2

. SIMULATOR MODIFICATION

SUMMARY

DR.#  :

DCP #"  :

TITLE  :

S/W ACTIVITY- M/H S/H DB Related N/A I.A.~ Related N/A-Detailed Design 4N/A Code Implementation N/A o- Initial Test Associated S/W Support Documentation N/A DWG Update- N/A Total H/W ACTIVITY M/H S/H-Installation Dwg. Update N/A-N/A Total PERFORMANCE TESTING M/H S/H l

=

I- Total

ERC890985 04/06/89 FIG. 7 SIMULATOR MODIFICATION SPECIFICATIONS REVIEW DR # DCP # ,,

DATE SM SPECIFICATION APPROVED:

Sim Engr Lead Sim Inst l

l l

l a

ERC890985 04/06/89 FIG. 8

}

SM HARDWARE DESIGN DR # DCP # DATE Designer:

^

s. _

_____---,----_---_____~_-a

ERC890985 04/06/89 FIG. 9 SM SOFTWARE DESIGN DR // DCP # DATE Designer:

____-_I___

ERC8'0985 9

04/06/89 4-FIG. 10 SIMULATOR DR TEST PLAN:

DEVELOPED BY: DATE: IC#(s): DR#:

. INITIAL TEST: DATE: REVIEWED BY:

. REFERENCES USED:

THE FOLLOWING TEST WAS COMPLETED:

1. SATISFACTORY /

NAME DATE

2. UNSATISFACTORY / ~

NAME DATE.-

IF UNSATISFACTORY LIST DISCREPANCIES OBSERVED:

1 PROCEDURE

1. RESET SIMULATOR TO IC-  !

I l

i I

i

-l l

1 i

PROCEDURE CONTINUED' PAGE 1 l

l

~ERC890985 04/06/89' FIG.'11

'Page 1 of 2-DOCUMENTATION UPDATE PACKAGE.

DR #

Place a check by the documents (for which an update'is being provided.

~

A. Final Software Design Specification-

-1. System Design Data

2. System Malfunctions
3. System Remote Functions
4. Design Assumptions
5. Design Simplifications
6. System Panel Instrumentation
a. Meters
b. Recorders
c. Controllers
d. Lights
e. Switches
f. Miscellaneous
g. Annunicators
7. PCM Monitored Parameters
8. Process Computer Monitored Parameters.
9. Air Operated Valves
10. Solenoid / Motor Operated Valves .,
11. Pump Motors
12. Meters / Transmitters
13. Simulation System Description

a

  • i ERC890985 04/06/89 FIG. 11-

'Page 2 of.2-

14. Simulation' System Diagrams '
15. Source Code comments.
B. Simulator. Operations and Maintenance Manual
1. Description and Leading Particulars-
2. Operating Instructions .

C. Simulator Hardware Drawings

1. Trainer Block Diagrams (900 Seriew)~ ,,

~

2. Wire-List 3.
4. ,

5.

D. Design Data Base Report E. Simulator Test Plan (s)

F. Simulator Malfunction Cause and Effects g .,.

ERC890985: i 04/06/89 {

i FIG. 12 JOB REQUEST i.

SUBJECT:

, FROM: )

TO:

DR #: UNIT #: DATE ISSUED:

DCP #: DATE COMPLETED:

DESCRIPTION:

ATTACHMENTS:

ACTION:

i l

l l

l l

l l

l

.._,~

l

i i

i 1

ATTACHMENT 4 i

ANO TRAINING ADMINISTRATIVE GUIDELINE  !

I DOCUMENTS WHICH AFFECT TRAINING J l

1 i

l t

I

(

i I

I e

i 1

i I

l  !

4 I

l ,,

i l

l l

l