top - download
⟦03f06b144⟧ Wang Wps File
Length: 35747 (0x8ba3)
Types: Wang Wps File
Notes: CPS/SDS/020
Names: »0889A «
Derivation
└─⟦872f87e0f⟧ Bits:30006013 8" Wang WCS floppy, CR 0052A
└─ ⟦this⟧ »0889A «
WangText
…1c……0b……1b… …1a……08……1a……0b……1a……02……1a……05……1a……06……19……0b……19……01……19……05……86…1
…02…
…02…
…02…
…02…CPS/SDS/020
…02…URH/810430…02……02…#
CTDS SOFTWARE
SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL............................................
5
1.1 PURPOSE......................................
5
1.2 PROJECT REFERENCES...........................
5
1.2.1 Applicable Documents.....................
5
1.3 TERMS AND ABBREVIATIONS......................
6
1.3.1 Acronyms.................................
6
2 SUMMARY OF REQUIREMENTS............................
7
2.1 PROGRAM DESCRIPTION..........................
7
2.2 PROGRAM FUNCTIONS............................
7
2.2.1 CTDS System Overview.....................
9
2.3 ACCURACY AND VALIDITY........................
10
2.4 TIMING.......................................
11
2.5 FLEXIBILITY..................................
11
3 ENVIRONMENT........................................
12
3.1 SUPPORT SOFTWARE ENVIRONMENT.................
12
3.2 INTERFACES...................................
12
3.3 STORAGE......................................
13
3.4 SECURITY.....................................
13
3.5 CONTROL......................................
13
4 DESIGN DETAILS.....................................
14
4.1 PROGRAM OPERATING PROCEDURES.................
14
4.1.1 Script Compiler..........................
14
4.1.1.1 Batch Mode Operation.................
16
4.1.1.2 Interactive Mode Operation...........
18
4.1.2 On-Line Test Controller..................
18
4.1.2.1 Command Interpreter..................
21
4.1.2.2 Test Message Controller (TMC)........
21
4.1.2.3 Protocol Handler.....................
21
4.1.2.4 LTU Driver...........................
22
4.1.2.5 Real Time Clock......................
22
4.1.3 Log File Editor..........................
23
4.2 INPUTS.......................................
23
4.2.1 Script Compiler Input....................
23
4.2.1.1 Workload Script......................
25
4.2.1.1.1 Declaration........................
26
4.2.1.1.2 Commands...........................
27
4.2.1.1.2.1 Message Format Commands........
27
4.2.1.1.2.2 Message Traffic Commands.......
28
4.2.1.1.2.3 Synchronization Commands.......
29
4.2.1.2 Protocol Control Command Script......
30
4.2.2 On-Line Test Controller Input............
30
4.2.2.1 Command Interpreter Input............
31
4.2.2.1.1 Set-Up Channel Command...........
31
4.2.2.1.2 Assign Script....................
32
4.2.2.1.3 Display Script Assignment........
33
4.2.2.1.4 Clear Script Assignment..........
33
4.2.2.1.5 Start Test.......................
34
4.2.2.1.6 Query Status of Test.............
35
4.2.2.1.7 Halt Test at Current Script......
35
4.2.2.1.8 Halt Test at Current Script
Command..........................
36
4.2.2.1.9 Monitor a Channel ...............
36
4.2.2.1.10 Reset Test Controller............
36
4.2.2.1.11 Batch Mode.......................
36
4.2.2.2 Test Message Controller Input........
37
4.2.3 Log File Editor Input....................
38
4.3 OUTPUTS....................................
38
4.3.1 Condensed Script File....................
38
4.3.2 On-Line Test Controller Output...........
38
4.3.3 Log File Listing.........................
39
4.4 DATA ENVIRONMENT.............................
39
4.5 STORAGE ALLOCATION...........................
39
4.6 DATA RETENTION...............................
39
4.7 PROGRAM RELATIONSHIPS........................
39
4.8 PROGRAM LOGIC................................
39
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲
The CAMPS Test Drive System (CTDS) software specification
has the purpose:
- to present a summary of the requirements concerning
the CTDS.
- to describe the environment in which the CTDS shall
operate.
- to outline the operating procedures and -capabilities
of the CTDS.
A final description of the design details and operating
procedures will be provided in the CTDS Design Specification
and -Users Manual.
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
The following documents are applicable to the CTDS
Software Specifications to the extend specified herein.
CPS/210/SYS/0001, CAMPS System Requirement Specification.
Contract between CR and CRC on supply of TDS, dated
12th March 1981.
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 A̲c̲r̲o̲n̲y̲m̲s̲
Within this document the following definitions apply
for the interpretation of the listed acronyms:
CR Christian Rovsing A/S, Ballerup, Denmark
CRC Christian Rovsing Corporation, California 91362,
U.S.A
CTDS CAMPS Test Drive System
CMI Command Interpreter
EDC Error Detection and Correction
LTU Line Termination Unit
RTC Real Time Clock
PH Protocol Handler
SRS CAMPS System Requirement Specification
TDS Test Drive System
TMC Test Message Controller
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲R̲O̲G̲R̲A̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The CTDS is designed to emulate the operational environments
of the CAMPS system. It interfaces to all CAMPS external
and internal I/O channels and handles all types of
level 1 and 2 protocols involved herein. The CTDS can
impose on the CAMPS system a workload which resembles,
as closely as possible, the external systems traffic
generated by NICS-TARE, SCARS II and CCIS systems,
and the internal traffic imposed by human users working
at the CAMPS user positions.
The workload is specified by means of scripts. The
scripts are written in a specially designed script
language, described in section 4.2. It offers the test
operator a wide range of possibilities for specifying
workloads, plus it has a simple straightforward syntax
that makes it easy to use.
Each script specifies the traffic on one I/O channel.
A script can be assigned to more than one channel or
each channel to be tested can have its own script assigned.
2.2 P̲R̲O̲G̲R̲A̲M̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
The CTDS consists of three modules:
- Script Compiler
- On-Line Test Controller
- Log File Editor
Before a script can be used it has to be compiled by
the Script Compiler (see section 4.2)
Compiling the scripts before execution allows for a
more flexible and human understandable language plus
it cuts down the execution time to a minimum. Furthermore,
it makes a more extensive error checking possible.
The output from the compilation, condensed script,
can be stored in a disk file for later execution by
the On-Line Test Controller.
The On-Line Test Controller executes the workload commands
for each channel independently. For tests where traffic
on a channel is dependent on traffic on another channel
a Send signal/Await signal mechanism is available.
The On-Line Test Controller handles the on-line test
execution and produces a log file containing the results
of the test.
The Log File Editor produces a formatted print out
of the log file produced during a test. Furthermore,
it provides the test operator with the capability of
selecting only the significant parts of the test results
to be printed without burying them in unwanted output.
On fig. 2.2-1 is shown an overview of the CTDS.
Fig. 2.2-1 CTDS SYSTEM OVERVIEW
2.3 A̲C̲C̲U̲R̲A̲C̲Y̲ ̲A̲N̲D̲ ̲V̲A̲L̲I̲D̲I̲T̲Y̲
The requirement concerning accuracy and validity of
operation of the CTDS is stated in the SRS para 3.5.11.5.2.b:
"The standard test environment shall be provided by
simulation of pseudorandom operational environment."
To meet this requirement two conditions must be satisfied:
a) The transaction workload specified for test execution
must be composed with the characteristics and distribution
specified for operational traffic (ref. SRS para
3.4.1.1).
b) The CTDS must provide means for a pseudorandom
variation of the timelapse between transmission
of transaction sequences.
The under b) mentioned CTDS facility has the effect,
that repeated execution of testruns containing the
same transactions will likely result in different execution-
sequences. This means, that even with a limited number
of different workloads (testruns) specified, a high
degree of accuracy and validity is obtained in simulation
of CAMPS's operational environment.
2.4 T̲I̲M̲I̲N̲G̲
Timing of the CTDS operation can be controlled in two
ways:
a) message traffic commands which are used to specify
the rate at which the individual channel traffic
shall be transmitted or received.
b) synchronization commands which are used to specify
inter-channel synchronization
With the message traffic command the traffic load on
the individual channels can be specified.
By means of the synchronization command inter-channel
dependant operation can be controlled and monitored.
For monitoring of timing requirements concerning CAMPS
operation the CTDS will provide a Real Time Clock (RTC)
for time-tagging of transmitted - as well as received
messages
2.5 F̲L̲E̲X̲I̲B̲I̲L̲I̲T̲Y̲
In the design of the CTDS it has been the aim to provide
a maximum of flexibility and ease of operation. As
a consequence hereof the CTDS has been partitioned
into 3 modules.
The interactive Script Compiler provides the user with
means for generation of test data with a minimum of
effort. Through format and parameter declarations the
compiler provides error checking, and default format
sequences and parameter values can automatically be
inserted.
The On-Line Test Controller provides means for arbitrary
assignment of script-files to channels and protocol
control command files to protocol handlers.
The Log File Editor provides means for a selective
analysis of generated test output.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
No support software is required for test preparation,
test execution or analysis of test output.
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
The CTDS will provide interfaces for the following
number and type of channels:
VDU/Printer: 36 channels of 1200 baud async/V24
Teletype: 24 channels of 110 baud async/V24
NICS-TARE: 4 channels of 2400 baud sync/V24
CCIS/SCARS: 2 channels of 9600 baud sync/V24
The output capacity to be provided by the CTDS is specified
as follows:
For external channels, the peak load is:
NICS/TARE 750 chars/sec.
CCIS 240 chars/sec.
SCARS II 2̲4̲0̲ ̲c̲h̲a̲r̲s̲/̲s̲e̲c̲.̲
1230 chars/sec.
From the terminal connecting channels, the peak load
is 200 chars/sec. The total peak load is thus:
1430 chars/sec.
Accordingly the required input capacity:
The CTDS will log and store CAMPS busy minute (hour)
output at the following rate:
TRAFFIC NO OF DISTRIBUTION NO OF
ORIGIN INPUT FACTOR OUTPUT
MSGS MSGS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
External ch. 15 (300) 8 120(2400)
Terminal ch. 6 (180) 10 60(1800)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
Total 180(4200)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
Thus the CTDS will have a capacity to log and store
per minute (hour):
180(4200) messages of average 1500 bytes.
3.3 S̲T̲O̲R̲A̲G̲E̲
The CTDS will be equipped with sufficient RAM-memory
to provide for execution of any of the CTDS software
functions. Further the CTDS will be equipped with sufficient
disk storage to provide for minimum 1 hour of continous
operation with a throughput as specified in para 3.2.
3.4 S̲E̲C̲U̲R̲I̲T̲Y̲
It is not foreseen that any classified information
will be processed by the CTDS.
3.5 C̲O̲N̲T̲R̲O̲L̲
No specific controls are to be established at the program
level.
4̲ ̲ ̲D̲E̲S̲I̲G̲N̲ ̲D̲E̲T̲A̲I̲L̲S̲
4.1 P̲R̲O̲G̲R̲A̲M̲ ̲O̲P̲E̲R̲A̲T̲I̲N̲G̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
4.1.1 S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲p̲i̲l̲e̲r̲
The Script Compiler translates scripts written in Script
language (see section 4.2) into condensed scripts directly
usable as input to the On-Line Test Controller.
Two types of Script can be compiled:
- Script with protocol control commands
- Script with channel workload specifications
The Script Compiler is a one-pass compiler. It compiles
one sentence (declaration or command) at a time.
A declaration will cause the compiler to create an
internal table to be used when compiling commands.
A command will cause the compiler to create an empty
command block with an id. specifying the command. Each
following parameter to the command will be validated,
compiled according to previous declarations, and inserted
in the command block. Commands with parameters of varying
length will have varying size command blocks. When
all necessary parameters have been compiled, the command
block will be written to the condensed script file.
The Script Compiler can be operated in two different
modes as described below.
fig.4.1.1-1 Batch Mode Operation
4.1.1.1 B̲a̲t̲c̲h̲ ̲M̲o̲d̲e̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The script is stored in advance in a disk file by running
the compiler in interactive mode. The compiler is started
and the script disk file is assigned to it by means
of standard procedures.
During compilation, the compiler writes each script
sentence to the listing file (disk file or operators
console), with error messages inserted as appropriate,
and writes the compiled sentence, if applicable, to
the condensed script file.
Compilation ends when END is encountered. An error
does not stop the compilation. If possible, the compiler
analyses all sentences until END or end of file, but
the condensed script file will be cleared in case of
errors.
Fig. 4.1.1-2 Interactive Mode Operation
4.1.1.2 I̲n̲t̲e̲r̲a̲c̲t̲i̲v̲e̲ ̲M̲o̲d̲e̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The compiler is started by means of standard procedures.
If the input file is specified as "operator's console",
the compiler is in interactive mode and prompts the
operator when ready to accept input.
The format of the script is the same as in batch mode.
The compiler reads one line and compiles the sentences
it may contain. If no errors were detected, the compiler
prompts the operator to type next line.
Each time a line has been compiled, it is written to
the script file for later use and the resulting output
is written to the condensed script file.
If a sentence has not been finished in one line, the
compiler expects it to continue on the next.
If a line contains errors, an error message will be
shown on the operator's console including an indication
where the error is. The compiler expects the line to
be repeated from the beginning of the first erroneous
sentence.
The compilation ends when the operator types in END
4.1.2 O̲n̲-̲L̲i̲n̲e̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
The On-Line Test Controller is used to:
- Set-up channels
- Assign condensed scripts with workload data to
the channels
- Assign condensed scripts with protocol control
commands to the protocol handlers
- Start the test
- Monitor and control the test while it is in progress
- Log test data during a test
The On-Line Test Controller consists of the following
submodules:
a) Command Interpreter
b) Test Message Controller
c) Protocol Handler
d) LTU Driver
e) Real Time Clock
Figure 4.1.2-1 shows a block diagram of the On-Line
Test Controller. The modules are described in the following
subsections.
fig. 4.1.2-1 On-Line Test Controller…01…Block Diagram
4.1.2.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲
The Command Interpreter (CMI) handles the communication
between the test operator and the test controller.
Commands entered by the operator are validated by CMI.
If an invalid command is entered, an error message
is sent to the console.
4.1.2.2 T̲e̲s̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲T̲M̲C̲)̲
The Test Message Controller (TMC) executes commands
specified in condensed workload scripts (see section
4.2.1.1.2).
Each channel to be used during a test has assigned
to it one or more condensed script files.
The TMC starts executing the commands for a channel
as soon as the "Start Test" command (see Section 4.2.2.1.5)
for the channel has been given by the test operator.
The commands are executed in the order they have been
specified in the script(s).
Commands for each separate channel are executed independently
(except for the use of SIGNAL's, see section 4.2.1.1.2.3)
and concurrently.
4.1.2.3 P̲r̲o̲t̲o̲c̲o̲l̲ ̲H̲a̲n̲d̲l̲e̲r̲
The Protocol Handler (PH) handles the level 2 protocol
for EDC and X.25 channels.
The PH receives messages to CAMPS from the Test Message
Controller (TMC) and passes them on to the LTU Driver
for transmission, according to the protocol of the
channel chosen for the transmission. For channels without
a level 2 protocol the messages pass directly through
the PH.
In order to be able to simulate level 2 protocol errors
and anomalies, the PH has been designed to accept a
set of commands for controlling the protocols. Each
channel can be assigned its own set of commands (see
Section 4.2).
Each set of protocol control commands are specified
by the test operator by means of a script (see section
4.2), which is compiled by the Script Compiler into
a condensed script, directly usable by the PH.
The protocol control commands are executed in the order
they are specified in the script. Basically the commands
consist of an event, a modification and a count. The
event can be the input or output of a protocol block
of a certain type.
If a block of that type is detected, it will be modified
or deleted according to the modification specified.
Blocks of other types will pass unchanged. The count
specifies how many times the command can be used. If
the count is met the next command will be used.
All level 2 protocol operations including modifications/deletions
will be logged during a test.
4.1.2.4 L̲T̲U̲ ̲D̲r̲i̲v̲e̲r̲
The LTU Driver handles the data traffic between the
LTU's and the Protocol Handler. The data are stored
in buffers.
For incoming data it disconnects full buffers from
the LTU's and hands them over to the Protocol Handler
while supplying the LTU's with empty buffers.
For outgoing data it disconnects full buffers from
the Protocol Handler and hands them over to the LTU's.
4.1.2.5 R̲e̲a̲l̲ ̲T̲i̲m̲e̲ ̲C̲l̲o̲c̲k̲
The Real Time Clock (RTC) provides the Test Message
Controller and Protocol Handler with timing information
for time tagging messages sent to the CTDS, messages
received by the CTDS and protocol operations.
4.1.3 L̲o̲g̲ ̲F̲i̲l̲e̲ ̲E̲d̲i̲t̲o̲r̲
The Log File Editor is used to convert into readable
form the logging information produced and stored on
disk files during a test.
Two log files are produced. The one contains blocks
of data, each a result of execution of condensed script
commands. The other contains level 2 protocol operation
data.
It is possible by means of operator commands to select
only a part (or all) of the log files to be converted.
Selection criteria can be start and stop times and
channel numbers.
Each selected part of the log file is converted into
human readable form and formatted to improved visibility
and correlation with the original script.
4.2 I̲N̲P̲U̲T̲S̲
Inputs for the CTDS can be divided into the following
groups:
a) Script Compiler input
b) On-Line Test Controller input
c) Log File Editor input
4.2.1 S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲p̲i̲l̲e̲r̲ ̲I̲n̲p̲u̲t̲
The script language is used to specify workloads and
protocol control commands for the CTDS.
The syntax of the script language is described by means
of syntax diagrams.
Rectangular boxes are described in a lower level diagram
if provided with a number in the lower right corner.
The number refers to the section with the description.
Circular boxes describes the command identifiers and
special words and characters used in the language.
Boxes are connected with lines showing the legal syntax
of the language. The flow is from left to right if
not otherwise shown.
E̲x̲a̲m̲p̲l̲e̲
The actual contents of messages (the message text)
is specified as a so-called s̲t̲r̲i̲n̲g̲ with the syntax:
Description: Delimeter is "," "/" or "$".
The heading and trailing delimeter
must be the same character.
Decimal equivalent is an integer value
in
the range
from 0 to 255, inclusive.
4.2.1.1 W̲o̲r̲k̲l̲o̲a̲d̲ ̲S̲c̲r̲i̲p̲t̲
This type of script consists of a seguence of sentences
(declarations and commands). Each sentence consists
of an identifier followed by one or more parameters,
if any parameters are required.
The identifier may be preceded by one or more spaces
and/or tabs, and, if there are any parameters, they
must be separated from the id. by one or more spaces
and/or tabs.
Two or more sentences may appear on the same line if
they are separated by tabs and/or spaces.
If a semicolon appears in the script outside a string,
it and all characters to the right of it on the same
line are treated as a comment - they appear in the
output listing from the compiler but are otherwise
ignored. A completely blank or empty line also appears
in the listing but is otherwise ignored.
The language has the structure:
4.2.1.1.1 D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲s̲
The function may be used to associate an entire string
with a name for use later on in the script. If the
string is expressed by a string name, the name has
to be defined previously in the script.
4.2.1.1.2 C̲o̲m̲m̲a̲n̲d̲s̲
Three types of commands are available:
1. Message format commands
2. Message traffic commands
3. Synchronization commands
4.2.1.1.2.1 M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The script language offers an automatic message generation
capability.
Description: UF - U̲se F̲ormat
CF - C̲lear F̲ormat
W - W̲ith
All strings following the UF command will automatically
be provided with headers and trailers according to
the Format type and Message type specifications. Default
values are provided for all Format/Message types. It
is possible to overwrite the values by using the "With"
option. The Keywords shown in the Syntax diagram are
keywords for specific parameters in each Format/Message
type like for ACP127 format SEC for security, SHD for
special handling designators, etc.
The UF command is in effect until another UF command
is specified.
The Clear Format command is used to cancel the automatic
formations.
4.2.1.1.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Description: SE - S̲end
The command sends the string to CAMPS. If a UF command
(section 4.2.1.1.2.1) is specified before the SE, the
string is formated accordingly. It is possible to overwrite
values selected by the UF commands by using the "With"
option.
RE - R̲e̲ceive.
The command makes the CTDS receive the specified number
of messages. A maximum wait time can be specified after
which the CTDS proceeds to the next specified command
whether or not the number of messages have been received.
PA - P̲a̲use.
The command makes a pause of the specified time in
execution of commands.
4.2.1.1.2.3 S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Description:
SS - S̲end S̲ignal
The command stores the signal numbers and the channel
numbers of the channel having the script assigned to
it, in a common signal pool.
The command suspends execution of a script until a
signal with the specified number has been stored in
the signal pool. It is possible to wait for a signal
from a specific channel by using the FC (F̲rom C̲hannel)
option.
4.2.1.2 P̲r̲o̲t̲o̲c̲o̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲S̲c̲r̲i̲p̲t̲
Decription:
PS - P̲rotocol S̲cript
PC - P̲rotocol Command
Blocktype is the type of block to be modified.
Direction is to or from CAMPS, or both. Count is the
number of times a command can be used.
Modification is the type of modification to be applied
to the block.
SS - S̲end S̲ignal
This command is used to send signals to the common
signal pool. See 4.2.1.1.2.3.
4.2.2 O̲n̲-̲L̲i̲n̲e̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲I̲n̲p̲u̲t̲
Inputs for the On-Line Test Controller can be divided
in:
a) Command Interpreter input
b) Test Message Controller input
4.2.2.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲I̲n̲p̲u̲t̲
The Command Interpreter (CMI) handles the communication
between the test operator and the test controller.
Commands entered by the operator are validated by CMI.
Valid controller commands are as follows:
- Set-Up Channel (SC)
- Assign Script (AW or AP)
- Display Script Assignment (DS)
- Clear Script Assignment (CS)
- Start Test (ST)
- Query Status of Test (QS)
- Halt Test at Current Script (HS)
- Halt Test at Current Script Command (HC)
- Monitor a Channel (MN)
- Reset Test Controller (RT)
- Batch Mode (BA)
Each controller command is specified as two letters,
followed by optional parameters.
The very first command entered after initialization
must be a "Set-Up Channel" command.
4.2.2.1.1 S̲e̲t̲-̲U̲p̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲
The purpose of this command is to define the specific
channels to be used in the test.
The format of the command is:
SC P…0f…11 …0e…, P…0f…12…0e… , P…0f…13…0e…........,P…0f…N1…0e… , P…0f…N2…0e… , P…0f…N3…0e…
where
P…0f…j1…0e…: the logical channel number
P…0f…j2…0e…: the physical channel number
P…0f…j3…0e…: the channel type
- The logical channel number is used for identification
of a channel, which may be addressed by other commands.
- The physical channel number is a combination of
a device address and port address.
- The channel type defines level 2 protocol to be
used, baud rate, parity, etc.
If a set-up command is in violation with the actual
physical configuration or previous set-up command,
a proper error mesage is issued.
4.2.2.1.2 A̲s̲s̲i̲g̲n̲ ̲S̲c̲r̲i̲p̲t̲
Before a test can begin on any channel, one or more
condensed scripts with workload data must be assigned
to the channel.
The command
AW l…0f…1…0e…, f…0f…1…0e… , f…0f…2…0e… , ................f…0f…n…0e…
assigns the specified condensed script files (f…0f…j…0e…) with
workload data to channel l…0f…1…0e…, in addition to any files
previously assigned.
"c" is the logical channel mumber defined by a previous
setup command.
For tests that require user control over the level
2 protocols applied, the command
AP l…0f…1…0e…, P…0f…1…0e… , P…0f…2…0e… , ...............p…0f…n…0e…
assigns condensed script files (p…0f…n…0e…) with protocol control
commands to channel number l…0f…1…0e….
4.2.2.1.3 D̲i̲s̲p̲l̲a̲y̲ ̲S̲c̲r̲i̲p̲t̲ ̲A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲
The operator may query the status of script assignment
by the command:
DS l…0f……0e… , l…0f…2…0e… , ...............l…0f…n…0e…
When this command is issued, the CMI displays the following
information at the console:
C̲h̲a̲n̲n̲e̲l̲ ̲N̲u̲m̲b̲e̲r̲ S̲c̲r̲i̲p̲t̲ ̲A̲s̲s̲i̲g̲n̲e̲d̲:
l…0f…1…0e…: f…0f…11…0e… , f…0f…12…0e… , ... f…0f…1j…0e…
p…0f…11…0e… , P…0f…12…0e… , ... p…0f…1j…0e…
l…0f…2…0e…: f…0f…21…0e… , f…0f…22…0e… , ... f…0f…2k…0e…
p…0f…21…0e… , p…0f…22…0e… , ... p…0f…2k…0e…
l…0f…n…0e…: f…0f…n1…0e… , f…0f…n2…0e… , ... f…0f…nm…0e…
p…0f…n1…0e… , p…0f…n2…0e… , ... p…0f…nm…0e…
The information summarizes which script files remain
(or in progress) on all channels specified (1…0f…j…0e…).
4.2.2.1.4 C̲l̲e̲a̲r̲ ̲S̲c̲r̲i̲p̲t̲ ̲A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲
The command
CS l…0f…1…0e… , l…0f…2…0e… , ..............l…0f…n…0e…
releases all script files asigned to the channels (l…0f…j…0e…)
by previous assign commands.
4.2.2.1.5 S̲t̲a̲r̲t̲ ̲T̲e̲s̲t̲
The command
ST l…0f…1…0e… , l…0f…2…0e… , ..................l…0f…n…0e…
starts test on those channels (l…0f…1…0e… , ..............
.....1…0f…n…0e…) which have been assigned scripts by a
previous "Assign Script" command. A "ST" command
has no effect if a test already is in progress
for the specified channel(s).
The start command is rejected, if at least one l…0f…j…0e… is
unknown, i.e. a previous set-up command has not created
the logical channel (l…0f…j…0e…).
4.2.2.1.6 Q̲u̲e̲r̲y̲ ̲S̲t̲a̲t̲u̲s̲ ̲o̲f̲ ̲T̲e̲s̲t̲
The operator may query status of a channel by entering
the command:
QS l…0f…1…0e… , l…0f…2…0e… , ............l…0f…n…0e…
where l…0f…j…0e… is a logical channel number. The command may
be issued regardless of whether the test is in progress
or halted.
The relevant status is retrieved and compiled by CMI
for presentation at the console. The status displayed
contains the following information:
Logical Channel Number
Status: Initialized
Active
Halted
Waiting for end of script
Waiting for end of command
The QS command enables the test operator to monitor
the test.
4.2.2.1.7 H̲a̲l̲t̲ ̲T̲e̲s̲t̲ ̲a̲t̲ ̲C̲u̲r̲r̲e̲n̲t̲ ̲S̲c̲r̲i̲p̲t̲
While in progress the test may be halted at script
boundaries, on selected channels by the command:
HS l…0f…1…0e… , l…0f…2…0e…, ...............l…0f…n…0e…
where l…0f…j…0e… is a logical channel number.
4.2.2.1.8 H̲a̲l̲t̲ ̲T̲e̲s̲t̲ ̲a̲t̲ ̲C̲u̲r̲r̲e̲n̲t̲ ̲S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲
The command
HC l…0f…1…0e… , l…0f…2…0e… , ..............l…0f…n…0e…
is similar to the HS command except that the test is
halted at script command boundaries. Neither the HS
nor the HC command halt a test immediately. The test
controller will finish the present script or script
command before halted.
4.2.2.1.9 M̲o̲n̲i̲t̲o̲r̲ ̲a̲ ̲C̲h̲a̲n̲n̲e̲l̲
While test is in progress the test operator may monitor
the activity on a channnel. The command:
MN n
causes the CMI to send the console all characters sent
to and received from CAMPS via the logical channel
number n.
Monitoring continues until any key is struck on the
console keyboard.
4.2.2.1.10 R̲e̲s̲e̲t̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
The command:
RT
resets the Test Controller to be initialized state,
and a new test run may be recommenced, starting with
set-up channel commands.
4.2.2.1.11 B̲a̲t̲c̲h̲ ̲M̲o̲d̲e̲
The initial set-up and assignment of scripts, before
a test can start, may be a rather cumbersome and trivial
task, especially if several channels are tested simultaneously.
By the command:
BA file…0f…1…0e…
CMI enters batch mode and takes input from the command
file "file…0f…1…0e…". At the end-of-file CMI returns to the
controller.
"File…0f…1…0e…"is a preassembled command file containing major
set-up and assignment command. If no "start" command
is contained in the command file, the operator may
enter additional "Set-Up Channel" and "Assign Script"
commands before a test is started.
The batch mode enables the operator to start a test
by just entering one command.
4.2.2.2 T̲e̲s̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲I̲n̲p̲u̲t̲
The Test Message Controller (TMC) executes Message
Traffic Commands and Synchronization Commands specified
in the workload scripts (section 4.2.1.1).
With reference to sections 4.2.1.1.2.2-3 the following
describes the commands accepted by the TMC and the
processing they initiate.
Command Action taken by TMC
SE "message" Send "message" to Protocol
Handler, attach a time
to it and log the time
tagged message.
RE n T = t Receive one time tagged
message from the Protocol
Handler at a time until
n messages has been received
or the time t is exceeded,
whichever occurs first.
Each received message is
logged.
PA t Wait t time units before
executing the next command.
AS "signal" Wait until a "signal" is
sent from another script
execution before executing
the next command.
SS "signal" Send "signal" and start
executing the next command.
4.2.3 L̲o̲g̲ ̲F̲i̲l̲e̲ ̲E̲d̲i̲t̲o̲r̲ ̲I̲n̲p̲u̲t̲
Input for the Log File Editor is operator commands.
Commands will be provided for selection and display/
printout of the contents of the Log File generated
during test execution.
A detailed command description will be provided in
the CTDS Design Specification.
4.3 O̲U̲T̲P̲U̲T̲S̲
Output from the CTDS can be divided into the following
groups:
a) Condensed Script File
b) On-Line Test Controller output
c) Log File Listing
4.3.1 C̲o̲n̲d̲e̲n̲s̲e̲d̲ ̲S̲c̲r̲i̲p̲t̲ ̲F̲i̲l̲e̲
The Condensed Script File contains the output generated
by the Script Compiler. The Condensed Script File contains
a sequence of Command Blocks each containing the data
strings and parameters necessary for execution of the
command.
The detailed content and format of the Condensed Script
File will be provided in the CTDS Design Specification.
4.3.2 O̲n̲-̲L̲i̲n̲e̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲O̲u̲t̲p̲u̲t̲
During test execution two Log Files are generated:
a) contains blocks of data resulting from execution
of each of the condensed script commands.
b) contains data derived from level 2 protocol operation.
The detailed content and format of the two Log Files
will be provided in the CTDS Design Specification.
4.3.3 L̲o̲g̲ ̲F̲i̲l̲e̲ ̲L̲i̲s̲t̲i̲n̲g̲
After test execution a printout of the generated Log
Files can be made by means of the Log File Editor.
The Log File Editor produces a formatted printout of
the Log File.
The Log File Editor also provides the user with the
capability to search and select specified parts of
the Log File content.
The detailed format of Log File Listings will be provided
in the CTDS Design Specification.
4.4 D̲A̲T̲A̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
A detailed description of files, tables and other data
structures together with the related storage allocation
will be provided in the CTDS Design Specification.
4.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲
The detailed description of internal- and auxiliary
storage regarding media, size and address will be provided
in the CTDS Design Specification.
4.6 D̲A̲T̲A̲ ̲R̲E̲T̲E̲N̲T̲I̲O̲N̲
A description of which data to be retained will be
provided in the CTDS Design Specification.
4.7 P̲R̲O̲G̲R̲A̲M̲ ̲R̲E̲L̲A̲T̲I̲O̲N̲S̲H̲I̲P̲S̲
Program relationships are outlined in section 4.1.
4.8 P̲R̲O̲G̲R̲A̲M̲ ̲L̲O̲G̲I̲C̲
The Program Logic will be described in the CTDS Design
Specification.
