top - download
⟦cc59c96ae⟧ Wang Wps File
Length: 73150 (0x11dbe)
Types: Wang Wps File
Notes: CECOM
Names: »1612A «
Derivation
└─⟦121503e5a⟧ Bits:30006255 8" Wang WCS floppy, CR 0116A
└─ ⟦this⟧ »1612A «
WangText
…19……0a……19……0d……19……0e……19… …18……08……18……09……18……0e……18… …17……0a……17……00……17……07……16……0d……16…
…15……09……15……0f……15……01……15……02……15……07……14……09……14……0a……14……0f……14……06……13……0c……13…
…12……09……12……0d……12… …11……09……11……0a……11……01……10……09……10……0e……10……0f……10……06……0f……0c……0f… …0e……0b……0e……0e……0e……0f……0e……00……0e……01……0e……02……0e…
"Use or disclosure of quotation data is subject to the
restriction on the title page of this Proposal/Quotation."
PART II TECHNICAL PROPOSAL #
4.2.3.3 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The addressing mechanism of the CR80 limits the address
space seen by a process at any one time to a window
of 2 x 64K words. Due to the virtual memory concept
of DAMOS a process may, however, change the "position"
of the window, thus leading to a practically unlimited
addressing capability.
The finest granularity of the virtual memory known
to a process is a segment. Segments can be created
and deleted. They have unique identifiers and may
have different sizes. A process which has created
a segment may allow others to share the segment by
explicitly identifying them and stating their access
rights to the segment.
The Page Manager implements virtual memory. The actual
space allocated in a Processing Unit to a process may
be only a few segments, while the logical address space
is the full 2 x 64k words. Whenever addressing of
a segment, that is not in physical memory, is attempted,
the Page Manager will bring in the addressed segment.
4.2.3.4 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Synchronization of processes and communication between
them is supported in DAMOS by objects called Synchronization
Elements (synch elements) which are referred to by
symbolic names and may thus be known by processes system-wide.
In DAMOS a process cannot "send" a block of data directly
to another process identified by name. The exchange
must be done using a synch element.
4.2.3.5 C̲P̲U̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The CPUs in a processing unit may be pooled and a given
process is allocated processing power from one such
pool. In this way CPUs can be dedicated processes.
4.2.3.6 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲U̲n̲i̲t̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The DAMOS Kernel provides facilities for managing the
logical connections between the individual Processing
Units attached to a Supra Bus.
PUs may be connected logically into groups. The number
of PUs in a group may vary from 1 to 16. Two groups
may be merged, the result being a new PU-group.
Objects are identified by symbolic names having either
local or global scope. They are accessible from all
PUs in the group where they reside.
PU Management provides functions for inclusion of a
PU in a PU-group.
A logical connection between two PUs is not established
until both have received an include request from the
opposite. When trying to connect two PU-groups, conflicts
between the use of global names may arise. Therefore,
a connection is only established if the scope of all
names can be maintained.
The PU Management is designed to allow graceful degradation
when purposely closing a PU or isolating a faulty PU.
It is possible from a PU to force a member out of
its common group. All PUs in the group are informed
to break their logical connection to the designated
PU. As a consequence all global objects residing in
the isolated PU are thereafter unknown to the group.
If not faulty, the isolated PU continues executing
its local processes and is ready to receive new include
requests.
4.2.3.7 B̲A̲S̲I̲C̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲
The Basic Transport Service (BTS) offers DAMOS processes
and device handlers the possibility to communicate
with other remote or local processes and device handlers.
Processes and device handlers - in the following called
Service Users (SU) - may be addressed indirectly via
ports.
A service user can dynamically be tied to a port.
When a service user wants to communicate with another
service user, the former service user requests a connection
to be established between (one of) his own port(s)
and a port to which the remote service user is tied.
Once such a connection has been established, the two
service users may exchange data and control information
across the connection.
The figure overleaf depicts the possible connections
within a multiple PU node.
(skema med tekst "Gateway process, not part of BTS)
4.2.3.7.1 S̲e̲r̲v̲i̲c̲e̲ ̲T̲y̲p̲e̲s̲
The BTS offers two different types of service:
- stream service and
- message service
In the first type of service data flows as a logically
continuous stream from one SU to the other. The blocking
of data into buffers performed by the transmitting
SU is not seen by the receiving SU.
In the second type of service the buffers are treated
as semantic entities and transmitted as such. I.e.,
a homomorph correspondance between transmit and receive
buffers is enforced.
4.2.4 D̲A̲M̲O̲S̲ ̲I̲n̲p̲u̲t̲/̲O̲u̲t̲p̲u̲t̲
DAMOS supports input/output (I/O) from user programs
at different levels.
At the lowest level user programs can interact with
device handlers directly and transfer blocks of data
by means of the Basic Transport Service module. This
interface is illustrated in the figure on next page.
Device control is exercised via the Device Manager
functions. Data is transfered between the user process
and the device handler using a port in the user process
and a port in the device handler.
At a higher level DAMOS offers a more structured I/O
facility under the DAMOS I/O System (IOS).
The IOS provides a uniform, device independent interface
for user processes to
- disk files
- magnetic tape files
- interactive terminals
- communication lines
- line printers
The IOS is a set of standard interface procedures through
which a user communicates with a class of DAMOS service
processes known as General File Management Systems.
General File Management Systems include:
- the File Management System which implements disk
files
- the Magnetic Tape File Management System for magnetic
tape files
- the Terminal Management System for communication
lines, interactive terminals and printers.
The General File Management Systems provide functions
which are classified as:
- device handling
- user handling
- file handling
- file access
The common file access functions provided by the IOS
are readbytes for input and appendbyte and modifybytes
for output.
Skema under afsnit 4.2.5 DAMOS Input/Output.
These basic functions are used for transfer of blocks
of data.
On top of these functions the IOS provides a stream
I/O facility where the IOS handles the blocking and
buffering of data.
4.2.4.1 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
The File Management System (FMS) is responsible for
storing, maintaining, and retrieving information on
secondary storage devices (disks).
The number and kind of devices attached to the FMS
is dynamically reconfigurable.
The following subjects are handled:
- devices and volumes
…02…- directories
- files
- users
- integrity
- access methods
4.2.4.1.1 D̲e̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲V̲o̲l̲u̲m̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The file system may be given commands concerning:
- Management of peripheral devices.
Devices may be assigned to and deassigned from
the file system dynamically. Instances of device
handlers are at the same time created or deleted.
- Management of volumes.
Volumes may be mounted on and dismounted from specific
devices.
4.2.4.1.2 D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲
The file system uses directories to implement symbolic
naming of files. If a file has been entered into a
directory under a name specified by the user, it is
possible to locate and use it later on. Temporary
files does not need to be named. A file may be entered
into several directories, perhaps under different names.
Since a directory is also considered a file, it can
itself be given a name and entered into another directory.
This process may continue to any depth, thus enabling
a hierarchical structure of file names.
4.2.4.1.3 F̲i̲l̲e̲s̲
4.2.4.1.3.1 F̲i̲l̲e̲ ̲T̲y̲p̲e̲s̲
The file system supports two different organizations
of files on disk. Al contiguous file consists of a
sequence of consecutive sectors on the disk. The size
of a contiguous file is fixed at the time the file
is created and cannot be extended later on. A random
file consists of a chain of indices giving the addresses
of areas scattered on the volume. Each area consists
of a number of consecutive sectors. The number of
sectors per area is determined at creation time, whereas
the number of areas may increase during the lifetime
of the file.
4.2.4.1.3.2 F̲i̲l̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The commands given to the file system concerning files
may be grouped as:
- Creation and removal of files.
A user may request that a file is created with
a given set of attributes and put on a named volume.
- Naming of files in directories.
A file may be entered into a directory under a
symbolic name. Using that name it is possible
to locate the file later on. The file may also
be renamed or removed from the directory again.
- Change of access rights for a specfic user group
(or the public) vis a vis a file. The right to
change the access rights is itself delegatable.
4.2.4.1.4 U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The file management system may be given commands concerning:
- Creation and Removal of users (processes)
4.2.4.1.5 D̲i̲s̲k̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
4.2.4.1.5.1 S̲e̲c̲u̲r̲i̲t̲y̲
The protection of data entrusted to the file management
system is handled by two mechanisms:
The first mechanism for access control is based on
the use of Access Control Lists (ACL). There is an
ACL connected to each file. The ACL is a table which
describes the access rights of each individual user
group (one being the public) to the corresponding file.
Whenever a user tries to access a file, the ACL is
used to verify that he is indeed allowed to perform
this access.
The second mechanism for access control is based on
a security classification system. Each user and each
file is assigned a classification. The user classification
is recorded in the user control block and the file
classification is recorded on the volume. An access
to a file is only allowed if the classification levels
of the user and the file match to each other.
4.2.4.1.5.2 R̲e̲d̲u̲n̲d̲a̲n̲t̲ ̲D̲i̲s̲k̲s̲
The FMS allows use of redundant disk packs, which are
updated concurrently to assure that data will not be
lost in case of a hard error on one disk.
The FMS allows exclusion of one of the two identical
volumes, while normal service goes on on the other
one. After repair it is possible to bring up one volume
to the state of the running volume, while normal service
continues (perhaps with degraded performance).
The bringing up is done by marking a raw copy of the
good disk to that which should be brought up. While
the copying takes place all read operations are directed
to both disks.
4.2.4.1.5.3 B̲a̲d̲ ̲S̲e̲c̲t̲o̲r̲s̲
The FMS is able to use a disk pack with bad sectors,
unless it is sector 0.
The bad sectors are handled by keeping a translation
table on each volume from each bad sector to an alternative
sector.
While using redundant disks the translation tables
of the two disks must be kept identical to assure that
all disk addresses can be interpreted in the same way.
If bad sectors are detected while bringing up a disk,
they are marked as such on both disks and both translation
tables are updated accordingly.
4.2.4.1.6 A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
The file management system implements two access methods
to files:
4.2.4.1.6.1 U̲n̲s̲t̲r̲u̲c̲t̲u̲r̲e̲d̲ ̲A̲c̲c̲e̲s̲s̲
For transfer purposes a file is considered simply as
a string of bytes. It is, therefore, a byte string
which is transferred between a file and a user buffer.
The user can directly access any byte string in a file.
The commands which are implemented by this access methods
are:
READBYTES - Read a specified byte string
MODIFYBYTES - Change a specified byte string
APPENDBYTES - Append a byte string to the end of
the file.
4.2.4.1.6.2 I̲n̲d̲e̲x̲e̲d̲ ̲S̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲
CRAM is a multi-level-index indexed sequential file
access method. It features random or sequential (forward
or reverse) access to records of 0 to n bytes, n depending
on the selected block size, based on keys of 0-126
bytes. The collating sequence is using the binary value
of the bytes so e.g. character strings are sorted alphabetically.
CRAM is working on normal contiguous FMS files which
are initialized for CRAM use by means of a special
CRAM operation.
The CRAM updating philosophy is based on the execution
of a batch of related updatings, which all together
forms a consistent status change of the CRAM file,
being physically updated as a single update by means
of a LOCK operation. That is, after such a batch of
updates, all these updated may either be forgotten
(by means of the FORGET operation) or locked (by means
of the LOCK OPERATION). Both operations are performed
without critical regions, i.e. without periods of CRAM
data base inconsistency.
For convenience, CRAM supports subdivision of the CRAM
file in up to 255 subfiles, each identified by a subfile
identifier of 0-126 byte (as a key).
CRAM keeps track of the different versions of the CRAM
data base by means of a 32 bit version number, which
is incremented every time CRAMNEWLOCK (the locking
operation) is called. This version number can only
be changed by CRAMNEWLOCK (and CRAMINIT), but if the
user intends to use it for some sort of unique update
version stamping, it is delivered by the operations
CRAMNEWOPEN, CRAMNEWLOCK, CRAMFORGET and CRAMNEWVERSION.
4.2.4.2 M̲a̲g̲n̲e̲t̲i̲c̲ ̲T̲a̲p̲e̲ ̲F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
The Magnetic Tape File Management System (MTFMS) is
responsible for storing and retrieving information
on magnetic tapes. It is able to handle one magnetic
tape controller with a maximum of 8 tape transports
in daisy-chain. The driver is logically split into
3 parts:
- I/O-SYSTEM interface
- Main Processing
- Magnetic tape controller interface
Commands for the MTFMS are received by the I/O-System
interface while the controller interface implements
a number of (low level) commands for handling a tape
transport.
Symbolic volume names and file names are implemented
through use of label records which comply with the
ISO 1001 standard.
The functions of the file system can be separated into
four groups:
- Device functions
- Volume functions
- File functions
- Record functions
4.2.4.2.1 D̲e̲v̲i̲c̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
The following functions are defined:
- Assign a given name to a given unit of the
controller.
- Deassign a given device.
4.2.4.2.2 V̲o̲l̲u̲m̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
- Initiate the tape on a given device assigning a
name to it by writing a volume label.
- Mount a given volume on a given device.
- Dismount a given volume.
- Rewind a given volume.
4.2.4.2.3 F̲i̲l̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
- Create a file on a given volume. The following
information must be supplied by the caller and
will be written onto the tape in a file header
label records:
- File name
- Fixed/variable length record specification
- Record size.
The file is opened for output and the given volume
is reserved for the caller.
- Find a file with a given name on a given volume.
The file is opened for input and the given volume
is reserved.
- Skip a given number of files (backwards or forwards)
on a given volume. The file at the resulting tape
position is opened for input and the volume is
reserved.
- Get information about the currently open file on
a given volume. Information like file sequence
number, record size and type (fixed/variable length)
can be retrieved.
- Close currently open file on a given volume. Volume
reservation is released.
4.2.4.2.4 R̲e̲c̲o̲r̲d̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
- Skip a given number of records (forwards or backwards)
in a given file.
- Read a record in a given file.
- Write a record in a given file. The MTFMS performs
recovery from writing errors by
- backspacing over the record in error
- erasing a fixed length of about 3.7 inches (thus
increasing the record gap).
- attempting the writing once more.
This procedure will be repeated maximally 10 times.
4.2.4.3 T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲
The TMS is a service process which manages devices
characterized by serial blockwise access. Examples
of such devices are:
- interactive terminals (screen or hardcopy)
- data communication equipment (modems)
- line printers
- card readers
In the following, the phrase "terminal" is used as
a common term for any device of this category.
Terminals may be attached to LTUs, LTUXs (via TDX)
and parallel interfaces.
The TMS performs the following main functions:
- terminal related security validation
- access control for terminals
- collecting of statistical information
- management of terminals
- transfer of I/O data between terminal device
handlers and user processes.
The following subsections define:
- transfer of I/O data
- user handling
- hardware categories
4.2.4.3.1 T̲r̲a̲n̲s̲f̲e̲r̲ ̲o̲f̲ ̲I̲/̲O̲ ̲D̲a̲t̲a̲
The TMS enables user processes to perform I/O communication
with terminals.
The I/O communication can be performed in two modes:
file mode and communication mode.
4.2.4.3.1.1 F̲i̲l̲e̲ ̲M̲o̲d̲e̲
In this mode I/O to terminals is identical to I/O to
backing store files from the point of view of the user
process.
The same IOS basic procedures are used (appendbytes,
modifybytes, readbytes) and direct as well as stream
I/O can be used.
This mode provides the greatest flexibility for the
user process. This flexibility is obtained at the expense
of an additional overhead, as all I/O requests from
the user process will have to pass the TMS.
File mode I/O is aimed at terminals which will be connected
to varying processes with different security profiles.
The terminals in question will normally be local or
remote interactive hardcopy or screen terminals.
4.2.4.3.1.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲e̲
In this mode I/O requests from the user process are
sent directly to the terminal handler. The I/O interface
between the user process and the terminal device handler
is that of the BTS and therefore inherently different
from backing store I/O.
Communication mode I/O is aimed at - but not limited
to - terminals which are connected to a single user
process throughout its lifetime.
The terminals in question are primarily communication
lines like e.g. trunk lines in a message switching
network.
figur inds`ttes
4.2.4.3.2 U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Before a user process can make use of the TMS functions,
it must be logged on to the TMS by means of th Useron
command. This command must be invoked by a process
which is already known by the TMS, either through another
Useron command or because it is the parent process
for the TMS.
In the Useron command the calling process grants some
of its TMS resources to the process which is logged
on to the TMS in the Useron command.
When a user process seizes to use the TMS, its TMS
resources must be released by a call of Useroff.
4.2.4.3.3 H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲a̲t̲e̲g̲o̲r̲i̲e̲s̲
The TMS recognizes the following categories of equipment:
- T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ which is a line controller
interfacing one or more lines.
- L̲i̲n̲e̲, which is a group of physical signals
capable of sustaining one simplex or duplex
data stream.
- U̲n̲i̲t̲, which is a terminal device connected
to a line.
If more than one unit is connected to a given line,
the line is called multiplexed line.
4.2.4.3.3.1 E̲x̲a̲m̲p̲l̲e̲s̲
1. A parallel interface module interfacing one or
more line printers. The line printers are units.
tegning
2. An LTU with four interface lines each connecting
one VDU.
tegning
3. An LTU with two interface lines on which a number
of VDUs are multidropped.
tegning
4. An X25 LTU with a single line which supports N
virtual circuits (VC).
Each VC is a unit.
4.2.4.3.3.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲s̲
Terminal controllers may dynamically be assigned and
deassigned by the parent process for the TMS.
A controller can either be assigned as an active or
as a stand-by controller.
A stand-by controller is a device which normally is
not active, but which may take over in case of a failure
in an active controller.
When an active controller is assigned for which a stand-by
is available, this must be defined in the assignment
command.
The process which assigned a controller is its initial
owner.
Ownership of a controller may be transfered to another
user process which is logged on to the TMS.
When a controller is assigned, the TMS creates a corresponding
device handler.
4.2.4.3.3.3 L̲i̲n̲e̲s̲
The owner of a controller may assign lines to the controller.
When a line is assigned the TMS calls the device handler
for the controller to that effect.
4.2.4.3.3.4 U̲n̲i̲t̲s̲
The owner of a controller with lines assigned to it
may create units on the lines.
Units can be created for file mode I/O or communication
mode I/O.
A unit created for file I/O may be a multiple or single
access unit.
Single access units can only be accessed by the owner
whereas multiple access units may be accessed by a
number of user processes.
When the owner creates a unit, an access path to the
unit is established. The owner may from now on access
the unit by the IOS functions readbytes for input -
and appendbytes, and modifybytes for output.
Other users may obtain access to a multiple access
unit in different ways as described in the following.
The creator of a unit may offer it to another user
by means of the TMS OFFER function. The user to which
the unit is offered obtains access to the unit by the
ACCEPT function.
The creator of a unit may define a symbolic name -
a unit name - for the unit. A unit name is syntactically
identical to an FMS file name.
Other users may obtain access to the named unit by
the LOOKUP ̲UNIT command which corresponds to the FMS
commands getroot, lookup and descent.
4.2.5 S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
When a CR80 memory mapped PU is master cleared., a
boot strap loader is given control.
The boot strap loader is contained in a programmed
read-only memory which is part of the MAP module. Having
initialized the translation tables of the MAP module,
the boot strap loader is able to fetch a system load
module from a disk connected to the PU.
An initialization module which is part of the load
module initalizes the DAMOS kernel and the DAMOS Root
process.
The Root process possesses all the PU resources. The
Root creates and intializes a system File Management
System.
4.3 S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
O The support software assists in software development
and in hardware maintenance and diagnostics.
The support software consists of:
- terminal operating system
- language processors
- system generation software
- debugging software
- utilities
- maintenance and diagnostics programs
4.3.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲T̲O̲S̲)̲
TOS is an operating system which supports interactive
terminal users in a program development environment.
The functions performed by TOS are invoked by two types
of requests:
Operator commands, which are messages typed at terminals
and sent to TOS. The functions which may be performed
in response to these requests are:
- assign/deassign disk devices
- mount/dismount volumes on disk drives
- include terminals in the system/remove terminals
from the system
- log on to the system
- remove processes from the system
- broadcast messages to terminals
- manipulate a "news" message facility
- present status information
- run a task
- close the system
Programmed requests are sent from processes to TOS.
The functions which may be performed in response to
these requests are:
- allocate resources (memory) for a task, load a
program, and create a process to execute the program
- start a process
- stop a process
- restart a process
- logout from the system
- reserve a print queue file semaphore
- release a print queue file semaphore
- start a printer task
4.3.2 L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲ ̲(̲O̲p̲t̲i̲o̲n̲a̲l̲)̲
The CR80 language processors include the following:
- PASCAL is a high level block-orientated language
that offers structured and complex data and enforces
well structured programs. The CR80 implementation
is based on standard Pascal as defined by Kathleen
Jensen & Niklaus Wirth, with only minor deviations.
The CR80 implementation provides for bit mask
operations in addition to standard PASCAL data
structures. Furthermore, the CR80 implementation
provides the following powerful additions:
- Compile time option enables merging assembly
object directly into the Pascal module.
- Overlay technique is supported.
- Built-in Trace of program execution may optionally
be switched in/out for debugging purposes.
- Sequential and random file access is available
from run time library.
- The CR80 COBOL compiler is an efficient industry-compatible
two-pass compiler, fulfilling American National
Standard X3.23-1974 level 1 as well as most of
the level 2 features.
- SWELL 80 is a S̲oft W̲are E̲ngineering L̲ow level L̲anguage
for the CR80 minicomputer. SWELL offers most of
the data and program structures of PASCAL, and,
by enabling register control, is without the efficiency
penalties experienced in true high-level languages.
The main purpose of SWELL is to combine efficient
program execution
with efficient program development and maintenance.
- The assembler is a machine-orientated language
for the CR80. The language has a direct correspondence
between instructions read and code generated.
- ADA compiler is included. A project has been launched
for implementation of the new DOD standard programming
language ADA on the CR80 machine. The project
is planned for completion in 1983 and includes
development of an ADA compiler hosted on and targeted
for the CR80 as well as of an ADA programming support
environment. The programming support environment
is based on the Stoneman report. Presently a subset
of the Ada language is available producing SWELL
code.
4.3.3 S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The utility SYSGEN-EDIT generates object files - based
upon a set of directives, a system source, and command
files - for subsequent compiling and linking. A BINDER
then binds the system object together with the application
object based upon a command file from SYSGEN-EDIT.
All the external references of the object modules
are resolved in the Binder output, which is a load
module ready for execution. The BINDER produces a
listing giving memory layout, module size, etc.
4.3.4 D̲e̲b̲u̲g̲g̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The software debugging facilities include:
- Test Output Facility
- On-Line Interactive Debugger
4.3.5 U̲t̲i̲l̲i̲t̲i̲e̲s̲
The CR80 utility software package will include:
- Editor
- File Copy and Compare
- File Merge
- Interactive Proper Patch Facility
- File Maintenance Program
4.3.6 D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲ ̲(̲S̲O̲W̲ ̲4̲.̲1̲0̲)̲
The Maintenance and Diagnostic (M&D) package is a collection
of standard test programs which is used to verify proper
operation of the CR80 system and to detect and isolate
faults to replaceable modules.
4.3.6.1 O̲f̲f̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The off-line M&D software package contains the following
programs:
- CPU Test Program
- CPU CACHE Test Program
- Memory Map Test Program
- RAM Test Program
- PROM Test Program
- Supra Bus I/F Test Program
- CIA Test Program
- LTU Test Program
- Disk System Test Program
- Magtape System Test Program
- Floppy Disk Test Program
- TDX-HOST I/F Test Program
- Card Reader and Line Printer Test Program
4.3.6.2 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
On-line Diagnostic programs will execute periodically
as part of the exchange survailance system. On-line
diagnostics consists of a mixture of hardware module
built-in test and reporting, and diagnostic software
routines. The following on-line diagnostic capability
exists:
- CPU-CACHE diagnostic
- RAM test
- PROM test
- MAP/MIA test
- STI test
- Disk Controller/DCA test
- Tape Controller/TCA test
- LTU/LIA test
On-line diagnostics will report errors to higher level
processing to take recovery/switchover decision in
the case of failures.
4.5 T̲R̲A̲N̲S̲M̲I̲S̲S̲I̲O̲N̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲(̲S̲O̲W̲ ̲4̲.̲2̲ ̲&̲ ̲4̲.̲3̲)̲
The Transmission Software (or the Nodal Sub System:
NSS) is the software located in each node of the Packet
Switching Network.
The purpose of the Transmission Software is the error
free transmission of message traffic from end to end.
The messages are packetized and routed via virtual
circuits throughout the network. Routing is adaptive
because nodes and/or trunks may fail.
The adressing scheme of the network is based on the
X.21 recommendation. By using a superior region in
the numbering plan the network may be expanded in practice
without limits.
Traffic control will be maintained in the network by
giving data, which are on their way into the network,
a lower priority than relay data already inside the
network. Relay data,however, are given a lower priority
than data which are on their way out of the network.
In this way a congestion situation will be delayed
or even avoided.
4.5.2 N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The internal interface of the Transmission software
is the interface between the individual NSS'.
4.5.2.1 P̲r̲o̲t̲o̲c̲o̲l̲ ̲L̲e̲v̲e̲l̲s̲
Level 1 is the physical layer which performs the transmission
bits over the channel, and will not be further described
here.
Level 2 (Data Link Layer) will guarantee error free
delivery of frames. It will also have the ability
of retransmission of selected frames so nodes may be
connected by satellites. This layer, however, will
be implemented in down line loadable software executed
in communications processors or in firmware for the
package switching network and the local area network
respectively. It is possible to create different versions
of the down line loadable software. By this mean package
switching simulation can be performed in many ways.
Level 3 (Network Layer) performs the routing and switching
of packets from node to node.
Level 4 (The Transport Level) performs the end-to-end
control of messages. It ensures reliable transport
through several interconnected networks.
The communication as well as the network interfaces
are shown in fig. III 4.5-3.
Fig. III 4.5-3: The Network Interface
4.5.3 T̲h̲e̲ ̲M̲o̲d̲u̲l̲e̲s̲ ̲o̲f̲ ̲t̲h̲e̲ ̲N̲S̲S̲
The NSS will be structured in modules each consisting
of one or more parallel tasks (co-routines).
4.5.3.1 T̲h̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲
The main task of the Transport Station (TS) is to perform
end-to-end control on message level.
The TS of the originating node must therefore maintain
a disc copy of the packets of each message which should
be acknowledged. If such a message is not acknowledged
from the destination node, it must be retransmitted.
The TS of the destination must perform a possible sorting
of the packets of a message ensuring the propes sequence
of their delivery, and it must return an ACK or NACK
depending on all the packets were correctly received
or not.
Finally it must be mentioned that errors (trunk failure,
node failure, congestion) may be reported from the
underlying module.
4.5.3.2 T̲h̲e̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲
The main task of the Packet Handler (PH) is to switch
data packets from node to node.
The PH must maintain flow control ensuring that packets
are not tansmitted faster than they may be received
and buffered. The flow control will also ensure that
some high priority packets will be transmitted even
during congestion conditions.
4.5.3.3 T̲h̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲M̲o̲d̲u̲l̲e̲
This module will monitor the state of the node and
report statistics and errors to the NCC, i.e network
host. It will also receive controlling information
from the NCC for example Routing Tables.
4.6 C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
4.6.1 H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲H̲S̲S̲)̲
o This subsystem supports the interface to the network
at the presentation level of the OSI reference
model. The subsystem supports the virtual terminal
protocol (VTP), the file transfer protocol (FTP)
and the internal session layer protocol (ISL).
Two simple protocols, Nodal transport interface
(NTS) and queue interface (QI) supports the interfase
to other submodules.
The HSS is used when a network user wants to create
a virtual circuit to another print in the network,
e.g. a terminal that wants a communication with a specific
host. The request for the virtual circuit is serviced
by the internal session layer. The setup request must
contain information about the presentation layer protocol
(VTP of FTP) to be used on the actual virtual circuit.
When setting up the circuit the ISL interfaces to
the NSS through the NTI.
The queue interface (QTF) to the HSS will contain one
pair of queues per priority defend. This insures quick
response. Only when high priority queues are empty
lower priorities are serviced. A special control queue
is defined to support the session layer. All kind
of setup and close down requests will be inserted in
this queue. A virtual circuit setup request must contain
information about distribution address, priority, rate,
protected/nonprotected and test/operational/other.
A special kind of session layer service is the transfer
of statistical and billing information to the Network
Control Center, i.e the network host.
4.6.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
o The Terminal access subsystem handles the layered
interface and access between the physical terminals
and the network.
The following levels are present, which will be described
during the next paragraph:
-1: ICC physical link layer (IPL)
-2: ICC link layer (ILL)
-3: ICC protocol to Network Layer (IPN)
-4: Terminal Transport Layer (TTL)
-5: Terminal Session Layer (TSL)
-6: Terminal Protocol/Printer Protocol (TP/PP)
-7: Application Layer (APP)
T̲h̲r̲e̲e̲ ̲L̲o̲w̲e̲s̲t̲ ̲L̲e̲v̲e̲l̲s̲
The 3 lowest levels ahs already been described.
T̲e̲r̲m̲i̲n̲a̲l̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲L̲a̲y̲e̲r̲
The transport layer supports a reliable transport through
several interconnections.
T̲e̲r̲m̲i̲n̲a̲l̲ ̲S̲e̲s̲s̲i̲o̲n̲ ̲L̲a̲y̲e̲r̲
The terminal session layer contains all kinds of access
and securtiy information. It manages session between
word statistics.
T̲e̲r̲m̲i̲n̲a̲l̲ ̲F̲o̲r̲m̲a̲t̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲L̲a̲y̲e̲r̲
This layer contains the programs which the devices
use to gain access to the function-oriented protocols.
Included in the programme is the translation of requests
into local or remote requests. Furthermore, this layer
controls the screen facilities, such as split screen,
protected fields, etc.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲a̲y̲e̲r̲
This application layer is user-defined and consists
of the specific operator functions.
Figure
5̲ ̲ ̲A̲D̲A̲ ̲C̲O̲M̲P̲I̲L̲E̲R̲
The ADA Compiler Development Project is being carried
out by a consortium consisting of three partners.
The aim of the project is to construct a compiler for
the full ADA language. The ADA Compiler Development
project is a part of the Portable ADA Programming System
project, which addresses the construction of an entire
programming environment including an ADA compiler.
The main purpose of this programming environment is
to facilitate the development of system and application
software for a wide variety of systems using the ADA
high level language. The programming environment will
conform to the Stoneman specifications from the U.S.
Department of Defense.
The Portable ADA Programming System project particularly
stresses portability and feasibility for computers
with limited address and memory space. The compiler
development project additionally will demonstrate the
power of formal specification and design techniques,
which will be used to derive the compiler algorithms.
The resulting programming environment system will be
implemented on the Christian Rovsing CR80.
5.1 P̲R̲O̲J̲E̲C̲T̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The purpose of the source language conversion program
(SLCP) project is to construct a program which converts
source programs written in a suitable subset of the
ADA high level language into SWELL source programs.
The resulting SWELL source programs can be compiled
into machine code using an existing SWELL compiler
for the Christian Rovsing CR80 computer.
The components of the ADA compiler developed by Christian
Rovsing A/S will be written in the ADA subset and debugged
using the SLCP on the CR80 computer. After the compiler
components have been debugged and integrated into a
complete compiler system, the compiler system will
be used to compile the compiler components thus rendering
superfluous the SLCP.
The SLCP project consists of the following subprojects:
1. Determination of a number of design criteria for
the ADA subset.
2. Informal description of the ADA subset.
3. Formal description of the abstract syntax of the
ADA subset.
4. Elaboration of a formal description of SWELL.
5. Informal description of the mapping of the ADA
subset onto equivalent SWELL constructs.
6. Formal description of the mapping of the ADA subset
onto equivalent SWELL constructs (compiling algorithm).
7. Selection of a suitable implementation langauge
for the conversion program.
8. Coding and debugging of the conversion program
by stepwise refinement of the compiling algorithm.
5.2 D̲E̲S̲I̲G̲N̲ ̲C̲O̲N̲S̲I̲D̲E̲R̲A̲T̲I̲O̲N̲S̲
This chapter describes the design considerations that
have led to the selection of the SWELL language as
the target language, i.e. the output language of the
source language conversion program.
Furthermore, the design considerations that have governed
the selection of the features to be included in the
ADA subset are described.
5.2.1 S̲e̲l̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲a̲r̲g̲e̲t̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲
Target language candidates were selected on the basis
of availability on the CR80 computer.
The following target language candidates were considered:
1. CR80 assembly language
2. COBOL
3. Pascal
4. Modula 2
5. UCSD Pascal
6. SWELL
CR80 assembly language was rejected because it did
not appear to have any advantages over SWELL. In many
respects, however, it is much more primitive and more
complicated to use than SWELL.
COBOL, which is implemented on the CR80, was rejected
because the mapping of ADA into COBOL was considred
much too complicated. In particular the lack of type
mechanisms in COBOL was considered difficult to manage.
The Pascal compiler on the CR80 is an improved version
of te Sequential Pascal compiler from the Solo operating
system project. It was rejected because severe difficulties
were expected when implementing the separate compilation
facilities of ADA. No separate compilation or segmentation
facilities exist in the CR80 Pascal dialect.
Modula 2 and UCSD Pascal compilers are presently not
implemented on the CR80 compiler. The project members
briefly considered implementing these compilers on
the system in order to use these powerful languages
as target languages. This approach was rejected because
he advantages over SWELL were not considered sufficiently
significant to justify the implementation costs.
SWELL was selected because of its type handling and
separate compilation handling facilities. The drawbacks
of the language (servere restrictions on procedure
parameters, local variables, and expression syntax)
were considered manageable without a large effort by
placing acceptabel restrictions on the ADA subset.
5.3 A̲D̲A̲ ̲S̲U̲B̲S̲E̲T̲
The following design criteria were used during the
design of the ADA subset:
1. The source language conversion program project
must be completed within an effort of approximately
10 person months.
2. The ADA subset should be a true subset. The machine
independents programs accepted by the conversion
program should be acceptable by any ADA compiler
without modificaiton.
3. An ADA language facility must be included in the
ADA subset if the implemention of this facility
will shorten the compiler development time by more
than is used to implement the facility.
4. ADA language facilities not required for compiler
construction should not be implemented.
5. The limitations in the ADA subset must not exclude
any reasonable compiler design strategy.
6. The ADA subset is not required to be ideal for
compiler construction. Language facilities may
be omitted if they are difficult to implement and
if the omission will cause only minor problems
with respect to structure and efficiency of the
resulting compiler:
As soon as the ompiler is able to compile itself,
the compiler will be restructured and minor parts
of it will be recoded in order to take advantage
of the facilities initially omitted.
These criteria have been used to design the ADA subset.
5.4 A̲D̲A̲ ̲S̲U̲B̲S̲E̲T̲
This chapter describes the ADA subset which is being
used to implement the ADA compiler. The ADA subset
has been designed using the criteria outlined in section
5.3.
The most important ADA features that will not be implemented
in the subset are
D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲:̲
Approximate data types (real numbers)
Subtype declarations
Renaming
Arrays with more than one index
Dynamic ranges
Representaion specifications
Overloading (note that overloading of array and record
aggregates is implemented)
C̲o̲n̲t̲r̲o̲l̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
Return and goto
P̲r̲o̲g̲r̲a̲m̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
Functions
Private parts in packages
Generic program units
Procedures within procedures
Nested packages
Separate compilation of subunits
Tasking
5.4.1 A̲D̲A̲ ̲S̲u̲b̲s̲e̲t̲ ̲S̲y̲n̲t̲a̲x̲ ̲S̲u̲m̲m̲a̲r̲y̲
5.4.2 P̲r̲e̲d̲e̲f̲i̲n̲e̲d̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
6̲ ̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲F̲O̲R̲M̲A̲T̲S̲ ̲A̲N̲D̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲
In order to perform a realistic demonstration of an
Experimental Distributed Processing Facility, Christian
Rovsing A/S propose to implement all the six message
formats contained in the RFQ. The formats are shown
in section 6.1.
In addition Christian Rovsing A/S has analysed the
data base, data flow requirement as described in the
RFQ.
CECOM's request for a demonstration of the EDPF which
does not necessarily contain the exact information
flow in maneuver elements, but demonstrates the capabilities
of a distributed data base. The data base is described
in section 6.2.
6.1 M̲E̲S̲S̲A̲G̲E̲ ̲F̲O̲R̲M̲A̲T̲S̲
The message formats shown in the RFQ will be implemented
as they are described. The only change will be the
change entailed by the VDU used.
6.2 D̲A̲T̲A̲ ̲B̲A̲S̲E̲
It has been the objective of Christian Rovsing A/S
to design a general, but simple distributed data base
to demonstrate the capabilities of the EDPF.
The flow and sizing requirements in the RFQ annex C
has been interpreted.
It is imagined that the distributed database will be
used in a strict military organizaition like the one
shown in figure 6.2-1.
The information items names and the description of
the items have let Christian Rovsing A/S to believe
that all information fields in the database should
be fields for narrative description. Room will be allowed
for operator insertion of a text. No computation such
as addition or subtraction will be performed.
The length allocated in the data abase will be controlled
by the peak load, which is the maximum length of information
elements can have at the maneuver element level in
question. The average length is not used.
In section 6.2.2 the data base description is shown.
The INIT parameter is used to decide whether the information
element can be initiated at this element or if it is
only received. An information item can always be entered
if mentioned in the table.
The STORE parameter, which is always yes in the data
given, will be used to decide if any entered information
item will be retained in the node database after transmission.
The UP parameter determines if the information field
automatically will be transmitted one step up in the
military hierarchy.
The DOWN parameter determines if the information field
automatically will be transmitted down one step to
all subordinate elements.
The LATR parameter determines if the information field
automatically will be transmitted to all adjecent elements
under the same commanding element.
The CURRENCY parameter determines the priority of the
transmissions and will be used as such.
6.2.1 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲U̲p̲d̲a̲t̲e̲
A typical data base update scenario is described in
the following. A battalion element requires some air
craft support and enters the requirement in narrative
text at the node computer.
When the A/C requirement is updated locally it is automatically
transmitted one step up and stored in that database
with an identification of where it came from and at
what time it was transmitted.
The brigade element wants to enter its requirements
for aircraft in its local database and identifies the
information field in question. In conjunction with
the local field are stored all A/C requirements fields
received from the subordinant elements, i.e. the VDU
display the subordinates requirements node by node
and this is used as decision making data for entry
of A/C requirement to be sent up to the higher element.
The VDU formats required to use the distributed database
are shown on the following pages.
The division element can display all the A/C requirements
information fields received from the subordinate
brigade nodes and decide how many A/C will be allocated
to the subordinate elements. This information field
is automatically transmitted one step down in the
hierarchy and so forth.
6.2.2 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The data base is described in ADA or as a file in a
format like the following.
Figure 6.2.2-1
7̲ ̲ ̲N̲E̲T̲W̲O̲R̲K̲ ̲T̲O̲P̲O̲L̲O̲G̲Y̲ ̲(̲S̲O̲W̲ ̲4̲.̲6̲)̲
In the following subsection an analysis will be carried
out to reveal the pro et con of the different network
type like bus, star, ring, tree, broadcast, and irregular
network.
The analysis will be carried out, considering that
the application of the network will be communication
between units in a hierarchical military organization,
i.e. most communication will be limited to one step
up, down or lateral in the organization. See figure
7-1. Aspects like redundancy, survivability and local
distribution will be considered.
There is an ambiguity in the objective of designing
an optimal network which serves a hierarchical military
organization and which allows true distributed processing
with survivalibility features. This ambiguity will
entail that none of the simple networks is optimal,
but that trade off has to be made.
figure
7.1 B̲U̲S̲ ̲N̲E̲T̲W̲O̲R̲K̲
The bus network is characterized by a single string
connection network on which the nodes are attached
like pearls on a string. See figure 7.1-1. It minimizes
the number of interfaces in all nodes to maximum 2.
However, it can entail many transmission where more
than two nodes are involved.
As an example of this look at the network in figure
7.1-1 where node 6 is anticipated to serve a maneuver
element which is under command of the element served
by node 3. In order to communicate between these two
nodes, node 2, 4, and 5 has to be engaged. Although
this does not imply operator interaction at these nodes
there must be sufficient processing power to handle
this extra intermediate communication.
Seen from a pure military tactical point of view it
is not desirable that the well functioning of one flank
is dependent on the condition of the other flank. The
connections between node 4, 5, and 6 will be at the
frontier of the battlefield and will be threatened.
In the event that one node or one connection between
two nodes becomes inoperational, the total network
will be divided into two subnetwork, i.e. there is
no redundancy in the network.
Other bus network structures could be established,
but the disadvantages of these cannot be completely
removed.
FIGURE 7.1-1 BUS NETWORK APPLIED ON THE HIERARCHICAL…01…MILITARY ORGANIZATION SHOWN
IN FIGURE 7-1
7.2 S̲T̲A̲R̲ ̲N̲E̲T̲W̲O̲R̲K̲
The Star network is characterized by a cental node
which does all the switching. No other nodes besides
the central node needs to have the switching facility.
In that respect it is a simple system.
The star network is a very vulnerable network. If the
central switch becomes inoperational all nodes are
isolated and cannot communicate with any other node.
In figure 7.2-1 a star network which serves the military
organization depicted in figure 7-1 is shown. Node
3 has been selected as the central node. A more immediate
selection of a central node would be node 1 which serves
the maneuver element in charge, but this would give
raise to large communication lines:
The star network will require transmission over intermediate
node in the normal military communicaton scheme, i.e.
one step up, down or lateral. Messages sent from node
2 to 4 must go via node 3. The number of intermediate
nodes are smaller in this case compared to the bus
network.
In order to minimize the length of the connection lines
and to protect the crucial central node, this node
should be placed in the geographical mittle of the
area covered by the organization.
The star network does not have any build in back up
lines, and hence it is not in accordance with a survivable
distributed system.
FIGURE 7.2.1…01…STAR NETWORK APPIED TO THE MILITARY ORGANIZATION SHOWN…01…IN FIGURE
7-1
7.3 R̲I̲N̲G̲ ̲N̲E̲T̲W̲O̲R̲K̲
The ring network can be looked at as an improved bus
network. It has the disadvantage of many intermediate
nodes when communicating in the underlying military
organization. However, it has the great advantage that
every node can be reached from any other node via two
different routes.
In case node 1 wants to communicate with node 2, this
can be done by the direct link between the two nodes,
or in case the link becomes inoperational, then the
communcation can take place via node 3, 6, 5, and 4.
The ring network must be considered better than both
the bus and the Star network. It contains back up lines
and all the node computers perform identical function.
This allows reconfiguration after one node failure.
In the star network this would not be the case, where
it was the central node which became inoperational.
FIGURE 7.3-1…01…RING NETWORK APPLIED ON THE MILITARY ORGANIZATION …01…SHOWN IN FIGURE
7-1
7.4 T̲R̲E̲E̲ ̲N̲E̲T̲W̲O̲R̲K̲
The tree network is the network which resembles the
underlying organization best and hence it is well suited
as starting point for designing an optimal network
for a military organization like the one shown in figure
7-1.
The tree network follows the communication lines in
the military organization. Hence it minimizes the number
of intermediate nodes. However, there is no low maximum
of the number of links attached to any node. This implies
that the distribution is not evenly distributed or
all nodes, but it is likely that the number of legs
from one node will be propertional with the communication
performed by the mode in question.
The tree networks are not optimized to perform lateral
communication, i.e. a message from node 5 to 6 will
have to go via node 3. A worse case exists when going
from node 4 to 6. This will require 3 intermediate
nodes to be involved.
The tree network does not have any build in back up
lines. Hence it is not optimal for a distributed survivable
network, without modifications.
FIGURE 7.4-1…01…TREE NETWORK
7.5 B̲R̲O̲A̲D̲C̲A̲S̲T̲ ̲N̲E̲T̲W̲O̲R̲K̲
The broadcast network philosophy in its clear case
means that all nodes are connected to all other nodes.
By broadcasting a message from one node to all other
nodes, they decides if the message is intended for
the receiving node. This philosophy gives a high degree
of ensurance for message delivery, but it also makes
messages available for not intended recipients. The
expenses for this network are a high overload compared
to the optimal.
This type of network is expensive to establish and
operate, but it gives other desirable attributes to
a flexible and survivable network.
In practical trade off has to be made regarding the
number of connections for each node. A good choice
would be to connect every node with any other node
if it is likely to communicate with, i.e. one up in
hierarchy to the commanding element, and one node down
to all the subordinate elements plus connection to
all nodes of the hierarchy level in question. The lateral
connections may only contain elements directly under
the same commanding element.
FIGURE 7.5-1…01…BROADCAST NETWORK APPLIED TO THE MILITARY ORGANIZATION SHOWN…01…IN
FIGURE 7-1
7.6 I̲R̲R̲E̲G̲U̲L̲A̲R̲ ̲N̲E̲T̲W̲O̲R̲K̲
The performed analysis has shown that none of the previous
networks are optimal, but indication of different benefits
has been brought to attention.
The tree network seems appropriate from an organizational
point of view, and the broadcast network seems appropriate
from a flexibility and survivability point of view.
By combining the two network types a reasonable trade
off has been made. The proposed irregular network has
been depicted in figure 7.6-1. The normal transmission
scheme used in the first network will be applied. This
means that a node will find a preference link to send
the message via and check that the link is operational.
Only in case the link is inoperational the node will
find a second or third choice. The number of back up
links is only limited by the number of outgoing links
from a given node.
This type of network will be used in the demonstration
set up.
Figure 7.6-1…01…IRREGULAR NETWORK APPLIED TO THE MILITARY HIERARCHY IN FIGURE
7-1
8̲ ̲ ̲A̲C̲C̲E̲P̲T̲A̲N̲C̲E̲ ̲T̲E̲S̲T̲S̲ ̲(̲S̲O̲W̲ ̲4̲.̲7̲)̲
Christian Rovsing A/S will prepare a separate acceptance
test plan and procedure for the delivered hardware
and for the demonstration system. These tests will
demonstrate that the systems delivered are in full
accordance with the requirements.
The hardware acceptance procedures will be performed
at the Christian Rovsing A/S facilities prior to shipment.
The hardware acceptance procedures will be repeated
on the first system delivered at the CECOM sites.
The second acceptance test which comprises the application
system test will be performed on both systems after
installation at the CECOM site. This demonstration
will include the generation of the executable system
from source code. The test will be documented in acceptance
test reports.
The demonstration test will show how messages can be
sent from node to node using different routes, i.e.
first, second, and third route depending on availability.
The demonstration will show both use of local area
network and packet switching network. On the packets
siwtching network, error simulation will be included
in the laboratory demonstration in order to simulate
bad connections in the field. This simulation is done
by changing the software in the communication processor.
No extra hardware is needed to simulate these transmission
errors.
During the demonstration the host will gather statistics
on the network performance.
The network topology for the demonstration will be
based on the irregular network described in section
7.6. The network is a modified tree network, i.e. some
of the nodes on the same level are connected directly
to establish back up links or more direct links than
otherwise established. See figure 8.1.
FIGURE 8.1
9̲ ̲ ̲T̲R̲A̲I̲N̲I̲N̲G̲ ̲(̲S̲O̲W̲ ̲4̲.̲8̲ ̲&̲ ̲4̲.̲9̲
9.1 T̲R̲A̲I̲N̲I̲N̲G̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
Based on information in the RFQ Christian Rovsing's
previous experience from similar projects, the following
training requirements are listed:
a) One course will train the personnel in the system
hardware and the operation of the software.
Another course will train in running the demonstration
of the "Maneuver Element of the tactical battlefield"
and understand and modify all demonstration software.
b) Courses (including practical work) will have approx.
40% theory and 60% hands-on training.
c) Courses for the following personnel categories
are proposed:
- Installation and maintenance technicians/engineers.
- ADA application programmers.
d) Training techniques will be described.
e) Location of the training courses will be described.
f) Christian Rovsing will develop an Integrated Training
Plan outlining the contents of the courses and
training methods.
9.2 T̲R̲A̲I̲N̲I̲N̲G̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲
9.2.1 M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
The training section, which is a part of the Integrated
Logistics Support department, see fig. 9.2.1-1 is responsible
for development and conduct of customer training and
the documentation delivered with the systems.
Figure 9.2.1-1 Organization of…01…Integrated Logistic Support
The training section is organized with a manager, technical
writers and instructors.
The combination of user documentation and training
ensures that the training is supported by documentation,
which is not only easy to use, but also complements
the training documentation, enabling effective training
in all aspects.
9.2.2 T̲r̲a̲i̲n̲i̲n̲g̲ ̲P̲l̲a̲n̲
The integrated training plan gives an overview of how
the training courses are planned, developed, and conducted.
Later, it forms the basis for development of training
plans for the individual courses and is the customers
first assessment of the approach taken by Christian
Rovsing towards the training.
This plan contains details regarding the training management,
how the courses are interrelated and how the requirements
connected to each course will be incorporated. Each
course is outlined, the facilities and equipment to
be used are explained, and a schedule for the formal
training of the customer personnel is proposed.
9.2.3 C̲o̲u̲r̲s̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
Courses will cover the following system components:
- CR80 Computer-system
- Software
Courses are offered for the following categories of
personnel:
- Installation and maintenance engineers.
- ADA application programmers.
The following courses will be offered:
a) A CR80 hardware/software course
b) A system demonstration course.
9.3 C̲R̲8̲0̲ ̲H̲A̲R̲D̲W̲A̲R̲E̲/̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲C̲O̲U̲R̲S̲E̲
Contents:
- Installation of the CR80 system
- Reconfiguration of the CR80 system
- Operation of the CR80 system
- Maintenance of the CR80 system
- Troubleshooting of the CR80 system
- Repair of the CR80 system
- Use of the software development system.
Previous knowledge required:
5 years of experience in computer maintenance and operation.
Number of participants: 15
Length of course:
One week of 30 lessons.
9.4 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲M̲O̲N̲S̲T̲R̲A̲T̲I̲O̲N̲ ̲C̲O̲U̲R̲S̲E̲
Contents:
- DAMOS operating system
- Environment software
- The ADA compiler
- ADA environment software
- ADA applications (demonstration system)
- Software Modification
Previous knowledge required:
- 5 years experience in application programming in
at least one high level language.
- 1 year experience in ADA programming.
Number of participants: 15
Length of Course:
One week of 30 lessons
9.5 T̲R̲A̲I̲N̲I̲N̲G̲ ̲M̲A̲T̲E̲R̲I̲A̲L̲S̲
The training plans will specify the training materials.
Draft copies (2 sets) of the training materials will
be delivered 60 days prior to the start of the course
for review and approval.
Final issues (15 sets) of the materials will be ready
at start of the courses.
9.6 S̲T̲U̲D̲E̲N̲T̲S̲ ̲T̲R̲A̲I̲N̲I̲N̲G̲ ̲C̲O̲U̲R̲S̲E̲ ̲G̲U̲I̲D̲E̲
Christian Rovsing A/S will develop and deliver the
students Training Course Guides, each matching the
contents of the two courses described earlier in this
paper.
Each guide contains the following elements as required:
S̲e̲c̲t̲i̲o̲n̲ ̲1̲:̲
- Information sheets
S̲e̲c̲t̲i̲o̲n̲ ̲2̲:̲
- Assignment sheets
- Note taking sheets
- Job sheets
S̲e̲c̲t̲i̲o̲n̲ ̲3̲:̲
- Student Workbook
S̲e̲c̲t̲i̲o̲n̲ ̲4̲:̲
- Diagram sheets
A̲p̲p̲e̲n̲d̲i̲x̲:̲
- Supplementary information
5 draft copies and 5 final copies are delivered according
to the agreed time schedule.
9.7 T̲R̲A̲I̲N̲I̲N̲G̲ ̲T̲E̲C̲H̲N̲I̲Q̲U̲E̲S̲
The main principle of Christian Rovsing's courses is,
that student centered training methods are used wherever
possible.
To evaluate the outcome of the courses, oral questions,
quizzes and tests are used during the courses, and
a final practical and theoretical test is performed
by the participants.
The following training methods are used during the
courses:
a) Group-work: Specific tasks are distributed
in writing to the groups to
work on. The tasks may be theoretical
or practical examinations of
the various topics.
b) Reports: The groups report the results
of their tasks in a group session.
c) Discussion: The results of the groups are
discussed by the class under
guidance of the instructor.
d) Lecture: Lectures are used (limited)
for outlining the basic rules
for a given topics.
e) Informal talk: Informal talk is invoked to
obtain feed-back to the instructor
on the outcome of the instruction.
f) Hands-on: Practical work is used extensively,
as this is the best way to
implement the use of theoretical
knowledge on the various topics
covered by other training methods.
In the same way, the instructor
gets feed-back on the student's
understanding of the topics
covered in the instruction.
g) Tests: Tests and questionnaires are
used frequently, as these are
highly motivating and underline
important points of the instruction.
1) D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The documentation is the responsibility of the
Integrated Logistic Support Department.
The following documentation is proposed for the
system:
2) S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲a̲n̲u̲a̲l̲s̲
a) Programming Development Tools
b) S/W As-Built Documentation
c) S/W Listings
d) Users Manual for the demonstration package.
3) H̲a̲r̲d̲w̲a̲r̲e̲ ̲M̲a̲n̲u̲a̲l̲s̲
a) System Operating Manual
b) Maintenance Manual
c) Installation Manual
d) Module description Manuals
e) Inventory Manual
f) Hardware Assembly Breakdown
g) Peripheral Equipment Manuals
h) Test Equipment Manuals.
This documentation covers all applicable aspects of
use, operation, configuration and maintenance of the
CR80 system and the demonstration system.
3 draft copies are delivered at the time of system
check-out. 10 final copies are delivered 30 days after
Government approval.
Good commercial practice is used for reproduction and
binding.
1̲1̲ ̲ ̲D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲(̲S̲O̲W̲ ̲4̲.̲1̲0̲)̲
The CR80 computers have been developed with extensive
Diagnostic Software. All critical hardware modules
are equipped with built in test BIT programs which
are activated at start up and which can be activated
manually during error location and maintenance.
In addition extensive software has been developed to
perform diagnostic of subsystems.
It is evident that a fault tolerant multiprocessing
system with extreme high reliability and availability
requirement must rely heavily on efficient diagnostic
software.
The CR80 diagnostic software is standard software,
which have been implemented on many CR80 system. Hence
its usefulness has been tested in the field.
1̲2̲ ̲ ̲S̲P̲A̲R̲E̲ ̲P̲A̲R̲T̲S̲ ̲A̲N̲D̲ ̲S̲P̲E̲C̲I̲A̲L̲ ̲T̲O̲O̲L̲S̲ ̲(̲S̲O̲W̲ ̲4̲.̲1̲1̲)̲
Christian Rovsing A/S will deliver spare parts as requested
by CECOM. The spare part will be delivered as hardware
modules to be easily inserted in the crates when a
module fails.
The package switching simulation facility will be provided
without extra hardware. The Line Termination Unit of
the Channel Unit can be down line loaded with new software
from the host. By this mechanism many different error
types can be programmed into the LTU software.
The EDPF is composed of standard equipment and many
diagnostic programs are available for error finding.
One set comprising a scope, a data communication tester
and a disk package field test unit will be delivered.
1̲3̲ ̲ ̲M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲ ̲(̲S̲O̲W̲ ̲4̲.̲1̲2̲)̲
Christian Rovsing will perform maintenance on both
EDPF system from delivery until final hardware acceptance.
However, agreement has to be made between Christian
Rovsing and CECOM, who is allowed to operate and maintain
the system. All personnel must be trained accordingly.
1̲4̲ ̲ ̲S̲A̲F̲E̲T̲Y̲ ̲(̲S̲O̲W̲ ̲4̲.̲1̲3̲)̲
The CR80 has been designed with thorough considerations
to personnel safety. The original design was made in
accordance with the very strict Danish national regulations.
The CR80 has also past the safety requirement set forth
by the US military in connection with the NICS-TARE
systems.
At present Christian Rovsing has also sold CR80 computers
to the American Commercial Industry and met the safety
requirement. Hence Christian Rovsing does not expect
any problems in meeting the Army safety requirement
for the EDPF according to the MIL-STD-882A. A preliminary
Hazard Analysis will be performed in accordance with
para. 5.5.1.1 of MIL-STD-882A to investigate if there
are any hazards in the design.
The safety laid down in the CR80 is very deep and thorough,
because it is part of general reliability, availability
and flexibility concept to be able to modify the hardware,
i.e. replace faulty module with error free modules
or to add extra modules, during operation.
There is no radioactive materials in the system, hence
radioactive materials do not cause any hazards.
1̲5̲ ̲ ̲P̲E̲R̲S̲O̲N̲N̲E̲L̲ ̲A̲V̲A̲I̲L̲A̲B̲L̲E̲ ̲F̲O̲R̲ ̲T̲H̲E̲ ̲E̲D̲P̲F̲ ̲P̲R̲O̲J̲E̲C̲T̲
Christian Rovsing A/S proposal for an EDPF system is
based on advanced existing components, which disminshes
the need for R & D personnel. Christian Rovsing A/S
intends to allocate full time assigned persons to the
EDPF project. The curriculum vitae for all proposed
persons follows.
Any special problems which might arise during the project,
which will require special expertise will be attached
by establishing task forces comprising persons in possesion
of the required skills and expertise to handle the
problem in question.
KM[
chakera
lsj
OE
H[H
holger
jrv
1̲6̲ ̲ ̲T̲R̲A̲V̲E̲L̲ ̲A̲N̲D̲ ̲S̲U̲B̲S̲I̲S̲T̲A̲N̲C̲E̲
At present Christian Rovsing A/S anticipates the following
travels and subsistance.
- 5 progress meetings in US involving senior engineers/managers
in one week.
- Site survey performed by one senior engineer during
5 days
- Installation of system 1 performed by 1 manager
and 2 technicians during 1 month
- Installation of system 2 performed by 1 manager
and 2 technicians during 1 month.
- Execution of the demonstration performed by 1 manager,
two senior engineers and 1 technician during 1
month
- Maintenance performed by 1 technician during an
initial 3 months' stay followed by 10 trips of
each 5 days.
- 5 technical trips involving 2 senior engineers/managers
and 1 engineer of one week's duration.
