top - download
⟦44c04449e⟧ Wang Wps File
Length: 119899 (0x1d45b)
Types: Wang Wps File
Notes: BURMA - AMSS, PART II
Names: »4374A «
Derivation
└─⟦32ff5500f⟧ Bits:30006025 8" Wang WCS floppy, CR 0410A
└─ ⟦this⟧ »4374A «
WangText
…00……00……00…A…0a…A…0b……00……00…A…0c…A…02…@…0b…@…05…?…0e…?…05…>…0d…>…05…=…09…=…0a…=…0b…=…0e…= =…05…<…0b…<…05…;…09…;…01…:…08…:…0f…: 9…0a…9…0e…9…05…8…0b…8…0e…8…0f…8…02…8
8…07…7…09…7…0c…7…01…7
6…09…6…0c…6 6…07…5…0f…5…07…4…08…4…0b…4…0f…4…05…4…07……86…1 …02… …02… …02… …02…
BURMA AMSS - PART II
SYS/83-12-07
TECHNICAL PROPOSAL Page
BURMA AMSS
AUTOMATIC MESSAGE SWITCHING SYSTEM
DOC. NO. B-AMSS/8020/PRP/001 ISSUE 1
PART II
TECHNICAL PROPOSAL
SUBMITTED TO: INTERNATIONAL CIVIL AVIATION ORGANIZATION
1000 SHERBROOKE STREET WEST, SUITE
400
MONTREAL, QUEBEC H3A 3R2
CANADA
IN RESPONSE TO: ST-1955
PREPARED BY: CHRISTIAN ROVSING A/S
SYSTEMS DIVISION
LAUTRUPVANG 2
2750 BALLERUP
DENMARK
PRINCIPLE CONTACT: Gert Jensen, Systems Division
Manager
Telex Denmark 35111 cr dk
Telephone: 02 65 11 44
…0e…c…0f… Christian Rovsing A/S - 1983
This document contains information proprietary to Christian
Rovsing A/S. The information, whether in the form of
text, schematics, tables, drawings or illustrations,
must not be duplicated or used for purposes other than
evaluation, or disclosed outside the recipient company
or organisation without the prior, written permission
of Christian Rovsing A/S.
This restriction does not limit the recipient's right
to use information contained in the document if such
information is received from another source without
restriction, provided such source is not in breach
of an obligation of confidentiality towards Christian
Rovsing A/S.
L̲I̲S̲T̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
1 INTRODUCTION ..................................
6
1.1 DECISION TO BID BURMA AUTOMATIC MESSAGE
SWITCHING SYSTEM ..........................
6
1.2 PURPOSE AND SCOPE OF SYSTEM ...............
8
2 FUNCTIONAL CAPABILITIES .......................
12
2.1 SYSTEM OVERVIEW ...........................
12
2.1.1 AMSS Functions ........................
13
2.1.2 Communications ........................
15
2.1.3 Current Line Configuration ............
16
2.2 SYSTEM DESIGN CONSIDERATIONS ..............
17
2.3 HUMAN FACTORS CONSIDERATIONS ..............
21
2.3.1 Operations ............................
21
2.3.2 Maintenance ...........................
21
3 HARDWARE ......................................
23
3.1 INTRODUCTION ..............................
23
3.1.1 Overview ..............................
24
3.1.2 AMSS Single System ....................
25
3.1.3 AMSS Dualized System ..................
27
3.2 CR 80 PROCESSING ELEMENT ..................
29
3.2.1 The Processor Units (PU) ..............
29
3.2.2 The Channel Units (CU) ................
30
3.2.3 Bus Structure .........................
33
3.3 WATCHDOG COMPUTER .........................
35
3.4 CR80 PACKAGING ............................
37
3.5 THE DISC SYSTEM ...........................
41
3.6 TERMINAL EQUIPMENT ........................
42
3.7 POWER SYSTEM ..............................
43
3.8 ENVIRONMENTAL CONDITIONS ..................
44
L̲I̲S̲T̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
4 SOFTWARE CONFIGURATION ........................
46
4.1 GENERAL OVERVIEW ..........................
46
4.2 MESSAGE PROCESSING SOFTWARE ...............
48
4.2.1 Line Handler Submodule (LH) ...........
51
4.2.2 Input Processing Submodule (IP) .......
53
4.2.3 Routing and Queueing Submodule (RQ) ...
61
4.2.4 Output Processing Submodule (OP) ......
77
4.2.5 Message Storage and Retrieval (MRS) ...
79
4.2.6 Command Interpreter (CI) ..............
82
4.2.7 Supervisory Functions .................
82
4.2.8 Reject Message Editor Submodule (RME) .
85
4.2.9 Statistical Analysis and Reporting
(SRA) .................................
86
4.2.10 System Initialization Submodule
(INI) ...............................
87
4.3 SYSTEM SOFTWARE ...........................
88
4.3.1 XAMOS Operating System ................
88
4.3.2 Extensions ............................
89
4.3.2.1 Memory Management..................
90
4.3.2.2 Message Transition Control ........
90
4.3.2.3 Queue Access Management ...........
95
4.3.2.4 Shared Memory Access ..............
98
4.4 SUPPORT SOFTWARE .......................... 101
4.4.1 Off-Line Diagnostic ................... 101
4.4.2 Switchover and Recovery ............... 102
5 SYSTEM PERFORMANCE ............................ 107
6 AVAILABILITY REQUIRMENTS ...................... 109
6.1 RECOVERY PROCEDURES ....................... 111
6.2 FALLBACK PROCEDURES ....................... 112
6.3 RECOVERY TIMES ............................ 112
6.4 OVERALL SYSTEM AVAILABILITY ............... 112
6.5 MEAN-TIME-BETWEEN-FAILURE (MTBF) .......... 115
6.6 MEAN-TIME-TO REPAIR (MTTR) ................ 118
L̲I̲S̲T̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
7 INSTALLATION ................................. 122
7.1 EQUIPMENT INSTALLATION ................... 122
7.2 REQUIREMENT ANALYSIS ..................... 122
7.3 INSTALLATION PLANNING .................... 123
7.3.1 Site Survey .......................... 124
7.3.2 Site Preparation Requirements ........ 124
7.3.3 Equipment Installation Drawings ...... 125
7.4 TRANSPORTATION OF THE EQUIPMENT .......... 126
7.5 SITE INSTALLATION ........................ 128
8 TRAINING .................................... 130
8.1 REQUIREMENTS ANALYSIS .................... 130
8.2 TRAINING PLANNING AND MANAGEMENT ......... 131
8.2.1 Management and Organization .......... 131
8.2.2 Training Program Plan ................ 132
8.3 COURSE DESCRIPTION ....................... 132
8.3.1 Factory Training ..................... 132
8.3.1.1 Contents of Course ............... 132
8.3.1.2 Number of Students ............... 133
8.3.1.3 Length of Course ................. 133
8.3.1.4 Location of Course ............... 133
8.3.2 On-the-job Training (Operator) ....... 133
8.3.2.1 Contents of Course ............... 133
8.3.2.2 Number of Students ............... 133
8.3.2.3 Length of Course ................. 134
8.3.2.4 Location of Course ............... 134
8.3.3 On-the-job Training (Maintenance) .... 134
8.3.3.1 Contents of Course ............... 134
8.3.3.2 Number of Participants ........... 134
8.3.3.3 Length of Course ................. 134
8.3.3.4 Location of Course ............... 134
8.3.4 Course Material ...................... 135
8.3.6 Training Methods ..................... 135
L̲I̲S̲T̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
9 DOCUMENTATION ................................ 137
9.1 DOCUMENTATION OVERVIEW ................... 138
9.2 STRUCTURE OF MANUALS ..................... 140
9.3 DOCUMENTATION DESIGN REQUIREMENTS ........ 141
9.4 DOCUMENTATION PRODUCTION REQUIREMENTS .... 143
10 MAINTENANCE PLANNING ..................... 146
10.1 MAINTENANCE PLAN ....................... 146
10.2 RECOMMENDED SPARE PARTS LIST (RSPL) .... 148
10.3 TOOLS AND TEST EQUIPMENT LIST .......... 148
10.4 MAINTENANCE ACTIVITIES ................. 149
10.4.1 Preventive Maintenance ............. 149
10.4.2 Emergency Maintenance .............. 149
10.5 TECHNICAL SUPPORT ...................... 150
10.5.1 Hardware Support ................... 150
10.5.2 Software Support ................... 150
10.6 SPARE PARTS PROVISIONING .............. 151
10.6.1 Requirement Analysis ............... 151
10.6.2 Spares Delivery .................... 151
10.6.3 Repair Philosophy .................. 151
11 ACCEPTANCE TESTING ......................... 153
11.1 FACTORY ACCEPTANCE ..................... 153
11.2 FINAL ACCEPTANCE ....................... 153
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
1.1 D̲E̲C̲I̲S̲I̲O̲N̲ ̲T̲O̲ ̲B̲I̲D̲ ̲B̲U̲R̲M̲A̲ ̲A̲U̲T̲O̲M̲A̲T̲I̲C̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲S̲W̲I̲T̲C̲H̲I̲N̲G̲ ̲S̲Y̲S̲T̲E̲M̲
The decision to bid the Burma AFTN AMSS represents
a definite commitment on the part of CHRISTIAN ROVSING
A/S to devote its resources and technical talents to
the successful implementation and performance of the
system. The decision was taken at toplevel after thorough
discussions with the staff of marketing, administration,
and engineering at CHRISTIAN ROVSING A/S.
Considerable experience in the field of data communication
combined with experience as prime manager of major
computer system projects provide a solid basis for
our participation in this project. Prime contractor
responsibility, particularly for military customers
and Airline carriers, has demanded a professional approach
to turn-key project management with particular emphasis
on planning and documentation in all phases from system
design and development to production, integration,
installation, training, and maintenance. The contracts
awarded to the company have been typically worth from
several to tens of millions of Dollars.
To provide the necessary talent and facilities, the
Burma AMSS project will be staffed by experts from
several divisions at CHRISTIAN ROVSING A/S. Thus, exceptionally
strong capabilities will be available in computing
and data communication.
Participating entities at CHRISTIAN ROVSING A/S are:
o The Systems Division - structured in 1979 to consolidate
management of major computer system projects. The
CAMPS project for NATO is the responsibility of
the Systems Division.
o The Development Division - responsible for the
design of the CR80 Computer product line of which
more than 200 systems are currently on order from
major customers such as NATO, ICL and L.M. Ericsson.
o The Production Division - responsible for manufacturing
of the CR80 Computer product line.
The AMSS Project Group will be supported by the Integrated
Logistics Support Group, which provides services including
site surveys, installation in Rangoon, training of
country nationals, documentation, maintenance, spares
and other necessary support services.
Product quality will be ensured by the Quality Assurance
Department, which reports directly to company management.
A distinct Project Group will be established to manage
the AMSS Project. This project group will have total
system responsibility and authority to coordinate in-house
activities and to provide close liaison with the Buyer
throughout the duration of the project.
In summary, the decision to bid is based on the confidence
that CHRISTIAN ROVSING A/S has all the necessary qualifications
for the successful procurement, implementation and
maintenance of the AMSS.
The processor for the message handling and communication
system is similar to the highly efficient communications
processor already proven in other programs and also
to be used in extensive airline communication systems
like Air Canada's and American Airlines', where up
to 65,000 terminals will be connected to various host
computers.
The node computer proposed for the AMSS can be a fully
dualized CR80 computer system, with automatic switch-over
from active to the standby in the event of failure.
Manual switch-over is also possible to accomplish "on-line"
maintenance, i.e. maintenance without loss of function
by using the standby unit for processing while the
formerly active unit is serviced. In addition to fault
tolerant operation and ease of maintenance, the CR80
is characterized by high performance, high system availability,
and growth by simple addition of standard modules.
1.2 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲ ̲O̲F̲ ̲S̲Y̲S̲T̲E̲M̲
The Automatic Message Switching System (AMSS) for Rangoon
is designed to replace the existing "TORN"-tape operated
facility for the Government of Burma. The switch is
intended to form a part of the Aeronautical Fixed Telecommunication
Network (AFTN) for the region and will carry the general
and administrative AFTN traffic.
The AMSS will be configured from the wide range of
CR80 advanced fault tolerant computer system and will
function as a store and forward message switching centre.
The system functional diagram is illustrated in Figure
1.2-1 and the physical layout is illustrated in Figure
1.2-2.
Two computer configurations will be offered, a single
system and a fully dualized system with watchdog computer
for fault tolerant operations.
FIGURE 1.2-1…01……01…BURMA AUTOMATIC MESSAGE SWITCHING SYSTEM,
FUNCTIONAL CONNECTIONS
FIGURE 1.2-2…01……01…BURMA AUTOMATIC MESSAGE SWITCHING SYSTEM,
PHYSICAL LAYOUT
2 FUNCTIONAL CAPABILITIES ........................
2.1 SYSTEM OVERVIEW ............................
2.1.1 AMSS Functions .........................
2.1.2 Communications .........................
2.1.3 Current Line Configuration .............
2.2 SYSTEM DESIGN CONSIDERATIONS ...............
2.3 HUMAN FACTORS CONSIDERATIONS ...............
2.3.1 Operations .............................
2.3.2 Maintenance ............................
2̲ ̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
2.1 S̲Y̲S̲T̲E̲M̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The Burma Automatic Message Switching System provides
a complete facility for fast reliable and flexible
distribution, management and control of the AFTN traffic.
The AMSS will meet all requirements for speed, capacity,
reliability and expandability.
The system can manage a significant number of incoming
outgoing and messages per hour. Availability is ensured
by the flexibility and modularity of the system, which
provides easy and fast maintenance, and it can be improved
by use of fault-tolerant equipment and dualization
of components.
F̲e̲a̲t̲u̲r̲e̲s̲
o M̲o̲r̲e̲ ̲r̲e̲l̲i̲a̲b̲l̲e̲ ̲c̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ through computer control,
equipment dualization and system redundancy.
o H̲i̲g̲h̲e̲r̲ ̲s̲u̲r̲v̲i̲v̲a̲b̲i̲l̲i̲t̲y̲ through alternative paths
and automatic rerouting.
o T̲i̲g̲h̲t̲e̲r̲ ̲c̲o̲n̲t̲r̲o̲l̲ through centralized computer coordination,
supervisor visibility, and automatic collection
of statistics and status information.
o O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲s̲i̲m̲p̲l̲i̲c̲i̲t̲y̲ through automatic distribution,
and minimum operator intervention.
o E̲a̲s̲i̲e̲r̲ ̲e̲x̲p̲a̲n̲s̲i̲o̲n̲ through flexible, common and interchangeable
hardware/software modules.
o M̲e̲s̲s̲a̲g̲e̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲. Store and forward switching
of messages.
o E̲x̲p̲a̲n̲s̲i̲o̲n̲ ̲F̲e̲a̲t̲u̲r̲e̲s̲. Fully dualized system with
n+1 redundancy.
o G̲r̲e̲a̲t̲e̲r̲ ̲e̲f̲f̲i̲c̲i̲e̲n̲c̲y̲. Faster delivery and higher
throughput through real-time multiplexed use of
network facilities.
Figure 2.1-1
Functional Elements of AMSS
The Burma AMSS consist of the following main elements.
o Flexible modern circuit connections to international,
local and domestic circuits.
o Store and forward CR80 computer system.
o Three terminal positions with VDU and teleprinters
for system supervision, message corrections, and
training.
o Static uninterruptable power system.
The AMSS CR80 store and forward message switch can
be implemented both as a single system and as a fully
fault tolerant dualized system. The proposal describes
both systems. The differences in the two solutions
is limited to the internal hardware structure and modules,
which results in the higher availability and fast performance
of the dualized system. The configurations for the
two systems are shown in chapter 3. The availability
features described in the following sections can not
always be fully exploited in a single system.
2.1.1 A̲M̲S̲S̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The functional aspects of the AMSS comprise three principal
functions:
o The message switch
o The Supervisor/Operator interface
o Statistic and Reporting.
The message switch implements all essential functions
for automatic storing and forwarding of messages. This
includes line handling, processing of input signals,
output processing, routing and queueing, and message
storage and retrieval.
The supervisor/operator interface implements a user
friendly man-manchine interface, enabling human intervention
and control, where necessary. The supervisor function
can due to safe operations only be allowed at one position
at a time; examples of the supervisor capabilities
are routing table changes and allocation of functions
to the other positions (training, editing etc.). The
operator function includes the reject message processing
and can be done at the same position as the supervisor
or at all positions, if required.
Finally, facilities are provided to produce required
statistic reports, and log/printouts used to evaluate
functioning of the AMSS and ensure optimum performance.
2.1.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲
The baseline system is designed for the 12 circuits
currently availabe i.e. 4 international circuits, 6
local subscriber circuits and 2 domestic circuits.
But due to the modular design of the hardware is it
possible to expand to virtually any number of circuits,
not only the indicated increase in international, local,
and domestic circuits, but also with multiple channels
on individual circuits, should the load exist. The
line interface hardware is general purpose and also
used in the communications systems for Air Canada and
American Airlines. It can accommodate much higher transmission
speeds; the Line Terminating Unit (LTU), which handles
four circuits is designed for 9600 baud, and is being
used for maximum 4 x 300 baud. The line interface hardware
is capable of operating with full duplex, half duplex
and simplex lines.
The modular design of not only hardware but also software
facilitates expansions and extendability. The software
modules used for the AMSS are from the same baseline
as the Air Canada and American Airlines communications
software which is employing CCITT X.25 packet switching
up to OSI level 3. The external network environment
accommodates the SITA, ARINC, and CNT networks.
The migration to the future CIDIN* network with the
expected level 3b and level 4 will not pose any problems
and basically off-the-shelf software will be available
from the present CHRISTIAN ROVSING A/S projects.
* CIDIN: Common ICAO Data Interchange Network
2.1.3 C̲u̲r̲r̲e̲n̲t̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The requirements for a simple, yet flexible system
with manual fall back facility is optimally provided
with the full patch panel with connections to the circuits,
the computer lines and the three teleprinters. The
basic setup is illustrated in figure 1.2-1. The circuits
are terminated in FSK modems, and the modems are connected
to the patch panel. The panel provides a normal connection
to the AMSS CR80 system (no patch inserted) or to any
of the teleprinters. Normally the teleprinters are
connected to the AMSS CR80 system and physically to
be located next to a AMSS console VDU and keyboard.
A patch insert can then provide a direct connection
between the teleprinter and any of the circuits without
any equipment movement.
2.2 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲I̲G̲N̲ ̲C̲O̲N̲S̲I̲D̲E̲R̲A̲T̲I̲O̲N̲S̲
The many functional and operational features inherent
in the CR80 computer systems for AMSS go beyond the
mere physical size variations and expansion options.
The computer family is designed for high reliability,
high flexibility system, such as communications processors,
front-end processors, data concentrators and packet-switched
networks.
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 XAMOS software operating system and programs to
survive operational failure of individual components.
o Distributed processing throughout the CR80 computer
family
- Multiple Central Processors
- Multiple CPU's in Central Processors
- Individual Microprocessors in each Peripheral
Controller Module
- Fast separate processor for Interrupt Preprocessing
and Data Channel management.
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
an n+1 redundance scheme without preassignment of system
functions to specific processors. This is in marked
contrast to the more common rigid dualized configurations
often encountered in dedicated applications with on-line
master/slave arrangements, or off-line backup with
switchover facility.
o Fault Tolerancy
- NO-BREAK computing supported by numerous unique
hardware, software and maintenance features
to achieve mean time between system failures
in the order of years.
- Multiple Central Processor incorporation of
Peripheral Controller modules providing alternative
processing paths.
- Economic N+1 Central Processor redundancy.
- Economic N+1 Communication Interface redundancy.
- Dual Powering of Peripheral Controller modules
safeguards against single power failures.
- Redundant Fan Units ensure sufficient cooling
of equipment in the event of Fan breakdown
or failure in a mains phase supply.
- Short mean time to repair ensured by major
system components exchangeable from the front
with no cable detachment or special tools needed.
- Extensive Quality assurance and control program
during design and production for achieving
and maintain the CR80 high level of module
reliability.
- Maintenance and Configuration Processor subsystem
supervises Power Supply voltages and environmental
conditions and provides reconfiguration of
the computer in response to errors reported
by on-line diagnostics, self-checks and status
reporting.
Coupled with reliability is maintainability. The CR80
computer system family offers a very advanced concept
of on-line serviceability and extendability. It offers
an integral maintenance and configuration processor
for system supervision and unattended operations.
o On-line serviceability and extendability
- Computers partioned in self sustained physical
subunits complete with power supply and cooling.
- Physical subunits galvanically isolated from
each other and interconnected via high speed
dual or multiple redundant long distance data
highways, omitting ground loops normally limiting
size and on-line extension of computer systems.
- All major modules, inclusive the power supplies
and Fan Units, are insertable and exchangeable
from the front without special tools.
- On-line exchange and addition of modules without
power down provided by electronic power switches
and bus high impedancing circuitry in the individual
modules.
- Extensive individual module self test at power-on
provides immediate visual indication to operator
of hardware status.
- Wide range of maintenance and diagnostic programs.
- Early warning of error prone conditions and
preventive fault correction made possible by
the Maintenance and Configuration microcomputer
monitoring power supply voltages and environmental
conditions of subunits.
o Maintenance and Configuration Processor
- Stand-alone system Watchdog microcomputer monitors
equipment status through physical sensing.
- Voltage variations of power supplies monitored
with A/D converters.
- Fault Tolerancy computer reconfigurations,
based on accumulated on-line diagnostics, selfchecks
and status reporting.
- Distributed monitoring and control of all computer
subunits through separate redundant, galvanically
isolated connections.
- Fail-safe switch-over to manual set-up of configuration
in case of error in the Maintenance and Configuration
Processor itself.
- Manages the economic N+1 redundancy switch-over
of communications lines.
o Extensive use of LSI technology
- High equipment density achieved by use of RAM's,
PROM's, CPU's, USART's, FIFO's, Programmable
Logic Arrays and microprocessors.
- Low power consumption, allowing for forced
air cooling of even the largest computer configurations.
- Very low space requirements of packed computers.
- High speed based on Schottky-TTL technology.
o Powerful CPU utilized
- Microcycle time 250 nanoseconds.
- 16 bit instructions.
- Internal pipe lining.
- Instruction prefetch.
- Comprises dual Arithmetic and Logic Units allowing
up to 3 operand arithmetic operations to be
executed simultaneously.
- Extensive error checking with roll-back allowing
instruction reexecution.
- Designed for multi CPU, multiprocessor environment.
- Non-mapped and mapped virtual memory capability.
- Field exchangeable single unit.
2.3 H̲U̲M̲A̲N̲ ̲F̲A̲C̲T̲O̲R̲S̲ ̲C̲O̲N̲S̲I̲D̲E̲R̲A̲T̲I̲O̲N̲S̲
The system is designed to comply with modern man-machine
interface practice and with due considerations to operators
and maintenance personnel for minimal training, operational
knowledge, minimal computer system knowledge, and user
error tolerance. The system is also designed for unattended
operations to the widest possible extend. The primary
fields where human factors have been considered are
in operations and in maintenance.
2.3.1 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The system have been designed for operators with little
or no knowledge of computers by providing menu driven
function selection, both for the supervisory functions,
for the Message correction functions and for training.
Furthermore, where input is allowed or requested to
the operator the data is checked in type, range and
legality to the extent possible. The updates to the
tables are validated where possible and critical input
data must be validated by the operator after injection.
2.3.2 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
The system has been constructed for fast maintenance
with minimum training. The fault finding is heavily
supported by visual aids in the form of control LEDs
on all modules and by on-line and off-line diagnostic
programs.
The capability for on-line maintenance is described
in the preceeding section, section 2.2.
3 HARDWARE .......................................
3.1 INTRODUCTION ...............................
3.1.1 Overview ...............................
3.1.2 AMSS Single System .....................
3.1.3 AMSS Dualized System ...................
3.2 CR 80 PROCESSING ELEMENT ...................
3.2.1 The Processor Units (PU) ...............
3.2.2 The Channel Units (CU) .................
3.2.3 Bus Structure ..........................
3.3 WATCHDOG COMPUTER ..........................
3.4 CR80 PACKAGING .............................
3.5 THE DISC SYSTEM ............................
3.6 TERMINAL EQUIPMENT .........................
3.7 POWER SYSTEM ...............................
3.8 ENVIRONMENTAL CONDITIONS ...................
3̲ ̲ ̲H̲A̲R̲D̲W̲A̲R̲E̲
3.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The CR80 product line is extremely versatile. The computer
system proposed for AMSS will be the very flexible
and modular CR80 computer, which has been used in many
military and commercial projects.
CR80 modules can be configured to meet specific costumer
requirements or delivered in standard configurations.
The 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 80:1 range in processing power utilizing one
CPU or up to 16 interconnected multiprocessors
with a maximum of 5 CPUs each, providing instruction
rates of 0.6 mips to 30 mips.
- a 1000:1 range in memory capacity from 512 kilobytes
to 512 megabytes.
- a 400:1 range in connectivity through Peripheral
Controllers accommodating a variety of terminations
with as many as 960 peripherals or up to 4096 communication
lines.
Flexible variation in the size and structure of the
CR80 systems 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 XAMOS software operating system.
Reliability 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 redundancy scheme without preassignment of system
functions to specific processors.
3.1.1 O̲v̲e̲r̲v̲i̲e̲w̲
The CR80 System can consist of the following elements
depending on requirements:
o Processing Elements (PE), i.e.
- Processing Units (PU)
- Channel Units (CU)
o Watchdog Computer
o Peripheral Equipment, e.g.
- Disc systems, tape systems, relational database
systems, communication lines, and communication
systems.
o Terminal Equipment, e.g.
- Alphanumeric displays, graphic displays, printers,
...
The Burma Automatic Message Switching System hardware
for both the single and the dualized system consists
of the following main elements:
1 CR80 single or dualized system
2 Disc drives
3 CR-comfort VDUs
3 Sagem Latin type TX20 ASR Teleprinters
1 Patchpanel
1 Set of modems
1 Uniterruptable power system with battery
2 Air conditioning units.
The single and dual system is described in the next
paragraphs, the remaining hardware elements, which
are common for the two solutions are described in section
3.5 to 3.8.
3.1.2 A̲M̲S̲S̲ ̲S̲i̲n̲g̲l̲e̲ ̲S̲y̲s̲t̲e̲m̲
The single system for the store and forward message
switch consists of the following main CR80 modules:
. a Processing Unit with a single CPU and 512 Kbytes
of RAM
. a Channel Unit with single disc controller and
line interfaces to communication lines, VDUs and
telepriners.
The configuration is illustrated in figure 3.1.2-1.
The Processing Unit and the Channel Unit are described
in detail in section 3.2. The modular packaging is
illustrated in section 3.4.
Figure 3.1.2-1
BURMA - AMSS Single System Configuration
3.1.3 A̲M̲S̲S̲ ̲D̲u̲a̲l̲i̲z̲e̲d̲ ̲S̲y̲s̲t̲e̲m̲
The fully dualized fault tolerant store and forward
message switch consists of the following main CR80
modules:
. 2 Processing Units, each with a single CPU and
512 Kbytes of RAM
. 1 Channel Unit with dual bus and duplicated disc
controllers and n+1 redundant line interfaces to
communication lines, VDUs and teleprinters
. 1 Watchdog computer to automatically control the
configuration and to switch PU or line interfaces.
The configuration is illustrated in figure 3.1.3-1.
The functioning of the Processing Units and the Channel
Unit is described in section 3.2, the Watchdog computer
in 3.3 and the packaging in 3.4.
Figure 3.1.3-1
Dual System configuration
Watchdog component not shown
3.2 C̲R̲8̲0̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲ ̲E̲L̲E̲M̲E̲N̲T̲
A CR80 Processing Element (PE) comprises Processing
Units (PUs), Channel Units (CUs), and a supporting
bus structure, providing the user(s) with a virtual
memory multiprogram/multiprocessor computing system.
3.2.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 consisting
of up to 5 Central Processor Units, CPUs, utilizing
virtual memory and demand paging.
The PU is highly flexible, allowing selection of modules
to meet specific requirements. The modules are interfaced
via a dual bus structure for reduction of bus contention
as shown in figure 3.2.1-1.
Figure 3.2.1-1
Processor Unit
3.2.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 single or dual transfer
bus structure. The dualized structure ensures that
no single failure can stop operation of more than one
I/O controller as shown in figure 3.2.2-1.
Figure 3.2.2-1
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. 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 figure
3.2.2-2. They exist in two versions, for single and
for dual bus.
Figure 3.2.2-2
Channel Unit Interface
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 downloaded from the CR80.
The DISK CTRL and PARALLEL CTRL modules employ PROM's
while the Line Termination Modules (LTU) used for control
of communication lines, terminals etc., are loaded
with programs from the CR80, meaning that different
protocols can be supported without hardware changes.
The physical interfaces to the peripherals, communication
lines etc., are adapter modules located at the rear
of the CU Crate. For interfacing to a communication
line, a line interface adapter module (LIA) 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 backup for a number of
active LTU's (n out of n+1 redundancy).
Not only is the internal bus structure dualized, the
power input is also taken from two separate sources
to ensure that a failure in one power source cannot
stop the CU from operating.
3.2.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.
The interconnections of the different buses and units
are shown schematically in figure 3.2.3-1.
Figure 3.2.3-1
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.
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.
3.3 W̲A̲T̲C̲H̲D̲O̲G̲ ̲C̲O̲M̲P̲U̲T̲E̲R̲
The Watchdog computer, also called the Maintenance
and Configuration Processor (MPC) system, consists
of standard CR80 modules used in the monitoring and
control of the total CR80 system. As for the main elements,
PUs and CUs, the MPC can be configured to suit specific
requirements over and above the standard watchdog functions
shown here. The normal watchdog system structure employed
in the dualized AMSS is shown in figure 3.3-1.
Figure 3.3-1
AMSS Watchdog System
The WD-CPU, positioned as a standard Peripheral Module
in the CU-Crate, is the central Maintenance and Configuration
Processor receiving status and control messages from
the CR80 Processing Elements through its dual interface
to two PE's of the CR80 system.
The WCA (Watchdog CPU Adapter) constitutes the interface
between the WD CPU and the configuration Bus and the
four available V24 communication ports. The V24 ports
are used for possible connection of one or two system
consoles and for connection to a communication port
for remote maintenance and diagnostics of the CR80
system.
The Daisy Chained Configuration Bus is a dualized serial
communication path between the WCA and the connected
CCA's (Crate Configuration Adapters). The CCA is a
standard CR80 adapter module designed for monitoring
and control of the PU and CU Crates. The functions
available are: monitoring of the DC voltages, switching
of LIA-S modules (switching a spare LTU to the lines
instead of a defect module), and monitoring of digital
and analogue inputs, and control of digital outputs.
The WD CPU and the WD Panel Controller utilize alternative
paths of the serial configuration bus for control and
monitoring of the attached crates and associated modules.
The serial configuration bus is therefore redundant,
with different parts of it being used in AUTO and MANUAL
mode.
A fail safe circuit is implemented between the WD CPU
and the WD Panel Controller, which performs automatic
switching to the manual settings of the WD Panel in
case of WD CPU failure or service. Similarly, replacement
of the WD Panel Controller can be done with the system
online and under control of the WD CPU.
Crates under control of the MCP system is galvanically
isolated by optocouplers from the serial configuration
bus and can be removed from the operational configuration
bus without electrical interference with the remaining
part of the system.
3.4 C̲R̲8̲0̲ ̲P̲A̲C̲K̲A̲G̲I̲N̲G̲
As for the processing system design, great emphasis
has been put on failure tolerance and modularity of
the packaging, cooling and Power Supply subsystems.
The CR80 modular fault tolerant computer system is
assembled using standard modules (printed circuit cards)
housed in Processor Units and Channel Units (Card Cages).
The Units are interfaced by galvanically isolated transfer
buses, structured as shown below (figure 3.4-1) and
described in the following.
Figure 3.4-1
Units are housed in 19" Crates (Card Magazines) for
installation in standard 19" Racks, as shown overleaf
(figure 3.4-2). A Crate contains a 25 slot Front Magazine
for insertion of up to 17 Printed circuit card modules
and 2 Power Supply modules, the two upper rows of connectors
are each interconnected by multilayer printed circuit
buses, while the lower row of connectors is connected
individually via flatcables to corresponding connectors
in the Rear Magazine. The 19 slot Rear Magazine, which
can be pivoted down for access to Crate internal cabling,
holds controller Adapter modules providing the interface
and cabling to peripherals. Also a number of slots
is provided outside the rear Magazine, at the rear
of the crate for insertion of bus termination cards
and interface cards to the Data Channel bus. Keeping
all external cabling at the rear of the Crate, allows
all front modules (CPU, RAM, Peripheral Modules etc.),
inclusive the plug-in Power Supplies, to be exchanged
quickly without use of special tools.
Below each crate (PU or CU) in the CR80 system is installed
an exchangeable fan unit, which by forced air cools
the modules in the crate. To ensure continuous air
flow, the fan unit is redundantly constructed with
the airstream being provided by two sets of blowers,
each being powered from different mains phases, and
each with a capacity sufficient for cooling the entire
crate over a prolonged period of time. This ensures
the failure tolerance of the fan unit, both against
a Mains phase falling out and mechanical breakdown
of a blower.
One, or two power supply modules operating in parallel,
are installed, in each PU crate dependent of the required
power consumption. A power supply failure in the PU
will cause the PE to stop processing, but it will not
influence the system operation, as processing of the
failed PE will be taken over by the remaining operating
PE's.
In a dualized CU crate two Power Supplies are installed,
each backing up for the other in supplying the modules
power via two separate buses. This power scheme ensures
that a single power supply can fail without influencing
the operation of the modules in the CU crate due to
the special Power Supply ORing-circuit in each of the
modules. The power ORing-circuit contains a current
limiter which ensures that a short in a module will
not draw excess power from the power supplies, and
thereby interrupt the operation of other modules in
the crate.
A second function of the Power ORing-circuit is, in
combination with a slightly shorter pin in the interface
connector of any Peripheral Module and the buses, to
allow on-line replacement of a module in an operating
CU-crate. When a module is removed or inserted the
shortened pin will disconnect first and connect last.
This pin controls the current limiter in the Power
ORing-circuit and power to the module is therefore
removed, or applied, without spikes on crate-busses
during module exchange. Since the special bus driver/receivers
have high impedance against the buses, when the power
is removed, no interruption occurs in operation of
the Data busses during module exchange.
BIT (Built In Test) are found in most CR80 modules.
The test starts automatically when power is applied
to the module and lights the red TEST LED on the front
plate. When the internal test cycle lasting a few seconds
has been run through successfully, the TEST LED is
estinguished; therefore, on faulty modules the red
TEST LED will remain on.
Other built-in test functions, which are not destructive
to the normal module function, are used for error detection
by the CR80 on-line diagnostics during actual operation
of the computer.
Figure 3.4-2
CR80 Processor Unit & Channel Unit
3.5 T̲H̲E̲ ̲D̲I̲S̲C̲ ̲S̲Y̲S̲T̲E̲M̲
The disc system consists of two identical CDC SMDs,
each containing 80 Mbytes. The SMD disc is a random
access rotating memory using removable disk packs as
storage media.
The two discs are operated as mirrored discs, and are
connected to the Channel Unit to support the single
or dual system. In the dualized system two separate
disc controllers are used solely to avoid single point
failure.
The discs will hold both the 1 hour message file with
additional data, the long term retrieval file, e.g.
30 days storage of messages, and the system log file.
3.6 T̲E̲R̲M̲I̲N̲A̲L̲ ̲E̲Q̲U̲I̲P̲M̲E̲N̲T̲
The terminal equipment consists of 3 CHRISTIAN ROVSING
VDUs in modern ergonomic styling and with user designed
keyboards, and 3 standard Latin type Sagem ASR teleprinters,
Model TX20.
The VDUs will normally be the operator interface to
the AMSS with the teleprinters providing a hardcopy
record of events. The terminals are flexible and no
functional dedication is assigned to physical units.
The VDUs are directly connected to the AMSS; whereas
the teleprinters are connected through the patch panel
allowing for fast and direct switchover, should it
be required.
The specified CHRISTIAN ROVSING A/S VDUs can be supplied
in a version with built-in telex operation and/or wordprocessing
capabilities.
3.7 P̲O̲W̲E̲R̲ ̲S̲Y̲S̲T̲E̲M̲
The total AMSS must function with high availability,
and the system is depending on continuous power supply.
The external power is of limited quality in terms of
voltage and frequency tolerances.
The power system for the AMSS is a complete, modern
solit state uninterruptable power system with built-in
voltage and frequency stabilization, see figure 3.7-1
for schematic functioning.
The AMSS is permanently coupled to the system, inclusive
the battery element; which eliminates any switching
in case of mains failures and resulting interrupted
message switching function. The modems and the teleprinters
can also in case of long term main power breakdown
or main AMSS failure function on the power system.
The uninterruptable power system is dimensioned for
a freestanding power supply from the batteries of 4
hours with a 10-12 hour recharging period. A slight
deviation from the ICAO requirements is made in that
the lead acid storage batteries are dimensioned for
220 V DC, which results in much smaller currents than
48 V DC and the installation can therefore be reduced
in size due to smaller heating problems.
Figure 3.7-1
Static No-break Power Supply
Basic Configuration
3.8 E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲A̲L̲ ̲C̲O̲N̲D̲I̲T̲I̲O̲N̲S̲
The AMSS main equipment needs for reliable and permanent
functioning temperatures below 40…0e…0…0f…C, therefore dual
airconditioning units will form a part of the total
AMSS system to provide for working conditions for the
system.
4 SOFTWARE CONFIGURATION .........................
4.1 GENERAL OVERVIEW ...........................
4.2 MESSAGE PROCESSING SOFTWARE ................
4.2.1 Line Handler Submodule (LH) ............
4.2.2 Input Processing Submodule (IP) ........
4.2.3 Routing and Queueing Submodule (RQ) ....
4.2.4 Output Processing Submodule (OP) .......
4.2.5 Message Storage and Retrieval (MRS) ....
4.2.6 Command Interpreter (CI) ...............
4.2.7 Supervisory Functions ..................
4.2.8 Reject Message Editor Submodule (RME) ..
4.2.9 Statistical Analysis and Reporting
(SAR) ..................................
4.2.10 System Initialization Submodule
(INI) ................................
4.3 SYSTEM SOFTWARE ............................
4.3.1 XAMOS Operating System .................
4.3.2 Extensions .............................
4.3.2.1 Memory Management...................
4.3.2.2 Message Transition Control .........
4.3.2.3 Queue Access Management ............
4.3.2.4 Shared Memory Access ...............
4.4 SUPPORT SOFTWARE ...........................
4.4.1 Off-Line Diagnostic ....................
4.4.2 Switchover and Recovery ................
4̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
This section contains a description of the software
supplied with the AMSS. First, an overview of the software
is given, and then the major items are described in
the subsections to follow.
4.1 G̲E̲N̲E̲R̲A̲L̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The AMSS software structure is outlined in FIGURE 4.1-1.
Operational software comprises the system software
and the application software.
The application software, which is discussed is section
4.2, contains a detailed description of each software
module, showing the direct relationships between the
requirements of an AFTN Message Centre and the functional
implementation of these requirements by each individual
software module.
System software is described in section 4.3, and essentially
comprises the basic multiprocessor operating system
- XAMOS - and extensions that have been developed in
order to optimize the CR80 communications processing
features.
Support software is described in section 4.4, and covers
off-line diagnostics as well as switchover and recovery.
Switchover and recovery, referring to the optional,
fault-tolerant configuration, describes how the fault-tolerant
configuration functions, including highlights of restart/recovery,
checkpointing, and watchdog functions.
AMSS SOFTWARE STRUCTURE,
showing module breakdown
FIGURE 4.1-1
4.2 M̲E̲S̲S̲A̲G̲E̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
The AMSS Message Processing Software is based on the
modular architecture of the CR80, with the application
program package broken down into a number of smaller
submodules. Figure 4.2-1 illustrates the application
program submodules and their interrelationships.
The application program consists of the submodules:
- Line Handler (LH)
- Input Processing (IP)
- Routing and Queuing (RQ)
- Output Processing (OP)
- Message Storage and Retrieval (MRS)
- Command Interpreter (CI)
- Reject Message Editor (RME)
- Statistical Analysis and Reporting (SAR)
- System Initialization (INI)
- On-line Diagnostics (ERR)
To determine the AMSS routing requirements, a survey
of ICAO routing methods in relation to fully automatic
message switching centres was carried out, and the
routing algorithm has been based on the survey results.
APPLICATION S/W FUNCTIONAL DIAGRAM
FIGURE 4.2-1
T̲h̲e̲ ̲L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲ (LH) is an LTU (LTU: Line Termination
Unit; see H/W description) driver and performs all
input/output transactions between the LTU modules and
the input/output queues of the system.
I̲n̲p̲u̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲I̲P̲)̲ executes the complete character
sequence examination of the ICAO formatted messages
received in the external lines. IP prepares for message
retention and delivers extracted routing information
to RQ.
R̲o̲u̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲Q̲u̲e̲u̲e̲i̲n̲g̲ ̲(̲R̲Q̲)̲ determines outgoing routes
for all message deliveries and makes the output line
queue entries for onward relay.
O̲u̲t̲p̲u̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲O̲P̲)̲ finalizes preparation of outgoing
messages, e.g. appends message headers and shortened
addresses. OP also code-translates each outbound message
into the ITA2 alphabet.
M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲(̲M̲S̲R̲)̲ provides for message
storage on the system disk and processes message retrieval
requests.
T̲h̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲I̲)̲ is the interactive means
for communication between the users and the system.
CI interfaces to all application program submodules
in the process of interpreting and executing the various
supervisor commands to the system.
T̲h̲e̲ ̲R̲e̲j̲e̲c̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲o̲r̲ ̲(̲R̲M̲E̲)̲ controls supervisor
reject message editing sessions.
S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲(̲S̲A̲R̲)̲ collects and
extracts various statistical information made available
by the application program submodules and, on request,
generates statistical reports for display or printout.
S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲(̲I̲N̲I̲)̲ ̲initializes the AMSS system
data base following bootload.
O̲n̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲(̲E̲R̲R̲)̲ executes on-line loop tests
of the AMSS hardware and receives software error interrupts
from the application program submodules.
4.2.1 L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲L̲H̲)̲
The purpose of the Line Handler Submodule (LH) is to
control input and output between the AMSS and the external
communication lines.
The LH has two main interfaces: The LTUs on one side
and the line input queues and line output queues on
the other side. Furthermore, LH communicates with the
system error routine and with the buffer allocation
routine.
a) L̲H̲ ̲P̲o̲l̲l̲ ̲a̲n̲d̲ ̲S̲e̲l̲e̲c̲t̲ ̲S̲t̲r̲a̲t̲e̲g̲y̲
The LH controls input and output between the external
lines and the AMSS by a poll and select strategy.
To each channel is connected one input and one
output line queue. The lines are simultaneously
active and handled by the LH, which scans the LTUs
in sequence. The scanning is performed at a rate
equal to or greater than the critical rate determined
from the line character speed and the number of
lines.
b) A̲s̲y̲n̲c̲h̲r̲o̲n̲o̲u̲s̲ ̲L̲T̲U̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Input/output from/to external communication lines
is performed via LTU modules. Each LTU module contains
4 logical LTU channels on one card (input + output).
The LH polls each (open) LTU channel in a sequential
manner in accordance with line characteristics
(character rate). During the same polling cycle
both input and output are handled. The LTU status
word is used for determination of LTU transmit
buffer empty and receive buffer full conditions
and miscellaneous error conditions which might
have occurred on the line, e.g. framing error,
parity error, etc. Error status information is
reported to the On-line Diagnostocs (ERR).
The LH receives input data and status information,
and delivers output data and commands to the LTUs.
Input from the LTUs is on a character by charcter
basis. Each character read from the LTU receive
buffer is stored in the input line buffer allocated
for the line in question.
Output to the LTUs is on a character by character
basis. Each character read from the current output
line buffer is stored in the LTU transmit buffer
for the line in question.
c) L̲i̲n̲e̲ ̲Q̲u̲e̲u̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The input and output characters (Rx and Tx data)
from/to the communication lines are exchanged between
the LH and the central routines via line buffer
queues.
Messages are segmented and stored in fixed length
buffers. Each buffer contains a Logical Channel
Identifier (LCI) which uniquely identifies the
origin/destination channel associated with the
message. The LCI, which is used as a channel, identifies
internally in the AMSS.
Each buffer also contains a character count and
two links: one to the next buffer containing elements
of the same message and one which either links
to the first buffer of the next or to the first
buffer of the same message:
Message queue for one line (input or output):
Only complete messages are linked into and out
of the line queues.
d) L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲T̲a̲b̲l̲e̲s̲
The LH operates with and maintains a Polling Control
Table (PCT) and a number of Channel Descriptor
Tables (CDTs).
The PCT contains all general LH data. In particular
the PCT contains the channel select strategy, i.e.
the sequence and speed with the different channels
shall be polled.
The CDTs, one per channel, contain line specific
information such as:
- channel timer
- logical channel identifier (LCI)
- interface address (physical LTU address)
- channel error status
- line buffer addresses
- stuck tape counter
- halted message timer.
4.2.2 I̲n̲p̲u̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲I̲P̲)̲
a) I̲n̲p̲u̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The major task performed by IP is the syntactical
analysis of the ICAO-AFTN formatted messages received
by the system. The analysis/synthesis will conform
to the rules given in "AERONAUTICAL TELECOMMUNICATIONS"
ANNEX 10, VOLUME II.
IP receives inbound messages from the Line Handler
(LH), which maintains one input line queue for
each input communication channel. IP delivers preprocessed
messages in intermediate precedence queues for
disk storage and extracted RI Lists (RIL) to the
Routing Submodule (RQ).
The message processing functions performed by IP
are:
- Character code translation
- Header analysis and check
- Input data sectorizing
- RI list preparation
- Precedence queue linkage
- Service message generation
b) C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲C̲o̲d̲e̲ ̲T̲r̲a̲n̲s̲l̲a̲t̲i̲o̲n̲
Both ITA2 and ITA5 code is accepted as input
code. In the case of ITA2 code, each input
character is translated from 5-bit external
code (ITA2) to 7-bit ASCII code (ITA5) which
is the internal code. This is done by table
lookup and is integrated with the character
sequence processing described in the following.
c) H̲e̲a̲d̲e̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲a̲n̲d̲ ̲C̲h̲e̲c̲k̲
As the IP submodule scans the complexities
of the ICAO format, it is basically searching
for the message precedence indication and the
Routing Indicators which will be used for determination
of the onward message relay.
The syntax scanning function is fully table
driven (state-event approach). IP maintains
the Channel Status Table (CST) where the progress
of the input analysis is held. Hence, when
IP calls for the next buffer of a message under
analysis, it branches to the specific program
segment by using the stateaddress temporarily
saved in the CST. Note that IP is always at
various stages of analysis of many messages.
This table driven approach, therefore, allows
for interrupts in the analysis without loss
of the analysis vector.
When PIP finds the field it is looking for,
it extracts the information and moves the analysis
vector forward in the CST. Hence, when the
message is stored on the disk, all the information
necessary to relay the message onward is in
temporary memory storage.
The CST provides storage for Circuit Identification,
Channel Sequence Number, Diversion Indicator,
Priority Indication and various times (e.g.
date-time-group). All RIs extracted from the
line following the message heading are held
in connecting buffers, taken from buffer store,
and called RI Lists (RIL).
Figure 4.2.2-la,b provide the generic layout
and a layout example of an ICAO AFTN formatted
message.
In particular, IP detects and checks the message
elements summarized in table/figure 4.2.2-2.
The types of message corruptions to which IP
will adapt is specified in table/figure 4.2.2-3.
Note that the program may be designed for adaptation
to additional corruptions very easily, due
to the table driven approach that has been
adopted.
Generic format of ICAO AFTN
formatted messages; () means optional
Figure 4.2.2-1a
Example layout of ICAO AFTN formattet message
Figure 4.2.2-1b
ICAO AFTN message elements to be recognized by the
AFTN-MSP message scanning function. Note that the message
filling time may be included in the detectable category
for statistical purposes.
Table/Figure 4.2.2-2
Allowed message elements corruptions, i.e. corruptions
to which the program will automatically adapt.
Table/Figure 4.2.2-3
d) I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲S̲e̲c̲t̲o̲r̲i̲z̲i̲n̲g̲
IP will transform the message bins received
from the Line Handler (LH), i.e. 32 character
buffers, into message sectors appropriate for
disk storage. A candidate sector is 128 characters
per sector.
e) R̲I̲ ̲L̲i̲s̲t̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
All destination call signs, i.e. Routing Indicators
(RI) extracted from the line following the
heading (either normal address line or shortened
address line) are stacked in RI lists (RIL)
which are then attached to their appropriate
message buffers. The RILs contain all information
necessary for the Routing Submodule (RQ) to
expedite onward relay of the messages.
f) P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲Q̲u̲e̲u̲e̲ ̲L̲i̲n̲k̲a̲g̲e̲
Completely processed messages are linked into
the interprocess precedence queues in accordance
with the priority level of the message as determined
from the Priority Indicator in the line following
the heading.
g) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
In the case that IP detects syntactical message
errors which can not be resolved without human
intervention, IP will initiate the generation
of a service message for display/output. This
service message will enable recall of the erronous
message and start of an editing session.
4.2.3 R̲o̲u̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲Q̲u̲e̲u̲e̲i̲n̲g̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲R̲Q̲)̲
The routing algorithm of the AMSS relays each message
on the optimum channel or channels; the decision is
based on an adaptive routing plan. To determine the
AMSS routing requirements, a survey of ICAO routing
methods in relation to fully automatic message switching
centres was carried out, and the routing algorithm
has been based on the survey results (see Appendix
A to section 4.2.3).
The purpose of the RQ submodule is in essense, for
each inbound message, to find the circuit or group
of circuits on which the message in accordance with
its RIs has to be relayed, i.e. for which the AMSS
has positive responsibility.
The AMSS has an active Routing Directory (RD) in computer
memory. The RD consists of an Incomming Circuit Responsibility
Table (ICRT) and a Normal Routing Table (NRT). The
ICRT contains one record for each incomming communication
line. This record designates the addressees (RIs) for
which the AMSS, for the incomming line in question,
has positive relay responsibility. The NRT contains
one record for each addressee (RI) or Location Indicator
(LI) which are recognizable by the AMSS. This record
designates which outgoing channel shall be used for
the RI in question, the current status of the line,
i.e. up/down/outage, and further a reference to the
Diversion Routing List which shall be used in the case
of line failure/outage.
The Diversion Routing Lists (DRLs), of which multiple
may exist for each outgoing circuit, may either be
memory or disk resident, depending on the number of
DRLs to be incorporated in the system.
As an example, a Line Connectivity Diagram for the
Gufunes AFTN-Centre, Iceland is given in Figure 4.2.3-1.
A connectivity diagram for Rangoon will be generated
at the time of contract.
A example of an Incomming Circuit Responsibility Table
(ICRT) is given in Table/Figure 4.2.3-2, and an example
of a Normal Routing Table (NRT) is given in Table/Figure
4.2.3-3.
Example of Connectivity Diagramm
Figure 4.2.3-1
Example of ICRT. Some non-directly connected stations
have been included for illustrative purpose.
Table/Figure 4.2.3-2
Example of NRT. Some non-directly connected stations
have been included for illustrative purpose.
Table/Figure 4.2.3-3
a) R̲o̲u̲t̲i̲n̲g̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲S̲e̲t̲-̲U̲p̲
The Routing Directory (RD) is set up at System
Initialization time. The contents of the RD are
determined as an off-line task, and loaded into
computer memory as part of the program bootload
module.
The contents of the RD will dynamically adapt to
the current condition of the surrounding AFTN network
in accordance with line failures detected by the
AMSS program.
Further the RD may, subject to strict program control,
be altered by the system supevisor through commands
entered from the System Terminal. The reason for
supervisor controlled alteration of the Routing
Directory would for example be the receipt of service
message(s) indication channel outage or circuit
congestion in some part of the AFTN.
b) R̲o̲u̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲Q̲u̲e̲u̲e̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The kernel of the RQ processing is described in
the following.
RQ extracts RIs from the RI list prepared by Input
Processing (IP), and compares the RIs against the
Incoming Circuit Responsibility List (ICRT) for
the channel. When a route has been selected through
examination of the Normal Routing Table (NRT) RQ
makes the appropriate output line queue entry.
RQ scans all RIs for current message, then readjusts
its status to repeat the process for the next message
entered in the interprocess queue by IP.
RQ destinguishes between un-diverted an diverted
inbound traffic as described below.
1) U̲n̲-̲d̲i̲v̲e̲r̲t̲e̲d̲ ̲i̲n̲b̲o̲u̲n̲d̲ ̲t̲r̲a̲f̲f̲i̲c̲
RQ examines the RIs against the ICRT record
for the channel in question and determines
if all message addressees belongs to the positive
responsibility group or not. The following
cases are considered:
a) All Ris of the message belong to the positive
group; RQ simply makes the appropriate
output line queue entries in accrodance
with the NRT.
b) Some, not all RIs of the message belong
to the negative group; RQ makes the appropriate
output line queue entries for those RIs
belonging to the positive group only. If
an outgoing channel appears for both an
RI in the positive and negative responsibility
group then the copy of the message corresponding
to this relay must be given a Shortened
Address. RQ in this case prepares the new
address line to be inserted in the message
by OP. The RIs deleted in the new address
line are those which would otherwise cause
double deliveries.
c) All RIs of the message belong to the negative
group; the system must in this case take
full responsibility for relay to all the
addressees RQ makes the appropriate output
line queue entry for all the negative responsibility
RIs.
2) D̲i̲v̲e̲r̲t̲e̲d̲ ̲I̲n̲b̲o̲u̲n̲d̲ ̲T̲r̲a̲f̲f̲i̲c̲
In the case where a diverted message is received
the diversion indication is supplied to RQ
in the RI list generated by IP. RQ will then
omit the usual ICRT record examination. Thus
the system will take full responsibility for
message relay to all the addressees indicated
in the address line following the heading.
c) D̲i̲v̲e̲r̲s̲i̲o̲n̲ ̲R̲o̲u̲t̲i̲n̲g̲
RQ recognizes channel outage through the NRT status
items, which are maintained by the Line Handler
(LHR), and which may also be altered through supervisor
interrogation. When the need for diversion routing
is thus detected RQ makes the output line queue
entries in accordance with a Diversion Routing
List attached to the NRT record.
A new address line containing only those RIs for
which the receiving centre must take responsibility
("shortened address") are prepared for insertion
in the message together with the diversion indicator
(DI=VVV). The actual insertion is performed by
Output Processing (OP).
d) A̲d̲d̲i̲t̲i̲o̲n̲a̲l̲ ̲N̲o̲t̲e̲s̲ ̲i̲n̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲ ̲t̲o̲ ̲R̲o̲u̲t̲i̲n̲g̲
i) Q̲u̲e̲u̲e̲ ̲e̲n̲t̲r̲y̲ ̲m̲e̲t̲h̲o̲d̲s̲
The outgoing messages are queued in the output
line queues in First-In-First-Out (FIFO) by precedence
order. This means that each outgoing message queue
will at any time be ordered according to the message
precedence levels SS, DD, FF, GG, JJ, KK, LL and
FIFO within each of these precedence categories.
ii) Provision will be made (in the NRT design)
to enable selection of diversion routing for
discreet Priority Indicators.
iii) Where more than one output line is available
to positions with identical Location Indicator
(LI) the most preferable queue (i.e. the shortest
one) will be selected for queue entry.
A̲p̲p̲e̲n̲d̲i̲x̲ ̲A̲ ̲t̲o̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲3̲
S̲u̲r̲v̲e̲y̲ ̲o̲f̲ ̲t̲h̲e̲ ̲I̲C̲A̲O̲ ̲A̲F̲T̲N̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲M̲e̲t̲h̲o̲d̲
This section provides a summary of the AFTN routing
method and requirements in relation to fully automatic
AFTN message switching centres. These requirements
are the basis for design of the Routing and Queueing
submodule (RQ) previously described.
1. I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Routing Algorithm to be worked out for the
AMSS will implement the set of rules outlined in
ICAO DOC. 8259-COM/553/4, thereby facilitating
correct communication to all Addressees to whom
the centre has positive message responsibility
(and also in certain cases, as described in the
following, have negative responsibility).
The outing filosophy adopted by the ICAO AFTN system
is designed to fulfil the requirements:
o delivery of messages always to correct addressee(s)
o to prevent double delivery of identical message
copies to same addressee
o to prevent that messages are not lost in transit.
2. R̲o̲u̲t̲i̲n̲g̲ ̲T̲a̲b̲l̲e̲s̲
In order to direct message traffic over the AFTN
routings established by ICAO the set of tables
described below is used. These tables constitute
the Routing Directory (RD) of the Communications
Centre. These RD elements, which presumably are
utilized in the current manual operation at the
Communications Centre, are adopted by the AMSS,
formatted in a way suitable for computer storage.
The elements making up the Routing Directory are:
a) Incoming Circuit Responsibility Table (ICRT).
ICRT contains, for each ingoing line, all addressees
for which the system has responsibility for
routing (positive responsibility), with respect
of messages received on the line in question.
b) Normal Routing Table (NRT).
NRT contains information concerning which outgoing
lines to be used for every addressee known
by the system. Further NRT will provide information
as to which procedures shall be used - or reference
to line failure adaption data, in the event
of circuit outage(s).
c) Diversion Routing Lists (DRL's).
DRL's correspond the specific entries (RI's)
in the NRT. Multiple DRLs will exist for each
NRT RI entry. Each DRL indicates which changes
shall be made in the NRT entry to which it
is attached, i.e. what diversion routing shall
be applied in the case of outgoing circuit
outage.
3. M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲s̲
The routing directives for each message is contained
in the message line following the heading of the
telegram. The Routing information consists of one
or more addressees, i.e. Routing Indicators RI's.
In the former case the message is called a single-address
message, in the latter, the message falls into
the multi-address message category. Single and
multi-address traffic is, in most respects, subject
to the same processing. However, certain specific
rules apply to single-address messages as described
in the following.
3.1 S̲i̲n̲g̲l̲e̲-̲a̲d̲d̲r̲e̲s̲s̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲(̲S̲A̲M̲)̲
Single-address messages, i.e. containing only one
Routing Indicator, requires the following handling:
o unconditional relay responsibility shall be
taken
o relay to be determined in accordance with the
Normal Routing Table (NRT), or in the case
of circuit outage, with the appropriate Diversion
Routing List (DRL)
o message return (on the return channel) only
to be performed if absolutely necessary, and
then after advising originating station through
a service message.
For single RI messages cross reference to the ICRT
is not needed since the system in both the positive
and negative responsibility case is required to
perform onward relay.
o Only one normal routing should exist between
two points on the AFTN.
o Traffic coming from any one point to any one
addressee should normally always be transmitted
on the same outgoing circuit.
o Traffic for a particular addressee should not
be passed on different routes depending on
e.g. the state of the circuit loading s or
other consideration.
o For the same reason, in the event of failure
of one of the circuits on the normal route,
diversion of the messages without additional
instructions, should not be performed.
o An essential principle of the MPR is that the
Routing Directories of two adjacent Communication
Centres should always be in strict agreement,
so that between any two points there is always
o̲n̲e̲ route determined from end to end and never
n̲o̲n̲e̲ or t̲w̲o̲.
o Agreement is guaranteed by the fact that the
RI's associated to an outgoing circuit in the
NRT of the transmitting system should all appear
in the ICRT of the receiving system. It is
this identity of the ICRT and NRT at both ends
of one and the same circuit that makes it possible
to check, circuit by circuit, that there is
no error in the Directories.
o To each incoming circuit there is associated
an ICRT record containing all the Routing Indicators
for which the system is to assume responsibility
for relay of the message (positive responsibility);
the Routing Indicators not shown there are
considered as corresponding to negative responsibilities.
o Every Indicator for which a positive responsibility
is found should involve relay on the outgoing
circuit corresponding to the Routing Indicator
in the NRT. Indicators for which a negative
responsibility is found should not lead to
relay on the outgoing circuit, corresponding
to the Routing Indicator in the NRT.
o It may be that none of the Routing Indicators
of a message when received appears in the ICRT
record for the ingoing channel. (No positive
responsibilities found). In this case the results
of the consultations of the ICRT must be ignored,
and the message relayed to all the addressees.
This can occasionally cause double delivery
of the message, but is considered acceptable
and preferable to losing a message destined
for one or several addressees.
o No message should be sent on one of the return
channels of the circuit on which it was received,
without prior notification (service message).
Note that a single RI can be a group address,
and will be expanded to a multi-address message.
Additionally, connected to a single RI, a message
can also be flagged for delivery to one or
more addresses from a table of implied routing.
3.2 F̲l̲a̲w̲
In some network configurations the method of routing
by Predetermined Responsibilities allows a flaw
known as the "Shortened Address condition" to exist.
The result of this flaw is that the message, relayed
as received, would be routed twice to an addressee
(double delivery) or, in some cases, would indefinitely
circulate on the network (repeated deliveries).
The flaw must be corrected by adding to the message
a Shortened Address, i.e., a line in which the
indicators which cause the flaw will no longer
appear. The principles underlying the AFTN procedures
are such that, for a given combination of Addressee
Indicators, only one Centre can detect and eliminate
the flaw.
3.3 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲P̲R̲ ̲F̲l̲a̲w̲
The "Shortened Address" condition is detected by
finding the following two groups of lines and do
a comparison between the groups:
group 1 - Outgoint circuits to which the message
has to be relayed, derived from the
analysis of those Addressee Indicators
for which the system has to assume responsibility
(positive group).
group 2 - Outgoing circuits to which the message
does not have to be relayed, due to
the fact that analysis of some other
Addressee Indicators has shown that
the system is not responsible for relay
(negative group).
The need to add a Shortened Address is evident
from the comparison of these two groups. If the
circuits of the "negative" group are all different
from those in the "positive" group, the message
should be relayed as received on all the outgoing
circuits in the positive group. However, if an
outgoing circuit appears in the two groups the
copy of the message corresponding to this relay
must be given a Shortened Address.
3.4 C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲P̲R̲ ̲F̲l̲a̲w̲
The flaw shall be corrected by adding to such messages,
i.e. vulnerable to the MPR flaw, a Shortened Address
in the line following the heading. The Shortened
Address line shall contain only those Addressee
Indicators for which the system has positive responsibility.
Th Shortened Address line may be added to all the
message copies to be relayed.
4. D̲i̲v̲e̲r̲s̲i̲o̲n̲ ̲R̲o̲u̲t̲i̲n̲g̲
Diversion routing is applied whenever the network
suffers from communication line outage(s) or communications
centre failures. The application of diversion routing
ensures that the message traffic is directed around
the network failure(s) on the most straight forward
routing availabe on the AFTN.
4.1 D̲i̲v̲e̲r̲s̲i̲o̲n̲ ̲o̲f̲ ̲S̲i̲n̲g̲l̲e̲-̲A̲d̲d̲r̲e̲s̲s̲ ̲T̲r̲a̲f̲f̲i̲c̲
Diversion of single-address traffic represents
no problem since as described in section 3.1, any
centre unconditionally must accept full relay responsibility
for all single-address messages.
4.2 D̲i̲v̲e̲r̲s̲i̲o̲n̲ ̲o̲f̲ ̲M̲u̲l̲t̲i̲-̲A̲d̲d̲r̲e̲s̲s̲ ̲T̲r̲a̲f̲f̲i̲c̲
Messages containing more thant one Addressee Indicator
(RI) or Location Indicator (LI) cannot, as a general
rule, be diverted unchanged since direct routing
would result in rejection by adjacent centres not
being able to locate the RI/LI's in their ICRT.
To prevent such rejection, a Diversion Indicator
(DI) must be inserted in the header of the message
to be diverted. The DI is supposed to command the
receiving centre to ignore normal PR routing procedures,
and fully accept responsibility for onward relay
to all addressees for which an RI is contained
in the addressee line of the message.
The DI consists of a triple V character sequence
in the end of the heading line (VVV).
The centre adding the DI shall insert a new addressee
line in the message, which contains only RI's for
those addressees which are influenced by the diversion
and for which the next centre must take responsibility.
The centre receiving the diverted message shall
after accepting relay responsibility for all addressees,
remove the DI from the message header before onward
transmission on the AFTN.
4.3 D̲i̲v̲e̲r̲s̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲m̲i̲n̲g̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
Upon detection of circuit outage(s) the Centre
will immediately make provisions for adjustment
of the normal routing procedure, i.e. the NRT.
This is accomplished through the Diversion Routing
Lists (DRL's) related to each addressee/outgoing
line.
To each outgoing line a number of DRL's will exist.
More exactly, each outgoing line will have a number
of DRL's corresponding to the number of network
failures that is possible. Each DRL contains, corresponding
to each addressee in the network for which the
centre has positive relay responsibility, alternative
routing directives.
a) C̲o̲m̲p̲l̲e̲t̲e̲ ̲D̲i̲v̲e̲r̲s̲i̲o̲n̲
Complete diversion, i.e. diversion routing
for all addressees for which an RI is present
in the addressee line, is applied whenever
the failing communication link directly connects
transmitter and receiver.
b) P̲a̲r̲t̲i̲a̲l̲ ̲D̲i̲v̲e̲r̲s̲i̲o̲n̲
Partial diversion, i.e. diversion routing for
a subset of the addressees for which an RI
is present in the addressee line, is applied
in connection with failure(s) on line(s) which
is not adjacent to centre initiating the diversion.
4.4 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
The centre initiating diversion routing shall transmit
a service message to the centre(s) receiving the
diverted traffic.
4.5 Diversion Method (in accordance with ICAO at Annex
10, P̲A̲R̲T̲ ̲I̲I̲,̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲4̲.̲9̲)̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
This method requires that the system makes a distinction
between traffic which is normally routed to the
circuit used for diversion and that traffic which
is diverted to it due to an outage.
The first category is flowing into the circuit
used for diversion due to its appearance in the
NRT, whereas the second category is sent via that
circuit due to its appearance in the DRL.
Therefore, on the outgoing circuit used for diversion,
messages can be found which fall into one of the
following categories listed in table A-1.
Summary of Outgong Message Types
Table A-1
4.6
4.2.4 O̲u̲t̲p̲u̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲O̲P̲)̲
The major task performed by Output Processing is the
final preparation of the outgoing messages queued for
onward relay by the Routing Submodule (RQ).
OP receives its input, i.e. message preparation directives
and message sectors queued in the interprocess queue
by RQ, and delivers the finalized messages in the output
queues for further handling by the Line Handler (LH).
In the event of full output queues, there is adequate
disc capacity for temporary storage while awaiting
available space in the queues. Output messages will
be queued on disc automatically in this case.
The specific Output Processing functions are:
- Appending of message heading (insertion of Diversion
Indicator when required).
- Insertion of Shortened Address when required.
- Insertion of message filing time.
- Character code translation.
- Desectorizing.
a) A̲p̲p̲e̲n̲d̲i̲n̲g̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲e̲a̲d̲i̲n̲g̲
OP inserts a new message header in front of every
outgoing message (the old header is deleted). The
new header contains the elements:
- Start of Message (SOM)
- Transmission Identification (TI)
- Channel Sequence Number (CSN)
and optionally if so requested
- Diversion Indicator (DI).
The SOM (and DI) is synthesized, i.e. equals the
uncorrupted sequence. The new TI will reflect the
coming onward relay of the message, i.e. originating/destination
station identification and the channel identification.
The CSN will be the increment of that used for
the previous message relayed or in queue awaiting
relay on the channel in question.
b) I̲n̲s̲e̲r̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲h̲o̲r̲t̲e̲n̲e̲d̲ ̲A̲d̲d̲r̲e̲s̲s̲
For message requiring a shortened address in the
line following the heading OP will receive the
appropriate RI list from RQ, and insert the Shortened
Address immediately after the new heading (i.e.
between the heading and the original address line).
The resulting Shortened Address will be so constructed
that double delivery of messages will not occur.
c) I̲n̲s̲e̲r̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲i̲l̲i̲n̲g̲ ̲T̲i̲m̲e̲
OP will for each outgoing message insert the filing
time of the message. The Filing Time is a 6-digit
Date Time Group (DTG) combination. The time is
obtained from the AMSS system clock.
d) C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲C̲o̲d̲e̲ ̲T̲r̲a̲n̲s̲l̲a̲t̲i̲o̲n̲
OP scans all outgoing message buffers and translates
each output character from 7-bit internal code
(ASCII) to the 5-bit external line code (ITA2).
Messages received on the ingoing lines contain
the appropriate (SI and SO characters, translated
from figure shift (FS) and letter shift (LS) respectively)
since these messages were received in ITA2, and
hence represent no problem.
Messages generated internally in the AMSS system,
however, must expand due to insertion of case shift
characters. This problem will exist for example
in the case of service messages to be relayed.
OP will during the code translation process monitor
the case state of the character stream and insert
the required figure and letter shift characters.
e) D̲e̲s̲e̲c̲t̲o̲r̲i̲z̲i̲n̲g̲
OP formats the processed message sectors into output
bins (32 character buffers) which is the buffer
size expected by the Line Handler (LH).
4.2.5 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲(̲M̲R̲S̲)̲
AFTN Centre messages which are distributed to designated
addressees are also retained on the message storage
disk for message accountability and message retrieval.
A mirrored copy of all storage is kept on a second
disc to ensure continued operation after a signle disc
failure.
a) M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
AFTN messages are stored on the message storage
disk. Adequate disc storage will be delivered to
allow both short-term and long-term retrieval directly
from disc. In other words, the disc capacity will
allow storage of messages for 30 days. These messages
are stored in the ICAO telegram format. Messages
in the message retention file are available for
message retransmission in the event of equipment
failure somewhere in the network. These messages
are also available for review by the system supervisor.
Messages received with unacceptable corruptions
are stored in the reject message disk file for
further handling by the supervisor.
b) M̲e̲s̲s̲a̲g̲e̲ ̲J̲o̲u̲r̲n̲a̲l̲
Every action related to a particular message is
noted in the message journal maintained for the
particular message. After all actions for a message
have been completed the journal remains as a historical
record of the progress of the message through the
system.
The input journal entry contains initial information
available in every message such as the Transmission
Identification (TI). The TI is used as a message
reference, therefore the journal is a positive
means of cross reference. The input journal entry
also contains the time of receipt of the message
and the length of the message in characters.
The output journal entry contains information pertinent
to message deliveries, i.e. destination addressees.
Message and message journal storage provide the
means to recover not only the original message
but also all pertinent message handling information.
c) M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲g̲i̲n̲g̲
As a message arrives in AMSS memory it is assigned
a starting disk address (SDA). Disk addressed are
assigned in a serial manner from one end of the
disk to the other. This is similar to magnetic
tape. The method is well suited for the hardware,
it is non complex and easy to implement, and it
is the most practical use of available storage.
The log is built and queued. Both log and the subsequent
blocks of the message are written to the disk.
The message log is one or more disk sectors; a
sector holds 128 characters. The log holds the
following information extracted from the message
by Input Processing (IP).
- Transmission Identification (TI)
- Channel Sequence Number (CSN)
- Diversion Idication (DI)
- Message Priority (PI)
- Message Addressees (RIs)
- Message Filing Time
- Message Character Count
- Starting Disk Address (SDA)
d) M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
The log is the key to finding the message during
retrieval. The log is placed in a log queue (LOQ)
before writing to disk. The LOQ is a three word
entry in memory giving:
- filing time of oldest message in storage (on
hourly or daily basis)
- disk address of the oldest message
- disk address of the next available sector.
Hence, whith three words an entire hour's (or day's)
worth of normal arriving message traffic, on hourly
basis approximately XXX messages are linked together.
This is shown pictorily in the figure below. To
achieve rapid LOQ scans a new LOQ is created each
hour, and the old one is closed out by moving its
next available address to the new queue, and zeroing
the word. Hence for tne days of stored traffic
LOQs occupy 24x10x3 = 720 words of memory. …86…1
…02… …02… …02… …02…
These logs are available to the system for statistical
and report purposes as well as retrievals.
Retrieval requests are honoured only from the supervisor
or originator/recipients of a message. The request
itself is an ICAO formatted service message that bears
priority indication and the request-originators RI
and the Channel Serial Number (CSN). These items are
used for the retrieval function in the process of scanning
the LOQs.
4.2.6 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲I̲)̲
In an automated message switching system human intervention
in the automated processing functions is necessary
for overall supervision of the system and direct control
for initiation of changes to the normal procedures,
in the event that unexpected situations should arise.
For this purpose the AMSS application program package
includes an interactive Command Interpreter submodule
(CI) which will act as an interface between the System
Supervisor and the AMSS.
The main areas for supervisory intervention the system
operation are:
- Overall supervision of the message switching system
and the message traffic flowing through it.
- Reprocessing of reject traffic and the handling
of received service messages.
- Technical maintenance of the system.
4.2.7 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
In particular, the below listed functions have relation
to the supervisory intervention in the AMSS. These
functions are further described in the following:
- Overall system supervision
- System initialization
- Switchover and Recovery
- Message retrieval and display
- Reject message editing
- Service message generation
- Initiation of re-routing/diversion
- System time control
- Off-line diagnostic software execution
a) O̲v̲e̲r̲a̲l̲l̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
Although the AMSS Operational Program is designed
to operate almost execlusively without human intervention,
certain means for system monitoring
and control are essential for handling of conflict
or error situations beyond the scope of the automatic
processing capabilities.
The system includes facilities which enable the
System Supervisor to request various system status
displays on the Supervisor Position, e.g. message
statistics, routing status, storage and disk utilization
and equipment hardware status. Any of the three
positions can be configured to be the supervisory
position. The remaining positions can be utilized
for training.
b) S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The Bootload from disk of the AMSS Operational
Program is controlled from the System Supervisor
Terminal. After system power-on, the system enters
a state awaiting a boot - command. Following successful
bootload (indicated on the display) the supervisor
may key in system initialization adaption parameters
if other than default values are to be used.
c) S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Upon detection of hardware or software malfunctions
in either the active or standby processor (optional),
the system will issue an alert or alarm and display
appropriate status information on the system terminal.
The supervisor may then initiate manual switchover
(if such action is required as determined from
the status displayed).
d) M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲a̲n̲d̲ ̲D̲i̲s̲p̲l̲a̲y̲
The system will include facilities for message
log summary displays. These display functions will
enable the supervisor to receive message logging
information related to specified message serial
number - filing time ranges. Any message filed
in disk retention storage is given a message serial
number and will be recallable for display on the
system terminal.
e) R̲e̲j̲e̲c̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲i̲n̲g̲
Message which contain unacceptable corruptions
(as detected by IP) are stored in a temporary reject
message disk file. The supervisor is alerted upon
detection of such messages, or if the system has
been unattended, the supervisor can request the
queued rejected messages. Rejected messages are
subject to manual edition (see RME, section 3.1.2.7)
and is recallable from the reject message
file by appropriate command. The erroneous message
is edited, using the terminal built-in editing
function. Following edition of a message, the supervisor
may return the corrected message to the appropriate
inbound message queue for reprocessing by IP
f) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
ICAO AFTN formatted service messages may be entered
from the system terminal for transmission to other
communication centers on the AFTN.
Further, the system has a number of prestored service
messages on disk which through appropriate command
may be selected for transmission.
g) I̲n̲i̲t̲i̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲e̲p̲o̲r̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
The supervisor may at any time, through appropriate
commands, request output of statistical reports
(see also section 4.2.9). Statistical reports will
by default be directed to the TTY hardcopy backup
printer, but may if desired be displayed on the
terminal.
h) R̲o̲u̲t̲i̲n̲g̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲U̲p̲d̲a̲t̲e̲
The Routing Directory (RD) of AMSS may be changed/updated
by the System Supervisor. This might for example
be desired upon schedule service on the communication
lines or AMSS line interface equipment.
The RD change entry function will provide comprehensive
error checking on the entry data.
i) I̲n̲i̲t̲i̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲e̲-̲R̲o̲u̲t̲i̲n̲g̲/̲D̲i̲v̲e̲r̲s̲i̲o̲n̲
In cases where the AMSS is not able to determine
the appropriate routing for relay of a given message,
or in the case of received service message requesting
re-routing of specific message (s), the AMSS system
will alert the System Supervisor. Facilities are
included which enable the Supervisor to initiate
re-routing/diversion routing.
j) S̲y̲s̲t̲e̲m̲ ̲T̲i̲m̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Supervisor has full control of the System Time
Function. The System Time may be set to a specified
value and displayed on the system terminal.
k) E̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲o̲f̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
In the event of total failure of one of the redundant
systems, the Off-Line Maintenance and Diagnostic
Program Package may be bootloaded from the disk.
M & D contain a number of different test programs
intented for test of descreete modules in the system.
These submodules may be executed separately. Errors
detected/test results are displayed on the system
terminal.
4.2.8 R̲e̲j̲e̲c̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲o̲r̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲R̲M̲E̲)̲
Messages containing serious corruptions, i.e. to which
the IP analysing function may not adapt, will be saved
on temporary disk file. Such messages shall be subject
to text editing controlled by the System Supervisor.
Rejectable messages are queued as received in the FIFO
reject message queue, and from there are recallable
upon request from the System Terminal.
The System Supervisor is made aware of the precense
of messages awaiting his attention, for analysis and
correction, through appropriate service messages directed
to the System Terminal.
The Reject Message Editor (RME) acts as an interactive
interface between the Supervisor and the System during
reject message editing sessions. When a garbled message
has been recalled and edited, it is upon command returned
to the system for reprocessing by Input Processing
(IP), which will handle the edited message as if it
has arrived in one of the external lines.
4.2.9 S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲(̲S̲A̲R̲)̲
System data files contain the current and historical
data needed to meet reporting requirements. The statistical
data for messages are updated by the message processing
submodules (IP and OP). Other
related statistics such as message storage occupancy,
route and channel status, queue length, etc. are maintained
by other submodules (LH, MSR, RQ). These statistics
do not require frequent access, and therefore, the
disk access time does not impact message processing
time. Miscellaneous statistics such as equipment status
information are extracted from the current data base
contents.
The Statistical Analysis and Report submodule (SAR)
performs the compilation and extraction of statistical
data made available for analysis by the various other
submodules of the AMSS. Below is given a preliminary
list of the statistics that might be part of the analysis.
Related to message handling:
- message transit timing
- message priority accounting
- reject message accounting
- hourly traffic volumen
- daily traffic volumen
- average message length
Related to routing and queueing:
- average queue lengths
- re-routing accounting
- diversion routing accounting
Related to message storage:
- memory utilization
- disk file utilization
Miscellaneous:
- equipment status
a) R̲e̲p̲o̲r̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
The generation of statistical reports is performed
by SAR. The SAR submodule extracts and compiles
the statistics in a format suitable for display
on the Supervisor Terminal or printout on the hardcopy
backup.
The Communication Center Supervisor can monitor
AMSS operations by manually requesting statistical
reports, but he is also alerted to situations requiring
possible operator intervention by automatically
generated reports. A report is triggered whenever
an event or situation occurs which indicates a
change in normal system operation.
4.2.10 S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲I̲N̲I̲)̲
After power-on the system will be in a state awaiting
a bootload command from the System Terminal. The boot
command initiates transfer of the entire operational
program from disk file to the AMSS memory. When the
entire boot block has been loaded into memory the bootstrap
loader passes control to the initialization submodule
INI which is part of the operational program.
a) I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
INI initializes all memory resident tables and
interface devices (e.g. LTUs) necessary for operation
to commence. INI automatically adapts to the actual
memory and line configuration for the site, e.g.
sets up line status tables for the communication
channels. After initialization control is passed
to the system program.
4.3 S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
The system software described in this sub-section is
the XAMOS Operating System, a standard product of Christian
Rovsing A/S, and XAMOS extensions that have been developed
is order to optimize CR80 communications processing
features.
4.3.1 X̲A̲M̲O̲S̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
The XAMOS operating system comprises the following
subsystems:
o XAMOS Kernel
o File Management System (FMS)
o Input/output system (I/O System)
o Critical Region Monitor
The function of the XAMOS Kernel is to allocate CPU
time to processes as a function of their priority,
as well as their application characteristics.The Kernel
further performs event synchronization, interprocess
communication and fault detection.
The I/O Systems supports the application programs in
accessing I/O devices by a uniform set of commands.
The I/O System contains drivers for external devices
such as LTU Driver, DISC Driver dualized disc system,
and drivers for the different terminal types: VDUs
and teleprinters.
The file management function exhibits also a departure
from the traditional approach found in most communication
network implementations by recognizing that a primary
design goal is to minimize the elapsed time for disk
file operations, while supporting dynamic file creation,
extension and deletion for multiple interactive terminal
users and for real-time network traffic. It meets
these objectives in part by isolating, in a separate
computer system, disk file operations from execution
of AMSS application processes.
The File Management Supervisor treats the disk unit
as two logical devices. This allows data transfer
from the fixed-head portion of the disk to occur simultaneously
with moving-head seek operations.
Disk operations are dualized on two separate disk units.
This is accomplished by duplicating the logical file
structure and control on each of two configured disk
units. Disk dualization is supported by the Input/Output
System and the File Management System in a way that
is transparent to application programs, except for
reporting of disk operation status. Error status returns
are reported by application software to the Error Switchover
Processor.
The file management function further reduces the potential
for bottlenecks to throughput by providing multiple,
logical data channels between the File Processor (FP)
and the AMSS application, or User Processor (UPs).
These channels, referred to as "DMA ports", transfer
commands and data concurrently between the FP and UP.
The FP services each transfer in a sequence whose
priority is specified for each port. The number of
ports in concurrent use is a system parameter.
The fault detection and error recovery function provides
on line test and diagnostics concurrently with the
real time functions performed by applications processes.
It attempts also to recover from CPU and other processors'
execution faults. If the fault is unrecoverable the
Error Switchover Processor (ESP) is notified of the
condition. The ESP is otherwise notified periodically
that the processors of the system are executing normally.
Finally, this function provides for recovery from
system failure by recording the occurrence of significant
events that indicate message and terminal status.
These checkpoint records are available to the standby
processor during its restart and recovery procedure.
4.3.2 E̲x̲t̲e̲n̲s̲i̲o̲n̲s̲
The standard XAMOS operating system has been extenden
to support the concurrent flow of messages and reports
and to provide facilities for dualized operation.
These extensions are categorized as:
o Memory Management
o Message transition control (MTCB Monitor)
o Queue Access Management (QACCESS)
o Shared Memory Access (Critical Regions)
o Switchover and Recovery
o On line diagnostics
The queue and memory management monitors are designed
to interact as necessary to manage the shared use of
primary and secondary disk memory. They recognize
that subsystems are designed to execute as queue driven,
independent groups of software processes.
The principal extensions are described in the sub-sections
to follow.
4.3.2.1 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Each program is allocated, at system start up time,
a contiguous data space large enough to contain its
I/O buffers and file descriptions and other data local
to
execution of the program. This results in identifying,
to the ESP, the program and its data space as a "process",
as illustrated in Figure 4.3.2.1-1. Processes in AMSS
may execute the same program reentrantly, but may not
share the same process data space.
4.3.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲i̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
Memory data space that is not dedicated to local processes,
or for global reference to subsystem queues or system
data, is avialable for allocation during system operation.
This space is designed to be used to record the status
of messages and reports as they flow through subsystem
interfaces.
Figures 4.3.2.2-1 and 4.3.2.2-2 illustrate use of Message
Transition Control Blocks (MTCBs) to maintain system-wide
awareness of the status of messages and reports. Awareness
of message status is maintained by recording in the
MTCB the indicators listed below.
Figure 4.3.2.1-1…01…Overview Of Process Concept
Figure 4.3.2.2-1…01…MTCB Use, Real MTCB
Figure 4.3.2.2-2…01…MTCB Use, Pseudo MTCB
a. The message is now being served by one (or
more) specific subsystem processes.
b. The message is located on an inbound file or
preparation file, or it is stored in the Historical
Data Base at a specific address.
c. The message requires optional special security
handling.
d. The message's precedence and length, in number
of bytes, is recorded.
e. The message's security classification is recorded,
if it is being delivered to a local MEDE terminal.
In addition to these common status indicators, the
MTCB is designed to record information needed for specific
subsystem use. This includes, for example, routing
information for message switching and distribution,
and the time of day the message was queued for entry
into the Historical Data Base.
To control the use of Message Transition Control Blocks,
an MTCB Monitor is used as shown in Figure 4.3.2.2-3.
It allocates fixed-length blocks from a memory pool,
assigning each block a number ("MTCB index") that is
used in queue references to messages and reports.
It provides also as an option the creation, and subsequent
deletion, of disk files for use by multiple processes.
It ensures that a file is not deleted until the last
process that references the file's MTCB completes processing.
4.3.2.3 Q̲u̲e̲u̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Processes that require a message or report to be delivered
to a subsysten or terminal interface request the QACCESS
monitor to perform the service. Figure 4.3.2.3-1 provides
an overview of the general queue structure, and its
memory management.
An entry in a queue is an index number that references
an MTCB.
Queue server processes call QACCESS to read or remove
queue entries, by FIFO precedence, or by position in
the queue.
Some interfaces are configures with one queue for each
level of message precedence. QACCESS can be requested
to enter and retrieve entries from a single logical
queue that represents the group of precedence queues
assigned to an interface.
Other queue management services are provided by QACCESS,
including the numbering and reorganizing of queues,
as well as returning data to the requestor about the
lengths of queues.
Figure 4.3.2.2-3…01…Use Of MTCB Monitor
Figure 4.3.2.3-1
General Queue Structure
4.3.2.4 S̲h̲a̲r̲e̲d̲ ̲M̲e̲m̲o̲r̲y̲ ̲A̲c̲c̲e̲s̲s̲
The executive software has been extended to control
multiple processes that access concurrently shared,
"critical" regions. Processes that require such access
are considered to be in one of the states shown in
Figure 4.3.2.4-1.
Critical regions are addressed by symbolic name. Memory
locations within a critical region also are addressed
symbolically, the result being an offset value relative
to the origin of the region. The memory area contained
within a region is referred to as the "variable space",
or VS.
Note that the states shown in the Figure apply only
to the relation between a single region and a process.
The process may interact with several other regions
at the same time.
The meaning of the states are:
R̲e̲g̲i̲o̲n̲ ̲l̲e̲f̲t̲:
In this state the process has no access to the
VS of the region. A process will initially be
in this state.
R̲e̲g̲i̲o̲n̲ ̲e̲n̲t̲e̲r̲e̲d̲:
In this state the process has access to all the
variables of the VS. Only a single process can
be in this state (in relation to a specific region)
at any one time.
W̲a̲i̲t̲i̲n̲g̲ ̲t̲o̲ ̲e̲n̲t̲e̲r̲ ̲r̲e̲g̲i̲o̲n̲
The process is suspended until no other process
is in the "region entered" state.
W̲a̲i̲t̲i̲n̲g̲ ̲t̲o̲ ̲r̲e̲-̲e̲n̲t̲e̲r̲ ̲r̲e̲g̲i̲o̲n̲
The process is suspended until a process leaves
the region.
The purpose of this state is to be able to wait
until the variables of the VS fulfils a wanted
condition.
Figure 4.3.2.4-1…01…Critical Region Control
The transitions between the states occur at the following
events:
1: The current process calls ENTER-REGION and
the region already contains a process in the
"region entered" state.
2: The current process calls ENTER-REGION and
no process is in the "region entered" state.
3: Another process (which was in the "region entered"
state) calls LEAVE-REGION or WAIT-REGION, and
the current process is at the head of the queue
of processes waiting to enter the region and
no processes w̲e̲r̲e̲ in the state "waiting to
re-enter region".
4: The process calls LEAVE-REGION.
5: The current process calls WAIT-REGION.
6: Another process calls LEAVE-REGION or WAIT-REGION
and the current process is at the head of the
queue of processes waiting to re-enter the
region.
The normal use of critical regions is:
o to enter a region
o modify and/or inspect the variables in VS
o if the varibales inspected must fulfil a certain
condition (which they do not) before processing
can continue, the process may call WAIT-REGION.
This causes the process to be delayed until
at least one other process has been in the
"region entered" state.
o and finally to leave the region.
A region does not need to control a VS. If it does
not, the criticl region serves as a simple synchronization
element.
4.4 S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
This section highlights the CR80 support software.
Two aspects are described:
- Off-line diagnostics
- Switchover and recovery
Off-line diagnostics can be run on both single and
fault-tolerant (optional) systems, while switchover
and recovery is only relevant for fault-tolerant systems
4.4.1 O̲f̲f̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
Off-Line diagnostics are disc resident programs controlled
from a terminal which may be loaded on a processor
system, which is already declared off-line because
of noticeable error.
For fault-tolerant systems, the off-line diagnostics
programs must be able to operate in the failed half
part of the system simultaneously with continued operation
of the other half part.
Off-Line diagnostics detect faults by direct checking
of equipment modules and by analysis of test results,
which isolate faults to replaceable hardware modules.
The off-line Maintenance and Diagnostics (M+D) program
contains the following submodules: Central Processing
Unit Test (CPU), Random Access Memory Test (RAM) and
Programmable Read Only Memory Test (PROM).
The Central Processing Unit Test tests proper operation
of a CPU by verification of all possible instructions
in the instruction set except for Monitor call and
I/O instruction.
The Random Access Memory Test verifies proper operation
of RAM memory module. The following elements are tested:
Main Bus interface, RAM internal addressing circuitry
and storage circuitry.
The Programmable Read Only Memory Test verifies proper
operation and proper contents of the PROM.The following
elements are tested: mainbus interface, internal addressing
circuitry and contents of PROM chips.
4.4.2 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Switchover and recovery is performed by the ESP - Error
and Switchover Process. The functions performed by
the ESP are as follows:
o Start
o Restart/Recovery
o Checkpointing
o Watchdog communication
S̲t̲a̲r̲t̲
The very first initialization of an AMSS is called
the start. The subsystems are loaded, initialized,
and started with the common RESTART ̲FLAG set to
FALSE.
There are no messages within the subsystems for
which they are responsible.
R̲e̲s̲t̲a̲r̲t̲/̲R̲e̲c̲o̲v̲e̲r̲y̲
The system restart function executes after a switchover
from an active to standby unit. During a restart
the former cold stand-by computer is started, i.e.
the subsystems are initialized with the common
RESTART ̲FLAG set to TRUE.
In case of a fatal error in the active branch,
i.e. an error which makes it impossible for the
branch to continue operations, a switchover from
active to stand-by branch is performed. The stand-by
branch has to be RECOVER'ed. This means that it
must be brought into a position from where the
former active failed. The standby branch has in
advance been loaded with all necessary software
modules ready to start executing of instructions.
The Disk system can immediately be used. The vital
thing missing to start operations is the data placed
in the CR80-memory of the formerly active branch.
These data are recovered by use of CHECKPOINTs
stored outside the CR80 memory. Checkpoints are
data records that define the states and substates
of a system, e.g.
- state of message being processed
- state of circuit
- state of terminal.
In the AMSS, these records are stored in the disc
system, where they can be retrieved by the standby
branch. After the processes are started in the
standby branch these checkpoints are processed
in the RESTART procedure to reestablish the data
structures in the CR80-memory as close as possible
to the original contents former active:
o All queues are regenerated.
o The Routing Data File is loaded as left
by the failed branch. In this way neither
routing information nor circuit status
is lost.
o All circuits which were open during the
crash are re-opened.
o The outbound Message file is scanned and
emptied, and each message is put into the
transport queue for rerouting and retransmission.
o After recovery, normal processing continues
without message loss.
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲
By means of checkpoints the book-keeping of messages
for which the AMSS is responsible is currently
updated.
Locally generated messages put into the Transport
Queue are p̲o̲s̲i̲t̲i̲v̲e̲l̲y̲ checkpointed by the supplier.
Remotely generated messages are p̲o̲s̲i̲t̲i̲v̲e̲l̲y̲ checkpointed
when written on disc before the ACK is returned.
Whenever a message is put into an output queue
a positive checkpoint is made. For the transport
queue, however, this is done by saving the Outbound
Message Buffer onto the Outbound Message File or
the Checkpoint File.
When a message is deleted from a queue a n̲e̲g̲a̲t̲i̲v̲e̲
checkpoint is made. For the transport queue, however,
this is done by saving the Outbound Message Buffer
onto the Outbound Message File.
Figure 4.4.3-1 shows some typical checkpoint events.
W̲a̲t̲c̲h̲d̲o̲g̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The ESP resides in both the active and the standby
branch of the dualized CR80 Node/Mede computer.
Both ESP will with regular intervals send Keep
alive messages to the Watchdog. If Keep alive messages
from the active branch are missing, the watchdog
will initiate switchover. The ESP will receive
error messages from the on line diagnostics and
in case of fatal errors request for a switchover.
Also fatal S/W errors will be cause notification
of the ESP, which will initiate switchover and
resart.
S̲U̲B̲S̲Y̲S̲T̲E̲M̲ A̲C̲T̲I̲O̲N̲ R̲E̲S̲P̲O̲N̲S̲I̲B̲L̲E̲
B: ACCESS MSG. IN QUEUE AB
B: PROCESS MSG
B
B: PUT MSG: INTO QUEUE BC
B: MAKE A POSITIVE CHECKPOINT FOR C
B: MAKE A NEGATIVE CHECKPOINT FOR B
B: REMOVE MSG. FROM QUEUE AB
C
C: PROCESS MSG.
C: PUT MSG. INTO QUEUE CD
C: MAKE A POSITIVE CHECKPOINT FOR D
C: MAKE A NEGATIVE CHECKPOINT FOR C
C: REMOVE MSG. FROM QUEUE BC
D
Figure 4.4.3-1…01…Positive And Negative Checkpoints
