(Yes - I know the formatting is messed up. This document was converted from a from one word-processor to another, to another, and then to text. And the figures are missing.) Don't know what PLATO is? Click here to see it in action.

A PLATO COMPUTER BASED EDUCATION SYSTEM
FOR TRAINING NUCLEAR REACTOR OPERATORS




A Thesis


Presented in Partial Fulfillment of the Requirements
for the Degree Master of Science in the Graduate
School of the Ohio State University

By

Stanley F. Quayle, B.S., M.S.


The Ohio State University

1980

Reading Committee
Approved by
Dr. Philip A. Schlosser, Advisor
Dr. Don W. Miller
Mr. Brian K. Hajek

Copyright **COPYRIGHT** 1980 by Stanley F. Quayle.
All rights reserved.
DEDICATION

To Lynn, a dear friend from PLATO.














ii

ACKNOWLEDGEMENTS

My greatest thanks go to those persons at Ohio State who
were the most instrumental in this project: Salvatore
Abate, Dr. James Canelos, Rosanne Francis, Dave Romer, and
Joseph Talnagi.
I deeply thank the users of PLATO everywhere, who are too
numerous to list: they supported me when I was going
insane, and helped me to solve many a programming problem.
I thank the management personnel of the Tech Spec project
for making this project possible: Brian Hajek, Keith Hall,
and George Hodge.
Special thanks to my advisor, Dr. Philip A. Schlosser, for
putting up with me for so long.


















iii
TABLE OF CONTENTS


Page
DEDICATION ..................................... ii
ACKNOWLEDGEMENTS ............................... iii
LIST OF FIGURES ................................ v
GLOSSARY ....................................... vi
Chapter
1. INTRODUCTION ............................. 1
1.1 Objectives .......................... 1
1.2 What Is to be Taught ................ 2
1.3 Rationale ........................... 3
1.4 Methods Examined .................... 4
1.5 The Mastery Learning Model .......... 6
1.6 Results of Project .................. 15
2. THE COMMON PROGRAM ....................... 17
2.1 Design of Program ................... 17
2.2 Structure of a Module ............... 20
2.3 The Test ............................ 38
2.4 Features Available .................. 46
2.5 Creating New Modules ................ 57

3. AUXILIARY PROGRAMS ........................ 59
3.1 Utility Lesson ...................... 59
3.2 Instructor Control Program .......... 60
3.3 Student Router ...................... 62
4. FUTURE OPTIONS ........................... 64
4.1 Addition of New Features ............ 64

4.2 Revision to Use New PLATO Features .. 66
4.3 New Educational Projects ............ 69
5. CONCLUSIONS .............................. 71
5.1 Impact on Operations ................ 71
5.2 Summary ............................. 71
REFERENCES ..................................... 73
APPENDICES
A. MODULES DEVELOPED ........................ 74
B. USER'S GUIDE--BUILDING A MODULE .......... 81
iv

LIST OF FIGURES

Page
1 Block Diagram of Instructional Model 7
2 Instructional Flowchart 8
3 Relationship of files in a module 19
4 Block diagram of a module 21
5 Sample of code from common program,
initial entry unit 22
6 Sample of code from a module,
initial entry unit 25
7 Picture of a typical title page 26
8 Picture of a typical credits page 27
9 Picture of a typical overview page 28
10 Code for an instructional display 30
11 Picture of a typical instructional
display 31
12 Code to ask a question 33
13 Sample of code from a module,
question and feedback subroutines 34

14 Sample of code from common program,
subroutine "multif" 35
15 Picture of question from a module 36
16 Picture of feedback from a module 37
17 Sample of code from common program,
subroutine "multi" 40
18 Picture of criterion test page 41
19 Criterion test code 42
20 Elaborative feedback code 47



v
GLOSSARY

Bases--Those parts of the technical specifications that
detail the rationale for operational limitations.
CBE--Computer Based Education. Education conducted, at
least in part, by the use of a computer.
CDC--Control Data Corporation. The owners of PLATO.
common block--A special machine-readable data area. The
text of the questions are stored in a common block.
DBNPS--Davis-Besse Nuclear Power Station.
ICP--Instructor Control Program. The lesson that
instructors will use to modify the records in the
database. Written by Dave Romer.
IEU--Initial Entry Unit. The first code to be executed
upon entry to a lesson.
lesson--A computer program to teach a subject. Synonymous
with "module" and "program" in this thesis.
module--One of the twenty lessons developed to teach
technical specifications. The modules are divided
by system. (See Appendix A.)
PLATO--The computer education system developed by CDC and
the University of Illinois. PLATO is a registered
trademark of CDC.
PLM--PLATO Learning Management. A CBE system developed by
CDC on the PLATO system.
program--A computer program. Synonymous with "lesson" and
"module" in this thesis.
Technical Specifications--Limitations on the operation of
the nuclear plant, and the
reasons for those limits.
TUTOR--The programming language available on PLATO.



vi

CHAPTER 1

INTRODUCTION



1.1 Objectives


This thesis describes the design and development of a
set of computer programs that implement a computer based
education system for nuclear power plant operators. Each
of these programs is known as a module. The information is
split among the modules by reactor system. (Appendix A.)
The modules are based upon a common core of subroutines
known as the "common program."
The design objectives of the common program were to:

1. Minimize the programming time required to create a new
module,

2. Make each module easy to modify,

3. Permit a large amount of data about each student to be
recorded, while making the data invisible to programmers of
individual modules,

4. Provide features useful to programmers of new modules,

5. Allow program maintenance without sending personnel to
the sponsor location,

6. Permit and use the full capability of the PLATO
computer system,

7. Permit new features to be added with a minimum of
programming time and effort, and

8. Make the subroutines general enough so that
another education project can be undertaken,
whether for nuclear power plant operators or
another audience entirely.

Since the form in which the questions are stored is not
directly human-readable, several utility programs were to
be written to facilitate creation of new modules. These
programs help create, display, and print question blocks.
Also, special interfaces were needed for the students
and instructors. The student interface, called a router,
controls the order in which students may take the modules.
The instructor control program allows an instructor to
Manipulate the records of each student. The records
determine what modules the student may take and in what
order they may be taken.


1.2 What Is to be Taught

The technical specifications for each nuclear power
plant detail the limitations on the operation of that
plant. Operators are required to know these
specifications. When an unsafe condition arises, operators
are required to be able to recognize the
condition and to
act in accordance with the applicable specifications and
procedures.
Technical specifications are different for each plant;
however, they share common features. Technical
specifications exist for operational limits, how to
insure that those limitations are not exceeded, the action
to be taken when the limitations are exceeded, and the
rationale for each requirement.
At the Davis-Besse Nuclear Power Station (DBNPS), these
four areas are known as Limiting Conditions for Operation,
Surveillance Requirements, Action Statements, and Bases.
There is a numbering system such that associated
limitations from all four categories can be related to each
other.


1.3 Rationale


The accident at the Three Mile Island nuclear
power plant has brought attention to the subject of reactor
operator training. The problems at TMI were aggravated by
operator error. If human error can be avoided in the
future, accidents can be prevented or reduced in severity.
In the past, operators and engineers were given ten
hours of classroom instruction on the bases and technical
specifications that they were required to know, and then
were given a copy of the bases and technical specifications
to study on their own time.
The proposal for this project suggested that a computer
based education approach would improve training. It was
hoped that the high amount of interaction possible would
reduce student frustration, optimize the use of the
student's time, and reduce the student motivation required.
Since the technical material has many graphs and diagrams,
the Control Data Corporation PLATO system seemed to be the
perfect choice.

1.4 Methods Examined


PLATO has a powerful program package for education.
This is PLATO Learning Management (PLM), which is a very
well developed, CDC supported education system. There are
many options available to the developer of a course. Also,
the standardized format of lessons written with PLM allows
a typist to enter the entire lesson without help from a
programmer. This can result in significant cost savings.
One important requirement of a computer based
education system is that the student be comfortable with
it. The format becomes familiar quickly, so the student
knows what options he has available. This can reduce
student frustration.
However, PLM has several drawbacks. Because of the
rigid format, the full power of PLATO graphics cannot be
used. It was determined early in the project that PLM
could not support the necessary graphs and diagrams. The
only way to circumvent this problem would have been to
issue a booklet of diagrams. This eliminates one of the
attractions of the computer based education approach, which
has the potential to be entirely paper free and
instantly available anywhere in the country.
Further, PLM is a testing oriented system.
Instead of being able to present the technical specifications to the
student, PLM is designed only to test the student on his
knowledge. Therefore, each student would have to have a
copy of the specifications to study. The only function of
PLATO would be to issue tests to the students.
In lieu of PLM, programs can be written in the TUTOR
language. TUTOR was designed for the PLATO system. So, a
lesson in TUTOR can take advantage of the full capabilites
of PLATO. Flexibility is maximized.
With a lesson written in TUTOR, all information can be
presented on line. As far as the student is concerned, the
printed copy of the technical specifications need not
exist.
Any combination of information and testing can be
implemented.

However, writing a program in TUTOR can entail high
cost. Programmers must be hired and trained in the use of
the TUTOR language. If some unexplained error develops in
the lesson, the programmers must fix it; with PLM, CDC is
responsible for maintenance of the PLM package and will fix
system errors.


1.5 The Mastery Learning Model


The students at DBNPS form a diverse population.
There are three different types of students: reactor
operators (RO's), senior reactor operators (SRO's), and
engineers (ENG's). Some students are taking recurrent
training, while others are seeing the material for the
first time.
A wide range of student motivation and prior
experience can be handled well by mastery learning
educational models. (Ref. 1.) In a mastery learning
model, the student must demonstrate mastery of the material
by passing a final test over that material. This
"criterion test" ensures a minimum knowledge on the part of
each student. Safety requires this, since the student must
know the technical specifications to safely operate the
plant.
The movement of the student through a typical module
is described below. Figure 1 shows a very general block
diagram of the model, while figure 2 shows the model in a
flowchart.
The instructional model is broken into four phases:
pretest, overview, instructional material, and criterion
test. The student, at the option of the instructor,
may























Figure 1.

Block Diagram of Instructional Model
























Figure 2.


Instructional Flowchart

(Page 1 of 5)

























Figure 2.

Instructional Flowchart

(Page 2 of 5)

























Figure 2.

Instructional Flowchart

(Page 3 of 5)
























Figure 2
.

Instructional Flowchart

(Page 4 of 5)
























Figure 2.

Instructional Flowchart

(Page 5 of 5)


take a pretest. This allows students with prior experience
to gain credit for a module with little effort. If the
student passes the pretest, he exits the module.
Otherwise, he moves to the overview.
The overview provides an intellectual structure on
which he can add the information to be given in the
instructional section. The overview shows the specific
system and its relation to the whole plant. The student is
not tested on any of the material in the overview.
The instructional section presents material the
student must know. Questions are asked so he may
practice his knowledge. The score on these questions is not
considered significant and is not saved. The score is
shown to the student for his reference.

After completing the instructional section, the
student is given the criterion test. If the
student passes the criterion test, he exits the module. If he fails, he
is given elaborative feedback on the wrong answers he made
and is sent back to the test. This elaborative feedback
shows his answer and why it was wrong. If the student
fails the test again, he is sent back through the entire
instructional section. This cycle repeats until he passes
or he fails for the fourth time. After the fourth failure,
he is locked out of the module and notice is sent to his
instructor.
The three different student groups (RO, SRO, ENG)
require different amounts of material. The RO requires
only the technical specifications. The SRO receives the
bases in addition. The ENG receives all this, plus special
engineering technical specifications. When the student
is sent through the module, he sees only the information his
instructor desires him to see.
Material of each type that deals with the same concept
is arranged in a serial fashion; bases first, technical
specifications second, followed by engineering
specifications. The student proceeds straight through this
series and automatically skips material he is not to see
.
The student has many options and choices in each
module. At most points in a module, he may move to a
previous page, move onwards, or see various displays with
helpful material. At the ends of the overview and
instructional sections, he has options to go on to the next
section or to review. In the instructional section, he may
review an entire set of related technical
specifications.
The wide range of options can reduce student
frustration. The student may leave the less
on at any time.
The computer will remember what he was doing, and allow him
to resume later. If he is encountering some difficulty
with the computer,
and the on-line documentation is of no
help, he may quit and seek the help of his instructor.

1.6 Results of Project


The project staff wrote a series of modules to teach
technical specifications to the students at DBNPS.
Each
module presents the applicable technical specifications on
a particular reactor system. The student is then tested on
the specifications.
Each module is based on a general set of subroutines
known as the common program. The common program meets
its
design goals of making the writing of new modules easier,
faster, an
d less expensive. The time to produce a new
module can be as short as a week, depending on the
complexity of the material to be programmed. A guide for
programmers has been written
which outlines the steps
necessary to create a module. (Appendix B.)
The maintenance of existing modules is made easier by
the structure of the common program. This is because
critical and important operations are isolated from the
module programmer.

Features are provided which are very useful to
module
programmers. Also, flexibility to add new features
remains; a subroutine only need be added or modified to add
a new feature.
Several utility programs were written to assist in
programming new
modules. These programs were combined late

in the project into one integrated utility lesson. Another
staff member wrote a lesson to manage the student records.
These records are used by a special program (known as a
router) to control the sequence in
which a student may take
the modules.

CHAPTER 2

THE COMMON PROGRAM



2.1 Design of Program


To meet the design goals, the computer science concept
of modularity was used. In this approach, a task is broken
into subtasks.
These subtasks are performed by
subroutines. Each subtask is divided into sub-subtasks, so
each subroutine in turn calls additional subroutines. In
this way, only the lowest level of subroutines needs to be
dependent on the specific implementation
of the program.
Documentation of the common program is made easier, since
the number of points at which a given datum might change is
restricted. The highest level subroutines can be made
available to programmers who are not aware of the
underlying structure. This decreases training time and
costs.
The code that is used by all the modules is known as
the common program. Only one person changes the common
program. This prevents two persons from making conflicting
changes.

One of the most important aspects of the common program
is its database. The database consists of two separate
files. File "nukestu" contains a record for each module
that each student will take. The records
specify what
material he is to receive.
The record is updated by the
module periodically to reflect the student's progress.
File "sturesp" (the student response dataset) holds the
student's answers on the questions he has been given. The
records in this
file are not in one-to-one correspondence
with the modules. This complex database is invisible to
the module programmer. Subroutines from the common program
read and write the data. The module programmer is not to
interact with the database in any other
way.
Figure 3 shows t
he relationship between a module, the
common program, and the datafiles. Lesson "block" is a
utility program for manipulating the multiple choice
questions stored in a common block (a special machine
readable format).
Subroutines
are provided t
o reduce coding time for
various types of questions. These vary from fairly
primitive subroutines that insert a response into the
student response dataset, to complex routines that can
present, judge, and store a whole multiple choice question.

Other features include code for presenting the criterion
test and code for presenting elaborative feedback.























Figure 3.

Relationship of Files in a Module

All the modules have similiar structure. This is
encouraged by
project programming guidelines as well as the
structure of the common program. This commonality of
structure reduces the time to repair or update a given
module. A person who
did not program a module originally
can repair it quickly. Also, an existing
module can be
used as an example for a trainee.
The similarity between modules means that less time is
needed to document each module. The time can be used to
explain novel features of each module, rather than those
that are common to all. This again
results in a decrease
in costs and an increase in programmer productivity.


2.2 Structure of a Module


There are seven important sections of each module: the
inital entry unit (ieu), the pretest, the overview,
the
instructional section, the test, the elaborative feedback
section, and how questions are asked. The structure of
several of these components is shown
in Figure 4.
The first section of code in the common program defines
variables used in the program.
Since this code is supposed
to be executed when the module is entered for the first
time, it is known as the initial entry unit (ieu). P
art of
the code is shown in Figure 5.























Figure 4.

Block Diagram of a Module

























Figure 5.

Initial Entry Unit from Common Program

(Page 1 of 2)
























Figure 5.

Initial Entry Unit from Common Program


(Page 2 of 2)


The initial entry unit of the module must include the
ieu code from the common program. Figure 6 shows the ieu
of a typical module. The "use" refers to the ieu code
from
the common program. Each module must also specify the
location of a machine readable data area that contains the
text of the questions.
In the same block of code with the initial entry unit
are the statements to display the title and credits pages.

Typical title and credit pages are shown in Figures 7 and
8.
The pretest is the next major section. The student
receives the opportunity to take the pretest only if his
instructor has set that option in his records. If he
decides to take the pretest,
control passes to the test
subroutine ("tester"). If the student passes, he exits the
module. If he fails or does not take the test, he is sent
to the overview.
The first unit of the overview must be titled
"overview". The following units of the
overview may
have
any name. Names that start with "view" followed by a
serial number are encouraged. Control passes from one unit
to the next. The last unit of the overview passes control
to unit "instr1" of the common program. A typical overview
display
is
shown in Figure 9. Unit "instr1" gives the
student the option of reviewing the entire overview.























Figure 6.

Initial Entry Unit from a Module

























Figure 7.

Picture of a Typical Title Page

























Figure 8.

Picture of a Typical Cr
edits Page

























Figure 9.

Picture of a Typical Overview Page


Unit "instr1a" displays a standard page
that tells the
student that he must know the material to be presented.
Control then passes to unit "instr". This is the first
page of the instructional section, and is usually coded to
list the areas of information covered by the following
displays. The
following units may have any names the
programmer desires. The usual practice is to name each one
"d" followed by a serial number. An example of the
instructional section coding is shown in Figure 10, and a
typical instructional section display in Figure
11.
The display units are executed in serial fashion. The
computer checks the classification of the student before
presenting any information. If the student is not to see
the material, control passes to the next unit in the
instructional section.

When the instructional section is complete, common
program unit "instr3" is called. A standard page is
displayed, telling the student that he may review the
entire module or move on. Also, his score on the entire
instructional section is presented.
Depending on options
set by his instructor, he may be given a criterion test or
be allowed to leave the module.
If the student is to receive the criterion test,
control passes to module unit "tester". The student is
shown a page telling him the areas of
information on which
he will be tested. When he presses the NEXT function key,
the test begins.























Figure 10.

Code for an Instructional Display from a Typical Module


























Figure 11.

Picture of a Typical Instructional Display


After a specification, questions are asked to assist
the student in recalling the information. The unit
that
asks the question is very simple to code. The question
number that is to be displayed
("qnum") is incremented,
"ques" is assigned the serial number of the question, and a
question subroutine is called. An example of the code
necessary is show
n in Figure 12.
Each question has an associated subroutine. This
allows the same question to be
asked in both the
instructional section and the test without duplication of
code. Figure 13 shows the code required in a multiple
choice question subroutine. Also shown is the code
required for a multiple choice feedback subroutine.
Subroutines for
questions and their feedback should be in
one-to-one correspondence.
Figure 14 shows the code from the common program that
implements the elaborative feedback for multiple choice
questions. Subroutine "multif" reconstructs the student's
response to a
question on the criterion test and displays
it, the correct answer, and the question. Figures 15 and
16 shows how this appears on t
he screen.


























Figure 12.

Code to Ask a Question from a Typical Module

























Figure 13
.

Question and Feedback Subroutines from a Typical Module

























Figure 14.

Subroutine "multif" from the Common Program


























Figure 15.

Picture of Question from a Module


























Figure 16.

Picture of Feedback from a Module



2.3 The Test


The most
challenging specification for the common
program was for the test. There are two types of tests:
the criterion test and the pretest. On the pretest, if the
student misses enough questions to assure hi
s failure, he
is told as soon as possible and sent back
to the overview.
The criterion test allows the student to continue. Also,
the student may see elaborative feedback after a criterion
test. No elaborative feedback is shown after a pretest.

It was decided by the project staff, on educational
psychology
grounds, that the distractors (possible answers)
of multiple choice questions should be randomly permuted
each time the question was displayed. To minimize the time
spent writing quest
ions, the same questions are used in
both the instructional section and
criterion test. Since
the pool of available questions can be very small, the
student may begin to recognize questions that he had seen
before. It was decided to permute the distractors in the
instructional section as well as in the test.
Because of
psychology, the staff decided that the last
five questions in the instructional section should not
appear anywhere in the first five questions of the test.
DBNPS requested the option of specifying "difficult"
questions that should not appear within the
first fifteen
questions of the test, unless the test would be less than
fifteen questions. Also, DBNPS wanted the ability to
require certain questions to appear on every test.
Finally, the test should have thirty questions, unless
the pool is less than
thirty questions. In this case, the
student will receive all the questions in the pool. The
minimum passing grade is 80%.
Permutation of distract
ors was the first requirement
met. Since one subroutine ("multi") must be called to ask
all multiple choice
questions, that subroutine was written
to permute distractors. TUTOR provides a facility to
select elements randomly from a list of elements
. The
element selected is automatically removed from the list.
Figure 17 shows the code for subroutine "multi".
The
permutation of the distractors is done in low level
subroutine "displd" (line 7). "displd" builds a mapping
ifteen questions. Also
, DBNPS wanted the ability to
require certain questions to appear on every test.
Finally, the test should have thirty
questions, unless
the pool is less than thirty questions. In this case, the
student will receive all the questions in t
he pool. The
minimum passing grade is 80%.
Permutation of distractors was the first requirement
met. Since one subroutine ("multi")
must be called to ask
all multiple choice questions, that subroutine was written
to permute distractors. TUTOR
provides a facility to
select elements randomly from a list of elements. The
element selected is automatically removed from the list.
Figure 17
shows the code for subroutine "multi". The
permutation of the distractors is done in low level
subroutine "displd" (line 7). "displd" builds a mapping
between the position of the answers on the screen and their
position in the special machine readable
question bank
(called a common block). The mapping is passed in a
variable to subroutine "input" (
line 17). "input" judges
the response and stores it in the student response dataset.
Once the question is judged, the mapping is discarded.
The remainder
of the requirements were more difficult.
Figure 18 shows the entry page to the test. This
is
generated by lines 8-22 of Figure 19, which is the code
from a module's test. The "use" command inserts the
specified code from the common program into the
module























Figure 17.

Subroutine "multi" from the Common Program

























Figure 18.

Picture of Criterion Test Page

























Figure 19.

Code to Present a Test from a Typical Module

(Page 1 of 2)
























Figure 19.

Code to Present
a Test from a Typical Module

(Page 2 of 2)


where the command is (lines 1, 23, 29, 31,
33, and 44).
The first "use" causes a standard page to be displayed,
which warns the student that he about to take a test. The

"use" on line 23 inserts the code that sets up the required
information for the test.
The code inserted at line 23 does the
following. If
this is the student's first time in the test, a list of
questions will be created. This list (in variable
"list")
is the list of questions available to be asked on this
test. Then the current value of "list" is copied to
"oldlist". It creates
a list of questions that must be
asked on each test, "reqd". It also sets his score to
zero.
If the end o
f the test is approaching and required
questions remain to be asked, a required question is
randomly selected from "reqd".
Otherwise, it selects a
question at random from "list".
If there are no more questions in "list", a new list is
created.
In this case, "oldlist" contains the questions
asked so far during this test (it holds a copy of the
initial list). Those questions must be removed from the
new
list. So, the exclusive-or of "oldlist" and "list" is
computed and put into "list". Only questions that have not
been asked so far on this test and that the student is
eligible to receive are left in "list".
The code inserted at line 29 will put the
selected
question back in "list" if it is one of the last five
questions
in the instructional section and less than five
questions have been asked so far.
If the question chosen is a difficult question, it
will be put back into "list" by the code at line
31 if less
than fifteen questions have been asked. Line 30 checks for
difficult questions (none have been assigned by DBNPS in
this case).
Line 32 checks to see if the question selected is a
required question (none have been assigned by DBNPS in
this
case). If so, it must be removed from "reqd". Otherwise,
the program will force itself to ask this question again
near the end of the test. The code inserted at line 33
removes the question from "reqd", and prepares to ask the
question selected.

Each question has an associated subroutine. To ask
a
question, the corresponding subroutine must be called.
For example, lines 34-41 call ("do") a question subroutine
depending on the value of "ques", which is the serial
number of the question
selected.
The code at line 44 checks the student's score at the
end of the test. If the student passes, he is given a
standard congratulations message and is allowed to exit the
module. His records in the database are updated to
indicate his passing.
His grade and responses to the test
a
re stored.
If the student fails, he is shown a standard "better
luck next time" page. His performance and responses are
stored in the database. If the test was a pretest, he is
sent to the overview.
If the student
fails a criterion test for the first or
third time, the subroutine that performs elaborative
feedback is called. The student sees the questions he
missed, his answers, and why they are wrong. He is then
sent back through the criterion test. See Figure 20
for
the code for
a typical module's elaborative feedback
section.
If the student a criterion test fails for the second
time, he is sent to the beginning of the instructional
section without feedback.
If the student fails a criterion test for the
fourth
time, he is told that he should consult with his instructor
and is prevented from entering the module again. This is
to prevent the student from becoming stuck at one point in
the curriculum.


2.4 Features Available


There are two different types of code in the common
program. The first type is structrual; that is, code that
is executed in a main-line manner. The second type of code























Figure 20.

Code to Present Elaborative Feedback

from a Typical Module


is supportive. This code consists of subroutines that are
called from elsewhere in the common program and module but
are never executed as main routines.


Structural Features

Block "defines"--the code in this block holds much of the
initial entry unit (IEU) for the module. This sets several
parameters, and allocates the variables us
ed.

Block "start"--contains unit "inits".
This routine sets
three variables to initial values. If the module has not
been officially released, this unit displays a message to
non-project users.

Block "overvu1"--contains unit "overvu1". This routine
checks the student's records in file "nukestu".
If the
student has no record for the module, or if he is locked
out, he is stopped from going further in the module.

Block "overvu2"--contains units "keys", "overvu2", and
"preintro".
"keys" tells the student that the HELP key is
available throughout the
module. "overvu2" offers the
student the chance to take the pretest, if the instructor
has set that option. If the student decides to take the
pretest, control passes to unit
"preintro", which tells the
student on what material he will be tested.

Block
"instr1"--contains units "instr1", "instr1a", and
"instr2". Unit "instr1" tells the student that he has
finished the overview and offers him the opportunity to
review it. If he elects to continue, unit "instr1a" will
display a message saying that the
student will receive
questions during the instructional section. He is asked if
he wishes to see whether he is right or wrong on these
questions. Unit "instr2" initializes several variables
before the instructional section begins.

Block "instr2"--contains
unit "instr3". If the student has
gone through the module in the review-only mode (no
questions), he is told that he has finished the module. If
he is in
stead to receive the criterion test, he is given
the opportunity to review the instructional section
first.

Blocks "tester1", "tester2", "tester3", "tester4", and
"tester5"--contain units "test1", "setup", "generate",
"present", "done", "pass", "pass2", "fail", and "fail2".
These routines control the test. "test1" asks the student
if he wishes to see
immediate feedback during the test.
"setup" initializes the lists and variables required for
the test. "generate" selects the question
to be presented.
"present" presents the question and waits for the student's
response. When the student has finished the
test, unit
"done" passes control to either "pass" or "fail" depending
on the score. Units "pass" and "pass2" tell the student

that he passed the test and allow him the chance to see the
elaborative feedback on the questions missed. Units "fail"
and "fail2"
tell the student that he has failed the test
and then route him according to the testing algorithm.

Blocks "feed1"
and "feed2"--contain units "feedbk",
"nxtwrd", and "seek". Unit "feedbk" presents the
elaborative feedback on the questions missed on the test.

Units "nxtwrd" and "seek" are subroutines that are called
by "feedbk". Although "nxtwrd" and "seek" are
supportive
subroutines, they are included in block "feed2" because of
their close association with unit "feedbk".

Supportive Features

With the exception of subroutines "nxtwrd" and "seek",
all supportive code is contained in several blocks called
"subroutine". The purposes of these subroutines are many.
Several are called by other routines in the module.
Others
are called by programmers and users via special function
keys (the TERM key).

Subroutine "writeout" stores the student's record in
file "nukestu". This routine is called whenever a change
is made in the student record. Also, it is
automatically
called when the student exits the module.
Subroutine "writeres" stores the
student's responses to
the questions presented in file "sturesp". This routine is
called at the end of the instructional section and at the
end of the test.

Subroutine "arrow1" waits for a student's response to a
simple yes/no question. This
question is not on the test.
It appears when the student is asked if he wishes to
receive immediate feedback. There are four places in the
code where this question is
asked. The response is stored
in variable "i".
Subroutine "multi" asks a multiple choice question.
Variable "ques" must be set to the serial number of the
question before calling "multi". The question is fetched
from the common block and displayed.
The student's
response is input and judged. He is given immediatefeedback if he wishes. This subroutine is designed to be
called directly in a module.
Subroutine "fetch" consults the table of pointers at
the begining of the common block and sets up a
list of
pointers to the question and distractors of the question.
Subroutine "multif" presents elaborative feedback for a
multiple choice question. Variable "ques" must be set to
the serial number of the question. This subroutine is
designed to be
called directly in a module.
Subroutine "displt"
displays the text of a question
from the common block. "fetch" must be called first.
Subroutine "displd" displays the distractors for a
multiple choice question. "fetch" must be called first.

Subroutine "input" checks the student's response to a
multiple choice question and determines if it is a right or
wrong answer. It calls "insert" to store the response in
file "sturesp".
Subroutine "insert" inserts a word in the response
dataset.
The question serial number, response, and
correct/incorrect flag are packed into a word and stored in
"sturesp".
Subroutine "fill" displays the stem of a fill-in
question. Variable "ques" must be set to the serial number
of the question before calling
"fill". The text is fetch
ed
from the common block and displayed at the locations
specified by the parameters.
Subroutine "fillr" is called after a judging a fill-in
answer to be correct. "right", the number of questions
correctly answered, is
incremented and the student's
response is stored in "sturesp". The response is tagged to
show that the correct answer was chosen. The response must
be in variables "howfar" through "d5" when "fillr" is
called.
Subroutine "fillw" is called after judging
a fill-in
answer to be incorrect. "wrong", the number of questions
incorrectly answered, is incremented and the student's
response is stored in "sturesp". The response is tagged to
show that a wrong answer was chosen. The response must be
in variables
"howfar" through "d5" when "fillw" is called.
Subroutine "fillf" is called in a fill-in feedback
subroutine. This routine reconstructs the answer at the
current position in "sturesp" and places it in variables
"howfar" through "d5".
Subroutine
"imain" is automatically called by each
unit. When a new unit is entered, the code in "imain" is
executed first. "imain" sets default units to be called
when the student presses the HELP and Shift-DATA keys.
Also, the name of the current unit is
shown to
staff
members at all times. All users see the unit name until
the unit is released. When a staff member receives new
personal notes (a feature of PLATO), he is given a message
at the bottom of the screen.
Subroutine "help1" is called
when the student
presses
the HELP function key from most places in the module. The
student sees a display of available help documents. He may
choose to see a list of the function keys, see how to
answer the three types of questions, or leave a comment on
the lesson. The
student types a letter ("a"-"e") for his
choice. A jump is made to a unit that displays the
appropriate help. When the student presses the BACK
function key, he returns to the point where he pressed
HELP.
Subroutines "
keyhelp" and "keyhlp" list the
available
function keys and what each do. Subroutine "multhelp"
tells the student how he should type in his answer to a
multiple choice question. The same is done for touch and
fill-in questions by subroutines
"tchhelp" and "short".
Subroutines "trytch"
and "short2" allow the student to
practice answering sample touch and fill-in questions.
Subroutine "note" allows the student to write a comment on
the lesson. The comment goes to a special file specifiedby the module author.
Subroutine "set" is called
when the student presses the
Shift-DATA function key from most places in the module. If
the student is going through the module in review mode
(receiving no questions), he is told so. Otherwise
, he is
given an opportunity to see immediate feedback on
the
questions he is asked in the module.
Subroutine "chars" reloads the character set. There
can be times that noise on the telephone line connecting
the terminal to the computer will ca
use the character set,
a special memory in the terminal, to be
erased. When the
student presses the TERM function key and types "chars",
the character set will be reloaded.
Subroutine "icp" allows staff members to jump to the
instructor control
program. This allows an author to test
the features of the module by
changing his records. This
subroutine is called by pressing the TERM key and typing
"icp".
Subroutine "notes" allows staff members to read their
personal notes. Typing the TERM key and "notes" will send
the person to the system personal notes program.
Pressing
the BACK function key from that lesson will return to
subroutine "notes2", which then jumps to the point where
the staff member pressed the TERM key.

Subroutine "replot" is called by pressing the TERM key
and typing "replot". The screen is
erased by the
subroutine call. The subroutine branches back to the
beginning of the unit it was called from, thus replotting
the screen.
Subroutine "save" is available only to staff members.
The responses recorded in memory are transferred to
file
"sturesp" for permanent recording. This allows a module
author to save his responses to the questions and then test
the feedback section. This subroutine is called by using
the TERM key and typing "save". A message is shown at the
bottom of the screen
saying that the data have been saved.
Subroutine "stan" is available to staff members at NSTL
and the sponsor. Pressing the TERM key and typing "stan"
will cause a branch to the feedback section. This allows
quick testing of the feedback subroutines.

Subroutine "status" shows some information about the
lesson and PLATO system. Only staff members may see this
information. I
t is accessed by the TERM key and typing
"status". Subroutine "status2" is called from "status" and
allows the staff member to
see the information continually
updated every few seconds. This is a useful feature if he
is waiting for everyone to leave the lesson so that he may
perform some maintenance on it.
Subroutine "strat" is available only to staff members.
This feature
allows some variables to be changed without
having to jump to the instructor control program. This is
accessed by the TERM key and typing "strat".
Subroutine "term999" allows NSTL and sponsor staff
members to jump to any unit or subroutine in the module.

This allows great flexibility in testing small parts of a
module. A section in the middle of the module
may be
tested without having to proceed through the beginning part
as a student must. This feature is accessed by using the
TERM key and typing "u"
followed by the unit name desired.
Subroutine "convert" is called by "term999" to convert a
number stored in character form into a numeric form.
Subroutine "vars" displays the student variables for
staff members. This feature, accessed by the TERM key
and
typing "vars", allows the author to see the 150 words of
student variables displayed in three formats: as
characters, as decimal numbers, and as octal numbers. This
allows the author to see what is happening at any point in
the module.


2.5 Creating New Modules


The common program and a utility program have been
developed with the goal of implementing new modules quickly
and with a minimum of cost.
The structure of each module is at once rigid
and
open-ended. It is rigid because the programmer of a module
must follow
several conventions in interfacing with the
common program. However, he may organize the material in
any way as long as the interfacing requirements are met.
To facilitate the
creation of new modules, a
step-by-step instruction manual, "User's
Guide--Building a
Module" (Appendix B) has been developed. It details
required programmer experience. If the programmer meets
these minimum requirements, he can follow the
instructions
given and create a new module.
The module must first be prepared on paper. This
process is covered by the "Task Training Guide" (Ref. 2).
The text for the displays and the questions are then typed
onto PLATO by a secretary. The questions
and displays are
typed into separate locations.
Using
the paper version of the module as a guide, the
programmer converts the question text into a machine
readable format. This format is not easily readable by
humans. The question subroutines are then
coded. This
coding depends strongly on both the
question type and also
its particular form. Multiple choice questions are easy to
code. Fill-in questions are coded differently depending on
whether they require two words to be input for an answer or
only
one.
A template for the module is then copied into the
lesson space. This template consists of a standard set of
pages, including the title and credits pages. The
programmer then modifies the information in the template.
The text of the displays is
put into the correct sequence
and
converted to TUTOR statements.
After these few steps, the module will now work in a
rudimentary fashion. Some features, such as allowing the
student to leave and then resume where he left off are not
available, but the
displays can be reviewed.
After the
review process is complete, the code that performs these
more advanced features can be added. This addition is
usually simple; only a single TUTOR statement is usually
added to each display. After a final review, the
module is
complete.




CHAPTER 3

AUXILIARY PROGRAMS



3.1 Utility Lesson


The text of the questions is stored in a special
machine-readable format known as a common block. Although
a common block can be
converted to text and vice-versa,
some functions can only be performed by using the common
block. This was realized early in the program and three
programs were written to perform necessary functions.
At the beginning of each common block is a 1
30-word
area. (See Ref. 3.) This area holds a table of pointers.
The first pointer in the table points to the location of
question 1 in the common block, and so on. If a question
is missing from the common block, that pointer is zero.
Construction of this table would be very tedious if done
manually. Therefore, a utility program was written to
generate the table. The program searches through the
specified common block looking for '**Q', which separates
adjacent questions. The location of the '**Q' is stored in
the pointer table in the location indicated by the

following question number. For example, if '**Q38' were
found at location 1327 in the common block, the number 1327
would be stored at location 38 of the table.

Another lesson was written to display questions in the
same manner as would a module. This allows verification of
questions before the module is coded. Also, suggested
screen locations for the start of distractors for the
multiple choice question
s are displayed.
A third lesson prints the contents of the common block
for review. The output goes to a user-specified dataset.
The dataset can be printed out by any of several
system-supplied utility lessons.
All three lessons were combined near the end of the
project into utility lesson "block". This lesson performs
all three functions in one readily accessible
location. The User's Guide (Appendix B) instructs the
module programmer in the use of the three functions.


3.2 Instructor Control Program


The Instructor Control Program (PLATO lesson name
"icp") is interface between the student database and the
sponsor's instructors. This lesson, written by David
Romer, provides several options to instructor
s. (See Ref.
4.) The instructor may add students to the roster, delete
their records, or change the spelling of their names.
The instructor may examine the performance of the
students, either individually or by module. He may assign
modules t
o a student, lock him out of a moudule, or change
the material the student will see in that module. The
instructor may control the order in which his students
complete each module.
The instructor control program has an on-line series of
display
s to assist the instructor in the performance of his
duties. He may examine these displays at any time should
he need assistance.
The instructor control program allows the instructor
flexible control of the students while relieving him from
having to know the details of the database. This means
that problems caused by instructor error will be minor.
There are a few facilities that are available only to
project personnel. For instance, an instructor cannot
assign a module that has not
been released. Members of the
project staff may edit the list of released lessons to
permit instructors to assign a new lesson. Also, a
programmer may assign himself a module that is not released
to the sponsor. This permits debugging by staff members.



3.3 Student Router


The interface for students is known as the student
router. It is a special PLATO lesson called "nukerout".
When the student signs onto the system, PLATO executes the
router. The function of the router is control which
lessons the student executes. Router "nukerout" reads the
student's records from file "nukestu" and builds a table of
available lessons. The student is presented with a display
of which lessons he may begin, as well as those t
hat he has
started but not finished.
For the student's own information, the modules that he
is locked out of are listed. The modules that he has
finished are listed with his final score.
The responsibilities of the router are several. It

must remember which lessons the student has begun but not
completed. It must store the student's variables before
entering a new module. And it must present to the student
only those lessons that the instructor desires.
The router uses the records in "nukestu" to recall
which modules the student has begun. In a special data
area, the exact location in each module is stored. This
location is known as the restart point. When the student
resumes that module, he must be sent to the restart
point.
When a student enters a module, his variables must be
stored for future use. When he resumes a previous module,
the variables used in that module must be restored. The
copies of the variables are kept in file "stuvar". There
is one record for each module that the student has begun.
The router creates the records by itself. The instructor
control program does not interact with "stuvar" in any way.
The router checks the first record in file "nukestu"
for the student.
This is a special record which indicates
the order in which the student may take the modules. The
instructor sets this record using the instructor control
program. The instructor may force the student to take a
set of modules in order, or permit the student to take the
modules in any order. Two combinations are possible: the
student must take the sequenced modules before the
unsequenced ones, or the student may take the unsequenced
modules in the middle of the sequence. In either case, the

student may not break the sequence.
When the student leaves a module, control passes back
to the router. The student may take another module, or
leave the system.





CHAPTER 4

FUTU
RE OPTIONS



4.1 Addition of New Features


Ease of change has been one goal throughout the
development of the program. For instance, half-way through
the project it was decided to add fill-in type questions.
Subroutines to handle
this were written and easily included
in the common program. This addition was possible because
the structure of the common program did not have to change.
To change some aspects of the program could entail
considerable cost. After the test, t
he student is either
given elaborative feedback or is sent through the entire
module again. It might be desireable to allow a student to
take the test at any time and resume the instructional
section afterwards. In this case, a rewrite of the testing
strategy is necessary. However, flexibility is still
inherent, since this is possible. Whether or not to do it
becomes a decision of economics and educational benefit,
not a programming one.
One relatively simple change would be to
add a
subroutine that writes "Press -NEXT-" on the screen. This
is written by almost every unit. Space could be saved by
converting every instance of this code to a subroutine
call. However, the time required to backfit every module
can be substantial compared to the benefits received.
Some changes are more important. The subroutines used
for fill-in questions are primitive. The correct answer or
answers should be stored in the common block in much the
same way as multiple choice questions. An improved
subroutine "fill" could be written which would use this
information. This subroutine could input and judge the
student's response, rather than requiring the programmer to
write the code to do this. This would speed up
programming.
There is virtually no subroutine support for touch
questions. The programmer must write code to draw the
figure to be touched and judge the correctness of the
student's response. The judging of such questions is very
standardized. It is possible to write a subroutine that
waits for the student's response and judges it. A list of
correct and incorrect answers would be passed to the
subroutine. This would be fairly simple to do, and would
greatly decrease programmer time. Since few
touch
questions have been written, it should be possible to
retrofit existing modules within a few days of writing the
subroutine.
Files "nukestu" and "stuvar" should be combined. This
was not done during the project because of the timerequired to change the common and instructor control
programs. However, combining these files would reduce the
space required to store the student data and would make
system maintenance simpler.


4.2 Revision to Use New PLATO Features

Several major changes to the TUTOR language are being
planned. While the lessons developed will continue to work
properly, efficiency can be increased by making use of some
of these new features. The lessons will run faster, use
less processor capacity, and will use less lesson space for
the code. Also, some future additions to features of the
common program will be made much easier.
One recent change to TUTOR is the addition of local
variables. This is one of the most important additions to
TUTOR in many years.
Each student using a lesson has a set of 150 variables.
It appears to each student that he is the only one running
a lesson, since the variables of one student cannot affect
another student. The students only share the lesson code,
and proceed through each lesson independently.
These 150 variables are global variables. This means
that if a variable is used in one place in the program,
that use affects the entire program. Preventing accident
al
interference between sections of the program involves
careful documenting of variable use and subsequent
limitations on use of those variables.
When passing a value to a subroutine, that value must
be assigned to a variable (known as the target variable).
The total number of available variables restricts the
passing of parameters in TUTOR.
Local variables, on the other hand, exist only in an
individual subroutine. No other subroutine can disturb the
values of those variables. Local variables allow target
variables to be created without cutting into the 150
variable allotment. Also, documentation is made easier.
Global variables in the lesson must be completely
documented. When another subroutine is written, previous
subroutines and their variables must be taken into account.
This increases paperwork and documentation effort.
Several subroutines in the common program should be
re-written to make use of local variables. Because of the
scarcity of variables available, several subroutines
perform a similiar function that would best be done in a
separate, low level, subroutine. For example, subroutines
"displd" and "displt" both contain code that lists one line
of text from the common block. There should be a
subroutine which both call to do this function. This will
make the common program much easier to maintain, and will
not require any changes to existing modules.
Another feature just added to PLATO is the
Multiple-"use" facility. Each module merges its code with
the code from the common program. In the past, only one
file could be specified for this purpose (i.e., the common
program). The ability to specify more files (up to five)
permits material from several different files to
be
included. For instance, suppose file "x" contained the
technical specifications from plant "A" and file "y"
contained the technical specifications from plant "B." A
module could be written so that when using file "x" it
would present the specifications from "A." Changing the
"use" file to "y" would present specifications from plant
"B" without re-writing the module. Multiple-"use" files
are required, since the common program would still have to
be included.
The PLATO terminals have
a built-in microcomputer.
Right now, programming this computer is limited to some
animations and other "gee-whiz" effects. CDC plans to
expand the capability of this small computer. This means
that it may someday be possible for the terminal to present
all of the instruction without the main computer. Before
this can be used for this project, study would be needed.
It is not at all clear that the microcomputer capability is
sufficient.
Further down the road is color graphics cap
ability.
This would improve some of the figures currently used.
It
does not seem to be a large advancement. However, some
totally new application may be found. Color PLATO
terminals exist for demonstration purposes. Estimates of
commercial versions range from two to ten years.
The long-range plans for PLATO are vague. Various
extensions to the language have been discussed. A complete
revision of TUTOR has been contemplated. Such major
changes are being resisted by users, since some changes may
prevent current programs from executing properly. The best
way to stay abreast of these changes is through the CERL
system. Much of the development of TUTOR is done on that
system, and user input is actively encouraged.
Barring major changes to TUTOR, the lessons already
developed will continue to work. Taking advantage of
changes to TUTOR should increase the maintainability of the
lessons and increase the flexibility of future modules.


4.3 New Education Projects



A possible future project is teaching technical
specifications at other power plants. Under consideration
is a way to use "generic" technical specifications so that
modules written in a future project will be applicable to
several plants. This approach works best for one
manufacturer's plants at a time. Mentioned in the
"Revision to Use New PLATO Features" subsection is the
potential to change parts of the material by specifying
different files to be merged with the code for each module.
This method permits customized modules while reducing
programming time.
It is also possible to use the common program for other
education projects. Neither the education model nor the
common program are specific to teaching technicalspecifications. The standard pages provided by the common
program would have to be modified. The file structure used
may require modification. Of course, the material in the
displays and questions would have to be specific to the
project, but the common program would need very slight
revision. If many projects of this nature were
anticipated, the Multiple-"use" option could be used to
merge variable material such as standard pages with
absolutely fixed material such as many of the subroutines.
This would decrease programming time for future projects.






CHAPTER 5

CONCLUSIONS



5.1 Impact on Operations


It is too early to tell how much impact the model
developed will have on plant operations. To accurately
assess this, a large number of students would need to be
trained using both the classroom and PLATO methods.


5.2 Summary


A series of PLATO lessons were written by the project
staff to teach technical specifications to operators at
DBNPS. The information in these lessons, known as modules,
was divided by reactor system (Appendix A). Each lesson
was based on a common core of subroutines known as the
common program. T
he design objectives for the common
program were met.
The subroutines provided by the common program reduced
programmer time and effort. The common program provided a
structure for module programmers to use, which increases
productivity while making the modules produced easy to
maintain.
A very large and complex database was used. The
subroutines from the common program read and write
information about the student. The answers the student
gave to each question are stored for future
analysis. The
programmer of a module need not know the structure or
format of this database. All interaction with the database
takes place through subroutines in the common program.
This decreases programmer training time, as well as
ensuring that
the database will be properly maintained.
Many useful features were provided. Powerful
subroutines were available to present, score, and respond
to multiple choice questions. Less powerful subroutines
were provided for fill-in and touch questions, but the
potential to add these features exists. Specific
recommendations on features to add are discussed in this
thesis.
The full capability of PLATO is available. Unlike PLM,
the TUTOR language can be used to generate any display
whatsoever. Also, the model used can be changed easily and
with a minimum of time. This is an advantage for future
courseware projects. And, since PLATO allows instant
long-distance communication, support of this product and
any future ones can
be done at Ohio State.


REFERENCES



10
[1] James J. Canelos, Ph.D., private discussion.
Subject: the Mastery Learning Model used in this
project.



[2] James J. Canelos, Ph.D., "Task Training Guide,"
unpublished, Computer Based Education, The Ohio
State University, 1979.



[3] Stanley F. Quayle, "Specifications for
Multiple-Choice Commons," unpublished, Nuclear

Services and Training Laboratory, The Ohio State
University, 1980.



[4] Dave Romer, PLATO lesson "icp", Control Data
Corporation PLATO system "minna", Nuclear
Services and Training Laboratory, The Ohio Stat
e
University, 1980.











APPENDIX A





LIST OF MODULES




Module 1

Name: Not Assigned PLATO Name: Not Assigned

Outline: Not Available



Module 2

REACTOR COOLANT SYSTEM -- PART I PLATO Name: "rcs1"

Outline:

A. Operations
1. Reactor Coolant Loops
2. Pressure/Temperature Limits
3. Special Test Exceptions
B. Valves

1. Internal Vent Valves
2. Safety Valves
C. Coolant Chemistry
D. Specific Activity
E. Coolant Leakage
F. Materials


Module 3

REACTOR COOLANT SYSTEM -- PART II PLATO Name: "rcs2"

Outline:

A. Pressurizer
B. Reactor Coolant Pumps
C. Reactor Vessel and Internals


Module 4

REACTIVITY CONTROL SYSTEMS -- PART I PLATO Name: "reac1"

Outline:

A. Shutdown Margin
B. Borated Water Sources

C. Boron Injection Flow Paths
D. Pumps
E. Boron Dilution


Module 5

REACTIVITY CONTROL SYSTEMS -- PART II PLATO Name: "reac2"

Outline:

A. Moderator Temperature Coefficient
B. Minimum Temperature for Criticality
C. Movable Control Rod Assemblies
D. Xenon Reactivity


Module 6

POWER DISTRIBUTION LIMITS PLATO Name: "power"

Outline:

A. Axial Power Imbalance
B. Quadrant Power Tilt
C. Nuclear Enthalpy Rise Hot Channel Factor
D. Nuclear Heat Flux Hot Channel Factor
E. Special Test Exceptions
F. DNB Parameters


Module 7

REACTOR PROTECTION SYSTEM PLATO Name: "rps"

Outline: Not Available


Module 8


SAFETY FEATURES ACTUATION SYSTEM PLATO Name: "sfas"

Outline:

A. SFAS Operability
B. SFAS Setpoints


Module 9

STEAM FEED RUPTURE CONTROL SYSTEM

Outline: Not Available


Module 10

MONITORING INSTRUME
NTATION PLATO Name: "moninstr"

Outline:

A. Incore Detectors
B. Radiation Monitoring Instrumentation
C. Remote Shutdown Instrumentation
D. Post-Accident Instrumentation


Module 11

ELECTRICAL POWER SYSTEM
S PLATO Name: "electr"

Outline:

A. A.C. Sources
B. Onsite Power Distribution


Module 12

EMERGENCY CORE COOLING SYSTEM PLATO Name: "eccs"

Outline:

A. High and Low Pressure Injection Systems

B. Core Flooding System


Module 13

CONTAINMENT SYSTEMS -- PART I PLATO Name: "cs1"

Outline:

A. Air Temperature
B. Internal Pressure
C. Containment Purge and Exhaust System
D. Containment Cooling System

E. Containment Spray System
F. Combustible Gas Control


Module 14

CONTAINMENT SYSTEMS -- PART II PLATO Name: "cs2"

Outline:

A. Containment Integrity
B. Containment Leakage
C. Containment Isolation Valve
D. Containment Air Locks
E. Containment Vessel Structural Integrity
F. Shield Building


Module 15

STEAM GENERATORS PLATO Name: "stmgen"

Outline:

A. Pressure/Temperature Limitations
B. Water Level Limits
C. Inservice Inspection Program


Module 16

PLANT SYSTEMS -- PART I PLATO Name: "ps1"

Outline:

A. Safety Valves
B. Main Steam Isolation Valves
C. Auxiliary Feedwater Systems
D
. Condensate Storage Facilities
E. Steam Generator Pressure/Temperature Limitation
F. Secondary System Specific Activity
G. Component Cooling Water System
H. Service Water System
I. Ultimate Heat Sink


"Module 17

PLANT SYSTEMS -- PART II PLATO Name: "ps2"

Outline:

A. Instrumentation
1. Seismic
2. Meterological
3. Chlorine Detection
B. Control Room Emergency Ventilation
C. Hydraulic Snubber D. Sealed Source Contamination


Module 18

PLANT SYSTEMS -- PART III PLATO Name: "ps3"

Outline:

A. Fire Detection
B. Fire Suppression Water System
C. Spray/Sprinkler System
D. Fire Hose Stations
E. Penetration Fire Barriers


Module 19

FUEL HANDLING AND REFUELING OPERATIONS
PLATO Name: "refuel"

Outline:

A. Instrumentation
1. Source Range
2. Radiation Monitoring
3. Seismic

4. Meterological
5. Fire Detection
B. Decay Time
C. Boron
D. Coolant Circulation
E. Reactor Vessel Water Level
F. Reactor Coolant Chemistry
G. Containment
1. Penetrations

2. Purge and Exhaust Isolation Systems
H. Storage Pool
I. Electrical
J. Fire Suppression and Penetration Fire Barriers
K. Communication
L. Fuel Handling Bridge and Crane Travel


Module 20

SPECIAL TEST
S AND ADMINISTRATIVE CONTROLS
PLATO Name: "stest"

Outline:

A. Special Test Exceptions
B. Adminstrative Controls









APPENDIX B





USER'S GUIDE -- BUILDING A MODULE

Line Number Instruction
1 imain imain
2 define
3 name=n1
4 i=n3
5 dum=v3
6 modnum=n4
7
crit=n5
8 yesno=n6
9 qnum=n7
10 tright=n8
11 twrong=n9
12 right=n10
13 wrong=n11
1
4 initial=n12
15 ¬ qmax=n13
16 strcnum=n14
17 ques=n15
18 namest=n16
19 ctr=n17
20
dist=n18
21 max=n19
22 ¬ k=n20
23 dists=n21
24 pointer=n22
25 * Start of student record (64 words)
26
sturec=n23
27 module=n23
28 tstok=n24
29 sro=n25
30 sroq=n26
31 ro=n27
32 ¬ roq=n28
33
eng=n29
34 engq=n30
35 * words n31-n40 reserved
36 entered=n41
37 pscore=n42
38 crito=n43
39
pretso=n44
40 finish=n45
41 cscore=n46
42 fail=n47
43 locked=n48
44 * words n49-n52 reserved
45 return=n53
Figure 5.

Initial Entry Unit from Common Program (Page 1 of 2)

22
Line Number Instruction
46 howfar=n54
47 segment,string=n54, 12
48 d1=n55
49 d2=n56
50 d3=n57
51 d4=n58
52 d5=n59
53 pos=n60
54
j=n61
55 ¬ array, ptr(7)=n62
56 list=n70
57 list1=n70
58 list2=n71
59 list3=n72
60 list
4=n73
61 list5=n74
62 ¬ oldlist=n75
63 oldlst1=n76
64 oldlst2=n77
65 oldlst3=n78
66 oldlst4=n79
67
oldlst5=n80
68 reqd=n81
69 reqd1=n82
70 reqd2=n83
71 reqd3=n84
72 reqd4=n85
73
reqd5=n86
74 * Start of response storage area
75 array,rec(64)=n87
76 min(xx, yy)=[xx+yy-abs(xx-yy)]
/2
77 z1(aa)=(string(aa)=(tm)/0)
78 full(zz)=z1(zz)$or$z1(zz+1)
$or$z1(zz+2)$or$z1(zz+3)
$or$z1(zz+4)$or$z1(zz+5)
$or$z1(zz+6)$or$z1(zz+7)
79 ¬
revu=name='reviewer'
80 staff=(zgroup='osucbe')$or$
(zgroup='osunuke')$or$
(zgroup='nukes')
81 dbstaff=(zgroup='toledo')$and$
(user='author'$or$user=
'multiple'$or$user=
'inst¬ructor')
Figure 5.

Initial Entry Unit from Common Program (Page 2 of 2)

23






Line Number Instruction
1 use defines
2 unsafe=0 $$ module released
3 * Common that holds questions

4 comlen=2560
5 common dbblock2,rcs2,2560
6 use start
7 *
8 * Tell module what number it is
9 calc modnum<(tm)=3
10
use overvu1









Figure 6.

Initial Entry Unit from a Module




25




Line Number Instruction
1 unit d5
2
back instr
3 next d10
4 restart
5 at 0505
6 write Bases
7 at 1005
8 write A steam bubble in the
9
pressurizer ensures that the
10 RCS is not a hydraulically
11 solid system and is capable of
12 accommodating pressure surges
13 during
operation. The steam
14 bubble also protects the
15 pressurizer code safety valves
16 and power operated relief
17 valves against water relief.
18
at 2945
19 write (B. 3.4.4)
20 (B. 4.4.4)
21 at 2905
22 write Press -NEXT-
23 *






Figure 10.

Code for an Instructional Display from a Typical Module



30








Line Number Instruction
1 unit dq20
2 jump sroq=(tm)/-1,d30,x
3 n
ext dq25
4 calc ques<(tm)=1
5 qnum<(tm)=qnum+1
6 do q1
7 *










Figure 12.

Code to ask a Question from a Typical Module



33





Line Number Instruction
1 unit q1
2 do multi(0205,0504,0809,2005,
2205)
3 *

1
unit f1
2 do multif(0205,0504,0905)
3 at 2005
4 write The steam bubble in the
5 pressurizer prevents the
6 reactor coolant system from
7 being hydraulically solid.
8 The bubble can absorb short
9 term changes in volume and
10 pressure. This protects the
11
safety valves, and
12 accommodates pressure surges.
13 at 2905
14 write Press -NEXT-
15 *





Figure 13.


Question and Feedback Subroutines from a Typical Module



34

Line Number Instruction
1 unit multif(d1,d2,d3)
2 calc k<(tm)=rec(pointer)$mask$o77
3 at
d1
4 write Question number <(tm)(t,qnum,2>(tm))
5 do fetch
6 do displt(d2)
7 at d3
8 write The correct answer is:
9 calc i<(tm)=ptr(1)
10 ctr<(tm)=d3+105
11 at ctr
12 write
13 0loop1
14 doto 0loop2,j<(tm)=i, ptr(2)-2
15 if (nc(j)$mask$o7777)=o0
16
. write <(tm)(a,nc(i),
10(j-i+1))(tm)>
17 . calc ctr<(tm)=ctr+100
18 . i<(tm)=j+1
19 . at ctr
20
. write
21 . branch 0loop1
22 endif
23 0loop2
24 write <(tm)(a,nc(i), 10(ptr(2)-i-1)(tm)>
25 calc ctr<(tm)=ctr+100
26 i<(tm)
=ptr(k)
27 at ctr
28 write
29 0loop3
30 doto 0loop4,j<(tm)=i, ptr(k+1)-2
31 if (nc(j)$mask$o7777)=o0
32 . write <(tm)(a,nc(i),
10(j-i+1)>(tm))
33 . calc ctr<(tm)=ctr+100
34 . i<(tm)=j+1
35 . at ctr
36 . write
37 .
branch 0loop3
38 endif
39 0loop4
40 write <(tm)(a,nc(i), 10(ptr(k+1)-i-1>(tm))

Figure 14.

Subroutine "multif" from the Common Program

(Slightly simplified)

35




Line Number Instruction
1 unit multi(d1,d2,d3,d4,d5)
2 at d1
3 write Question number <(tm)(t,qnum,2>(tm))
4
do fetch
5 branch i=-999,0around,x
6 do displt (d2)
7 do displd (d3)
8 arrow d4
9 specs bumpshift
10 match i,a,
b,c,d,e
11 if i>max-2
12 . judge no
13 endif
14 endarrow
15 help
16 data1
17 do input (d5)
18
at 2905
19 write Press -NEXT-
20 0around
21 *






Figure 17.

Subroutine "multi" from the common program




40

Line Number Instruction
1 use instr2
2 *
3 unit tester
4 next test1
5 at 0223
6 write RCS - PART II TEST
7
at 0705
8 write This is the test covering Part
II of the
9 Reactor Coolant System. Your
knowledge of the
10
design bases and technical
specifications for
11 the following systems will be
tested:
12
13 Pressurizer
14
Reactor Coolant Pumps
15 Reactor Vessels and Internals
16
17 There are several different
types of questions
18 that may b
e presented. The
most common is
19 multiple-choice. To find out
how to answer
20 them, press HELP now.
21 at
2905
22 write Press -NEXT-
23 use tester1
24 branch ques=71,0rest,x
25 branch ques=72,0rest,x
26 branch ques=73,0rest, x
27 branch ques
=74,0rest,x
28 branch ques=75,0rest,x


Figure 19.

Code to Present a Test from a Typical Module

(Page 1 of 2)



42


Line Number Instruction
29 use tester2
30 branch ques=999,0rest,x
31 use tester3
32 branch ques=999,0rem,x
33 use tester4
34 do ques,x,x,q1
,q2,q3,q4,q5,q6,q7,
q8,q9,q10,x
35 do ques-10,x,x,q11,q12,x,x,q15,x
36 do ques-20,x,x,q21,x
37 do ques-30,x,x,x,x,x,
q34,x,x,x,x,

q39,q40,x
38 do ques-40,x,x,x,q42,q43,q44,q45,
x,q47,q48,q49,q50,x
39 do ques-50,x,x,q51,x,x,q54,q55,
q56,x,q58,q59,q60
,x
40 do ques-60,x,x,q61,q62,q63,q64,
q65,q66,q67,q68,q69,q70,x
41 do ques-70,x,x,q71,q72,q73,q74,
q75
42 pause keys=next,term,help,data1
43 erase
44 use tester5






Figure 19.

Code to Present a Test from a Typical Module

(Page 2 of 2)





43

Line Number Instruction
1 use feed1
2 . do ques,x,x,f1,f2,f3,
f4,f5,f6,f7,f8,f9,
f10,x
3
. do ques-10,x,x,f11,f12,
x,x,f15,x
4 . do ques-20, x,x,f21,x
5 . do ques-30,x,x,x,x,x,

f34,x,x,x,x,f39,f40,
x
6 . do ques-40,x,x,x,f42,
f43,f44,f45,x,f47,
f48,f49,f50,x
7
. do ques-50,x,x,f51,x,x,
f54,f55,f56,x,f58,
f59,f60,x
8 . do ques-60,x,x,f61,f62,
f6
3,f64,f65,f66,f67,
f68,f69,f70,x
9 . do ques-
70,x,x,f71,f72,
f73,f74,f75
10 use feed2








Figure 20.

Code to Present Elaborative Feedback
from a Typical Module





47



That's the end.  Now for the advertisements...

Contact Us!

We respect your privacy -- you will not be added to a mailing list. Check out our plain-language privacy policy.

If the address fields on this form are not suitable for specifying your address, please fill them with NA and provide your mailing address in the message box.

Required fields are labeled with red italic text.

 

Services

Quayle Consulting Inc. provides a complete menu of services, including:

Quayle Consulting in the news:

Quayle Consulting information:

Interesting items:

Stromasys Partner
HP Certified OpenVMS
          System Engineer
HP Business Partner
Quayle Consulting Inc. on LinkedIn
Trademarks
OpenVMS is a trademark of Hewlett-Packard.
CHARON-VAX and CHARON-AXP are trademarks of Stromasys.
Windows is a trademark of Microsoft Corporation, USA.