top - download
⟦3270ab5e5⟧ Wang Wps File
Length: 111655 (0x1b427)
Types: Wang Wps File
Notes: LKSAA Part 1
Names: »4248A «
Derivation
└─⟦91ced00d4⟧ Bits:30006032 8" Wang WCS floppy, CR 0384A
└─ ⟦this⟧ »4248A «
WangText
$…00……00……00……00…<…0a……00……00…<…0c…<…07…;…0a…;
:…0c…:…06…9…0a…9 8…0d…8…01…7…09…7…0b…7…00…7…01…6…08…6…0b…6…02…6
5…09…5…02…4…09…4…00…4…06…4…07…3…09…3…0b…3…0d…3…0f…3…02…2…0b…2…05…1…0b…1…0c…1…02…1 1…07…0…09…0…0a…0…0b…0…0c…0…0d…0…0e…0…00……86…1 …02… …02… …02… …02…
Issue 1.5
LKSAA - VOLUME II SYS/84-06-15
Part 1
TECHNICAL PROPOSAL Page #
2 COMPUTER SYSTEM ..................................
24
2.1 HARDWARE .....................................
26
2.1.1 Introduction .............................
26
2.1.2 X-Local Area Network (optional) ..........
28a
2.1.2.1 General Description of X-Net ........
28a
2.1.2.2 Basic Implementation of the Optional
Local Area Network ...................
31
2.1.2.3 Extension Capabilities of the Option
for Local Area Network ...............
32
2.1.2.4 Utilization of another Local Area
Network ..............................
34
2.1.3 Central Communication System .............
35
2.1.3.1 General Description ..................
35
2.1.3.1.1 The Processor Units (PU) .........
39
2.1.3.1.2 The Channel Units (CU) ...........
40
2.1.3.1.3 Bus Structure ....................
42
2.1.3.1.4 Watchdog System ..................
45
2.1.3.2 LKSAA Processor and Channel Units
(Basic Implementation) ..............
46
2.1.3.2.1 Rack Layout ......................
52
2.1.3.3 Extension Capabilities ...............
54
2.1.3.4 Dualization of External Communication
Lines ................................
54
2.1.4 Equipment Matrix for the Computing
System ..................................
56
2.1.5 System Capacity and Connectivity
of Computer System ......................
58
2.1.5.1 Local Area Network (Option) .........
58
2.1.5.2 Central Communication System ........
58
2.1.5.2.1 Process Capacity ................
58
2.1.5.2.2 Random Access Memory ............
61
2.1.5.2.3 Peripheral Disk Memory ..........
63a
2.1.5.2.4 Terminal Equipment ..............
64a
2.1.5.2.5 Off-Line Cryptographic Equipment
64a
2.1.5.2.6 External Lines Via On-Line
Cryptographic Equipment .........
64a
2.1.5.2.7 External Lines Bypassing the
On-Line Cryptographic equipment ..
65c
2.1.5.2.8 Public Telephone Net .............
65d
2.1.5.2.9 High Speed Optical Data Link .....
65e
2.2 SOFTWARE .....................................
66
2.2.1 System Software .........................
66
2.2.1.1 Standard Operating System ...........
66
2.2.1.1.1 Overview of DAMOS Operational
Software ........................
70
2.2.1.1.2 Kernel ..........................
71
2.2.1.1.2.1 Resource Management .........
73
2.2.1.1.2.2 Process Management ..........
74
2.2.1.1.2.3 Process Hierarchy ...........
77
2.2.1.1.2.4 Memory Management ...........
79
2.2.1.1.2.5 Process Communication .......
80
2.2.1.1.2.6 CPU Management ..............
80
2.2.1.1.2.7 Processing Unit Management ..
80
2.2.1.1.2.8 Transport Mechanisms ........
81
2.2.1.1.2.8.1 Basic Transport Service
. 81
2.2.1.1.3 DAMOS Input/Output ..............
82
2.2.1.1.4 File and Message Management
System ..........................
84
2.2.1.1.4.1 Device and Volume Handling ..
84
2.2.1.1.4.2 Directories .................
85
2.2.1.1.4.3 Files .......................
85
2.2.1.1.4.3.1 File Types ..............
85
2.2.1.1.4.3.2 File Commands ...........
85
2.2.1.1.4.4 User Handling ...............
86
2.2.1.1.4.5 Disk Integrity ..............
86
2.2.1.1.4.5.1 Security ................
86
2.2.1.1.4.5.2 Redundant Disks .........
86
2.2.1.1.4.5.3 Bad Sectors .............
87
2.2.1.1.4.6 Access Methods ..............
87
2.2.1.1.4.6.1 Unstructured Access .....
87
2.2.1.1.4.6.2 Indexed Sequential Access
88
2.2.1.1.4.7 Message Management System ...
89
2.2.1.1.5 Terminal Management System ......
89
2.2.1.1.5.1 Transfer of I/O Data ........
90
2.2.1.1.5.2 User Handling ...............
90
2.2.1.1.5.3 Security ....................
90
2.2.1.1.5.4 Hardware Categories .........
91
2.2.1.1.5.4.1 Terminal Controllers ....
91
2.2.1.1.5.4.2 Lines ...................
92
2.2.1.1.5.4.3 Units ...................
92
2.2.1.1.6 System Initialization ...........
93
2.2.1.1.7 System Status and Control .......
93
2.2.1.1.7.1 Main Functions ..............
94
2.2.1.1.7.1.1 On-Line Diagnostics .....
95
2.2.1.1.7.1.2 Line Monitoring and
Control .................
95
2.2.1.1.7.1.3 Handling of Technical
Errorreports ............
98
2.2.1.1.7.1.4 Operator Commands to an
On-Line PU ..............
98
2.2.1.1.7.1.5 Off-Line PU Operation ...
99
2.2.1.1.8 ZVA System Functions ............
100
2.2.1.2 General Maintenance Software ........
100
2.2.2 General Development and Maintenance
Software .................................
101
2.2.2.1 Programming Languages ................
101
2.2.2.2 Utility Software .....................
101
2.2.2.3 Binder ...............................
102
2.2.2.4 Test Tools ...........................
102
2.2.3 Highlevel Operating System (HIOS) ........
103
2.2.4 Security System .........................
105
2.2.4.1 Access Control .......................
105
2.2.4.2 Error Processing .....................
105
2.2.4.2.1&2 User Errors and System Errors ..
105
2.2.4.2.3 Post-Mortem-Protocol .............
105
2.2.4.2.4 Restart ..........................
106
2.2.4.3 Checkpoint, Recovery and Restart .....
107
2.2.4.3.1 Integrity ........................
107
2.2.4.3.2 Central Recovery Functions .......
107
2.2.4.3.3 Checkpoints ......................
109
2.2.4.3.4 Recovery .........................
113
2.2.4.3.4.1 Failure Types ................
113
2.2.4.3.4.2 Recovery Actions .............
114
2.2.4.3.4.3 Recovery Level ...............
115
2.2.4.3.4.4 Applications Recovery
Actions ......................
116
2.2.5 Application Software .....................
117
2.2.5.1 Message Correction Programs ..........
123
2.2.5.2 Message Processing ...................
123
2.2.5.1 Message Processing Programs ........
123
2.2.5.2.2 Storage ..........................
123
2.2.5.2.3 Transformation and
Transmission .....................
123
2.2.5.3 Network Management ...................
124
2.2.5.3.1 Configuration Management .........
124
2.2.5.3.2 Changes ..........................
124
2.2.5.4 Log ..................................
124
2.2.5.5 Statistics ...........................
124
2.2.6 Diagnostic Programs ......................
125
2.2.6.1 Off-Line Diagnostic Program ..........
125
2.2.6.2 On-Line Diagnostic Programs ..........
125
2.3 AVAILABILITY REQUIREMENTS ....................
126
2.3.1 General Considerations ...................
126
2.3.2 Recovery Procedures ......................
128
2.3.3 Fallback Procedures ......................
129
2.3.4 Recovery Times ...........................
130
2.3.5 Overall System Availability ..............
130
2.3.6 Mean-Time-Between-Failure (MTBF) .........
133
2.3.7 Mean-Time-To-Repair (MTTR) ...............
136
2.4 INSTALLATION .................................
140
2.4.1 FMZ Installations ........................
140
2.4.2 Radio Control System .....................
141a
2.4.2.1 Radio Control Center .................
141a
2.4.2.2 TX Station ...........................
141a
2.4.2.1 RX Station ...........................
141b
2.4.3 AE - Installations (option) ..............
141b
2.4.4 Typical Layout ...........................
141b
2.4.5 Installation and Cabling Requirements ....
153
2.4.5.1 General ..............................
153
2.4.5.2 FMZ Rooms ............................
153
2.4.5.3 Cable Routing to AE-Workstations .....
154b
2.4.5.4 AE Workstations or Cells (Option) ....
154b
2.4.5.5 Radio Control Centre .................
154b
2.4.6 Physical Location of the Equipment in
the FMZ ..................................
154c
2.5 DOCUMENTATION ................................
155
2.5.1 Documentation Requirement Analysis .......
155
2.5.1.1 General Requirements .................
155
2.5.1.2 Program Documentation Requirements ...
155
2.5.1.3 Work Procedures Requirements .........
156
2.5.1.4 Operational Procedures Requirements
157
2.5.2 Documentation Proposal ...................
157
2.6 METHODS AND TOOLS ............................
159
2.6.1 System Design and Hardware Configuration
. 159
2.6.2 Software Design, Development
and Integration ..........................
159
2.6.2.1 Development Method ...................
159
2.6.2.1.1 System Development
Baselines ........................
159
2.6.2.1.2 System Requirement Baseline ......
161
2.6.2.1.3 System Design Baseline ...........
161
2.6.2.1.4 Preliminary Design Baseline ......
161
2.6.2.1.5 Detailed Design Baseline .........
163
2.6.2.1.6 Implementation Baselines .........
164
2.6.2.1.6.1 Code and Unit Test
Baseline .....................
164
2.6.2.1.6.2 Subsystem Integration and
Test Baseline ................
167
2.6.2.1.7 System Verification Baseline .....
169
2.6.2.1.8 System Acceptance Baselines ......
169
2.6.2.1.9 Implementation Strategy ..........
170
2.6.2.2 Software Package Design ..............
171
2.6.2.3 Software Modularity ..................
173
2.6.2.4 Structure of the PDS .................
177
2.6.2.5 Package Design Standard ..............
182
2.6.3 Configuration Control ....................
186
2.6.4 Project Management .......................
186
2.7 SECURITY ...................................
187
2.7.1 Security Assurance Via Hardware ..........
187
2.7.1.1 Principal Hardware Architecture ......
187
2.7.1.2 Memory Mapping .......................
188
2.7.1.3 CPU States ...........................
190
2.7.1.3.1 Instruction Execution ............
191
2.7.1.4 Monitor Instruction ..................
191
2.7.1.5 Interrupts ...........................
192
2.7.1.5.1 External Interrupts ..............
192
2.7.1.5.2 Internal Interrupts ..............
192
2.7.1.5.3 Interrupt Handling ..............
193
2.7.1.6 Integrity Checks .....................
197
2.7.1.6.1 Passive Checks ...................
197
2.7.1.6.2 Active Checks ....................
197
2.7.1.7 Configuration Control ................
197
2.7.2 Security Assurance via Software ..........
198
2.7.2.1 Summary ..............................
198
2.7.2.2 Terminal Security ....................
199
2.7.2.2.1 Objectives .......................
199
2.7.2.2.2 Man Machine Interface ............
199
2.7.2.2.2.1 Security Attributes ..........
200
2.7.2.2.2.2 Initiation and Termination....
201
2.7.2.2.2.3 Security Attributes of
Users and Terminals ..........
202
2.7.2.2.3 Authentication ...................
203
2.7.2.2.4 Sign On ..........................
204
2.7.2.2.5 Sign Off .........................
204
2.7.2.2.5.1 Sign Off Command .............
204
2.7.2.2.5.2 Automatic Sign Off ...........
205
2.7.2.2.5.3 Terminal Blocking ............
205
2.7.2.2.6 Security Split ...................
206
2.7.2.2.6.1 Security Attributes Line .....
206
2.7.2.2.6.2 Security Command/Response.....
207
2.7.2.2.7 Change of Password .............
207
2.7.2.2.8 Relation to Security Model .....
207
2.7.2.3 Security Audit .......................
208
2.7.2.3.1 Objectives .......................
208
2.7.2.3.2 Auditing Events ..................
208
2.7.2.3.2.1 Terminal Activities ............
209
2.7.2.3.2.2 Communication Lines ..........
209
2.7.2.3.2.3 Local Devices ................
209
2.7.2.3.3 Protection of Auditing Data ......
210
2.7.2.3.4 Audit Trail Analysis .............
210
2.7.2.4 Security Administration...............
210
2.7.2.4.1 Security Data ....................
210
2.7.2.4.1.1 Security Tables...............
211
2.7.2.4.2 Protection of Security Data.......
211
2.7.2.4.3 Manipulation of Security Data.....
212
2.7.2.4.4 Security Transactions.............
213
2.7.3 Security Assurance of the
Integrated System ........................
213
2.7.3.1 Summary ..............................
213
2.7.3.2 Systems Architecture .................
216
2.7.3.2.1 Summary ..........................
216
2.7.3.2.2 DAMOS Operating System ...........
216
2.7.3.2.2.1 DAMOS Functions ..............
217
2.7.3.2.2.1.1 Kernel Functions .........
219
2.7.3.2.2.1.2 General File Management
…02… System ...................
221
2.7.3.2.2.1.3 System Status and
Control...................
221
2.7.3.2.2.2 Process Concept ..............
223
2.7.3.2.2.3 Object Concept ...............
229
2.7.3.2.2.3.1 Access to Objects ........
229
2.7.3.2.2.3.2 Object Types .............
230
2.7.3.2.2.3.3 Logical Object Level .....
231
2.7.3.2.2.4 Memory Protection ............
231
2.7.3.2.4.1 Views ......................
232
2.7.3.2.4.2 Process Layout .............
233
2.7.3.2.4.3 System Mode and System Level
233
2.7.3.2.3 Trusted Computer Base Software....
234
2.7.3.2.3.1 Security Kernel ..............
234
2.7.3.2.3.2 Trusted System Processes .....
237
2.7.3.2.3.3 Trusted Utilities ............
237
2.7.3.2.3.4 Trusted Application
Processes ................ ..
238
2.7.3.2.4 Protection and Encapsulation
of Trusted Computer Base .........
239
2.7.3.2.4.1 Protection of TCB against
Nontrusted Software ............
239
2.7.3.2.4.2 Internal Separation of TCB
Modules ..........................
240
2.7.3.2.5 Security Model ...................
240
2.7.3.2.5.1 Object .......................
241
2.7.3.2.5.2 Security Attributes ..........
243
2.7.3.2.5.3 Access Control ...............
244
2.7.3.2.5.3.1 Mandatory Access Control..
245
2.7.3.2.5.3.2 Discretionary Access
Control ..................
245
2.7.3.2.5.3.3 General Access Control ...
245
2.7.3.2.6 Enforcing Security or
Untrusted Software ...............
245
2.7.3.3 Covert Channel Analysis ..............
246
2.7.3.3.1 Covert Storage Channels ..........
246
2.7.3.3.2 Timing Channelse .................
248
2.7.3.4 Mapping Security .....................
248
2̲ ̲ ̲C̲O̲M̲P̲U̲T̲E̲R̲ ̲S̲Y̲S̲T̲E̲M̲
The computer system proposed for the LKSAA, will be
the very flexible, modular, and versatile CR80 computer,
which has been used with great success in many military
and commercial projects.
While most military and governmental systems require
specially tailored configuration in order to fulfil
the requirements, many commercial systems are delivered
using standard configurations.
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 configurations
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 512K 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 CPUs 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 communictation
lines.
Flexible variation in the size and structure of the
CR80 systems are 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 exploited by
the DAMOS software operating system and programs to
survive 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 not absolutely dedicated
to a specific role. Fault tolerance and backup are
achieved through a redundance scheme without preassignment
of system functions to specific processors. This is
in marked contrast to more common rigid dualized configurations
often encountered in dedicated applications with on-line
master/slave arrangements, or off-line backup with
switchover facility.
2.1 H̲A̲R̲D̲W̲A̲R̲E̲
2.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
In this section a general overview of the hardware
in the Computing System for LKSAA is presented.
In addition to the Computing System, LKSAA includes
the Terminal Equipment in offices, see chapter 4, the
Terminal Equipment in Communications Centre, see chapter
3 and a separate computer system to control the Online
and Offline Cryptos, see chapter 6.
In the basic implementation, the Terminal Equipment
in Offices is directly connected to the Computing System.
Alternatively, these terminals could be connected to
a local area network, which increases the growth capabilities
of the system. As an option, Christian Rovsing A/S
propose a local area network, the X-Net, for this purpose.
This optional X-Net is described in section 2.1.2.
The basic direct connection of these terminals to the
Central Communication System is included in the description
of the latter, which is found in section 2.1.3.
The interface to the terminal equipment in the Communications
Centre is also described in section 2.1.3.
Figure 2.1.1-1
Hardware System Overview
2.1.2 L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲ (Optional)
The basic option for the local area network includes
interface to 10 Terminals in Offices.
This option is based on Christian Rovsing A/S unique
X-Net concept for local area network. In section 2.1.2.1
a general description of the X-Net, and its building
blocks are given.
Section 2.1.2.2 describes the necessary hardware for
the basic option.
Section 2.1.2.3 describes the extension capabilities.
The impact on the System if another local area network
is selected, is described in section 2.1.2.4
2.1.2.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲X̲-̲N̲e̲t̲
The optional local area network is implemented using
CR's unique X-NET concept.
In the following the general features and characteristics
of the X-NET will be highlighted in order to show how
perfect the net fits this application.
The X-NET bus is a serial bus employing Time Division
Multiplexing to share the capacity between the various
users. Data travels on the X-NET bus at a max. rate
of 0.8192 Mbits per second.
The X-NET uses a HDLC-like protocol to ensure that
data either gets uncorrupted through or the user is
informed of fault in the network.
To optimize the utilization of the available bandwidth,
a Dynamic Bandwidth Allocation for the various users
is implemented.
When the application requires higher data rates, up
to 8 X-Nets may be used in parallel, thus adding up
to a total transfer rate of 6.5536 Mbps.
In order to meet requirements for high functional availability,
each branch may be dualized, i.e. the branch contains
2 buses.
Physically each bus in a non-dualized X-NET consists
of a pair of cables running through the site. Thus
a dualized X-Net bus uses 2 pairs of cables.
The units and elements included in one non-dualized
X-NET branch are shown on FIG. 2.1.2-1.
In a Dualized X-Net System, data is transferred between
each remote terminal and one Processor Unit (PU) within
a Computing System by the one X-Net bus which is active.
The other X-Net bus is connecting the remote terminal
to the other PU. This bus is in stand-by mode. Only
one bus is actively transmitting at a time.
The remote terminals are connected to the X-NET buses
by X-NET Terminal Adapters (XTA's). The XTA is a microprocessor-controlled
unit. The application S/W is down-line loaded from
the Communication System through the X-Net bus.
Where data is transferred serially between the remote
terminal and the XTA, the transfer rate is up to
9.6 Kbps.
In a dualized system the XTA is connected to both X-NET
buses but as explained above it is only communicating
on one bus at a time.
The traffic on the X-NET bus(es) is controlled by the
X-NET controller (XCT).
The X-NET Amplifying and Branching Unit (XAB) is used
for extending the bus-length and for creation of subbranches.
When remote terminals are placed so far from the Communication
System that a modem connection is required, this modem
connection is established using an X-NET Communication
Port link (XCP-link). The X-NET behind the XCP-link
has its own controllers but is in fact considered a
subbranch of the X-NET branch to which it is attached.
The X-Net bus(es) is connected to the Processors Units
through the Interface Adapter modules (TIA's).
All modules described above are connected to the X-NET
buses by an X-NET wall outlet (XWO). This XWO provides
galvanic isolation from the bus and features protection
to the bus for component failures in the attached modules,
thus allowing the bus-communication to continue independent
of single-point-failures.
If however communication on an X-NET bus is made impossible
due to H/W failure, communication will be handed over
to the dual X-NET bus, in a dualized system.
Figure 2.1.2-1
X-Net Structure and Units
2.1.2.2 B̲a̲s̲i̲c̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲O̲p̲t̲i̲o̲n̲a̲l̲ ̲L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲
In the pilot project, where up to 10 terminals shall
be connected to the Central Communication System, and
where there is no requirements for high availability,
a single X-Net is proposed for this option.
For the interface to the current IBM word processing
systems, refer to section 4.
As the Local Area Network enters areas outside the
shielded computer and communication area, a TEMPEST
version of the X-NET is proposed.
In this configuration, the X-net bus cables are run
in a metallic pipe and branched off in junction boxes
to the XTA-boxes, which include the XTA-module.
A terminal is connected to the X-net by a signal cable
to a XTA-box.
The XTA Box which is used when connecting a terminal
to the X-net contains one XWO (X-net wall outlet),
one XTA, a filtered CANNON DB 25s connector and a power
supply with power line filtering.
Mechanical dimensions:
Length: 300mm
Width: 210mm
Height: 110mm
The XWO, XTA and the power supply are existing X-net
system elements which in conjunction with the box will
be upgraded to meet TEMPEST requirements.
The XCT (X-net controller), which control data transport,
allocation of guaranteed minimum bandwidth, adaptive
bandwidth allocation and network fault detection, is
placed in the shielded computer and communication area,
wherefore no TEMPEST shielding is required.
2.1.2.3 E̲x̲t̲e̲n̲s̲i̲o̲n̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲ ̲o̲f̲ ̲t̲h̲e̲ ̲O̲p̲t̲i̲o̲n̲ ̲f̲o̲r̲ ̲L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲
̲N̲e̲t̲w̲o̲r̲k̲
The capacity, and/or availability of the basic option
can be upgraded by implementation of one or more of
the following extensions:
a) More terminal equipment to be added:
For each terminal to be added, an XTA is reuired.
On each X-net up to 254 XTAs may be addresssed.
However, a maximum of 64 XWOs may be attached to
a section of a X-net (a section consists of a pair
of cables both terminated at each end). If more
than 64 XWOs are required on one X-Net, X-net Amplifier
and Braching Units (XBAs), are used to interconnect
several sections. The XBA is also used if branching
points are required in the network or where the
extension is more than 0.8 to 1.2 Km. The maximum
coverage is a circle of 5 Km in diameter.
Dependent of the requirement to data throughput,
an increasing amount of terminals may also require
that more than one X-net is used. Up to 8 X-nets
may be connected to the system. The X-nets are
interfaced to each other by aid of X-net communication
port. Each X-net requires a X-net Controller (XCT).
Dependant of the traffic volume between the Central
Communication System (CCS) and the Terminal Equipment,
a STI/TIA (ref. secton 2.1.3) may be required in
each Processing Unit of the CCS and each X-Net.
The requirements to the thoughput to the CCS affects
also the requirement to memory capacity in the
CCS.
b) The Local Area Network shall be extended to non-neighbouring
buildings, so encryption is required:
The required amount of the up to 8 X-nets are moved
to the non-neighbouring buildings. As under a)
the interconnection of the X-Nets is performed
by aid of XCPs, but cryptographic equipment is
used on the interconnecting data link.
c) Increased availability of the Local Area Network
is required:
One or more of the X-Nets in the Local Area Network
may be dualized to increase the availability. In
the CCS this requires an additional TIA per STI,
and the dualized set of X-Nets requires their own
XCTs.
When utilizing dualized X-Nets, another version
of the XTA is used. It contains the additional
XWO necessary for interfacing to the redundant
X-Net.
The XAB Box to be used when:
1) an X-net branch is established
2) signals on the X-net needs to be restored (amplified)
is housed in a box, which is the same size as the XTA-box
and connected to the X-net in the same way. However,
this box has no terminal-connection.
The XAB Box contains two XWO's (X-Net Wall Outlets),
one XAB (X-Net Amplifier and Branching Unit) and a
power supply with line filtering.
Mechanical dimensions:
Length: 300mm
Width: 210mm
Height: 110mm
The XWO, XAB and the power supply are existing X-net
system elements which in conjunction with the box will
be upgraded to meet TEMPEST requirements.
The XCP/XCT Box is used when more than one X-Net is
required, e.g. when a local and a remote X-net are
connected via a CRYPTO/MODEM link.
The XCP- and the XCT-modules can be housed in the same
box, the XCP/XCT-box. The XCP-module provides the interface
to the crypto-link to remote sub-
branches, and to additional X-Nets.
In the main net-end, where the XCT can be situated
in the shielded computer and communications area an
XCP/XCT-box version 1 is used. It contains only the
XCP-module.
In the remote net-end, an XCP/XCT-box version 2 is
used. It contains both modules, as an X-net controller
is required for the remote subbranch.
The XCP/XCT Box version 1 contains 1 XWO (X-net wall
outlet), 1 MP…0e…2…0f… (Multi purpose Multi processor), 1 filtered
CANNON DB 25s connector and a power supply with power
line filtering.
The XCP/XCT Box version 2 is a XCP/XCT Box version
1 with 1 XWO and 1 XCT (X-net controller) added.
Mechanical dimensions (version 1 & 2)
Length: 515mm
Width: 370mm
Height: 110mm
The XWOs, MP…0e…2…0f…, XCT and power supply are existing X-net
system elements which in conjunction with the box will
be upgraded to meet TEMPEST requirements.
2.1.2.4 U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲n̲o̲t̲h̲e̲r̲ ̲L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲
Both hardware and software of the CR80 System is constructed
in a modular way in order to easily adapt new interfaces.
The Software Input-Output Control System consists also
of a number of levels in order to make the external
logic on a lower level transparent to a higher level.
The terminal application process interface to a Format
Handler, which controls the format layout, i.e. the
application does only know the logal items on a VDU
Format.
A set of protocols and handlers exists for each type
of device.
Additions of a new Local Area Network will thus require
a new set of protocols and handlers to be attached
in parallel to the existing sets together with the
addition of one or more hardware interface modules,
depending on the type of the Local Area Network selected.
Thus the modular structure of the CR80 System allows
easy addition of a new type of interface simply by
adding new hardware and software modules.
2.1.3 C̲e̲n̲t̲r̲a̲l̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲
2.1.3.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The Central Communication System is a CR80 configuration
specially modelled to meet the LKSAA requirements.
The Central Communication System (CCS) is completely
dualized in order to create a processor with a very
high availability.
Figure 2.1.3-1 is showing the structure of the CCS.
In normal operation one of the Processing Units (PU's)
is active and the other is in stand-by. The PU serves
the processing and supports the interface to the optional
Local Area Net.
The Channel Units (CU's), which serves the traffic
to terminals in the communication centre and the discs,
are contructed to be dualized units contained within
one physical crate. Each I/O controller module is supported
by the two independent data busses A and B.
Each I/O controller module can be accessed through
both bus A and bus B, though it is only accessed through
one bus at a time from the PU which has claimed access
most recently.
In the CU the power supply is completely dualized as
well.
A watchdog processor (physically placed in one of the
CU's) monitors and controls the PU's. In case of failures,
the watchdog processor will perform switch-over to
the stand-by PU.
Figure 2.1.3-1
Central Communication System Structure
The PU's and CU's are constructed by means of the modular
CR80 computer system by use of various standard modules
(printed circuit boards) organized in units which are
interconnected by galvanic isolated transfer buses
structured as illustrated below, and shortly described
in the following:
Figure 2.1.3-2
CR80 Transfer Bus Structure
The CR80 System Units are housed in 19" crates (Card
Magazine) for installation in standard 19" rack as
shown in Figure 2.1.3-3
Figure 3.1.3-3
CR80 Processor Unit & Channel Unit
Mechanical Layout
2.1.3.1.1 T̲h̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲U̲n̲i̲t̲s̲ ̲(̲P̲U̲)̲
The PU is a multiprogrammable multiprocessor (up to
5 Central Processor Units, CPUs) utilizing virtual
memory and demand paging.
The PU is highly flexible because the selectance of
contained modules can be changed. The modules are interfaced
via a dual bus structure for reduction of bus contention
as shown in FIG. 2.1.3-4.
Figure 2.1.3-4
2.1.3.1.2 T̲h̲e̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲U̲n̲i̲t̲s̲ ̲(̲C̲U̲)̲
The Channel Units contain the CR80 I/O controller modules
for interfacing towards peripheral equipment, communication
lines etc. The CU has an internal dual transfer bus
structure to ensure that no single failure can stop
operation of more than one I/O controller as shown
in figure, 2.1.3-5.
Figure 2.1.3-5
The transfer buses, data bus A and data bus B, are
connected to two different PU's to ensure continuous
access to the controller modules (CTRL, LTU). The characteristics
of data bus A and data bus B correspond to the internal
buses of the PU.
The CIA-modules constitute the interface between the
word oriented internal transfer buses and the byte
oriented data channels.
The I/O controller modules are all based on the same
principle for interfacing to the channel unit bus structure
and for the external interfaces as illustrated in FIG.
2.1.3-6.
Figure 2.1.3-6
The interface to the CR80 system employs a multiported
RAM memory through which the data is exchanged. The
program for the CPU of the controller module is either
resident in PROM chips or is down loaded from the CR80.
The DISK CTRL and PARALLEL CTRL modules employ PROM's
while the Line Termination Modules (LTU) used for interfacing
communication lines, terminals etc., are loaded with
programs from the CR80 meaning that different protocols
can be supported without hardware changes.
On the LTU communication between the bus inteface and
the microprocessor section is done via a RAM area,
called the shared RAM.
The bus interface contains two independent I/O bus
ports implemented by physically separate IC packages.
Thus no interface chip can simultaneously cause failure
of both ports. each port of the LTU has a 6 bit configurable
controller number, as well as an interrupt priority
setting. The only requirement is that the LTU must
be assigned an I/O number distinct from I/O controller
numbers located within the same channel unit.
Furthermore, the I/O interface circuitry contains:
- An Interface Control (including Interrupt Logic)
- An address Counter
- A Sequencer (micro programmed)
The microprocessor part contains:
- A system RAM
- A Bootload PROM
- A microprocessor section
When a LTU is addressed the Interface Control takes
over the control of the LTU. It handles all accesses
from a PU, and ensures that no new access is started
before the currrent one is finished. Upon address recognition,
the Interface Control gives a start signal to the Sequencer.
The Sequencer is controlled by a microprogram. This
program handles the access to the shared RAM, Loading
of the Address Counter, parity control and the hand
shaking between a PU and the microprocessor section
when sharing the shared RAM area. Part of the addressing
bits are by the Sequencer decoded as an instruction
to the LTU.
The Address Counter is a 16 bit up/down counter which
holds the next address in shared RAM to be accessed
from a PU. The loading is as mentioned controlled by
the sequencer which when it detects a "Load Address"
Counter" instruction, loads the address counter withn
the contents of the I/O bus Data lines.
The Microprocessor part of the LTU runs the communication
parts transforming data to/from the Shared Ram Area.
The Firmware Programs controlling the microprocessor
are resident in the System RAM which is a M x 9 bit
(8 bit data + 1 bit parity) dynamic RAM, where MIS
8,16 or 32K depending on LTU TYPE.
The Firmware is loaded to the system RAM by a Multi
Step Bootload Procedure. The PU issues a "boot load"
command to the LTU. This puts the LTU in bootload
mode, having the effect that all microprocessor section
reads are performed in the bootload PROM ("shadow"
PROM) and all writes are done to the system RAM. the
bootload PROM is a "shadow PROM" because the PROM in
the bootload mode during read operations occupies the
8K lower bytes of the system RAM. The microprocessor
now executes the programs resident in the PROM starting
with an offline Diagnostic Test Program. If the test
reveals no failures then the PROM resident bootload
program is executed. If the test detects a failure,
no bootloading is performed. The Bootload Program takes
care of loading the LTU Firmware from the Shared RAM,
to which it has been loaded from a PU, to the system
RAM. Handshaking between a PU and the microproccessor
part during bootload is performed via a status word
in the shared RAM. When the bootload has finished,
the LTU is set in normal mode by a "programmed clear"
command from the PU, and the LTU starts executing the
firmware program.
The microprocessor section contains hardware necessary
to serve the serial communication channels:
- Serial input/output circuitry, which converts parallel
data to serial data for transmission and vice versa
for reception.
- DMA circuitry for fast data transfer between serial
input/output circuitry and shared RAM.
- Synch. and asynchronus operation.
- Timer circuitry for generating the different baud
clocks for each channel. Baud rates are under Software
control. (50 - 9,6 KBd on all 4 channels 0 - 48
KBd on 2 channels)
- Parallel I/O circuitry giving an extended set of
control signals on the communication lines.
Dependant on the complexity of the protocol for which
the LTU shall be used, a number of the lower levels
of the protocol may be handled by the LTU.
Via The Transceiver block, the electrical conversion
between TTL level signals and line level signals and
vice versa is performed.
The physical interface to the peripherals, communication
lines etc., is an adaptor module located at the rear
of the CU Crate. For interfacing to communication
line, a special adaptor module (LIA-S) is available.
An optional version of this module is able to select
a spare LTU module to be used instead of a failing
module. The spare LTU can be back up for a number
of active LTU's (n out of n+1 redundancy).
As the Internal Bus Structure is dualized, the power
input is taken from two separate sources to ensure
that a failure in one power source cannot stop the
CU Operation.
2.1.3.1.3 B̲u̲s̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A CR80 computing system is organized around several
buses, which are described in this section.
A schematic overview showing the interconnection of
the different buses and units are given in Figure 2.1.3-7.
Figure 2.1.3-7
CR80 Bus Structure
Internal in a Processing Unit two buses are available
for data transfer. Electrically and functionally they
are identical, the only differences are related to
the type of module which are connected to them.
To the Processor Bus, the CPU's and Memory are connected,
and to the Channel Bus, DMA modules and memory are
connected.
The two buses are located on each motherboard, mounted
in the back of the PU-Crate.
Internal in a Channel Unit two buses are used for data
transfer, Data Bus A and Data Bus B. The buses are
identically, and further use the same signals as the
Processor and Channel Buses. These two buses are located
on each motherboard, mounted in the rear of the CU-crates.
The Data Channel is a flat cable bus connecting the
buses of a PU (Processing Bus and Channel Bus) with
one of the Data Buses of each CU. The transfer rate
on the Data Channel is up to 0.6 M words/sec.
This is done by means of the Data Channel interface
modules (MAP-MIA), CIA-A & CIA-B.
The Configuration Control Bus is used in the Watchdog
Subsystem. The traffic on the configuration control
bus are directives from the Watchdog about switching
of LTU's and information to the Watchdog concerning
the Crate Power Supply Voltage Levels. Also automatic
switch-over between active and stand-by processor are
performed and monitored by the watchdog.
2.1.3.1.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲S̲y̲s̲t̲e̲m̲
The Watchdog (WD) consists of four parts:
o A Normal LTU
o A Watchdog Controller Adapter (WCA)
o A Configuration Control Bus Adaptor (CCA)
o Colsole Terminals
The interconnection is shown below:
Figure 2.1.3-8
The Watchdog is used only for local supervision and
control, within the PU.
2.1.3.2 L̲K̲S̲A̲A̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲a̲n̲d̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲U̲n̲i̲t̲s̲ ̲(̲B̲a̲s̲i̲c̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲)̲
In this section the basic configuration of each PU
and CU is shown.
Fig. 2.1.3-9 shows the configuration of a PU. The 2
PU's are equipped identically.
The figures 2.1.3-10, -11, -12, -13 and -14 show how
the CU's are equipped. It can be seen, how the peripherals
and terminals in the Communication Centre and the Teletex
Terminals in offices are connected to the 5 CU's.
Note that figures 2.1.3-9 through 2.1.3-15 shows the
configuration of a system without dualization of external
lines. The final correct drawings will be part of the
Systems Design Document.
Note: STI and TIA are part of the Optional Local Area
Network
Figure 2.1.3-9
PROCESSING UNIT
PU #1 & 2
CONFIGURATION DRAWING
Note: One set of DISK CTRL, DCA and DISKDRIVE are optional
Figure 2.1.3-10…01…Channel Unit…01…CU#1
Configuration Drawing
Figure 2.1.3-11
Channel Unit
CU#2
Configuration Drawing
Figure 2.1.3-12
Channel Unit
CU#3
Configuration Drawing
Figure 2.1.3-13
Channel Unit
CU# 4
Configuration Drawing
Figure 2.1.3-14
Channel Unit
CU# 5
Configuration Drawing
2.1.3.2.1 R̲a̲c̲k̲ ̲L̲a̲y̲o̲u̲t̲
The proposed Rack Layout is shown on figure 2.1.3-15.
The Units presented in figure 2.1.3-1 can be identified
as separate physical units placed in the racks.
Each rack has an individual mains switch unit and the
design of the racks provides a good, structued appearance
with easy maintenance access.
The 300 MB Disk Drives are enclosed in a separate cabinets.
Figure 2.1.3-15
Central Communications System
Rack Layout
INTENTIONALLY LEFT BLANK
2.1.3.3 E̲x̲t̲e̲n̲s̲i̲o̲n̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
Due to the modular structure of the CR80 System, it
is very easy to extend the system see figure 2.1.3.3-1.
The processing capacity can be extended by addition
of more CPU's and Memory, and additional disk drives
can be connected.
The system connectivity (number of attached terminal
equipment and external lines) can be increased by addition
of I/O controlling unit (LTU's, PAR CTRL's).
2.1.3.4 D̲u̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲i̲n̲e̲s̲
To avoid that failures in the LTUs result in loss of
characters, a dualization of the LTU's connected to
the external lines is proposed.
In this case the LIAs to be used will have a selector
for outgoing traffic while the incoming traffic is
received by both LTU cahnnels.
This LIA will have a negligable failure rate. Considering
the overall MTBF for the communication channel, up
to the public or private circuit the crypto, which
has a MTBF which is very low, will be the vulnerable
item.
To implement the dualization of the 18 LTU's for external
communication, additional 13 LTU's are required.
In this case the number of spare channels is reduced
to 2 Teletex Channels.
Additionally 1 crate with interfacing equipment, PSUs
and fan is also required for the installation of the
LTUs.
FIGURE 2.1.3.3-1…01…CR80 FATOM - Fault Tolerant Multiprocessor
2.1.4 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲M̲a̲t̲r̲i̲x̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲C̲o̲m̲p̲u̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
2.1.5 S̲y̲s̲t̲e̲m̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲ ̲a̲n̲d̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲v̲i̲t̲y̲ ̲o̲f̲ ̲C̲o̲m̲p̲u̲t̲e̲r̲ ̲S̲y̲s̲t̲e̲m̲
2.1.5.1 L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲(̲O̲p̲t̲i̲o̲n̲)̲
In the basic implementation a Local Area Network is
not included. It is included as an option which may
give interface to 10 terminals in offices.
2.1.5.2 C̲e̲n̲t̲r̲a̲l̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲
2.1.5.2.1 P̲r̲o̲c̲e̲s̲s̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
Each PU contains 2 CPU/CACHE to form a multiprocessor
system. This gives a typical execution speed of 1.1
M instructions per sec.
The CPU part of the CPU/CACHE module is a general purpose
processing unit with a 16 bit word length and capable
of addressing 2K x 64 words of memory.
The standard instruction repertoire has more than 220
basic arithmetic, logic, transfer and special instructions
including bit, byte, word and multiple word manipulations.
Internal context registers include 8 general purpose
accumulators or index registers and 9 special purpose
registers. Instructions are provided to save and load
all registers minimizing overhead during context switching.
Instructions can be addressed directly or indexed;
data is always addressed relative to the Base Register.
Instructions are addressed in 16 bit words. Data may
be addressed in multiples of bits, bytes or words.
Two ALU's (Arithmetic Logic Units) are included, allowing
address and data manipulations to be performed simultaneously,
or allowing address calculations involving three elements
to be performed in one cycle when employing base register
addressing.
The micro-instruction cycle time is 250 ns.
The CPU may execute in two states:
- USER state, and
- SYSTEM state
In the system state, the CPU will further be at one
of 15 system levels which are numbered 1 through 15.
In user state, the level is 0.
In U̲S̲E̲R̲ ̲s̲t̲a̲t̲e̲, the CPU is not allowed to execute any
priviledged instructions and it is subject to the memory
access protection mechanism of the MAP module.
In S̲Y̲S̲T̲E̲M̲ ̲s̲t̲a̲t̲e̲, the CPU is not subject to the memory
access protection mechanism of the MAP module.
For those of the instructions which may be executed
on levels 1 to 14, a memory write protection mechanism
based on a BOUND register applies: the CPU only allows
write operations to locations with effective logical
addresses lower than or equal to the current value
of the BOUND register. This mechanism is implemented
in the CPU alone (not involving the MAP module).
Instructions which may only be executed on level 15
(highest level) are subjected neither to the MAP module
nor to the BOUND register memory protection mechanisms.
In the CR80 system, four types of vectored interrupts
exist:
- Module Interrupts
- CPU Interrupts
- Power Failure Interrupts
- Real-Time Interrupts
And two types unvectored interrupts:
- Fast Timer Interrupt
- Termination (Error) Interrupts
The interrupts are resolved by hardware within the
Memory MAP module.
T̲h̲e̲ ̲C̲A̲C̲H̲E̲ ̲M̲e̲m̲o̲r̲y̲ ̲p̲a̲r̲t̲ of the CPU/CACHE consists of
a 1k x 38 bit static memory directly connected and
accessible from the CPU without using the processor
bus.
Fundamentally, the CACHE memory provides a small high
speed buffer containing copies of most recently accessed
memory locations in the PU.
The CACHE memory algorithm used is the "write through
algorithm", which stores all of a CPU's "reads" from
Main Memory via the processor bus in its CACHE memory
and refers all the CPU's "writes" directly to Main
Memory with its CACHE memory updating itself in parallel
if it contains the specified address.
The CACHE memory also monitors the "write" accesses
done by other CPU's on the processor bus and by DMA's
on the channel bus, and in case it contains the specified
address, it is erased in the CACHE memory.
The above together with the "write through algorithm"
ensures that the contents of addresses stored in PU
memory and the CACHE memories of CPU's are always identical.
When context switching on the CPU takes place, normally
associated with change of CPU logical memory view,
the complete CACHE memory content is erased.
The efficiency of the CACHE memory relies on the basic
principle that, in the step by step execution of a
program, a CPU-originated read operation at an address
has a high probability of being repeated, and therefore
can be found in the CACHE memory after the first access
to it.
Two advantages when using CACHE memories are obtained:
- Loading of the Processor Bus is reduced, allowing
for the use of more CPU's before bus contention
occurs. The max number of CPU/CACHE's to be connected
without risk of continuous bus contention has been
raised to 5, compared to 2 if CPU's without CACHE
memory had been used.
- Average access time when performing memory read
operations is reduced, as reads from CACHE is faster
than from Main Memory, thus improving the speed
of each CPU.
Generally, the presence of the CACHE memory is only
visible to the programmer in terms of improved execution
speed, as no CACHE handling software is required.
M̲u̲l̲t̲i̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲E̲n̲h̲a̲n̲c̲e̲m̲e̲n̲t̲,
U̲t̲i̲l̲i̲z̲i̲n̲g̲ ̲C̲P̲U̲/̲C̲A̲C̲H̲E̲
The calculated benefits from using the CPU's with CACHE
memory in the PE are as follows.
Based on analysis and measurements on the distribution
of 12147 instructions of DAMOS Kernel programs, it
was found that the average instruction has 1.98 memory
references.
With one CPU/CACHE in a PU, and assuming a negligible
frequency of memory-write-operations initiated by other
address sourcing modules than the CPU's, the overall
CPU efficiency (80% HIT RATE) will improve 40% due
to faster memory access, relative to a CPU without
CACHE memory. The CPU/CACHE, on average (80% HIT RATE),
uses 28% of the processor-bus bandwidth.
Thus, some improvement of the throughput will result
with a single CPU/CACHE in a PU, but the main advantage
is that a greater number of CPU's can be used in a
single PU without heavy processor-bus contention.
2.1.5.2.2 R̲a̲n̲d̲o̲m̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲e̲m̲o̲r̲y̲
Each PU is equipped with 1.5M word of Random Access
Memory, which serves as virtual working memory.
The memory management is controlled by the MAP function
of the MAP module.
The concept is that of "Logical-to-Physical Address
Translation". The amount of memory required by a process
is defined to be its "view" or "logical address space".
This space may be as large as 2 x 64 1K pages. The
areas of physical storage assigned to the process are
defined to be its "physical address space". The address
translation function which converts the addresses in
the logical space to the addressees in the physical
space is called the view for that user. The view is
implemented by two Translation Tables which each contains
64 entries. Each of these entries defines the physical
address of a logical 1K word memory page.
The view is totally under control of the system software.
Each 1K page can be read and/or write protected.
The CR80 Advanced Multiprocessing Operating System
(DAMOS) determines what these maps are to be, and then
relays this information to the address translation
hardware. The figure 2.1.5-1 shows the logical-to-physical
address translation.
The mapping ensures total integrity, security, and
protection against interference by other users, e.g.
programs being debugged while the system is running
in actual on-line operation. Beyond being able to read
and/or write protected, each 1K page separately can
be marked "absent" giving rise to a page fault interrupt
when accessed. This feature is utilized in DAMOS to
implement an efficient Virtual Memory System allowing
Application Software requiring a large accessable address
space to run on smaller memory size CR80 computers.
The page fault interrupt issued when a page not resident
in memory is addressed by a CPU will initiate that
the page is rolled into memory from discs.
Figure 2.1.5-1…01……01…Address Sourcing Device Logical Address Space
Each of the up to 5 possible CPU's in a Processing
Unit works with its own private pair of Translation
Tables. One is allocated for p̲r̲o̲g̲r̲a̲m̲, i.e. the collection
of machine instructions compiled to perform a certain
function, while the other is allocated for the d̲a̲t̲a̲,
i.e. the collection of constants and variables and
data required to execute the function.
The Memory Map address translation circuitry can contain
64 translation tables. This means that change of user
(process switch) on a CPU, and the associated change
of view, often can be done just by changing the CPU's
Translation Table pointers (TTR pair) not having to
load the Translation Tables of the user view. This
feature is used by DAMOS for always having its Translation
Tables resident in the Memory Map.
In addition to the memory management function, the
MAP module performs the following functions:
- Timing and control
- Processor- and Channel Bus Authority control (arbitration)
- Datachannel interface
- Interrupt Preprocessing
- Bootstrap PROM
- PU-initialization and selfcheck control
2.1.5.2.3 P̲e̲r̲i̲p̲h̲e̲r̲a̲l̲ ̲D̲i̲s̲k̲ ̲M̲e̲m̲o̲r̲y̲
To be able to store 14 days of traffic at upper limit
337M byte of long term disk storage is required in
1990 and 545M byte for 1995.
As the requirement for short term storage is 15 to
40M bytes, the Central Communication System is equipped
with 4 300M byte disk drives. Optionally one additional
300M byte disk drive is proposed for off-line storage.
The disk drives are equipped with exchangeable disks.
One additional disk is provided.
The 4 basic 300M byte disks are working 2 and 2 in
parallel, and are used for storage of uncompleted message
transfers and for a short time archivation of processed
messages, as well as for long time storage of the latest
14 days traffic.
The optional Off-line storage may be used to store
traffic, where a longer time storage is desired. Messages
to be stored in this way are copied from the On-line
storage.
The disk controllers for the 4 or 5 disk drives are
situated in CU #1, and CU #5.
Based on the upper limit traffic load for 1990, the
number of disk accesses can be calculated as follows:
N̲u̲m̲b̲e̲r̲ ̲o̲f̲ ̲D̲i̲s̲c̲ ̲A̲c̲c̲e̲s̲s̲e̲s̲
Incoming msgs at peak hour load:308 6160
Outgoing msgs at peak hour load:462 2310
̲ ̲ ̲ ̲ ̲ ̲
Total Disk Access per peak hour 8470
Total per second 2.4
Per busy second 12
The calculation is based on 20 Disk Accesses per message
for incoming messages used for message analysis, conversion
and local distribution. For outgoing messages 5 disk
accesses is estimated for preparation, conversion and
transmission. Furthermore the number of accesses in
busy second, is obtained by multiplying the load per
second during peak hours by 5.
Similarly the number of accesses for telex preparation
can be calculated:
N̲u̲m̲b̲e̲r̲ ̲o̲f̲ ̲D̲i̲s̲k̲ ̲A̲c̲c̲e̲s̲s̲e̲s̲
Pages per peak hour: 285 1425
Total per second 0.4
Total per busy second 2
The total no. of disk accesses in busy second thus
becomes 14, while the possible amount is 50, corresponding
to approximately 30% utilization.
2.1.5.2.4 T̲e̲r̲m̲i̲n̲a̲l̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
The Central Communication System is equipped to give
connectivity to the following terminals:
In Communications Centre:
12 VDU's (i.e. 1 spare channel)
(excluding the VDU connected to the Watchdog,
i.e. 1 spare channel)
12 Printers (i.e. 3 spare channels)
1 OCR (i.e. 3 spare channel)
4 Papertape Readers (i.e. no spare channels)
4 Papertape Punch (i.e. no spare channels)
1 High Speed Printer
2 Document Printing Systems
(i.e. 6 spare channels, 2 LTU's have been used for
redundancy purposes)
1 Colour Graphic System
In Offices:
20 Telexstations (i.e. 2 spare channels)
1 IBM 5520
1 IBM 6580
The types of terminals are as specified in section
3.2.
2.1.5.2.5 O̲f̲f̲-̲L̲i̲n̲e̲ ̲C̲r̲y̲p̲t̲o̲g̲r̲a̲p̲h̲i̲c̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
The Central Communication System is equipped with interfaces
for 4 Off-line cryptos. The interfaces for these cryptos
(key loading and message information) will be designed
in accordance with the specifications in the RFP, part
1, annex 10.8.
The Central Communication System will generate a command
to the crypto system , which in turn will present the
requested key information to the Off-line crypto.
When key loading has taken place and the Central Communication
System has transmitted the "Program V", as specified
in the RFP, part 1, annex 10.8, the encryption starts
with the first character. After the last character
has been encrypted 15 x K will be added to terminate
the message.
The Encrypted Message is then stored on a secured area
of the disc until transmission takes place. Off line
Encrypted Messages received by the Central Communication
System are handled in a similar way for decryption
and may be stored on disc prior to distribution or
handled by the operator in accordance with operational
rules.
If the incoming message header indicates a key store
number (bereichkennzeichen), then this will be communicated
to the Crytpto System, which selects the proper key.
If the keying information contained in the header of
an incoming message does not correspond to a key known
by the Central Communication System, the messages will
be routed to the text correction position for manual
handling.
An Off-line encrypted message may be transmitted or
received from a leased telegraph circuit, an HF radio
circuit or telex, and it may further be superencrypted
by one of the On-line cryptos.
2.1.5.2.6 O̲n̲-̲L̲i̲n̲e̲ ̲C̲r̲y̲p̲t̲o̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
There are two types of On-line cryptos.
ELCROTEL E4s is assumed to be used on telegraph/telex
lines, while ELCROBIT 96 will be used on permanent
leased/public telephone lines.
2.1.5.2.6.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
In the RFP, part 1, section 1.13, it is stated that
X21/X24 and X26 or X27 interface specifications must
be supported. For this reason crypto will not be used
on teletex lines.
The LTU's are for this application programmed for interface
with X 21/X 24 with automatic dialing facilities in
which case the LTU's each support 4 channels.
X21/X24 Electrical Interfaces is implemented in the
LIA.
2.1.5.2.6.2 E̲L̲C̲R̲O̲T̲E̲L̲ ̲E̲4̲s̲
The E4s will be connected to HF radios, leased telegraph
circuits or the telex network. During set-up of the
connection, the E4s are bypassed until the exchange
of answer-back functions between the two stations has
taken place.
As soon as the connection is verified, and if encryption
is required the E4s is switched into the line and the
key is loaded by the crypto system. A second answer-back
exchange is performed in order to ensure that the two
cryptos are synchronized on the same key.
Once this has taken place, data will be transferred
with the distant station.
2.1.5.2.6.3 E̲L̲C̲R̲O̲B̲I̲T̲ ̲9̲6̲
The EB 96 will not be supported.
The Central Communication System will handle the filtering
of messages so that messages, which does not fulfil
the security requirements for transmission on open
non-en`crypted lines wil be rejected. A rejected message
will cause an alarm at the security operators console,
indicating the reason for rejection and the message
identification.
The Central Communication System is equipped to give
connectivity to the following communication channels:
30 Leased Telegraph Channels
10 Permanent Circuit
6 Radio Channels
10 Telex Circuits
6 Teletex Circuits (i.e. 1 spare channels)
Within each of the above groups, the same communication
protocol shall apply to all channels respectively circuits.
(The COREU and WUI protocol is handled on a higher
level of the software).
For the Automatic Call (X21/X24) the following procedure
is foreseen:
a) O̲u̲t̲g̲o̲i̲n̲g̲ ̲C̲a̲l̲l̲
The address of the called unit is transmitted as
selection signals to the DCE, which in turn will
return with the called line identification (it
is assumed that the telex/teletex net supports
this function), which is compared with the address.
If the message must be encrypted the Central Communication
System will request the Crypto System to present
the corresponding key to the crypto used on that
link, and to switch the crypto into the line.
The Crypto System loads the proper key and sends
a command to the switching panel to switch the
crypto into the line.
The Crypto System gets an acknowledge and status
from the switching panel, analyses the status for
correctness and transmits an acknowledgement to
the Central Communication System, which initial
sizes synchronization of the crypto.
If the message shall be transmitted unencrypted,
the Central Communication System sends a dummy
request to the Crypto System and a request to verify
status of the switching panel for that particular
line. Upon receipt of an acknowledgement from the
Crypto System the message will be transmitted on
the open line.
When crypto synchonization is achieved, data will
be released for transmission. It is assumed that
the crypto signals this condition by the 'ready
for data' - state.
b) I̲n̲c̲o̲m̲i̲n̲g̲ ̲C̲a̲l̲l̲
Upon receipt of the calling line identification,
the Central Communication System analyze the call
in order to identify, whether the line shall be
set-up with crypto or not. When this has taken
place the Central Communication System and the
Crypto System will react as explained in 2.1.5.2.6a.
For the other Communication Channels a similar procedure
will apply, except that for channels without automatic
call the selection state and DCE provided information
is ommitted.
2.1.5.2.7 External Lines Bypassing The On-Line Cryptographic
E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
Messages are required to be transmitted either via
the cryptos or directly to the same line bypassing
the crypto.
There are several cases to consider:
1. Off-line encrypted message
a. Via crypto
b. Directly to permanently leased line or HF radio
c. Via telex
2. Plain language message:
a. Via crypto
b. Directly to permanent leased line or HF radio.
c. Via telex
d. Via public telephone net or teletex
Connections to telex and other communication lines
or HF link, which require set-up in plain language,
will be performed through bypassing of the crypto units.
The criteria for sending a message without encryption
must by very strict. All of the following criteria
must be met:
a. Message must be unclassified
b. Message destination must be non-restricted
c. Message must be marked unencrypted
d. Message must be released by security operator
e. Acknowledge of switch position from Crypto System
must be received by the ZVA
The Central Communication System will handle the filtering
of messages so that messages, which do not fulfil the
security requirements for transmission on open non-encrypted
lines will be rejected. A rejected message will cause
an alarm at the security operators console, indicating
the reason for rejection and the message identification.
2.1.5.2.8 P̲u̲b̲l̲i̲c̲ ̲T̲e̲l̲e̲p̲h̲o̲n̲e̲ ̲N̲e̲t̲
Future connection to the public telephone net can be
established through the Line Terminnation Units (LTU),
which can be down-loaded to use different protocols
and speeds.
LTU's are available with HDLC, SDLC, BSC and many other
protocols.
Modems operating at 1200, 2400 and 4800 bps with auxiliary
back-channel facitilies (V26 bis and V27 ter) can be
controlled by the LTU's.
Dial-up is controlled in accordance with CCITT Rec.
V25.
Data Rate selection and backward-channel facilities
are in accordance with CCITT Rec. V24.
In order to establish a call, the operator must either
specify the total number to be dialed or the destination.
If destination is used, a look-up in an address table
will be performed by the Software and the number will
be automatically communicated to the LTU, which will
convert the digits one by one to V24 binary code, thereby
establishing the call. When the connection has been
established, the LTU will transmit the message using
the required protocol.
Interconnection to future digital telephone networks
(ISDN) will also be possible.
As a detailed CCITT recommendations for ISDN (future
I-recommendations) are unavailable, until 1985 the
non-recurrent cost cannot be estimated.
2.1.5.2.9 H̲i̲g̲h̲ ̲S̲p̲e̲e̲d̲ ̲O̲p̲t̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲L̲i̲n̲k̲
The Interface to the 64 kbit/s Optical Data Communication
Net is not included in this proposal.
The proposed CR80 System is due to its modularity well
prepared for such future extension.
Such interface to a 64K bit/s line is possible by the
addition of one or more LTU's of a type specially suitable
for this interface. The Interface Adaptors will have
the opticl interface.
Due to the high data rate each LTU can only be equipped
with one channel.
Additionally this extension will require adjustment
of the softwre package for traffic handling, e.g. a
larger buffer size my be required. This means also
that more memory may be required.
The capacity of the proposed LKSAA System enables extension
to support 4 lines at 64 K bit/s by addition of hardware
and change of software.
As a detailed Interface Specification is unavailable,
the non-recurrent cost cannot be estimated.
The recurrent cost for LTU's and LIA's will be of the
same order of magnitude as for the other LTU's and
LIA's used in the system.
Such interface to a 64 kbit/s line is possible by the
addition of one or more LTU's of a type specially suitable
for this interface. The Interface Adaptors will have
the optical interface.
Due to the high data rate each LTU can only be equipped
with one channel.
Additionally this extension will require adjustment
of the software package for traffic handling, e.g.
a larger buffer size may be required. This means also
that more memory may be required.
The capacity of the proposed LKSAA System enables extension
to support 4 lines at 64 kbit/s by addition of hardware
and change of software.
As a detailed CCITT recommendations for ISDN C coming
I-recommendations unavailable until 1985, the non-recurrent
cost cannot be estimated.
The recurrent cost for LTU's and LIA's will be of the
same order of magnitude as for the other LTU's and
LIA's used in the system.
2.2 S̲O̲F̲T̲W̲A̲R̲E̲
The proposed system is already developed for NATO and
this Operating System as well as Application Software
exists as tested and integrated packages.
2.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
2.2.1.1 S̲t̲a̲n̲d̲a̲r̲d̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
The CR80 Advanced Multi Processor Operating system
DAMOS is the standard operating system for memory mapped
CR80 systems.
DAMOS is divided into operational and support software.
DAMOS includes a virtual memory operating system kernel
for the mapped CR80 series of computers.
DAMOS fully supports the CR80 architecture which facilitates
fault tolerant computing based on hardware redundancy.
DAMOS supports a wide range of machines from a single
Processing Unit (PU) with 1 CPU and 128 K words of
main memory, and up to a maximum configuration with
16 PU's where each PU has 5 CPU's and 16 M words of
virtual memory and a virtually unlimited amount of
peripheral equipment including backing storage.
DAMOS is particularly suited for use in real time systems
but also supports other environments such as software
development and batch. The main objectives fulfilled
in DAMOS are: high efficiency, flexibility, and secure
processing.
DAMOS is built as a hierarchy of modules, each performing
its own special task. The services offered by DAMOS
include CPU, PU, and memory management. Demand paging
is the basic memory scheduling mechanism, but process
swapping is also supported. Other levels of DAMOS
provide process management and interprocess communication,
basic device handling and higher level device handling
including handling of interactive terminals, communication
lines, and file structured backing storage devices.
Multilevel security is an integral part of the DAMOS
Design. All objects such as message segments, files,
devices, terminals are referenced indirectly by application
and system processes, and each access is checked according
to manadatory and discretionary access rules.
The Reference Monitor Concept is thus used throughout
DAMOS. A complete overview of the security system may
be found in section 2.7.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DAMOS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
OPERATIONAL SUPPORT
SOFTWARE SOFTWARE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
- Kernel
- resource management - development operating
system
- directory functions - system generation software
- process management - maintenance and diagnostic
- memory management programs
- process communica-
tion
- device management
- device handling
- error processing
- real time clock
- PU management
- Transport Mechanisms
- Input/output system
- File Management
- Magtape Management
- Terminal Management
Database Monitoring System
- Initialization
System Status and Control
System Functions
Figure 2.2.1.1-1…01…DAMOS Software Overview
DAMOS provides an operating system kernel which integrates
supervisory services for real time, interactive and
batch systems.
The DAMOS standard operational software is described
in sections 2.2.2.1.1.1 - 2.2.2.1.1.11 The description
is divided into the following areas:
- Overview of DAMOS
- Kernel,
which describes the DAMOS operating system kernel
components
- DAMOS Input/Output,
which describes the DAMOS standard interfaces to
peripheral I/O equipment, the DAMOS disk file management,
magnetic tape file management (optional), terminal
and communication line management systems and Database
Monitoring and Control System (optional)
- System initialization
- System Status and Control
- Common System Functions
2.2.1.1.1 O̲v̲e̲r̲v̲i̲e̲w̲ ̲o̲f̲ ̲D̲A̲M̲O̲S̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
DAMOS may be visualized as the implementation of a
set of abstract data types and a corresponding set
of tools for creating and manipulating instantanions
(objects) of these types.
The major components in DAMOS are the Kernel, the File
Management System, the Magnetic Tape File Management
System (optional), the Terminal Management System,
the Database Monitoring and Control System (optional)
and the System Status and Control.
The DAMOS Kernel exists in one incarnation for each
processing unit (PU). The data types and functions
implemented by the Kernel are:
D̲a̲t̲a̲ ̲T̲y̲p̲e̲ F̲u̲n̲c̲t̲i̲o̲n̲
CPUs CPU management and scheduling
processes process management
virtual memory segments memory management
PU's PU management
synchronization elements inter process communication
device device management and
basic device access
methods
ports basic transport service
The Kernel also provides facilities for
- processing of errors
- centralized error reporting
- a data transfer mechanism
- a PU service module
The File Management System (FMS) implements files on
disks. The FMS provides functions for manipulating
and accessing files and controls a group of disks units.
The FMS may exist in several incarnations in each
PU where each incarnation controls its own devices.
The Terminal Management System (TMS) is similar to
the FMS. It provides functions for manipulating and
accessing communication lines and terminals including
line printers. The objects accessed via the TMS are
called units. A unit may be an interactive terminal,
a line printer or a virtual circuit. The TMS controls
a group of communication devices attached via LTUs,
LTUXs or a parallel controller.
The TMS may exist in several incarnations in each PU,
each incarnation controlling its own devices.
The Magnetic Tape File Management System handles files
on magnetic tape units.
The Database Monitoring and Control System provides
and controls functions for manipulating of the Database
System.
The System Status and Control Starts, allocates resources
to the CCIS Processes.
A common security policy and hierarachical resource
management strategy is used by the Kernel, the FMS,
the DMCS and the TMS. These strategies have been designed
with the objective of allowing multiple concurrent
higher level operating systems to coexist in PU in
a secure and independent manner.
2.2.1.1.2 K̲e̲r̲n̲e̲l̲
The DAMOS Kernel is a set of reentrant program modules
which provide the lowest level of system service above
the CR80 hardware and firmware level.
The Kernel consists of the following components:
- Resource Management,
which administers resources in a coherent way
- Directory Functions,
which provide a common directory service function
for the other Kernel components. It also performs
all access authorizations to objects upon request
from the other modules.
- Process Manager,
which provides tools for CPU management, process
management and scheduling
- Page Manager,
which provides memory management tools and implements
a segmented virtual memory
- Process Communication Facility,
which provides a mechanism for exchange of control
information between processes
- Device Manager
which provides a common set of device related functions
for device handlers and a standard interface to
device handlers
- Device Handlers,
which control and interface to peripheral devices
- Error Processor,
which handles errors detected at the hardware and
Kernel level and provides a general central error
reporting mechanism
- Real Time Clock
for synchronization with real time
- PU Manager,
which provides functions for coupling and decoupling
PUs
- Transport Mechanisms
which provides general mechanisms for exchange
of bulk data between processes and device handlers.
The following subsections describe the main Kernel
functions:
- resource management
- process management
- memory management
- process communication
- CPU management
- PU management
- Transport Mechanisms
The security functions are described in section 2.7.
2.2.1.1.2.1 R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The goal of DAMOS Resource Management is to implement
a set of tools which enables the individual DAMOS modules
to handle resources in a coherent way. This again,
will make it possible for separate operating systems
to implement their own resource policies without interference.
Further built-in deadlock situations will be avoided.
The resource management module governs anonymous resources,
such as control blocks. Examples of resource types
are:
- process control blocks
- segment control blocks
- synchronization elements
- PU directory entries
Each type of resource is managed independently from
all other types.
The resources are managed in a way that corresponds
to the hierarchical relationships among processes.
Two operating systems which have initially got disjoint
sets of resources, may delegate these resources to
their subordinate processes according to separate and
non-interfering strategies. For example, one operating
system may give all its subordinate processes distinct
resource pools, i.e. there will not be any risk of
one process disturbing another. On the contrary, the
other operating system may let all its subordinate
processes share a common pool, i.e there may be a much
better resource utilization at the cost of the risk
for deadlock among these processes.
2.2.1.1.2.2 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Process Management is concerned with long term control
of processes (e.g. their creation and deletion from
the system).
A process may be defined as an incarnation of the data
transformations obtained by execution of a program
in a given context. A context is taken to mean a set
of CPU registers (CPU resident or saved) and the two
memory translation tables describing the logical data
space seen when the process is executing.
A process is represented by a Process Control Block
(PCB). It is identified by an object descriptor as
described in Directory Functions.
Each process competes with other processes for the
system resources such as processor power, physical
memory, I/O service, etc.
During the lifetime of a process it undertakes different
process states. Figure 2.2.2.1.1.2.2-1 shows the process
states in conjuction with long and medium term scheduling,
and the process management functions which cause transitions
between them.
See figure in section 2.7.3.2.2-1
1: The process is subject to CREATE PROCESS
2: The process is subject to DELETE PROCESS
3: The process is subject to RESUME PROCESS
4: The process is subject to PASSIVATE PROCESS
or
RETIRE
Figure 2.2.1.1.2.2-1
Process Management
The process state ACTIVE may be further refined by
the short term scheduling (dispatching) as depicted
in figure 2.2.2.1.1.2.2-2.
See figure in section 2.7.3.2.2.2-2
The events which cause transitions between the different
active states are:
1: The process is scheduled by the dispatcher
2: The process is preempted by the dispatcher
3: The process is blocked awaiting some event
4: A previous awaited event occurs
Figure 2.2.1.1.2.2-2
Active Process States
2.2.1.1.2.3 P̲r̲o̲c̲e̲s̲s̲ ̲H̲i̲e̲r̲a̲r̲c̲h̲y̲
Processes are organized in a hierarchical manner as
shown in figure 2.2.2.1.1.2.2-3.
See figure in section 2.7.3.2.2.2-3
Figure 2.2.1.1.2.2-3
Process Hierarchy
A process may create subordinate processes. These are
called child processes in relation to the creator process,
which in turn is called their parent process.
The purpose of having a process hierarchy is to enable
implementation of multiple operating systems each having
supreme control over the processes of its process subtree.
The following process management routines are available
to the user:
CREATE PROCESS
which intiates a new process instance to run on
a specific processor pool. The new process is given
access to specified resource pools, and inherits
a set of object descriptors at the discretion of
the creator. The new process does not get execution
time before its parent process calls Resume Process.
RESUME PROCESS
which activiates a process which was either just
created or was previously passivated.
PASSIVATE PROCESS
which deactivates a process, that is the process
is temporarily withdrawn from the dispatching
CLEAN UP PROCESS
which catches a child process and terminates its
activities. Among other things, its possible child
processes are cleaned up and deleted, and outstanding
process activities (I/O requests, process communication)
are cancelled.
DELETE PROCESS
which removes a previously cleaned process from
the system. The resources occupied by the process
are returned to the caller (its parent process)
RETIRE
which passivates the caller and sends possible
error information to its parent process.
GET PROCESS ATTRIBUTES
which returns the current attributes of a child
process
CHANGE PROCESS ATTRIBUTES
which changes specified attributes of a child process.
The attributes may relate to the dispatching of
the process (e.g. its priority), or to the page
manager parameters for the process (e.g. the size
of its working set).
2.2.1.1.2.4 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 (restricted
by security constraints) 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.
2.2.1.1.2.5 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. Communication between
processes is restricted by security constraints.
2.2.1.1.2.6 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.
2.2.1.1.2.7 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.
2.2.1.1.2.8 T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s̲
2.2.1.1.2.8.1 B̲a̲s̲i̲c̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲
Basic Transport Service (BTS) is a module within DAMOS
which enables processes to communicate in a uniform
manner, whether they are located:
1) in the same CR80 processor unit
2) in computers connected via a supra bus, running
the same operating system
3) in computers connected via a communication line,
running independent operating systems.
2.2.1.1.3 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.
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 Database Controller System for communication
with the Database Management System.
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.
Figure 2.2.1.1.3-1
Interrelationship of IO System
and General File Management Systems
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.
2.2.1.1.4 F̲i̲l̲e̲ ̲a̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲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 described in the following:
- devices and volumes
…02…- directories
- files
- users
- integrity
- access methods
All accesses via FMS by user processes are security
checked.
2.2.1.1.4.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.
2.2.1.1.4.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 do 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.
2.2.1.1.4.3 F̲i̲l̲e̲s̲
2.2.1.1.4.3.1 F̲i̲l̲e̲ ̲T̲y̲p̲e̲s̲
The file system supports two different organizations
of files on disk. A 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.
2.2.1.1.4.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.
2.2.1.1.4.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)
2.2.1.1.4.5 D̲i̲s̲k̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
2.2.1.1.4.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 classificatio 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.
2.2.1.1.4.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.
2.2.1.1.4.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 bve 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.
2.2.1.1.4.6 A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
The file management system implements two access methods
to files:
2.2.1.1.4.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.
2.2.1.1.4.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.
2.2.1.1.4.7 M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
M̲essage M̲anagement S̲ystem contains facilities for storage
of messages and similar items on disk and manipulation
of these messages and items.
Each item is stored in an entity called Common Information
File. The main difference between a CIF and an ordinary
file is that CIFs are relatively small, and that they
are subject to very intense activity during a relatively
short period after their creation. After that period
they will be stored permanently, and will be subject
to very low activity. MMS will optimize storage of
and access to itmes according to the activity level.
2.2.1.1.5 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.
All accesses via TMS by user processes are security
checked.
The following subsections define:
- transfer of I/O data
- user handling
- hardware categories
2.2.1.1.5.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.
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.
It 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.
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.
2.2.1.1.5.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.
2.2.1.1.5.3 S̲e̲c̲u̲r̲i̲t̲y̲
The protection of data entrusted to the Terminal 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 line. The ACL is a table which
described the access rights of each individual user
group (one being the public) to the corresponding line.
Whenever a user tries to access a line 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 classifications system. Each user and each
line is assigned a clasification. The user classification
is recorded in the user control block and the line
classification is recorded in the line control block,
classification levels of the user and the line match
to each other.
2.2.1.1.5.4 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.
2.2.1.1.5.4.1 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.
2.2.1.1.5.4.2 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.
2.2.1.1.5.4.3 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.
2.2.1.1.6 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. Root
creates and intializes a File Management System, a
Terminal Management System and a System Status and
Control System.
2.2.1.1.7 S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲u̲s̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
The SSC package starts, allocates resources to, monitors
and controls the ZVA on-line and off-line system through
interaction between the two PUs, the peripherals, the
watchdog, and the operator.
The on-line modes of operation handled are:
- a dualized system consisting of one active PU and
associated peripherals and a stand-by PU
- a degraded system consisting of one active PU and
associated peripherals and an off-line PU and associated
peripherals
In the degraded system the SSC controls the off-line
operations:
- software development and test
- table generation
- maintenance and diagnostics
- offline utilities
The monitoring of the active and the standby system
includes:
- reception of error reports from other packages
- reception of hardware status from crates
- display of system status
- execution of on-line diagnostics programs
The control of the dualized and degraded system includes:
- physical connection of hardware modules
- allocation of resources to other packages e.g.
external and terminal lines
- execution of operator commands
The start-up of the dualized and degraded system includes:
- all forms of initialization
- ordered switchover to a stand-by processor and
corresponding recovery and restart actions
- recovery/restart actions during an emergency switchover
or after a total system error
2.2.1.1.7.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The SSC functions are separated in 3 groups:
- on-line functions
- off-line operation
- watchdog functions
The on-line functions include the ZVA top level operating
system COPSY, which
- is the parent of all non-DAMOS processes
- handles allocation of all types of resources, including
specification of security and access control
- determines hardware and software reconfiguration
after the reception of an error report or an operator
command
- implements logical access - and distribution control
on lines.
2.2.1.1.7.1.1 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
Generally the on-line diagnostics test programs aim
at limiting the effect of an error by
- timely detection of errors
- reporting the error condition
Specifically the test programs participate in meeting
the availability and integrity of operation requirements.
The test programs operate as low priority tasks together
with the application software.
A specific test program to verify system integrity
through a checksumming of read-only system software
is available. The program is executed on request from
the system management and periodically.
2.2.1.1.7.1.2 L̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲
Line Monitoring and Control are divided into four areas:
- Terminal Monitoring and Control (TEMCO)
- Device Monitoring and Control (DEMCO)
- Circuit Monitoring and Control (CEMCO)
- Watchdog Monitoring and Control (WAMCO)
a) T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲T̲E̲M̲C̲O̲)̲
TEMCO monitors and controls LTU lines to Alphanumeric
and Graphic Terminals.
The TEMCO functions are divided into three areas:
- Execution of logical control on behalf of other
packages e.g. access control.
- Monitoring of connections to the terminals
and subsequent execution of control
The control includes the user initiated events:
- sign on/off
- specification of functional capabilities and
security attributes
- transaction handling
- error reports
b) D̲e̲v̲i̲c̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲D̲E̲M̲C̲O̲)̲
DEMCO monitors and controls LTU lines to Stand
Alone Devices
The stand alone devices handled are:
- Line Printer
- Teletype
- Optical Character Reader
- Paper Tape Reader
- Paper Tape Punch
The DEMCO functions are divided into three areas:
- Execution of logical control on behalf of other
packages e.g. access control
- Monitoring of connections to the SADs and subsequent
execution of control
- Start and Retire Device Handling Control Processes
c) C̲h̲a̲n̲n̲e̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲C̲E̲M̲C̲O̲)̲
CEMCO monitors and controls LTU lines to External
Circuits.
No Circuits are handled in the initial configuration.
The CEMCO functions are divided into three areas:
- Execution of logical control on behalf of other
packages e.g. access control (accept/non accept
of input on a line)
- Monitoring of the connection to the EXCs and
subsequent execution of control.
The monitoring includes the reception of error
reports.
- Start and Retire Circuit Protocol Processes.
d) W̲a̲t̲c̲h̲d̲o̲g̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲W̲A̲M̲C̲O̲)̲
The WAMCO functions include
- sending of keep-alive messages from active/standby
PUs to the watchdog.
- monitoring of the WDP, WDP-VDU and WDP-ROP
physical state
and subsequent actions, which may be
- reinsertion of a device
- handling of a WDP ̲VDU connected directly
to the PU
- display the WDP ̲ROP paper out condition at
the WDP ̲VDU configuration display
- reception of monitoring information from the
WDP.
2.2.1.1.7.1.3 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
This section covers error handling in general and includes
the following topics:
- error detection
- error types
Technical errors are detected during:
- System calls or asyncronously
- Instruction execution
- Validity checks
- WDP monitoring
Errors detected during system calls have one of the
following types:
- SW errors:
- resource error
- security violation
- illegal parameter error
- informative completion code
- HW errors:
- TMS connection error
- FMS connection error
- CESE error (Central error reporting synchronization
element)
2.2.1.1.7.1.4 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̲
Operator commands control the ZVA hardware and software
configuration. The execution of the control is shared
between the SSC in the active PU and the WDP. The SSC
in the active PU directs in the WDP to execute hardware
control.
The basis for execution of operator commands is status
information displayed on the operator VDU and detailed
error reports printed at the operator printer.
The following types of operator functions are foreseen:
- start-up of all modes of the system
- ordered close down of the system
- switch-over from Active PUs to the Standby PU
- device control
- connection of devices to buses
- enable/disable operational use of a device/line
- control of line attributes (e.g. speed)
- load of new software
- print of software versions
- define generation of trace information
- print system status
- adjust time
- commands directly to the watchdog
2.2.1.1.7.1.5 O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The SSC provides a command interface to the support
software package (SSP) and the offline package (OLP)
in the off-line PU and allocates resources to enable
the off-line operations.
The SSP commands includes low level M&D (maintenance
and diagnostic) commands to the MAP and MIA (MAP interface
processor).
2.2.1.1.8 Z̲V̲A̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Monitors are implemented in the software package common
system functions. Possible special LKSAA requirements
can be implemented as an option.
2.2.1.2 G̲e̲n̲e̲r̲a̲l̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
General maintenance software consist of High Level
Operating System for system development and maintenance
as well as compilers, test tools, maintenance and diagnostic
software. This is described in details in the following
sections.
