top - download
⟦3319fe609⟧ Wang Wps File
Length: 102116 (0x18ee4)
Types: Wang Wps File
Notes: Crossfox tilbud
Names: »1818A «
Derivation
└─⟦e1d52bc1b⟧ Bits:30006228 8" Wang WCS floppy, CR 0137A
└─ ⟦this⟧ »1818A «
WangText
…00……00……00……00……00…D…02……00……00…D
C…0a…C…00…B…08…B…0c…B…0d…B
B A…0c…A @…0a…@…00…@…06…?…0c…?…01…>…08…>…0c…>…0e…> =…09…=…0d…=…0f…=…01…=…07…<…0d…<…01…<…05…;…0a…;…0e…;…0f…;…00…;…06…:…0b…:…0f…: 9…09…9…0d…9…01…9…06…8…0b…8…0e…8
7…08…7…0c…7…86…1 …02… …02… …02… …02…
APPENDIX I OF VOL IV 1982-03-05
MESSAGE SUBSYSTEM Page #
TECHNICAL PROPOSAL
4.3 M̲P̲F̲ ̲H̲A̲R̲D̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The MPF hardware will be based on the CR80 family of
computers.
Several years of rapid computer technology evolution
have led to the development of the CR80 computer product
line at CHRISTIAN ROVSING A/S. The computer family
is a collection of units architecturally structured
in an innovative way into powerful multiprocessor systems.
Through a high degree of parallelism and redundancy,
the configurations introduced herein offer nearly unlimited
operating power and outstanding system reliability.
From the outset, system architects at CHRISTIAN ROVSING
A/S recognized that micro -electronics was the driving
force behind modern computer technology. The CR80
product line is based on the functional modularity
made feasible by low-cost LSI with advanced distributed
architecture and multiprocessing concepts. Though
they appear to be minicomputers, the CR80 systems in
the larger configurations are competitive with and
challenge the power of large mainframes, but with far
superior operational characteristics and hitherto unrealizable
advantages. The CR80 building block modules allow
a system configuration flexibility previously unachievable;
this has led to the definition of the CR80 Computer
Family.
System boundaries are arbitrary and somewhat hard to
define since they are actually non-existent. The CR80
product line, as such, probably offers the most versatile
computer configurations in the industry. Nevertheless,
for purposes of categorization the CR80 systems are
based on 4 standard computer modules, the u̲n̲m̲a̲p̲p̲e̲d̲
MINI and TWIN and the M̲a̲p̲p̲e̲d̲ MAXIM and FATOM.
- CR80 MINI, a multiprocessor system with up to 4
CPU's and 256 K words of memory with an operating
range of 0.6 to 1.3 million instructions/second
- CR80 TWIN, a fully dualized version of the MINI
with twin multiprocessors and a dual bused peripheral
subsystem.
- CR80 MAXIM, a multiprocessor system with up to
5 CPU's and 16 megawords of memory with an operating
range of 0.6 to 2.0 million instructions/second
and a Data Channel with a megabyte/second transfer
rate interfacing up to 15 channel units for control
of up to 960 peripheral modules
- CR80 FATOM, a fault-tolerant system including up
to 16 multiprocessors interconnected through a
512 megabit message transport; each multiprocessor
has the same capabilities as a CR80 MAXIM with
256 megawords of memory and an operating range
up to 30 million instructions/second
Unmapped systems are supported by the AMOS software
operating system and mapped systems are supported
by the DAMOS software operating system.
These standard configurations encompass a broad range
of physical characteristics to meet the requirements
of the smaller stand-alone user and those of the largest
multi-installation network applications. The four
models offer:
- a 50:1 range in instruction execution rate, varying
from 0.6 mips to 30 mips.
- a 1000:1 range in memory capacity, from 512 K bytes
to 512 megabytes.
- a 80:1 range in processing power, utilizing one
CPU or up to 16 interconnected multiprocessors
with a maximum of 5 CPU's each.
- a 400:1 range in connectivity, through Peripheral
controllers accommodating a variety of terminations
with as many as 960 peripherals or up to 4096 communication
lines.
Flexible variation in the size and structure of the
CR80 systems is permitted by the unusual degree of
hardware and software modularity. The hardware essentially
consists of fast transfer buses joined to each other
by adapters which allow units on one bus to access
those on another. Dualization at the internal level
and multiple redundancy at the system level provide
a CR80 hardware architecture which is fully exploited
by the DAMOS software operating system and programs
to provide survival after operational failure of individual
components.
Reliability, which is increasingly becoming of concern
in real-time and distributed network applications,
is achieved in the CR80 computer systems by applying
unique architectural concepts. The CR80 hardware/software
architecture treats all multiprocessors as equal elements,
none absolutely dedicated to a specific role. Fault
tolerance and backup are achieved through an n+1 redundancy
scheme without preassignment of system functions to
specific
processors. This is in marked contrast to the more
common, rigid dualized configurations often encountered
in dedicated applications with on-line master/slave
arrangements or off-line backup with switchover facility.
The many functional and operational features inherent
in the CR80 computer system configurations go beyond,
therefore, mere physical size variations and expansion
options.
4.3.1 H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The MPF system will be based on the CR80 FATOM series,
more specifically the CR860/002 configuration. This
computer configuration is a fault tolerant, virtual
memory computer constituted of 2 racks, each containing
a dual bused Processor Unit crate and a dual bused
Channel Unit Crate.
The CR860/002 computer is a standard computer manufactured
and tested according to standard procedures set up
by our Production Division.
The custom-tailored MPF system will be established
from the CR860/002 by adding an extra rack for adaptors
and disc. The MPF configuration is depicted in fig.
4.3.1-1 and all components are listed in fig. 4.3.1-2.
More details are found in the datasheets in ANNEX C.
Fig. 4.3.1-1
Item Number Description
1 3 CR8101-/036/00 Rack
2 2 CR8125M/225PC/00 PU-CRATE
3 2 CR8125M/425AB/00 CU-CRATE
4 4 CR8105M/020-/00 FAN UNIT
5 3 CR8106-/220-/00 MAINS
FILTER
6 8 CR8050M/010-/00 POWER
SUPPLY
7 3 CR8107-/010-/00 POWER
DIST.PANEL
8 2 CR8020M/000PC/00 MAP
9 2 CR8071M/010-/00 MIA
10 4 CR8003M/040PC/00 CPU CACHE
11 6 CR8016M/128PC/00 RAM 128K
12 2 CR8081M/010A-/00 CIA-A
13 2 CR8081M/010-B/00 CIA-B
14 2 CR8211M/738-/00 DATA
CHANNEL
TERM.
15 4 CR8211M/015-/00 CABLE
DATA
CHANNEL
16 20 CR8201M/015-/00 CABLE
RACK
POWER
17 12 CR8055M/020-/00 MBT
18 3 CR8044M/040AB DISC
CONTROLLER
19 3 CR8084M/010 DCA
20 1 CR8047M/040AB FLOPPY
DISC
CONTR.
21 1 CR8087M/010 SFA
22 11 CR8066M/010AB LTU
23 11 CR8082M/010 LIA-N
24 1 CR890/104 WATCHDOG
25 1 DELTA DATA 7260TC TEMPEST
VDU
26 1 TRACOR 8000 TEMPEST
PRINTER
27 5 DELTA DATA 7301 VDU
28 3 CR8330/200 PRINTER
29 1 CR8300/080 80MB
SMD DISC
DRIVE
30 2 CR8300/150 150 MB
SMD DISC
DRIVE
31 2 CR8300/001 ACOUSTIC
CABINET
32 5 CR8319/80 80 MB
DISC
PACK
33 2 CR8319/150 150 MB
DISC
PACK
34 3 sets CABLES
FOR DISC
35 1 CR8308/232 DUAL
FLOPPY
DISC
36 1 CR1081S/020 S-CRATE
37 3 CR8105S/010 S-FAN
38 1 CR8022S/000 S-POWER
SUPPLY
39 2 OPTO
MULTIPLEXOR
40 3 CR1086S/000 BACK
PANEL
ADAPTOR
41 3 L/L ADAPTOR
42 4 CR2560/008 MCU's
BOX
Fig. 4.3.1-2
4.3.2 D̲u̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲c̲e̲p̲t̲
Two identical Processor Units are part of the hardware
configuration. One is the active PU, while the other
is the standby, ready to take over from the the active.
Each Processor Unit is equipped with Power Supply,
2 CPUs with CACHE memory, 3 128 kw memory board, and
a MAP module. The MAP module performs address translation
between the logical addresses used by the CPUs and
the physical addresses in the memory boards. The MAP
module is connected to the MIA module, i.e. the memory
interface adapter which connects a Processor Unit with
Channel Units.
The dualization principle in the Channels Units is
different from the principle applied in the Processor
Units as each CU is dualized within itself. All modules
in a CU are attached to both of the two buses, which
are powered from separate power supplies. The two 150
MB disk drives are attached to two separate disk controllers
and adapters. The software which controls the disk
operation will ensure that the contents of the two
disks are identical, i.e. the disks are mirrored.
In the event that one disk fails, the other disk will
continue operation while the faulty disk is being repaired.
After restoration of the erroneous disk, software
can copy all the contents of the correct disk to the
newly installed (repaired) disk. This can be done
during normal operation. The offline disk and the
floppy disks are not dualized. (Or rather: A dual
floppy disk is used, but it is not mirrored).
4.3.3 C̲R̲8̲0̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲S̲y̲s̲t̲e̲m̲
As has been seen previously, a CR80 Processor System
is implemented in 2 types of crates (card cages), the
Processor Unit (PU) containing all address sourcing
devices (CPU's and DMA's) and the memory. The second
type of crate is the channel Unit which can contain
additional memory if required. The Channel Units (CU),
furthermore, contain all peripheral processors interfacing
peripherals (e.g. disc, tape, terminals, communication
lines etc.). All modules in each type of crate are
attached to buses to allow communication between all
modules.
The P-bus in the PU is reserved for used by the Central
Processing Units (CPU's), while the C-bus, which is
also located in the PU crate, is utilized by Direct
Memory Access (DMA) devices, e.g. the MAP module.
In the Channel Unit (CU), peripherals (disc, terminals,
communication lines etc.) are attached by peripheral
processors that perform distributedly I/O processing
associated with the specific types of attached devices
and communicate directly data and status/control messages
to the main memory.
The parts of main memory accessible by peripheral processors
is compartmentalized. A peripheral processor can only
access its own compartment, and not that of another
peripheral processor or parts of main memory allocated
for general processing. The combination of a peripheral
processor and compartmentalized memory is defined as
a peripheral module. This design ensures integrity
and security of Input/Output and provides each peripheral
module with its own path to mainmemory, thus removing
restrictions and avoiding speed degradation commonly
associately with multiplexed I/O access to memory.
4.3.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲S̲y̲s̲t̲e̲m̲
The Watchdog Processor System is a Maintenance and
Configuration Processor (MCP). It is based on a standard
programmable Line Termination Unit (LTU) which has
been programmed to monitor and control the overall
operation of the CR80 computer system.
The MCP is interfaced to both PUs and CUs and is also
interfaced to the Watchdog Panel, which is used to
choose the different modes of Watchdog operation.
During normal opration the watchdog will continuously
monitor the well-functioning of all modules in the
PUs and CUs. In the event that a failure occurs, the
watchdog will initiate switchover procedures and recovery
procedures if appropriate.
The watchdog by itself is not dualized. Hence any
failure in the Watchdog will require manual operation.
The watchdog can be set in a manual mode to allow
this. System controller facilities are provided by
a VDU, a printer and floppy disc attached to the Watchdog.
The system operator can use this equipment for system
control.
4.3.5 P̲e̲r̲i̲p̲h̲e̲r̲a̲l̲s̲
The different peripherals used in the MPF configuration
are described in the following sub-sections.
4.3.5.1 V̲i̲s̲u̲a̲l̲ ̲D̲i̲s̲p̲l̲a̲y̲ ̲U̲n̲i̲t̲ ̲(̲V̲D̲U̲)̲ ̲
Two different types of VDUs will be used, i.e. one
tempest VDU and non tempest VDUs. The functions of
the two types are similar.
The VDU is a user programmable visual display terminal
with communication capabilities. It includes a visual
display screen, keyboard, text memory, and communication
cables. Each of these components is described briefly
below.
The visual display screen is a 14 inch (diagonal measurement)
CRT screen. It is used as a window to text memory,
where all entered data is stored. Different portions
of text memory can be displayed via user commands.
The screen has the capability to display 28 lines
of 80 characters each, thus allowing 2240 characters
to be displayed at a time. Since text memory contains
approximately 21,000 characters, only a segment of
this text memory can be displayed at one time. A status
line (first line of the screen) is reserved for terminal
and/or host messages to the system user. (This limits
the user to 27 screen lines, or 2160 displayable positions).
Messages are displayed in the status line to inform
the user of certain prevailing conditions pertaining
to the operating systems. The VDU is "flicker free"
and "non-reflective".
The cursor marks the video screen as to the user/host
next entry position. Cursor type is selectable in
the OPTIONS menu. There are six options:
a. blinking block
b. non-blinking block
c. blinking underline
d. non-blinking underline
e. blinking bar to the end of the current line
f. non-blinking bar to the end of the current line
The cursor can be positioned by home/up/down/left/right
keys.
Each character is displayed on a 7 x 9 dot matrix in
a 10 x 12 field. This arrangement allows for spacing
between characters.
The VDU keyboard is a detachable typewriter style keyboard
with repeatable keys. It includes the following keypads:
a. the main, central keygroup, used for alphanumeric
entry
b. 12 key numeric and program function (PF) keypad
(located to the right of the main keypad), used
for quick numeric entry and PF key (user definable)
entry
c. 12 key display control keypad (located above the
numeric keypad), includes paging, scrolling function
keys, and cursor control keys
d. 12 key text processing keypad (located to the left
of the display control keypad), used to effect
various text processing functions.
e. 10 key editing and clearing keypad (located to
the left of the text processing keypad), used to
effect various text editing and clearing functions,
the insert/delete characters and line or erase
screen
f. 12 key PF keypad (located to the left of the editing
and clearing keypad), used for PF key entry
g. 10 key miscellaneous function keypad (located immediately
below the PF keypad), used to effect various system
functions as indicated on the keycaps
All editing facilities may be controlled either
locally or from the host.
The character set is USASCII 7 bit-code and includes
both upper and lower case
All entered text, host or operator, is initially entered
into text memory. which has a capacity of 21,000 characters.
Data is stored in a packed memory format, meaning
that end of line spaces are suppressed, thus allowing
maximum use of available text memory storage. All
keyboard entries, text and codes corresponding to the
function keys, as well as host entries of the same
types, are stored in text memory. To delimit each
line of text in memory, a non-displayable end-of-line
character is stored to mark the end of each line of
text. This information instructs the printing and/or
receiving device where each line ends. Selected segments
of text memory can be displayed on the video display
screen via operator command. These segments of text
memory can be assigned to be displayed into any of
sixteen split screens.
The VDU is used for information retrieval from a host
computer, data entry and display, data transmission
to a host computer, and text processing applications.
Specific terminal capabilities include the following:
a) store large amounts of scrollable text
b) split screen operation
c) text manipulating and processing
d) video attributes
e) format operation
f) program function keys
g) alternate character sets
h) terminal menus
i) text delimiters
j) diagnostic testing
k) communications
l) control functions
m) printer option
The VDU can utilize different baud rates from 600 bps
to 9600 bps, and the baud rates are easily changeable.
The VDU is equipped with a "physical" security key
function, the position of which can be sensed by the
host.
As an option the VDU can be delivered in a TEMPEST
version which is in accordance with AMSG720A.
4.3.5.2 T̲e̲m̲p̲e̲s̲t̲ ̲P̲r̲i̲n̲t̲e̲r̲
This section describes the physical and operational
characteristics of the Medium Speed Printer MSP).
This printer happens to be termed "Medium Speed...".
Yet it complies with all the IFB requirements for
a "High Speed Printer".
The MSP is a microprocessor controlled communications
receive-only system with medium-speed printing, developed
for permanent installation in all message processing
activities. The MSP operates in a half-duplex configuration
providing hard-page-copies of all received messages.
The MSP can receive data from a d.c. signal line operating
in accordance with MIL-STD-188/114/RS449 or from a
fiber-optics signal line.
The major assemblies of the MSP are:
Teletypewriter Control Module (TCM)
Printer
The TCM is the prime assembly of the MSP. It contains
the central processing unit (CPU) and circuit card
assemblies (CCA) that interface the CPU to the other
major assemblies and the signal line. The TCM also
contains the system power supply and the high-speed
printer assembly. The printer contains the high-speed
printhead, paper feed, and ribbon assemblies. Hard-page
copy is provided by the dot-matrix impact printhead
which operates at the rate of 240 characters per second.
The MSP is capable of handling 30 lines of 15 charcters
at 600 bps without loss of character.
The high-speed is accomplished by using bidirectional
printing techniques. The printer accomodates up to
15.5 inch wide sprocket feed paper for a maximum 132-character
line. The printing assembly is set for either an 80-character
or a 132-character line by setting a switch located
on the Printer Interface CCA. Paper feed is selectable
to 3 or 6 lines per inch. An automatic reverse feature
extends ribbon use between changes. A security key-lock
panel on the front of the TCM prevents printing when
the lock is in the locked position.
The MSP interface systems allow the TCM to be connected
to modems, other terminals, data encryption equipment,
or data processing systems. Standard configurations
require low level, serial data input signals conforming
to MIL-STD-188/RS-449. The signal interface operates
asynchronously, isochronously, or synchronously in
accordance with MIL-STD-188 and can be switched for
either high-mark or low-mark signal sense.
All signal interface lines are filtered by a low-pass
signal line filter assembly. The interface can be
an asynchronous V24 interface with speeds up to 1.2
k-bps.
The character code set used on the MSP is a 96 character
ASCII set.
The MSP is equipped with audio alarm, paper out indicator
and physical key, making status signals available on
the interface.
For paper control, the MSP is equipped with automatic
line feed on carriage return, form feed and vertical
tabulation.
The MSP is TEMPEST approved in accordance with AMSG
720B. The acoustic noise will be below 60 dBA
4.3.5.3 N̲o̲n̲ ̲T̲e̲m̲p̲e̲s̲t̲ ̲P̲r̲i̲n̲t̲e̲r̲.
The matrix printer CR8330-/200--/00 will be used.
This printer complies with the IFB requirements to
a non-Tempest printer
4.4 M̲E̲S̲S̲A̲G̲E̲ ̲C̲O̲M̲P̲I̲L̲A̲T̲I̲O̲N̲ ̲U̲N̲I̲T̲ ̲(̲M̲C̲U̲)̲
4.4.1 G̲e̲n̲e̲r̲a̲l̲
The MCU solution proposed by Christian Rovsing A/S
is based on a military qualified, off-the-shelf micro-
processor system
Fig. 4.4-1
The message compilation Unit receives four serial data
streams from four ship-to-shore access sites. The
four data streams are identical except for transmission
errors and delay.
From the four channels, a single channel is compiled
by a majority voting algorithm and delivered to the
KW 7 crypto.
The functional characteristics of the proposed MCU
are
1. Reception of four 75 Baud V.24 channels.
2. Compensation for relative transmission delay on
the four channels (20msec).
3. Calculation of statistics for the purpose of determining
the probability of a correctly received character
from a particular channel (channel confidence).
4. Selection of most probably correct character among
the four; the selection is based on the current
channel confidence, combined with the character
status in term of framing status and correlation
with the other three channels.
5. Transmission of the character on a V24 line to
the Crypto.
6. Provision of a character on a separate line to
the MPF, indicating whether the selection of point
4 lead to ambiguity or not.
7. Provision of a channel confidence figure at regular
intervals.
4.4.2 C̲o̲m̲p̲i̲l̲a̲t̲i̲o̲n̲ ̲a̲l̲g̲o̲r̲i̲t̲h̲m̲
The IFB requires a message compilation by majority
voting on a character-by-character basis. Heavily
garbled channels shall be excluded from the voting
process. In addition, a confidence level of the channels
shall be established in order to facilitate selection
of the most probably correct character in case the
majority voting is ambiguous.
Since no a priori assumptions can be made about the
information in the message, the parameters left for
assigning a confidence level of a given character among
the four received are:
Character status:
o Received/not received status
o Correct/incorrect framing (start/stop bit)
o Agreement/non agreement between channels
Channel Status:
o Channel confidence level based on the status of
the previously received characters.
4.4.2.1 C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲S̲t̲a̲t̲u̲s̲
The character status is easily achieved. It should,
however, be emphasized that the errors are strongly
interrelated so a thorough knowledge of the failure
mechanisms is necessary for the correct interpretation.
Framing error, as an example, could be caused by
a) bit error on start bit
b) bit error on stop bit
c) bit slippage
Case a) Causes in general a data bit to be mistaken
for a start bit and hence leads to a garbled character.
Bit error on stop bit gives the same error indication,
but the character will be correct. Bit slippage will,
in general, lead to a garbled character, but an error
indication will only be given in certain cases.
4.4.2.2 C̲h̲a̲n̲n̲e̲l̲ ̲S̲t̲a̲t̲u̲s̲ ̲
Determination of the method for achieving the channel
status is quite complex.
The purpose of the channel status (channel confidence
level) is to provide a figure which reflects the relative
(prima facia) probability of receiving a correct character
from a given channel.
A means for determination of this probability is a
filtered version of the history of character status.
The filter function will be based on the Statistical
properties of the transmission channel. Some of the
more important requirements to the filter function
are:
o The ability to react rapidly on burst errors
o The ability to recover quickly from burst errors
o Smooth initialization.
4.4.3 M̲C̲U̲ ̲D̲e̲s̲i̲g̲n̲
Fig. 4.4-2: LTUX-M-CPU
The MCU functions are performed by two LTUX-M-CPU plug-in
modules, housed in a small crate with power supply.
The LTUX-M-CPU is a module designed for intelligent
line termination of multiple (up to 4) V.24 type channels.
The on-board microprocessor is programmed for the
individual application and the program resides in a
PROM.
The two modules communicate via the microbus.
Fig. 4.4-3
The input module performs the serial-to-parallel conversion,
collects the framing status and compares the characters
to achieve the correlation figure.
The output module receives the four characters and
the corresponding status and performs all message compilation,
data output and character quality assignment.
4.4.4 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The four serial, asynchronous data streams are converted
to parallel data by a universal asynchronous receiver/transmitter
(USART).
This digital circuit provides a status bit, indicating
framing error, i.e. incorrect frame format caused by
, for example, a falsely detected start bit or a corrupted
stop bit.
A "data available" status is indicated as a separate
signal when a character has been received.
The received characters, together with the above-mentioned
status, are read from the USART's after the expiry
of the max. delay period (20 msec) after the character
of the leading channel has been completed.
For each channel the following status is derived:
Data available yes/no
Framing error yes/no
Correlation, Fc 0,1,2
or 3
Fc is the number of channels which show the same character
as the one in question, i.e. Fc = 3 means that all
four channels agree, Fc = 0 that no other channel agrees
with the one in question.
Table look-up is a fast, very flexible and inexpensive
method of implementing algorithms, in particular if
the table size is small.
Data available, Framing error and F…0f…c…0e…, together with
channel confidence are used for table-look-up on a
channel-by-channel basis of:
a) Confidence level for present character
b) Updated channel confidence
The contents of the table are determined to fulfil
the specific IFB requirements on exclusion of garbled
channels. The remaining degrees of freedom are used
to provide the optimum choice based on the statistical
properties of the channel and taking into account the
behaviour during initialization, burst error, etc.
Having achieved the character confidence level, it
takes only a simple comparison to select the character
with the highest value for output.
Should more than one channel hold the same character
confidence level but claim different character values,
the one which was selected for the previous character
is chosen (provided this channel is among the channels
which hold the high level) or the one with the lowest
channel number is chosen for output. In this case,
the character transmitted simultaneously with the character
on the status line will indicate the ambiguity.
For each block of TBD compiled characters or after
TBD seconds of silence, a status message is sent on
the status line in addition to the above character
quality. The status message contains four characters,
reflecting the current channel confidence level.
4.4.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
4.4.5.1 M̲o̲d̲e̲m̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲
The MCU inputs are V.24/V.28 asynchronous channels.
Data rate is 75 baud.
Connection is via standard 25 pole connectors.
4.4.5.2 C̲r̲y̲p̲t̲o̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲
The MCU interfaces to the crypto through a KW-7 adaptor.
The MCU output to the KW-7 adaptor is a V.24/V.28
compatible line. Connection is via standard 25 pole
connector.
4.4.5.3 M̲P̲F̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The status line to the MPF is an asynchronous V.24/V.28
line.
Data rate is 1200 Baud.
Connection is via standard 25 pole connectors.
4.4.6 C̲o̲m̲p̲a̲r̲i̲s̲o̲n̲ ̲w̲i̲t̲h̲ ̲r̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The MCU, extended with the KW-7 adaptor, complies with
the requirements of the IFB in all respects.
4.5 M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲ ̲A̲N̲D̲ ̲T̲E̲S̲T̲ ̲F̲A̲C̲I̲L̲I̲T̲I̲E̲S̲
The MPF subsystems provide facilities for hardware
and software maintenance.
The maintenance support facilities are implemented
by exploitation of redundancy in the designed equipment.
System control facilities ensure that execution of
maintenance functions imposes no interference on normal
system operation.
4.5.1 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲e̲
The MPF hardware configuration is controlled by the
operator. There are two possible modes of on-line operation:
a) a dualized system consisting of an active PU with
associated peripherals and a standby PU.
b) a non dualized system consisting of an active PU
with associated peripherals and an off-line PU
with associated peripherals.
Maintenance functions are executed in mode b) (on-line).
4.5.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲/̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
The software development/maintenance facilities include
e.g.:
- compilers (including assembler)
- editors
- linker
- debuggers
For a more detailed description please refer to paragraph
4.6.4.
4.5.3 H̲a̲r̲d̲w̲a̲r̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
For hardware maintenance and diagnostics (M&D) a set
of M&D programs will be provided. For a description
of these programs please refer to paragraph 4.6.4.
4.5.4 S̲y̲s̲t̲e̲m̲ ̲T̲e̲s̲t̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
In the factory, facilities for simulation of a Standard
Test Environment (STE) will be provided. For a more
detailed description please refer to paragraph 7.2.4.
4.6 S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
4.6.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The MPF software system will, to a high degree, be
based on CAMPS software, presently being developed
for NATO. The high commonality with CAMPS software
will reduce software maintenance costs and reduced
life time costs for NATO.
The MPF software system is composed of three subsystems:
- System software
- Application software
- Support software
The overall software structure of the MPF and the packet
interrelationship is shown on figure 4.6.1-1
Figure 4.6.1-2 presents the hierachical relationship
of the MPF software in a visual table of contents.
a) S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The system software include the following packets:
- KERNEL, performs the functions closest to the
hardware, i.e. interrupt handling, process
concept, CPU management, process communication,
etc.
- I/O CONTROL, that performs the interface link
between the various users and the file-system.
- File Management System (FMS), handles the different
files allocated to the system.
- Message Management System (MMS), performs the
message handling, i.e. create, modify, append,
read, deletion, etc. of messages.
- Crossfox MPF System Functions (CSF), performs
a number of user functions that require execution
at system level.
- System Status and Control (SSC), handles the
supervision of the system and the alternative
MC communication.
- Table Management (TMP), contains all tables
related to the system and handles all table
updates performed by supervisor.
The system software is further described in section
4.6.2.
Her inds`ttes tegning 4.6.1-1
Her inds`ttes tegning 4.6.1-2
b) A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The application software handles the special functions
related to the specific CROSSFOX MPF requirements.
The application software includes:
- Traffic Handling Package (THP), receives the
external traffic and performs conversion, analysis,
and distribution. Further, THP handles the
messages for transmission.
- Logging Package (LOG), performs the collection
of log records from either THP or TEP for print
out and a (possible) later retrieval.
- Statistics Package (STP), collects statistical
information on system activities and generates
statistical reports for printout.
- Terminal Package (TEP), performs the operator
oriented communication with the system, such
as system supervision and message preparation.
- Storage and Retrieval (SAR), stores the processed
messages for later retrieval in case of retransmission
or local use.
The application software is further described in
section 4.6.3.
c) S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The support software includes:
- Support software package with development software
such as editor, compiler, linker, etc., and
diagnostics software.
- Off-line package contains the table generator
software, VDU format generation software and
system configuration software.
The support software is further described in section
4.6.4.
4.6.2 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The MPF system software will be based on the CR80 DAMOS
operating system. (Distributed Advanced Multiprocessor
Operating System).
On top of this highly versatile CR80/DAMOS architecture,
CHRISTIAN ROVSING A/S has created a set of Special
System Software packages for message processing systems
like Crossfox-MPF.
The major components in DAMOS are:
. KERNEL
. Terminal Management System (TMS)
. File Management System (FMS)
. Root Operating System (ROS)
The Special System Software consists of the following
packages:
. Input Output Control (IOC)
. Message Management System (MMS)
. Crossfox MPF System Functions (CSF)
. System Status and Control (SSC)
. Table Management Package (TMP)
The major features of the system software, described
in the following subsections, are:
. DAMOS ̲KERNEL
. Input Output Control, IOC (incl. DAMOS-TMS)
. DAMOS-File Management System, FMS
. Message Management System, MMS
. Crossfox-MPF System Functions, CSF
. System Status and Control, SSC (incl. ROS)
. Table Management Package
4.6.2.1 K̲e̲r̲n̲e̲l̲
The DAMOS KERNEL provides the lowest level of system
service above the CR80 hardware and firmware level.
Thus the KERNEL and the CR80 instruction set is the
interface between other S/W modules and the low level
H/W objects of the CR80M, namely: CPUs, memory modules,
memory mapping module, I/O buses and I/O devices.
The KERNEL, together with the MAP module, provides
a secure means of protecting all data and resources
from unauthorized use.
The major components of KERNEL are:
* Resource Management
* Directory Functions
* Process Management and Scheduling
* Process Communication Facilities
* Memory Management
* Device Management
* Real Time Clock
* Error Processor
* Transfer Module
These functions are briefly described in the following
subsections.
4.6.2.1.1 R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The Resource Management Module deals with synchronization
elements and governs references to e.g. processes and
memory segments, for example. Such resources are handled
in accordance with hierachical relationships among
processes. This will enable the various DAMOS modules
to handle resources in a coherent way.
4.6.2.1.2 D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
These are common service functions for the other KERNEL
components.
The Directory Functions are tools for allocation of
resources, i.e. memory segments, processes, CPUs and
synchronization elements.
4.6.2.1.3 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲S̲c̲h̲e̲d̲u̲l̲i̲n̲g̲
A process is defined as the incarnation of the data
transformation obtained by execution of a program.
During the lifetime of a process it is found in different
process states, e.g. it may be waiting for some event
to occur.
Each process competes with other processes for system
resources, e.g. processor power, physical memory, and
I/O-service.
Process Management deals with implementation of processes
and with the functions available for operating on them.
The processes are scheduled on the basis of a priority
scheme.
4.6.2.1.4 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲a̲c̲i̲l̲i̲t̲y̲
This provides the basic mechanisms for exchange of
information between processes.
A set of procedures are provided.
Two types of resources are used: synchronization elements
and communication elements.
4.6.2.1.5 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
At any one time, a process can address 2 x 64 K words
(code and data respectively) indirectly via translation
tables. This leads to reentrant and unmodifiable code.
The Page Manager (PM) allows changing the "position"
of the addressing window thus leading to practically
unlimited addressing capabilities.
The page manager contains basic mechanisms for security
and protection by administering the addressing capabilities
of processes to data and program segments.
4.6.2.1.6 D̲e̲v̲i̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Device Management controls the device handlers which
are handling the direct Input/Output execution and
device interrupts.
4.6.2.1.7 R̲e̲a̲l̲ ̲T̲i̲m̲e̲ ̲C̲l̲o̲c̲k̲
This facility offers functions for reading and setting
the system clock, tying the execution of processes
to time, and conversion between different time-formats.
4.6.2.1.8 E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲
Handles errors detected at the hardware and KERNEL
level and provides a central error reporting mechanism.
4.6.2.1.9 T̲r̲a̲n̲s̲f̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲
For hardware based transfer of data in a Processing
Unit.
4.6.2.2 I̲n̲p̲u̲t̲ ̲O̲u̲t̲p̲u̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲I̲O̲C̲)̲
The I/O Control S/W package provides the necessary
interfaces to the DAMOS Terminal Management System,
TMS, so that it can establish the connection between
Crossfox application S/W and terminals and lines. The
control functions can be divided into two distinct
functions:
- L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
This covers common S/W for interface to lines
via LTUs (L̲ine T̲ermination U̲nits)
- D̲e̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
All line, channel and device specific S/W and
firmware for
- TARE and MC control
- TRC, MRL, S/S and Broadcast control
- VDU control
- Software Development VDU control
- SSC interface (for watchdog console).
The IOC package is subdivided into subpackages of the
following categories:
- Format Handling (on VDUs)
- LTU Handling
- LTU Functions
- SSC Interface
4.6.2.3 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲F̲M̲S̲)̲
The File Management System is a general system software
package used for management of backing storage i.e.
disk and floppy disk storage.
The entities managed are the following:
- U̲s̲e̲r̲s̲ (i.e. processes or groups of processes)
- D̲e̲v̲i̲c̲e̲s̲ (e.g. disk drives)
- V̲o̲l̲u̲m̲e̲s̲ (e.g. disk packs)
F̲i̲l̲e̲s̲ (i.e. logical sequences of backing storage
blocks).
Management consists of naming, handling, description,
functions, etc. as, applicable for these entities.
Major aspects are those of reliability and security.
As for reliability it should be noted that the device
management of FMS supports the concept of fault tolerant
mirrored disks.
This implies that if both on-line disks are operational
they are updated concurrently.
If one of the disks for some reason is not operational
it will later be updated to re-establish a state with
two identical disk contents.
S̲e̲c̲u̲r̲i̲t̲y̲
Whenever file access is attempted, information related
to users and files are compared in order to perform
two kinds of security measures:
- A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
- S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲
The Access Control checks whether the particular user
has the right to the intended kind of access to the
particular file.
The Security Check compares the security profile of
the user with that of the file.
4.6.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲M̲M̲S̲)̲
The Message Management System is concerned with specific
information files of a fault tolerant message processing
system, so it partly resembles the FILE MANAGEMENT
SYSTEM (FMS) which is the general system S/W package
dealing with backing storage.
The two systems, MMS and FMS, are complementary and
are incorporated in a single process.
MMS interfaces to the application side (commands) and
to the disk (Disk Cache Manager).
Further, the major functions are:
- I̲n̲f̲o̲ ̲F̲i̲l̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
(In a Short Term Storage)
S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
Handling of Intermediate and Long Term Storage
of message incarnations.
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Facilities for continuation after restart or
after switchover to the standby processing
unit.
4.6.2.5 C̲r̲o̲s̲s̲f̲o̲x̲-̲M̲P̲F̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲(̲C̲S̲F̲)̲
CSF is a system software package which on top of KERNEL
supplies a set of support tools for application packages.
CSF combines the provision of these tools with a mechanism
for:
- Error detection and handling
- Security and access control
- Protection of data
- Checkpointing and recovery.
With reference to the subpackage names, the support
tools comprise:
- C̲o̲m̲m̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Utilities for the other CSF subpackages
- T̲i̲m̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
Timer driven event facilities and manipulation
with current time and date.
- Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
Provision of a tool for communication between
application processes.
- M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
Application interface to MESSAGE MANAGEMENT
SYSTEM
- C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
Monitoring of multiprogramming within a process.
- S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲
To serve as a central waiting facility for
interfaces to system tasks performed on behalf
of application programs.
4.6.2.6 S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲u̲s̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲S̲S̲C̲)̲
DAMOS is the general operating system for any local
CR80 configuration.
SSC is the specific system software which, on top of
DAMOS, performs the overall control of the particular
dualized H/W and S/W configuration of one site.
Within a site (e.g. no. 301), it starts, allocates
resources to, monitors, and controls the CROSSFOX-MPF
on-line and off-line system. This is done through
interaction between the watchdog, the two PUs, the
peripherals and the operator.
It contains programs for MC-transmission and MC-reception.
Which of the two that is active depends on the current
state of that site.
M̲o̲d̲e̲s̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
For a start it is worth clarifying the different scopes
of the total system.
a) T̲h̲e̲ ̲t̲w̲o̲ ̲s̲i̲t̲e̲s̲ ̲a̲s̲ ̲a̲ ̲w̲h̲o̲l̲e̲
The normal state of operation is:
One site (e.g. No.101) being active, message-processing
and sending MC-checkpoints.
The standby site (in casu No.301) being active
in receiving MC-checkpoints. The process of initiating
message processing at the other site will be termed
c̲h̲a̲n̲g̲e̲o̲v̲e̲r̲.
There is no central equipment to automatically
set the overall state.
The state of the individual site must be independently
settable by decision of the local supervisor.
If the incoming MC-traffic indicates problems,
the local supervisor will be notified automatically.
b) T̲h̲e̲ ̲i̲n̲d̲i̲v̲i̲d̲u̲a̲l̲ ̲s̲i̲t̲e̲
As indicated, an operational site may be in the
message processing or in the MC-checkpoint-receiving
state. In either of these states the site may operate
in one of the following two m̲o̲d̲e̲s̲:
- A dualized system consisting on an active PU
(P̲rocessing U̲nit) and associated peripherals
and a standby PU.
- A degraded system consisting of one active
PU and associated peripherals and one offline
PU and associated peripherals.
The explicit functional requirements of the SSC
are described in sections 4.2.8, 4.2.9 and 4.2.10.
A workable solution poses further implicit requirements
to be covered in the SSC-design.
This is based on the following partitioning into
subpackages:
- MC-Checkpoint Transmission
- MC-Checkpoint Reception
- Online diagnostics
- Line Monitoring and Control
- Reception of Technical Error Reports
- Operator Commands to an online PU
- Offline PU operation
- Watchdog Firmware Functions.
These subpackages are briefly described in the
following subsections.
4.6.2.6.1 M̲C̲-̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
This subpackage is active if the site is in the message
processing state.It receives checkpoint records from
MMS, LOG and CSF and transmits checkpoint information
via IOC to the other site.
4.6.2.6.2 M̲C̲-̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
This subpackage is active if the site is in the MC-Checkpoint-receiving
state. Via IOC it communicates with the message processing
site.
The information received is recorded on disk, and the
system is kept in a state ready for changeover.
4.6.2.6.3 O̲n̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
These programs are low priority tasks aiming at limiting
the effect of an error by
- timely detection of errors
- reporting the error condition
A specific test program checksums the read-only system
software periodically or on request.
4.6.2.6.4 L̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ (LIMCO)
LIMCO monitors and controls the LTU-lines (L̲ine T̲erminating
U̲nits) for VDUs, external channels, Stand Alone Devices,
the W̲atchD̲og Processor (WDP), the WDP-VDU, the WDP-printer,
and the Standby PU (Processing-Unit).
LIMCO performs two kinds of functions:
- Logical control, e.g. access control (block/unblock)
delivery control(security
function)
- Monitoring of the system connection and subsequent
execution of control. (The system connection is
used by applications to communicate with the system
software which handles security functions).
4.6.2.6.5 R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
Technical errors are errors resulting from
- system calls
- instruction execution
- validity checks
- WDP-monitoring (W̲atch D̲og P̲rocessor)
For the error reports, SSC performs:
- Update of the configuration table
- Update of configuration display
- Printing of an error report on the WDP printer.
The actions for error correction depend on the type
of error.
The actions automatically performed may include:
- the retiring of an application process
- reconfiguration
- emergency switchover to the standby P̲rocessing
U̲nit (PU) of the same site.
4.6.2.6.6 O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲a̲n̲ ̲o̲n̲-̲l̲i̲n̲e̲ ̲P̲U̲ ̲(̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
̲U̲n̲i̲t̲)̲
Operator commands control the Crossfox MPF Hardware
and Software configuration. The execution of the control
is shared between the active PU and the WDP.
Operator functions are:
- start-up of all modes of the system
- ordered close-down
- switch between redundant H/W units
- device control
- control of line attributes
- load of new software
4.6.2.6.7 O̲f̲f̲-̲l̲i̲n̲e̲ ̲P̲U̲-̲o̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲(̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲U̲n̲i̲t̲)̲
Command interface to the SSP (Support Software Package)
and the OLP (Offline Package) in the off-line PU and
allocation of resources for off-line operations.
4.6.2.6.8 W̲a̲t̲c̲h̲d̲o̲g̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
These include the following functions:
- W̲a̲t̲c̲h̲d̲o̲g̲ ̲l̲i̲n̲e̲ ̲c̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲f̲i̲r̲m̲w̲a̲r̲e̲.̲
This supports communication to the two PUs, the
operator VDU, and the operator printer.
- S̲w̲i̲t̲c̲h̲ ̲l̲o̲g̲i̲c̲
This controls the physical connection of H/W modules
based on
- commands from PUs
- no keep alive messages received from either
of the PUs
- commands from the operator
- direct monitoring of discrete points in the
crates.
(this is done through the Configuration Control
Bus by a periodic scanning).
- E̲n̲f̲o̲r̲c̲e̲m̲e̲n̲t̲ ̲o̲f̲ ̲s̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲t̲o̲ ̲t̲h̲e̲ ̲s̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲.̲
- W̲D̲-̲s̲t̲a̲n̲d̲a̲r̲d̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲
The WD-Kernel and start up firmware.
4.6.2.7 T̲a̲b̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲T̲M̲P̲)̲
The Table Management Package administers a data base
containing:
. Tables (e.g. (Plain ̲Languages ̲Address (PLA)tables))
. System Parameters (e.g Device Parameters)
. Global Serial Numbers (e.g. Transmission Serial
Nos).
TMP searches and delivers data to various other packages
on request.
TMP may update the data base automatically or on request.
An access control is employed in the search and update
functions.
TMP is composed of the following subpackages:
. TMP Search
. TMP Update
. TMP Monitor (For interfacing to the process being
served).
4.6.3 A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲/̲W̲
The following application S/W will be developed for
CROSSFOX:
1) System Data Base, i.e. tables supporting the system
configuration control and the traffic control.
2) Historical Data Base, i.e. stored messages, log,
statistics, and retrieval catalogues.
3) Application S/W Packages
- Traffic Handling Package
- Terminal Package
- Statistics Package
- Logging Package
- Storage & Retrieval package
System S/W and Support S/W, however, are standard CHRISTIAN
ROVSING A/S products.
4.6.3.1 T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Traffic Handling Package will support the following
major tasks
1) Incoming traffic reception from external channels
including:
- transport from channels to the MPF system
- traffic analysis
- local delivery of traffic
2) Outgoing traffic transmission to external channels
including
- conversion, i.e. format compilation and routing
of locally generated and relay traffic
- transport from MPF system to external channels
3) Traffic monitoring and control including:
- detection of special service messages and execution
of associated control functions
- monitoring of traffic flow and quality and
initialization of the relevant warnings and/or
transmission of proper automatic service messages
- support of the functions specifically related
to SHIP-TO-SHORE and BROADCAST channel monitoring
and control.
A S/W module breakdown has been performed according
to the above task structure and has further been checked
against the detailed functional breakdown of the sections
4.2.1 and 4.2.2. The result is presented in the pictorial
overview of fig. 4.6.3.1-1, which also indicates the
interfaces between modules. The following sub-section
will present some details of the functions associated
with each module.
A few remarks will be given here concerning the implementation
of the modules from the point of view of computer runtime
execution:
As indicated in the referenced figure there are several
TRANSPORT modules; possibly there will be one process
per network type (TARE, TRC, S/S, BROADCAST, MRL, and
Other MC) with three coroutines per channel, namely
the INCOMING TRANSPORT, the OUTGOING TRANSPORT, and
the TRANSPORT CONTROL. This S/W arrangement - supported
by the two CPUs per PU, the disk data transfer and
search, and the I/O data transfer all working in parallel
- provides for high throughput and low transfer times
even with high character transfer rates at multiple
channels.
Other modules are dedicated to the processing of complete
messages or transactions of less urgency and might
be implemented in one process (incarnation) only, although
the duplication of processes is a possibility if this
is found necessary.
There is a high functional similarity between the two
modules for Analysis; possibly they will be implemented
as one (may be duplicated) process with a set of coroutines.
The same is the case for the Conversion modules.
4.6.3.1.1 T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲s̲
The following is a short description of the modules
presented on fig. 4.6.3.1-1. It will be based mainly
on referencing the functional description of sections
4.2.1 and 4.2.2. The mapping is preliminary and is
not strictly one to one, however.
- Incoming Transport
The functions of this module have been described
in section 4.2.1.1.
Concerning the traffic control (message receipts,
channel check messages, etc.) the functions are
executed in cooperation with the Transport Control
Module.
For S/S connections certain functions are delegated
to the S/S Monitor & Control Module.
- Outgoing Transport
Fig. 4.6.3.1-1 TRAFFIC HANDLING PACKAGE, S/W MODULES AND INTERFACES
The functions of this module have been described
in section 4.2.2.2. Some of the functions of section
4.2.2.3 will also apply. The channel selection
procedures pertain to the Conversion module, however.
For the Broadcast/MRL connection, certain functions
have been delegated to the Broadcast Monitor &
Control Module.
- Transport Control
This module synchronises those functions of traffic
monitor and control which involve both incoming
and outgoing channels.
- S/S Monitor & Control
The functions which are related to the status of
S/S channels and those functions which are related
to monitoring and control of start of and execution
of transfer sessions on these channels are included
here; refer to section 4.2.1.1.2.
- BROADCAST Monitor & Control
This module serves the functions which are related
to the status of BROADCAST/MRL channels, the traffic
selection for transmission, and the generation
of service messages for traffic control. Refer
to section 4.2.2.3.
- ACP 126 Analysis
The functions described in section 4.2.1.2.1 are
supported by this module. Also the task of conversion
to internal ACP 127 format described in section
4.2.2.1.1 is included.
- ACP 127 Analysis
The functions described in section 4.2.1.2.2 are
supported by this module. Also the task of conversion
to internal ACP 127 format described in section
4.2.2.1.2 is included.
- Internal Transport
This module executes the functions of message routing
to local terminals.
- Broadcast Conversion
Refer to section 4.2.2.1 for the format compilation
from the internal ACP 127 format to the proper
Broadcast transmission format. All routing is
performed in this module including the routing
tasks described in section 4.2.2.3. (Broadcast).
- ACP 127 Conversion
Refer to section 4.2.2.1 for the format compilation
from the internal ACP 127 format to the proper
transmission format for non-Broadcast channels.
The channel selection procedures of section 4.2.2.2
are also included here.
4.6.3.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲a̲c̲k̲a̲g̲e̲
The terminal package constitutes the operator interface
to the MPF system and consists of 4 sub-packages that
provides a fully compliant high level operator interface
using menu selection and form-filling-out procedures.
Corresponding parts of the man-machine interface (MMI)
are identical with the CAMPS MMI, where possible.
The sub-packages are:
- Supervisor VDU Package (SUP)
- Message Service Operation Package (MSOP)
- Printer Package (PRIP)
- VDU User Package (VUP)
4.6.3.2.1 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲V̲D̲U̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The S̲u̲pervisor VDU P̲ackage (SUP) contains the software
to support the three main supervisor functions as shown
on Figure 4.6.3.2.1-1.
o System Control (SYSC)
o Message Handling (MSGH)
o Supervisor Engineering Functions (SENF)
The System Control Functions:
Device Control
Addressing Scheme Control
User Profile Update
Queue Control
Report Control
Supervisor Printout Control
Disk Control
Command Control
Security Control
Global No. Series Control
System Parameter Control
System Information Extract
Table Print
These functions enable the supervisor to control the
operational and functional aspects of the system.
Fig. 4.6.3.2.1-1
CROSSFOX Supervisor Functions
The Message Handling Functions allow:
a) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Prepare Service Message
Continue Preparation
Delete Service Message
Outgoing Service Message Status
b) R̲e̲t̲r̲i̲e̲v̲a̲l̲
Retrieval for Rerun
Retrieval for Re-distribution
Retrieval for Local use
These functions enable the supervisor to prepare and
edit Service Messages, to send Service Messages, to
delete Service Messages and to obtain status regarding
Service Messages under preparation or sent for transmission.
The retrieval functions enable the supervisor to retrieve
any message in a suitable format and to specify re-run
or redistribution for local use.
The Supervisor Engineering Functions enable the supervisor
to perform engineering/operator type functions upon
the system. Due to the nature of these functions they
will be defined during system definition phase.
4.6.3.2.2 M̲S̲O̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The VDU MSO Package (MSOP) constitutes the only means
by which Crossfox Personnel may gain access to the
services of the MPF user function.
a) The CROSSFOX MSO function is made up of six subfunctions:
Service Message Preparation, Retrieval for Retransmission,
Retrieval for Rerun, Incoming Message Service Assistance,
Outgoing Message Service Assistance, and Display
of Retrieval Messages. A VDU or MSO may have access
rights to one or more of the subfunction services
as specified by the Supervisor.
b) The VDU MSO package (MSOP) implements all the services
of the CROSSFOX MSO function, which implies the
following responsibilities:
1) Interface the MSO to the CROSSFOX system, i.e.
Man/Machine I/F Support and Monitoring
2) Direct all MSO requests/commands to the relevant
package within CROSSFOX
3) Present, to the MSO, information sent to his
VDU
4) Supervise/allow the MSO to prepare service
messages and annotation
5) Allow the MSO to make service on outgoing/incoming
messages, e.g. Garble Correction, Relay Assistance,
Pilot Control, Outgoing Routing Indicator Assignment
4.6.3.2.3 P̲r̲i̲n̲t̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The main functions implemented by the Printer Function
PRIP, are:
1. Formatting and printout
2. Document accounting
a) F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲P̲r̲i̲n̲t̲o̲u̲t̲
Some of the items queued for print contain binary
data which will have to be converted into a displayable
form before being printed.
The items do not contain all of the data to be
printed. The predefined part of it is contained
in the Print Format File and must be merged with
the variable part to form the complete text.
The formatting also includes placing of the text
so that a readable layout is obtained.
After the text has been formatted, it will be output
to the printer in blocks of upto 512 bytes.
b) D̲o̲c̲u̲m̲e̲n̲t̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
Document Accounting is to be carried out for the
following items:
- Messages
- Service Messages
- Reports
4.6.3.2.4 M̲C̲S̲F̲ ̲U̲s̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
a) In this section the functions to be performed by
VDU User Package (VUP) are outlined. The main task
of VUP is to implement the CROSSFOX MPF user function.
The CROSSFOX MPF user function and the related
requirements will be treated as a whole, i.e. the
two subfunctions Preparation and Reception constitute
the CROSSFOX MPF user functions, and access to
each must be granted by the supervisor.
b) As a short overview, of the services of VUP are
outlined below.
The user may access the preparation database, where
all messages under preparation are kept. The user
may insert/delete/edit items in the database.
The user may access the receive queue, which is
a queue of the precedence type into which the MPF
system inserts all messages destined to the terminal.
The user may inspect/remove/get a printed copy
of the queued elements. The operator may also
instruct the system to print all messages below
a certain security level on the printer immediately
on arrival to the queue.
The user may access the response queue, which is
a queue of the non-precedence type into which CROSSFOX
inserts responses to user issued requests with
long or unpredictable response times. The user
may inspect/remove/get a printed copy of the queued
elements.
The user may issue requests/commands to the system,
e.g. retrieve a message, delete a message.
4.6.3.3 S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲S̲A̲R̲)̲
SAR is an application package, performing storage and
retrieval of messages
4.6.3.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
The main functions performed by SAR are:
- storage of messages on-line
- on-line retrieval of messages
- off-line retrieval of messages
- dump of messages to off-line disk
SAR consists of four subpackages each performing one
of the above mentioned functions.
4.6.3.3.1.1 S̲t̲o̲r̲a̲g̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The storage of messages is performed by a STORE module,
the store subpackage.
Main functions performed by this module are:
- waiting for storage requests in the incoming storage
queue.
- identification of message and pick up of retrieval
key for temporary storage.
- emptying of temporary storage when either a certain
time interval has elapsed or a certain number of
storage requests has been received.
- appending temporary storage area to on-line catalogue.
- actual storage of message text by request to Message
Management System (MMS).
4.6.3.3.1.2 O̲n̲l̲i̲n̲e̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
The on-line retrieval sub-package handles the retrieval
of messages from the on-line disk. Retrieval requests
are received from the retrieval requests queue (RRQ)
and treated in an FIFO manner. The retrieval requests
are sorted according to TOC +DTG retrievals, TOC-window
retrievals and OFFLINE retrievals, and they are inserted
in corresponding lists.
4.6.3.3.1.3 O̲f̲f̲-̲l̲i̲n̲e̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
Off-line retrieval requests are handled in the same
manner as on-line retrievals. Mount requests for off-line
disk are delivered to supervisor's report printer.
If the off-line retrieval is of the DTG-retrieval type
and the result shows not found, the request remains
in the offline list if DTG is contained in the DTG
interval of the succeeding volume.
4.6.3.3.1.4 D̲u̲m̲p̲
Dump performs the transfer of messages and transactions
from on-line disk to the off-line disk.
A report to supervisor's report printer will indicate
that the dump has been performed.
4.6.3.3.2 R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲K̲e̲y̲s̲
A primary list of retrieval keys used by the supervisor
or message service position for retrieval of the previously
stored messages are given below.
The keys include security and access parameters used
for directing the message to the right operator with
the allowed classification level.
The primary key list is:
1) Internal serial number
2) Channel Identification
Transmission sequence number
Time of File (TOF)
3) Originating Station Routing Indicator
Time of File (TOF)
4) Action Addressee (TO)
Date Time Group (DTG)
5) Channel Identification
Time of File Window (TOF window)
The retrieval keys used during automatic retrieval
are:
Action Addressee (TO)
Date time Group (DTG),
which will be forwarded by the traffic handling package
(THP) when an automatic retrieval is required.
4.6.3.3.3 R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲C̲a̲t̲a̲l̲o̲g̲u̲e̲s̲
The following catalogue structure or file structure
is proposed:
- Internal Message Number (IMN)
- Time of File (TOF)
- Date Time Group (DTG)
- Main Catalogue
The DTG catalogue consists of 7, one day catalogue
where the day cataloguqe including the DTG is searched
first. If not found the next day's catalogue is searched
until a fit is found or until DTG is out of DTG catalogue
range.
When correspondance has been obtained in one of the
above mentioned three primary catalogues the corresponding
main entry is found for check of remaining parameters.
The primary catalogues contain pointers to the main
catalogue.
4.6.3.3.4 R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲R̲e̲s̲u̲l̲t̲
The result of a retrieval request will be the first
message found which fits the retrieval request keys.
If no message fits the request keys, a not found completion
report will be returned as the result of the retrieval.
4.6.3.4 L̲o̲g̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲L̲O̲G̲)̲
4.6.3.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲
The functions implemented by LOG are separated in two
groups:
1) Log collection functions
2) Log trace functions
4.6.3.4.1.1 L̲o̲g̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Log records, generated by the applications, are transferred
to the incoming log queue. The incoming log records
are read by the LOG application and processed as follows:
a) The log record buffer is read and stored in a log
CIF. (CROSSFOX Information File).
b) An acknowledgement is returned to the log record
sender.
c) Every 10 minutes, or on supervisor's request, the
present log CIF is closed and stored via SAR.
d) The closed log CIF is sent to the supervisory log
print queue for printout.
S̲t̲o̲r̲a̲g̲e̲ ̲o̲f̲ ̲l̲o̲g̲ ̲C̲I̲F̲'̲s̲
Every 10 minutes the presently used log CIF is stored
and catalogued via SAR. A new log CIF is requested
from MMS. If no log records were appended to the log
CIF, no action will be taken.
4.6.3.4.1.2 L̲o̲g̲ ̲T̲r̲a̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The stored log records may be retrieved with respect
to specific trace keys and sent to supervisor's position
via TEP. The following functions are implemented by
LOG when log records are retrieved:
a) The trace command is received from TEP.
b) The pertinent time interval is computed, and the
CIF-refs. are retrieved via SAR.
c) The wanted log records are traced and appended
to a trace CIF.
d) The trace CIF-ref is sent to TEP via a queue element
when the trace action is completed.
4.6.3.5 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲S̲T̲P̲)̲ ̲
This section describes the statistical functions under
normal operation.
The Statistics Package supports 4 functions outlined
in the package description:
- Statistics collection
- Statistics dump
- Statistics generation
- Statistics delivery
4.6.3.5.1 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
The statistics collection is performed by the STP collection
monitor procedure and statistics are stored in the
shared data area. The collection procedures include:
- Count increment
- Add a number to a value
- Boundary (minimum + maximum)
- Cumulative time periods (i.e. how many percent
on for a switch)
The table is defined by the Statistics Package in such
a way that the processing by STP is defined by the
table in conjunction with the parameters specified
by the calling application.
Fig. 4.6.3.5-1 STATISTICAL PACKAGE.
The request for statistics is made by supplying:
- Statistics group number
- Statistics sub-group number
- Statistics record number
- Statistics parameter
The group and number are verified against the requestor.
The events in the processing are (refer to fig. 4.6.3.5-1
for event numbers):
Application calls Statistics Package (STP) with a request
to generate statistics (1a). The STP collector checks
the request parameters by access to the Table in the
shared data and updates the shared area at addresses
specified in the Table (1b). During update and access
of the shared data area, exclusive access is granted
by requesting CSF. The STP collector returns to the
application (1c).
When different applications request statistics, its
collection specific parameters are supplied.
4.6.3.5.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲D̲u̲m̲p̲
The statistics package is activated every 6 minutes
to dump the collected data. The timing is controlled
by a request to the CROSSFOX MPF System Functions timer.
The dump processing is (Refer fig. 4.6.3.6-1 for event
numbers):
Invocation of the Statistics Package by CROSFOX MPF
System Functions (2a). Request to CROSFOX MPF System
Function for exclusive access to the shared data area
(2b). Dump the data area (2e) and (2d). Relinquish
the exclusive access (2f).
If a system switch-over or restart has taken place
the shared data area will be marked as invalid and
the dump will generate a dummy dump.
The dummy dump is a version of the shared data area
which does not contribute any information during generation
of the statistics.
4.6.3.5.3 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲
The statistics package generates statistics once per
hour for the last hour. The processing is (refer to
figure 4.6.3.6-1 for event numbers):
Invocation of generation part of statistics package
(3a). Calculate from the dumped statistics, statistics
for the last hour and output to statistics files (3c
and 3f).
Statistics are kept on an hourly basis for 24 hours,
on a daily basis for 1 day and on a weekly basis for
4 weeks.
4.6.3.5.4 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲
Statistics displays are printed via the terminal package.
STP delivers the statistics information to TEP. The
processing is (for event numbers, refer to fig. 4.6.3.6-1).
Invocation of delivering statistics (4a).
Read the appropriate statistics information (4b) and
copy it into 2 CIFs, as much as they can accomodate
(4c). Send CIFs to printer process (4d) and await reply
when next CIF shall be created and sent (c).
Request storage occupancy, from MMS (4f).
4.6.4 S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The support software includes all off-line software
required to support the operational system. The support
software will be provided by two different packages:
- Support Software Package (SSP),
which is independent on the actual use of CR80.
- Off Line Package (OLP),
For the generation and maintenance of Crossfox-specific
off-line data.
4.6.4.1 S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲S̲S̲P̲)̲
The Support Software Package is a common name for the
various units of general CR80-software that are independent
of the actual use of the CR80 (Crossfox-MPF), but used
for software development, test, and diagnostics as
well as for diagnostics of hardware.
The SSP software may be categorized as follows:
- S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
o Language Processors
o Text Processors
o Development and Test Tools
o Librarian
- S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲p̲o̲r̲t̲
o File Manipulation Programs
o Directory Maintenance
o High Level Operating System
o Disk Manipulation Programs
- D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Comprising test software for all hardware units.
4.6.4.1.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
4.6.4.1.1.1 L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲ ̲
Those that are relevant for Crossfox are the compilers
for
- SWELL, (Development language for CAMPS on-line
SW)
- PASCAL
- Assembler Language
4.6.4.1.1.2 T̲e̲x̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲
a) E̲d̲i̲t̲o̲r̲
This is an interactive line editor. A batch version
is also available.
b) G̲e̲n̲e̲r̲a̲l̲ ̲T̲e̲x̲t̲ ̲F̲o̲r̲m̲a̲t̲t̲e̲r̲
For margin justification, page headings, and underlining
of key words.
c) A̲ ̲p̲r̲o̲g̲r̲a̲m̲ ̲f̲o̲r̲ ̲m̲e̲r̲g̲i̲n̲g̲ ̲o̲f̲ ̲s̲o̲u̲r̲c̲e̲ ̲f̲i̲l̲e̲s̲.̲
4.6.4.1.1.3 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲T̲o̲o̲l̲s̲
a) L̲i̲n̲k̲e̲r̲
For generation of an object module from several
compiled modules.
b) D̲e̲b̲u̲g̲g̲e̲r̲s̲
Containing the language Debugger which operates
with symbolic names and the General Debugger which
operates on relative program addresses. Both facilitate:
Use of breakpoints, inspection and setting of current
values of variables, access to registers, creation
and removal of synchronization elements. The debuggers
may be operated interactively or by a test driver.
c) S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
To create a system load module from several program
modules.
4.6.4.1.1.4 L̲i̲b̲r̲a̲r̲i̲a̲n̲
The Librarian organizes all information pertinent to
system development to satisfy program development,
system generation, and documentation.
4.6.4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲p̲o̲r̲t̲
This covers
- File Manipulation Programs
- Directory Maintenance Programs
- High Level Operating System
- Disk Manipulation
4.6.4.1.2.1 F̲i̲l̲e̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
These programs include functions for:
- file copying
- file display
- file comparison
- file conversions (BIN/HEX)
4.6.4.1.2.2 D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
This is a suite of programs for inspecting and modifying
the contents of backing store file structures, i.e.:
- File creation, deletion, and renaming
- Entering of a file into a directory
- Listing of the contents of a directory or the attributes
of a file
- Changing the protection of a file
4.6.4.1.2.3 H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
The CR80 standard high level Terminal Operating System,
TOS, supports interactive terminal users in a program
development environment. A central part of this environment
is the hierachical, protected file-store system.
Normally, program development will be done on a site
which is in "Degraded Availability Mode" and where
the "off-line PU" plus peripherals are under the regime
of TOS.
4.6.4.1.2.4 D̲i̲s̲k̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
a) D̲i̲s̲k̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
To create a preformatted but "empty" structure,
e.g. on a virgin disk.
b) D̲i̲s̲k̲ ̲S̲a̲l̲v̲a̲t̲i̲o̲n̲
For a file structured volume the program is able
to check the readability and validity and to rebuild
the external file system data structure. It may
also list directory entries.
c) P̲r̲i̲n̲t̲ ̲Q̲u̲e̲u̲e̲ ̲R̲e̲c̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
To check, rectify, or initialize the print queue.
4.6.4.1.3 D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The Maintenance and Diagnostics (M&D) Package is a
collection of standard test programs which are used
to verify proper operation of the CR80 system and to
detect and isolate faults to replaceable modules.
The relevant programs of the off-line M&D software
package are briefly mentioned in the following:
* CPU test program
* CPU CACHE test program
* Memory MAP test comprising
- Memory MAP subtest
- DMA subtest (Memory to Memory XFRS)
- Interrupt subtest
- V24 Communication Port subtest
* RAM test program, comprising tests on all RAM modules,
namely:
- Bus interface
- RAM internal addressing circuitry
- RAM storage circuitry
* LTU tests (L̲ine T̲ermination U̲nit)
* Disk system test program, testing:
- Disk controller
- Disk controller adapter
- Disk drive
* Floppy Disk Test Program
4.6.4.2 O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲O̲L̲P̲)̲
The Off-Line Package is used for the generation and
maintenance for Crossfox-MPF specific data. The data
is created/updated off-line for subsequent incorporation
into the operational system.
The OLP consists of the following subpackages:
- T̲a̲b̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
For addressing tables as well as user and terminal
profiles.
- V̲D̲U̲ ̲F̲o̲r̲m̲a̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
For all formats required for the implementation
of Man-Machine interface.
- P̲r̲e̲d̲e̲f̲i̲n̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
To generate predefined messages directly from VDU,
input on a Message by Message basis.
- C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲T̲a̲b̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
Maintains all information relevant for generating
site specific software. It generates additionally
all input needed by the SSC package for initialization
of sites.
4.6.5 S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲s̲i̲d̲e̲r̲a̲t̲i̲o̲n̲s̲
As for similar CHRISTIAN ROVSING A/S projects, a main
aim in the design of Crossfox-MPF will be that of high
security.
Three major areas are:
- F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲L̲e̲v̲e̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲
To cover the security requirements regarding user
and message handling.
- I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
To minimize the probability of security violation
caused by errors in the system
- R̲a̲d̲i̲a̲t̲i̲o̲n̲
The general security objective is to assure that information
on a Crossfox-MPF site will neither be disclosed to
nor be modified by unauthorized individuals or external
systems, either intentionally or accidentally.
The CR80/DAMOS architecture is from the outset designed
with special regard to security. It employs centralized
mechanisms for addressing and access authorization
in a multilevel multicompartment system.
Further, hierachical levels of systems software and
application software are included. Each level contributes
in the appropriate way to a clean system design of
high security and integrity.
A list of security features is given in section 3.6.
4.7 S̲Y̲S̲T̲E̲M̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲
This section presents the evaluations of the proposed
MPF system in terms of performance. The system is fully
compliant with the IFB requirements (section 5.1.4)
for
- throughput
- storage
- timing
with the message traffic characteristics presented
in the IFB(section 5.1.4.1) as underlaying assumption.
Detailed information on the requirements has been given
in section 1.2 and will be repeated here in each subsection
together with the proof of compliance.
System characteristics and performance calculations
will be presented to the extent that sufficient evidence
is available for judgement of performance compliance.
In order to perform these calculations it has been
necessary in some cases to introduce assumptions concerning
message characteristics and the message flow: Such
assumptions are merely used in order to provide a rough
estimate for proof of system performance compliance;
deviations from these additional assumptions, which
are of conservative nature, are not expected to degrade
the performance appreciably and never to the extent
of non-compliance. Whenever additional assumptions
have been made this fact is made clear in the text.
4.7.1 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲F̲l̲o̲w̲ ̲
Refer to fig. 4.7.1-1.
The message traffic flow has been derived as follows:
- number of incoming messages equal to number of
outgoing is a direct consequence of the figures
from the IFB reflecting the fact that the MPF is
a relay facility.
- 50% ACP 127 formatted incoming messages which are
broadcasted, and 50% ACP126 formatted incoming
messages which are transmitted on TARE and TRC
is a conservative assumption giving the maximum
processing load for message analysis and conversion.
- 10% of incoming messages need service (garbled
etc.)this is a CHRISTIAN ROVSING A/S assumption.
3 of 4 supervisory positions are service positions.
- 20% of incoming message for local delivery is a
conservative CHRISTIAN ROVSING A/S assumption and
supported by the fact that 10% of all incoming
messages are service messages out of which a certain
part are directed to the supervisors attention.
- 10% of outgoing messages need routing assignment
is a CHRISTIAN ROVSING A/S assumption.
Fig. 4.7.1-1
- 20% of outgoing messages are locally prepared is
a conservative CHRISTIAN ROVSING A/S assumption
which is supported by the fact that 10% of all
messages are service messages out of which a certain
part is prepared at supervisory positions. This
is also the the maximum amount of messages which
may be prepared considering that message reception
will take place simultaneously.
- external channel capabilities are taken from the
IFB.
- character flows for the internal terminals are
calculated from the above flow figures assuming
maximum external character input rate and the following
assumptions plus derivations from the IFB:
- messages are presented in full with annotation
for message service, and returned in full (1500
char.)
- a guiding format is presented to the user for
message preparation and full message is returned
(400 char for supervisory positions, 1500 char.
for the MCSF).
- delivery of messages as received:
400 char. for supervisory positions and 1500
char for the MCSF.
- The outgoing character rate for external channels
has an upper limit given by the capacity; the ratio
between the actual number of outgoing messages
and the possible number of outgoing messages is
the maximum possible average number of multiple
transmissions per outgoing message. This number
is for the peak traffic flow found as the ratio
between the incoming character capacity and the
outgoing character capacity of external channels
and is 240/200 = 1.2.
- input character rate on the MC channel (from standby
system) is low and disregarded in these calculations.
- output rate to the MC channel (to standby system)
is assumed to be of the same size as the total
outgoing character rate for other external channels
(which reflects the message creation rate for the
system), i.e. 200 char./sec. minus 10% due to CTS
& ATOMAL messages which are deleted = 180 char/sec.
Fig. 4.7.1-1 presents the peak traffic flow in terms
of characters; the equivalent number of messages is
simply derived from the size of the average message.
1500 x 0.84 + 400 x 0.1 + 7000 x 0.04 = 1610 char.
where the distribution of operational, service, and
data messages corresponds to the figures from the IFB.
The p̲e̲a̲k̲ ̲n̲u̲m̲b̲e̲r̲ ̲o̲f̲ ̲i̲n̲c̲o̲m̲i̲n̲g̲ ̲a̲n̲d̲ ̲h̲e̲n̲c̲e̲ ̲o̲u̲t̲g̲o̲i̲n̲g̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲
̲f̲o̲r̲ ̲t̲h̲e̲ ̲p̲r̲e̲s̲e̲n̲t̲ ̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ is found as
…01…0.12 msg/sec. = 432 msg/hour-
According to the IFB, section 5.1.3(d) a 25% increase
in local (internal) and external communication lines
(terminals) combined with a 30% increase of message
traffic shall be possible without hardware or software
changes. A 30% increase will result in a p̲e̲a̲k̲ ̲n̲u̲m̲b̲e̲r̲
̲o̲f̲ ̲i̲n̲c̲o̲m̲i̲n̲g̲ ̲a̲n̲d̲ ̲h̲e̲n̲c̲e̲ ̲o̲u̲t̲g̲o̲i̲n̲g̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲e̲x̲p̲a̲n̲d̲e̲d̲
̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ of
0.16 msg/sec. = 562 msg/hour
Taking into account the maximum amount of multiple
transmissions (factor 1.2) the number of outgoing messages
for the expanded configuration is 674 msg/hour. It
is seen that the busy hour rate of 500 messages specified
in the IFB is included in these figures.
A peak (character) throughput rate of
600 char/sec incoming, and
800 char/sec. outgoing
has been specified in the IFB, section 5.1.4.2(g).
The sytem character throughput is discussed in section
4.7.2 and it is shown how the system also will accept
this peak rate which is well above the maximum possible
rate in a system with a 30% traffic expansion:
242 x 1.3 = 315 char/sec incoming, and
478 x 1.3 = 631 char/sec outgoing
Refer to fig. 4.7.1-1.
4.7.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
The expanded configuration flow, i.e. the configuration
corresponding to 30% traffic expansion and with continous
maximum character transfer rates is used for throughput
calculation. The corresponding traffic flow is explained
in section 4.7.1.
With the addition of one function-retrieval for rerun
of outgoing messages - the functions of the flow have
been analysed and the resource consumption in terms
of PU processing time and number of disk reads and
writes has been calculated.
The result is presented in the tables 4.7.2-1 to 9,
the last table containing the summation.
The following assumptions have been made in addition
to section 4.7.1:
- there is one edit session per prepared message
- retrieval is based on request for rerun and corresponds
to 5% of the transmitted messages (including the
effect of multiple transmissions). Worst case
retrieval (DTG and TO PLA) is assumed.
- 10% additional resource needs have been added to
message analysis and conversion to cover reprocessing
after message service (worst case corresponding
to 10% of messages going to message service)
The PU time needs correspond to instruction times without
CACHE HITS and is thus a conservative estimate. Since
the direct CPU time for an application process is known
to be small from experience with appliations of this
kind, a fairly accurate estimate is possible based
on number of system calls (I/O access, disk access,
table access etc.)
Any access to disk requires as well the time in the
File Management System as well as the disk access time
itself.
The time for execution in the File Management system
is about 30 ms.
The disk access time is given as
t…0f…access…0e… = t…0f…HANDLER…0e… + t…0f…channel…0e…+ t…0f…rot…0e…
+ t…0f…SEEK…0e… + t…0f…TRANSFER
t…0f…HANDLER…0e… = Disk handler CPU time = 6 ms.
t…0f…CHANNEL…0e… = transfer time to/from disk controller
of data and instructions, time is negligible
t…0f…ROT…0e… = rotational delay of disk = 8.3 ms. average
t…0f…SEEK…0e… = time for locating the proper track;
the seek time is calculated in fig.
4.7.2-1. As a worst case data have
been assumed located randomly on the
whole disk; on this point improvements
may be gained: Data which are often
required, such as tables, may be constrained
to smaller areas. t…0f…SEEK…0e… = 34.7 ms.
…0f…TRANSFER…0e… = time for transfer of data to/from disk
from/to the controller; time is approx
1 ms.
Consequently
t…0f…access …0e… = 50 ms.
The access time thus calculated is the time for executing
a READ to any of the two mirrored disks. since in
average any of the two disks may be used, half of this
time shall be used for load calculations.
Disk WRITE accesses are executed to both disks and
are in both cases followed by a READ for check. The
READ after WRITE will experience the average rotational
delay plus some validation time in the PU: A total
of 13 ms is added per WRITE access to each disk: hence
the resulting access time for disk writes to be used
for load calculations is
t…0f…WRITE…0e… = 63 ms.
The resource consumption figures have been estimated
on basis of the figures for a similar project (CAMPS).
In order to include the effect to the system load of
the support functions - log, statistics, storage catalog
creation, status preparation, report generation, security
functions - experience factors shall be used which
have been taken from the CAMPS project. The factors
are
PU 1.26
DISK READS 1.11
DISK WRITES 1.43
The final result thus obtained is then according to
table 4.7.2-9.
PU (2 CPUs) 63%
CPU load 31.5%
DISK load 55%
The throughput is thus secured in the absolute worst
case traffic load situation.
By having chosen a configuration with 2 CPUs the CPU
load is kept below 50%, which is considered a critical
value.
Finally, we will consider the peak character rate specified
in the IFB to last for up to 5 min. in any one hour:
600 char./sec. incoming traffic
800 char./sec. outgoing traffic
Comparing these character rates to the expanded configuration
rates used for the throughput calculations above, the
following factors of increase are found
incoming traffic: 600/315 = 1.91
outgoing traffic: 800/631 = 1.29
These character rates are only obtained with the introduction
of considerably more external channels and local terminals
than the number corresponding to the expanded configuration
.
The loads corresponding to the high character rates
are
Each CPU 42%
Disk 75%
It has here been assumed that all S/W modules, except
the Incoming Message Reception which works at the higher
input rate, work at the outgoing traffic rate.
Concerning the connectivity of internal terminals and
external channels a discussion is presented in section
1.2.1.
M̲S̲G̲,̲ ̲R̲E̲C̲E̲P̲T̲I̲O̲N̲
NUMBER OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Read from Channel 60
Create item 16
Prelim. Analysis 30
Write to disk 140 4
Trans.Acknowledgement 25
Checkpoint to disk 3̲5̲ 1̲
306 5
Unload to off line disk ̲6̲7̲ ̲ ̲2̲ ̲ ̲3̲ ̲
373 2 8
MSG. TRANSMISSION (1.2 transmissions per msg.)
NUMBER OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Read item 144 4.8
Table access for serial
no. plus direct CPU
time 36
Transmission to channel 72
Receive acknowledgement 25
Checkpoint to disk 42 1.2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
3̲1̲9̲ 4̲.̲8̲ 1̲.̲2̲
̲ ̲
T̲R̲A̲N̲S̲M̲I̲S̲S̲I̲O̲N̲ ̲T̲O̲ ̲S̲T̲A̲N̲D̲B̲Y̲ ̲S̲Y̲S̲T̲E̲M̲ ̲(̲V̲I̲A̲ ̲M̲C̲)̲
Approximately as for MSG TRANSMISSION divided by the
transmission multiplication factor
Table 4.7.2-1
M̲S̲G̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲,̲ ̲A̲C̲P̲1̲2̲6̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Read item from disk 30 1
Analysi 100
extract PLAs for 0.1
AIG's/AG's 20 0.1
Write item to disk 33 1
Checkpoint to disk ̲3̲5̲ 1̲ ̲
2̲1̲8̲ 1̲.̲1̲ 2̲ ̲
M̲S̲G̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲,̲ ̲A̲C̲P̲1̲2̲7̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲ ̲
̲
Read Item from disk 30 1
Analysis 40
Disk table access for
FROM PLA; extract
PLAs for 0.1 AIG/AGs 71 1.1
Write item to disk 33 1
Checkpoint to disk 3̲5̲ ̲ ̲ ̲ 1̲ ̲
̲ ̲
2̲0̲9̲ ̲ 2̲.̲1̲ 2̲ ̲
̲ ̲
Table 4.7.2-2
L̲O̲C̲A̲L̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲;̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲M̲S̲G̲
NO. OF DISK
̲ ̲ ̲ ̲ ̲I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Read item 150 5
Table access for
terminal designator
plus direct CPU time 60
Transfer as is to
printer/VDU 100
Checkpoint ̲3̲5̲ ̲ ̲ 1̲ ̲
̲
3̲4̲5̲ 5̲ ̲ 1̲ ̲
̲
L̲O̲C̲A̲L̲ ̲D̲I̲S̲T̲R̲I̲B̲I̲U̲T̲I̲O̲N̲,̲ ̲S̲E̲R̲V̲I̲C̲E̲ ̲M̲S̲G̲
NO. OF DISK
I̲T̲E̲M̲ ̲ P̲U̲(̲M̲S̲)̲ R̲ W̲ ̲
̲
Read item 30 1
Table access for
terminal designator
plus direct CPU time 60
transfer as is to
printer/VDU 45
checkpoint ̲3̲5̲ ̲ ̲ 1̲ ̲
̲
1̲7̲0̲ 1̲ ̲ 1̲ ̲
̲
Table 4.7.2-3
M̲S̲G̲ ̲S̲E̲R̲V̲I̲C̲E̲,̲ ̲I̲N̲C̲.̲ ̲M̲S̲G̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲ ̲
̲
Read item from disk 120 4
Presentation of item
with annotation and
input of corrected
msg. 260 1
Write to disc 1̲4̲0̲ ̲ ̲ 4̲ ̲
̲
5̲2̲0̲ 5̲ ̲ 4̲ ̲
M̲S̲G̲ ̲S̲E̲R̲V̲I̲C̲E̲,̲ ̲O̲U̲T̲G̲.̲ ̲M̲S̲G̲.̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲.̲)̲ R̲ W̲ ̲
Read routing list from
disc 33 1
Presentation of list
and input of correction 220 1
write to disc 3̲3̲ 1̲
2̲8̲6̲ 2̲ 1̲ ̲
Table 4.7.2-4
M̲S̲G̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲,̲ ̲A̲C̲P̲1̲2̲6̲ ̲t̲o̲ ̲A̲C̲P̲1̲2̲7̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲ ̲
̲
Read item 30 1
Conversion 75
Table access for RIs 408 8
Write item to disc 33 1
Checkpoint to disc ̲3̲5̲ 1̲ ̲
581 9 2
Unload to off-line
disk ̲6̲7̲ 2̲ 3̲
648 11 5
M̲S̲G̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲,̲ ̲A̲C̲P̲ ̲1̲2̲7̲ ̲t̲o̲ ̲A̲C̲P̲ ̲1̲2̲7̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲) R̲ W̲
Read item 30 1
Conversion 30
Table access for PLAs 408 8
Write item to disk 33 1
Checkpoint to disk 35 1
9 2
Unload to off-line
disk ̲6̲7̲ 2̲ ̲ 3̲ ̲
603 11 5
Table 4.7.2-5
P̲R̲E̲P̲ ̲O̲F̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲M̲S̲G̲.̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Create item 20
Format presentation
and transfer of input 318 2
Validation 200
Table accesses 1420 30
Write to disk 225 5
Checkpoint to disk 35 1
Make item inactive ̲ ̲3̲1̲ ̲1̲ ̲ 1̲ ̲
2249 33 7
P̲R̲E̲P̲ ̲O̲F̲ ̲S̲E̲R̲V̲I̲C̲E̲ ̲M̲S̲G̲ ̲(̲P̲L̲A̲I̲N̲D̲R̲E̲S̲S̲)
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Create item 20
Format presentation
and transfer of input 318 2
Validation 200
Table accesses 1420 30
Write to disk 90 2
Checkpoint to disk 35 1
Make item inactive 31
2114 31 3
Table 4.7.2-6
E̲D̲I̲T̲I̲N̲G̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲M̲S̲G̲
As preparation plus 5 disk reads and making item active
as replacement for making it inactive; hence
NO OF DISK
CPU(ms) R W
2459 38 7
E̲D̲I̲T̲I̲N̲G̲ ̲S̲E̲R̲V̲I̲C̲E̲ ̲M̲S̲G̲
As above but only 3 disk reads; hence
NO OF DISK
PU(ms) R W
2120 34 3
R̲E̲L̲E̲A̲S̲E̲ ̲O̲F̲ ̲M̲S̲G̲
NO. OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Create item 150 5
Presentation and input
of release decision 216 1
Table accesses and
validation 80
Checkpoint to disk ̲ ̲3̲5̲ ̲ ̲ 1̲ ̲
481 6 1
Table 4.7.2-7
R̲E̲T̲R̲I̲E̲V̲A̲L̲,̲ ̲D̲T̲G̲ ̲&̲ ̲(̲T̲O̲)̲ ̲P̲L̲A̲
This is the worst case single item retrieval. It is
assumed that the DTG directory is sectioned into 24
hours TOF sections with indication of oldest and youngest
DTGs; hence it may be assumed that the DTG related
items may be found by searching one 24 hour section
for finding f̲i̲r̲s̲t̲ retrievable item.
NO OF DISK
I̲T̲E̲M̲ P̲U̲(̲m̲s̲)̲ R̲ W̲
Retrieval request valid-
ation and responses 80
Read DTG Directory of
24 hours = 16Kbytes 980 16
Read record for DTG
found 120 2
Create item for display ̲ ̲3̲2̲ ̲ ̲
1212 18
Off-line retrieval (not
incl. volume mounting
VOL opening 100 5
DTG directory search,
on-line in vain ̲6̲0̲0̲ ̲ ̲ ̲
Total off-line 1912 23
The retrieved item is now ready for display or transmission.
Table 4.7.2-8
T̲R̲A̲F̲F̲I̲C̲ ̲L̲O̲A̲D̲,̲ ̲E̲X̲P̲A̲N̲D̲E̲D̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
PU NO OF DISK
NO SEC R
W
Msg Reception 562 210 1124 4496
Msg Analysis, ACP 126 307 67 339
618
Msg Analysis, ACP 127 309 64 649
618
Local distribution
Operat. msg 56 19 280
56
Service msg 56 10 56
56
Msg Service inc 56 29 280
224
Msg Service outg 56 16 112
56
Msg Conversion, ACP 126 618 400 6800 3091
Msg Conversion, ACP 127 618 373 6798 3091
Msg transmission 562 179 2698
674
MC transmission 562 149 2248
562
Msg prep. + 1 edit
Operational msg 14 65 994
196
Service msg 42 178 2772
252
Retrieval for retransmit
On-line 34 41 612
RESOURCES PER HOUR 1800 25762 13990
INCLUDING OVERHEAD 2268 28596 20005
LOAD (2 CPUs) 0.63 0.55
Table 4.7.2-9
her inds`ttes tegning
4.7.3 S̲t̲o̲r̲a̲g̲e̲
The tables 4.7.3-1 and -2 list all the requirements
for on-line storage.
The Traffic check list tables of the IFB are not mentioned
specifically: The information necessary for generating
these lists is contained in the retrieval catalogs
as primary (TOF) and secondary keys.
It is seen that supervisory data (log, statistics,
and also all reports if so wanted) may be kept for
the same 7 days as the messages without violating the
storage limit of 66.2 MBytes formatted disk storage
of a 80MBytes SMD disk.
However, IFB section 5.1.3 (d) calls for 30% traffic
expansion cabability without hardware changes. Consequently,
in order to comply with minimum on-line storage time
of 7 days of the IFB, a 150 MBytes SMD disk has been
proposed.
Refer to the discussion in section 1.2.2.
S̲T̲O̲R̲A̲G̲E̲ ̲O̲N̲ ̲D̲I̲S̲K̲
I̲T̲E̲M̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲M̲B̲Y̲T̲E̲S̲
A̲.̲ ̲T̲E̲M̲P̲O̲R̲A̲R̲Y̲ ̲S̲T̲O̲R̲A̲G̲E̲
20 msg under preparation 0.06
Checkpointing for msg under processing 0.1
Workspace and others 1.0
B̲.̲ ̲I̲N̲T̲E̲R̲M̲E̲D̲I̲A̲T̲E̲ ̲S̲T̲O̲R̲A̲G̲E̲
Tables 0.2
Reports not printed 0.01
48 Hours Status of Prep. Msg. 0.15
7 days of Log 1.5
7 days of Statistic 0.26
Catalog for retrieval 2.8
I̲N̲C̲.̲ ̲M̲S̲G̲
7x0.86x2000 Oper. Msg. (4 sectors/msg)* 24.7
7x0.1x2000 Serv. Msg. (1 sector/msg)* 0.72
7x0.04x2000 Data Msg. (14 sectors/msg)* 4.01
10% garbled msg -10% CTS & ATOMAL = 0
O̲U̲T̲G̲.̲ ̲M̲S̲G̲
As for INC. -10% CTS & ATOMAL 26.49
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
62.0
* 1 sector = 512 bytes
Table 4.7.3-1
S̲T̲O̲R̲A̲G̲E̲ ̲O̲F̲ ̲T̲A̲B̲L̲E̲S̲
I̲T̲E̲M̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲K̲B̲Y̲T̲E̲S̲
PLA&RI (1100 PLAs) 125
AIG/AG (10) 6
Channel Designater Tables
(a̲s̲s̲u̲m̲e̲d̲ 1100 RIs) 18
Terminal Designator 13
Terminal Profile 1
User Profile 3
Channel Profile 2.5
Command Tables 20
ACP 127/ACP 126 Parameters 5
System Parameters 3
Configuration Parameters 12
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
208
Table 4.7.3-2
4.7.4 T̲i̲m̲i̲n̲g̲
Timing requirements have been stated in the IFB, Section
5.1.4.5. The requirements may be grouped in three
categories.
1. Cross-office handling time, COHT. The COHT shall
apply from the receipt of EOM until the message
is converted for transmission. No service action
is assumed. (The COHT may also indicate delivery
to local terminals. Since the processing requirements
here are less, this case has been ignored in these
considerations).
Four requirements have been specified:
- General message: 10 sec. 99% of cases
- General message, FLASH: 5 sec. 99% of cases
- General message: 20 sec. maximum
- ACP 126 message: 5 sec. maximum
2. Interactive processes at local terminals:
- General Commands: Validation response within
1 sec for 90% of cases.
- Supervisor Commands: Validation response within
1 sec. for 99% of cases, maximum 2 sec.
3. Retrieval times from initiation of retrieval (request)
and until the message is available for transmission
or display:
- on-line: maximum 10 sec.
- off-line: maximum 10 minutes (not including
time for volume mounting).
For a proper assessment of the system performance based
on PU and disk access times presented in section 4.7.2
the following aspects will be taken into consideration:
- Cache hits will improve the PU speed. This advantage
is not compensated by the queuing for the common
Processor Bus in case of non-hits.
- According to the results of section 4.7.2 there
is a medium load on the system even with the expanded
peak traffic rate. With this traffic rate a constant
stream of information is arriving to the system
and, due to the time slice processing of the PU,
the only variation in arrival of requests for processing
at the service positions is due to variations in
time slice usage and disk access time.
Furthermore, the PU has two multiserving CPUs and
the disk has multiserving for reads. In conclusion,
queuing effects will be small, even with the peak
expanded traffic load of section 4.7.2.
Table 4.7.4-1 presents a calculation of the worst case
requirement from category one of timing requirements:
The transfer of an incoming ACP 126 message to output.
The worst case of a maximum length message with the
maximum amount of addresses has been considered.
The category 2 requirements will be considered as follows:
Since transfer times to and from the VDUs are governed
by the character transfer rates of the VDUs and the
I/O handling and since a command may be validated in
a few disk table accesses, the result presented in
table 4.7.4-2 shall apply. The VDU transfer rate is
4800 b/s, i.e. 1 character in 0.2 ms.
Table 4.7.4-3 presents the calculation of category
3-retrieval-times.
C̲O̲H̲T̲ ̲O̲F̲ ̲I̲N̲C̲ ̲M̲S̲G̲ ̲A̲C̲P̲ ̲1̲2̲6̲,̲ ̲M̲A̲X̲ ̲S̲I̲Z̲E̲
NO. OF DISK
ITEM PU(ms) R W
Msg Reception (transfer
from channel and unload*
not included), last part 120 1
Msg Analysis, ACP 126 358 4 2
Msg Conversion (no unload)* 1448 26 2
Msg Transmission, read of
first characters only
plus serial no creation ̲ ̲5̲0̲ ̲ ̲ ̲ ̲ ̲ ̲
1976 30 5
Total = 4106 ms = 1976 + 30x50 + 5x2x63
*Unload is a background activity.
Max Size Msg: 12000 char., 3AIGs plus 150 PLAs resulting
in 250 RIs.
In Analysis and Conversion the msg is read from and
written to disk in 1 access. There are 3 accesses to
table during Analysis, and there are 25 (all PLAs)
during Conversion.
Refer to the appropriate tables in section 4.7.2 for
analysis and conversion.
Table 4.7.4-1
C̲O̲M̲M̲A̲N̲D̲ ̲V̲A̲L̲I̲D̲A̲T̲I̲O̲N̲ ̲A̲T̲ ̲V̲D̲U̲s̲
Transfer of entry key to system (10 ch) 22
ms
I/O system polls…0e…x)…0f… VDU for cmd (50 ch cmd) 52
ms
Validation of cmd: 2 disk table accesses 200
ms
Transfer of result (20 ch) 24
ms
̲ ̲ ̲
̲ ̲ ̲
2̲9̲8̲
̲m̲s̲
x)…0f…IO requests data from VDU plus transfer of data to
PU.
Table 4.7.4-2
R̲E̲T̲R̲I̲E̲V̲A̲L̲ ̲O̲F̲ ̲M̲S̲G̲,̲ ̲D̲T̲G̲ ̲&̲ ̲T̲O̲ ̲P̲L̲A̲
ON-LINE: 1212 + 18 x 49 = 2074 ms
OFF-LINE: 1912 + 23 x 49 = 3039 ms
Refer to table 4.7.2-8 for CPU time and number of disk
reads.
Table 4.7.4-3
