top - download
⟦ccec78ea2⟧ Wang Wps File
Length: 112010 (0x1b58a)
Types: Wang Wps File
Notes: ASC GREECE; TECHNICAL
Names: »4655A «
Derivation
└─⟦27ab02fb4⟧ Bits:30006020 8" Wang WCS floppy, CR 0452A
└─ ⟦this⟧ »4655A «
WangText
…00……00……00……00…"…02……00……00…"
!…09…!
…0c… …05……1f……0e……1e……08……1e……02……1e……07……1d……0f……1c……08……1c……0c……1c…
…1c… …1b……0a……1b……01……1b……07……1a……0c……1a……0d……1a…
…19……0a……19……02……18……0b……18…
…17……0c……17……02……16……09……16……00……16……07……15……0f……15……06……86…1 …02… …02… …02… …02…
ASC GREECE - PART II SYS/84-03-10
TECHNICAL PROPOSAL Page
ASC GREECE
AUTOMATIC MESSAGE AND DATA SWITCHING CENTRE
DOC. NO. ASC/8020/PRP/001 ISSUE 1
PART II
TECHNICAL PROPOSAL
SUBMITTED TO: HELLENIC REPUBLIC
MINISTRY OF COMMUNICATION
CIVIL AVIATION AUTHORITY
SUPPLY DIVISION
1, VASILEOS GEORGIOUS AVENUE,
HELLINICON, ATHENS
IN RESPONSE TO: TENDER NO. EX22/1983
PREPARED BY: CHRISTIAN ROVSING A/S
SYSTEMS DIVISION
LAUTRUPVANG 2
2750 BALLERUP
DENMARK
PRINCIPLE CONTACT: Gert Jensen, Director Systems
Group
Telex Denmark 35111 cr dk
Telephone: 02 65 11 44
…0e…c…0f… Christian Rovsing A/S - 1984
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.
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
0 GENERAL ........................................
9
0.1 DECISION TO BID THE AUTOMATIC MESSAGE AND
DATA SWITCHING CENTRE ......................
9
0.2 PURPOSE OF SYSTEM ..........................
11
0.3 SCOPE OF THE SPECIFICATION .................
11
1 TYPE OF CENTRE - PURPOSE OF PROCUREMENT ........
12
1.1 TYPE OF CENTRE - IMPLEMENTATION ............
12
1.2 PURPOSE OF PROCUREMENT .....................
12
1.3 MODULARITY ................................
12
1.4 LICENSING ..................................
13
2 SPECIAL TECHNICAL CHARACTERISICS OF THE ASC ....
14
2.1 COMMUNICATIONS BASED ON THE CBI DATA LINK ..
14
CONTROL PROCEDURE/CIDIN PROCEDURE ..........
14
2.1.1 Commumications between the Athinai ASC .
14
and other CIDIN centres ................
14
2.1.1.1 General ............................
14
2.1.1.2 The Frame Structure ................
16
2.1.1.3 Implementation of Protocol Layers ..
17
2.2 ASC SOFTWARE ...............................
19
2.2.1 Software Structure .....................
19
2.2.1.1 General ............................
20
2.2.1.2 Software Configuration .............
16
2.2.1.3 Software Requirements ..............
32
2.2.1.4 Modularity and Flexibility .........
53
2.2.2 Software Modifications .................
54
2.2.3 Change of CIDIN Parameters .............
54
3 OPERATIONAL AND FUNCTIONAL REQUIREMENTS ........
56
3.1 TRAFFIC VOLUME .............................
56
3.2 CIRCUITS ...................................
60
3.3 CATEGORIES AND FORMATS OF MESSAGES .........
61
3.4 MESSAGE ROUTING ............................
65
3.5 TELEX SERVICE ..............................
70
3.6 OPTIONAL CAPABILITIES ......................
70
3.6.1 Message Composing Facility .............
70
3.6.2 Multicopy Facility .....................
71
Page
3.7 MESSAGE PROTECTION .........................
71
3.8 TRAFFIC RECORDS ............................
75
3.8.1 Long Term Traffic Records ..............
75
3.8.2 Short Term Records .....................
75
3.9 STATISTICS .................................
76
3.10 SYSTEM SUPERVISION AND CONTROL ............
77
4 ASC MAINTENANCE/TECHNICAL ASSISTANCE ...........
78
4.1 MAINTENANCE PHILOSOPHY .....................
78
4.1.1 General ................................
78
4.1.1.1 Maintenance Planning ...............
78
4.1.1.2 Maintenance Plan ...................
78
4.1.2 Maintenance Strategy (Hardware) ........
81
4.1.2.1 Preventive Maintenance .............
81
4.1.2.2 Emergency Maintenance ..............
81
4.1.2.3 Workshop Equipment .................
81
4.1.3 Maintenance Strategy (Software) ........
82
4.1.3.1 The ASC Software ...................
82
4.1.3.2 Firmware ...........................
82
4.1.4 Impact on Equipment ....................
82
4.1.4.1 Maintenance Equipment ..............
82
4.1.5 Impact on Staffing and Training ........
82
4.1.6 Special Requirements ...................
82
4.2 TECHNICAL ASSISTANCE ......................
83
4.2.1 General ................................
83
4.2.1.1 Field Support ......................
83
4.2.1.2 Repair .............................
83
4.2.2 Approval of Personnel ..................
83
4.2.3 Vendor Repair of LRU's and SRU's .......
84
4.2.4 On-site Maintenance ....................
84
4.2.5 General Information ....................
84
4.2.6 System Support .........................
84
4.2.6.1 General ...........................
84
4.2.6.2 Software and Hardware ..............
85
4.2.6.3 Documentation/Modifications ........
85
Page
5 ASC INSTALLATION ...............................
86
5.1 INSTALLATION ANALYSIS ......................
86
5.1.1 Requirement Analysis ...................
86
5.1.2 Installation Cost Analysis .............
87
5.2 INSTALLATION SERVICE .......................
88
5.3 CHANGE OVER ...............................
88
5.4 INSTALLATION SCHEDULE ......................
88
5.5 SITE PREPARATION AND INSTALLATION ..........
90
5.5.1 Site Preparation and Installation
Planning ...............................
90
5.5.1.1 Site Surveys .......................
91
5.5.1.2 Installation Plan ..................
91
5.5.1.3 Site Preparation Requirements ......
92
5.5.1.4 Equipment Installation Drawings ....
92
5.5.1.5 Site Readiness Verification ........
93
5.5.2 ASC Facilities .........................
94
5.5.2.1 Facility Layouts ...................
94
5.5.2.2 Facility Requirements ..............100
5.6 SITE INSTALLATION ..........................108
5.6.1 Transportation of the Equipment ........108
5.6.2 Installation and Cabling Requirements .109
5.6.2.1 Cabling ............................110
5.6.6.2 General Installation Rules .........110
6 DOCUMENTATION ..................................111
6.1 GENERAL ....................................111
6.1.1 Right to Dublicate .....................111
6.1.2 Standards ..............................111
6.1.3 Amendment Documentation ................112
6.2 DETAILED DOCUMENTATION REQUIREMENT ANALYSIS 112
6.2.1 Program Management Documentation ......112
6.2.2 Design Specifications and Reports ......112
6.2.3 Installation Documentation .............113
6.2.4 Quality Control Documentation ..........113
6.2.5 Provisional Handbooks ..................114
Page
6.2.5.1 System Description Manual ..........
114
6.2.5.2 S/W Documentation ..................
114
6.2.5.3 Maintenance Manual .................
115
6.2.5.4 Operation Manual ...................
115
6.2.5.5 Operator's/User's Manual ..........
115
6.2.5.6 Drawings ...........................
115
6.2.5.7 Hardware Assembly Breakdown ........
116
6.2.5.8 Spare Parts Catalog/List ...........
116
6.2.5.9 Auxiliary Equipment and Built-In
Test (BIT) .........................
116
6.2.5.10 Maintenance Check-List, Test
Records ..........................
117
6.2.5.11 Maintenance Reports ..............
117
6.2.6 Final Handbooks ........................
117
6.3 DOCUMENTATION UPDATE .......................
117
7 TRAINING ......................................
118
7.1 GENERAL ....................................
118
7.2 TRAINING DOCUMENTS ........................
119
7.3 TRAINING FACILITIES FOR ON-SITE COURSES.....
119
7.4 LANGUAGE ...................................
119
7.5 COURSE SUPERVISION/COORDINATION ............
120
7.6 COURSE EXAMINATION .........................
120
7.7 PREPARATORY TRAINING .......................
120
7.8 FINAL TRAINING PROGRAMS ....................
120
7.9 DETAILED COURSE DESCRIPTION ................
120
7.9.1 General Introduction Course ............
120
7.9.1.1 Objective ..........................
120
7.9.1.2 Contents ...........................
121
7.9.1.3 Target Group .......................
121
7.9.1.4 Number of Participants .............
121
7.9.1.5 Course Duration ....................
121
7.9.1.6 Number of Classes ..................
121
7.9.1.7 Location ..........................
121
7.9.1.8 Course Profile .....................
121
7.9.1.9 Finalized Training Program .........
121
7.9.2 Technical Course, Hardware - Type 1
and 2 ..................................
122
Page
7.9.2.1 Contents ..........................
123
7.9.2.2 Target Group .......................
123
7.9.2.3 Number of Participants .............
123
7.9.2.4 Course Duration ...................
123
7.9.2.5 Number of Classes ..................
123
7.9.2.6 Location ...........................
123
7.9.2.7 Finalized Training Program .........
123
7.9.3 Technical Course, Software - Type 1 and.
124
2 (S/W Development and S/W Maintenance).
124
7.9.3.1 Objective ..........................
124
7.9.3.2 Contents ...........................
124
7.9.3.3 Target Group .......................
124
7.9.3.4 Number of Participants .............
124
7.9.3.4 Course Duration ....................
124
7.9.3.6 Number of Classes ..................
125
7.9.3.7 Location ...........................
125
7.9.3.8 Finalized Training Program .........
125
7.9.4 H/W Maintenance Course - Type 3
(Module Level) .........................
126
7.9.4.1 Objective ..........................
126
7.9.4.2 Contents ...........................
126
7.9.4.3 Target Group .......................
127
7.9.4.4 Number of Participants .............
127
7.9.4.5 Course Duration ....................
127
7.9.4.6 Number of Classes ..................
127
7.9.4.7 Location ...........................
127
7.9.4.8 Finalized Training Program .........
127
7.9.5 Operator's/User's Course ...............
128
7.9.5.1 Objectives .........................
128
7.9.5.2 Contents ...........................
128
7.9.5.3 Target Group .......................
128
7.9.5.4 Number of Participants .............
128
7.9.5.5 Course Duration ....................
128
7.9.5.6 Number of Classes ..................
129
7.9.5.7 Location ...........................
129
7.9.6 Soldering Course (optional) ............
129
7.10 TRAINING IMPLEMENTATION PHASE 2 AND 3 .....
130
7.11 WITH REFERENCE TO THE RFP SECTION 7.9.3 ...
130
7.12 COURSE SCHEDULES ..........................
131
Page
8 ACCESSORIES - LABORATORY EQUIPMENT .............
132
8.1 WORKSHOP REPAIR FACILITIES ................
132
8.2 FUNCTIONAL REQUIREMENTS ....................
133
8.3 TRAINING AND DOCUMENTATION .................
133
8.4 HARDWARE DESCRIPTION .......................
133
8.4.1 Mock-Up System .........................
133
8.4.2 Workbench for CR80 Modules .............
133
8.4.3 Workbenches for Peripherals ............
134
8.4.4 Automatic Test Equipment ...............
134
8.4.6 Mock-Up Facilities .....................
134
8.4.6.1 ASC Mock-Up Room ...................
134
8.4.6.2 Air Cooling ........................
135
8.4.6.3 Environmental Conditions ..........
135
9 INITIAL SPARES .................................
137
9.1 GENERAL ....................................
137
9.2 SPARES CATEGORIES ..........................
137
9.2.1 Consumables ............................
137
9.2.2 Components (Piece Parts) ...............
137
9.2.3 Modules ................................
137
9.3 SPARES REQUIREMENTS ........................
140
9.4 OPTIMUM SPARES SUPPORT STRATEGY ............
140
9.5 SPARES CONSUMPTION QUARANTEE ...............
142
9.6 LOGISTIC DELAY TIME (LDT) ..................
142
9.6.1 Procurement of Spares ..................
142
9.7 DELIVERY ...................................
142
9.8 FORMAT FOR SPARE MODULES ...................
142
9.8.1 Level of Repair Analysis ...............
142
9.8.2 Explanation of the Table ...............
142
9.8.3 RSPL Format ............................
146
10 GENERAL TECHNICAL REQUIREMENTS AND CONDITIONS
148
10.1 INTRODUCTION .............................
148
10.2 MECHANICAL CONSTRUCTION ..................
150
10.3 ELECTRICAL DESIGN ........................
156
10.4 RELIABILITY, AVAILABILITY, MAINTAINABILITY
(RAM) ....................................
157
10.5 AUDIBLE NOISE LEVEL LIMITS ...............
170
10.6 ENVIRONMENTAL CONDITIONS AND REQUIREMENTS
170
10.7 ELECTROMAGNETIC INTERFERENCE (INTERNALLY
GENERATED) ...............................
170
10.8 GROUNDING ................................
170
Page
11 CONTRACT MANAGEMENT AND EQUIPMENT INSPECTION
PROCEDURES ...................................
171
11.1 GENERAL ..................................
171
11.2 PROJECT MANAGER ..........................
171
11.3 PROGRESS CHART ...........................
171
11.4 PROGRESS MEETINGS ........................
172
11.5 PROJECT EXECUTION CHECKS AND FACTORY
INSPECTIONS ..............................
173
11.6 FINAL FACOTORY INSPECTION TESTS
(FFI-TESTS) ..............................
173
11.7 PROVISIONAL ACCEPTANCE (PA) ..............
175
11.8 FINAL ACCEPTANCE .........................
178
12 SYSTEM CONFIGURATION .........................
179
12.1 GENERAL ..................................
179
12.2 INFORMATION .............................
179
12.3 IMPLEMENTATION ...........................
180
12.4 COST MODEL ...............................
180
0̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
0.1 D̲E̲C̲I̲S̲I̲O̲N̲ ̲T̲O̲ ̲B̲I̲D̲ ̲T̲H̲E̲ ̲A̲U̲T̲O̲M̲A̲T̲I̲C̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲A̲N̲D̲ ̲D̲A̲T̲A̲ ̲S̲W̲I̲T̲C̲H̲I̲N̲G̲
̲C̲E̲N̲T̲R̲E̲ ̲A̲S̲C̲
The decision to bid ASC 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 top-level 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 or sub-contractor
of major computer system projects provide a solid basis
for our participation in this project. Prime contractor
responsibility, especially for airline customers such
as Air Canada and American Airlines, 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 US Dollars.
To provide the necessary talent and facilities, the
ASC 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 Divisions.
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 Air Canada, American Airlines,
NATO and ICL.
o The Production Division - responsible for manufacturing
of the CR80 Computer product line.
The ASC Project Group will be supported by the Integrated
Logistics Support Group, which provides services including
site surveys, installation, training, documentation
preparation, maintenance, spares and other necessary
support services.
Product quality will be ensured by the Quality Assurance
Department, which reports directly to company management.
An administratively distinct Project Office will be
established to manage the ASC Project. This project
office will have total system responsibility and authority
to coordinate in-house activities and to provide close
liaison with the customer 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 design, implementation and maintenance
of the ASC.
The ASC switching facility is similar to the highly
efficient communications processor used in military
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 host computer proposed for the ASC is a CR80 computer
system, which can be fully dualized 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.
Christian Rovsing A/S 's experience in developing and
implementing systems is based on various military and
commercial projects conducted in the past. In close
cooperation with the customer, Christian Rovsing A/S
has provided cost effective systems, and believes that
a similar approach can be taken on the ASC. The extensive
experience from previous projects, will provide an
important no-risk aspect to the proposed ASC design.
0.2 P̲U̲R̲P̲O̲S̲E̲ ̲O̲F̲ ̲S̲Y̲S̲T̲E̲M̲
The CHRISTIAN ROVSING A/S proposed Automatic Message
and Data Switching Centre (ASC) will provide the Hellenic
Civil Aviation Authority with a modern, modular and
reliable system in accordance with the recommendation
as set out by the International Civil Aviation Organisation.
The ASC will be designed for a phased implementation
of the conventional AFTN message handling, the CBI
data link control procedures, the meteorological chart
traffic and the CIDIN switching centre capabilities.
0.3 S̲C̲O̲P̲E̲ ̲O̲F̲ ̲T̲H̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The document provides the technical description of
the Automatic message and Data Switching Centre system
and the options associated with the system.
1̲ ̲ ̲T̲Y̲P̲E̲ ̲O̲P̲ ̲C̲E̲N̲T̲R̲E̲ ̲-̲ ̲P̲U̲R̲P̲O̲S̲E̲ ̲O̲F̲ ̲P̲R̲O̲C̲U̲R̲E̲M̲E̲N̲T̲
1.1 T̲Y̲P̲E̲ ̲O̲F̲ ̲C̲E̲N̲T̲R̲E̲ ̲-̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
The ASC is a fully automatic AFTN Message switching
centre system capable of handlig message and data traffic
according to the AFTN, CBI and CIDIN functions and
procedures.
The ASC is according to requirements described as being
implemented in three phases:
Phase 1: An ASC for conventional AFTN traffic.
Phase 2: An extension of the ASC (phase 1) for
the CBI traffic.
Phase 3: An extension of the ASC (PHASES 1 and
2) for the CIDIN traffic.
The cost model reflects the phased implementation with
the implementation time - scale. The cost model can
be found in Part IV.
1.2 P̲U̲R̲P̲O̲S̲E̲ ̲O̲F̲ ̲P̲R̲O̲C̲U̲R̲E̲M̲E̲N̲T̲
The ASC will be capable of handling traffic of the
existing type and volume foreseen within a period of
10 years after the provisional acceptance of the ASC
phase 1. The traffic load is given in chapter 3.1.
The phases 2 and 3 of the ASC project will be an extension
of the phase 1 ASC as delivered by CHRISTIAN ROVSING
A/S and will cover the necessary hardware and software
as well as delivery, installation and commissioning
of the system extensions. The phases will provide HCAA
with a CIDIN centre as specified in chapter 12.
1.3 M̲O̲D̲U̲L̲A̲R̲I̲T̲Y̲
The hardware and software for all three phases will
be based on the highly modular, reliable and flexible
CR80 product line with distributed processing, optional
multilevel security, fault tolerancy and on-line serviceability
and extendability.
1.4 L̲I̲C̲E̲N̲S̲I̲N̲G̲
The interfaces to the Hellenic PTT equipment will be
licensed according to requirements.
2̲ ̲ ̲S̲P̲E̲C̲I̲A̲L̲ ̲T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲I̲C̲S̲ ̲O̲F̲ ̲T̲H̲E̲ ̲A̲S̲C̲
This section describes the special technical characteristies
of the ASC. The description are devided into two main
arreas:
- Communication protocol interfaces.
- ASC Software.
2.1 C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲ ̲B̲A̲S̲E̲D̲ ̲O̲N̲ ̲T̲H̲E̲ ̲C̲B̲I̲ ̲D̲A̲T̲A̲ ̲L̲I̲N̲K̲ ̲C̲O̲N̲T̲R̲O̲L̲ P̲R̲O̲C̲E̲D̲U̲R̲E̲/̲C̲I̲D̲I̲N̲
̲P̲R̲O̲C̲E̲D̲U̲R̲E̲
2.1.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲b̲e̲t̲w̲e̲e̲n̲ ̲t̲h̲e̲ ̲A̲t̲h̲i̲n̲a̲i̲ ̲A̲S̲C̲ ̲a̲n̲d̲ ̲o̲t̲h̲e̲r̲ ̲C̲I̲D̲I̲N̲
̲C̲e̲n̲t̲r̲e̲s̲
2.1.1.1 G̲e̲n̲e̲r̲a̲l̲
CR has as a part of previous projects implemented a
full X.25 protocol as defined by the CCITT recomandations
for X.25. The implementation of the X.25 protocol is
strongly adheres to the principles of the seven layer
ISO reference Model. The X.25 protocol implemented
is provided with extensive functions for add on additional
layers such as described for the CIDIN procedures.
The protocol layer for the CIDIN procudures will have
a layout as following:
a) L̲e̲v̲e̲l̲ ̲1̲,̲ ̲T̲h̲e̲ ̲P̲h̲y̲s̲i̲c̲a̲l̲ ̲L̲e̲v̲e̲l̲
Level 1 provides a standard electrical and physical
interface between Data Terminal Equipment and the
intermediate data communication equipment (ASC).
The Physical level Specifies operation on digital
data circuits and provides for fast digital addressing
for the establishment of circuits as well as operation
on these circuits (bit transfer). The Physical
level will be responsible for the physical and
electrical integrity of the transmission path.
b) L̲e̲v̲e̲l̲ ̲2̲,̲ ̲T̲h̲e̲ ̲L̲i̲n̲k̲ ̲L̲e̲v̲e̲l̲
The link protocol provides users with transparent
error free transmission on a synchroneous full
duplex link.
Four basic functions are provided.
- Link initialization, assuring that communication
begins in a know state.
- Error control, data link frames are checked
by means of redundancy check and sequence numbering.
Erronymous data link frames are corrected by
means of retransmission.
- Flowcontrol up to seven data link frames may
be transmitted before acknowledgement from
the receiver is required.
- Link disconnect control is provided to disconnect
the link properly.
c) L̲e̲v̲e̲l̲ ̲3̲a̲,̲ ̲T̲h̲e̲ ̲P̲a̲c̲k̲e̲t̲ ̲L̲e̲v̲e̲l̲
The packet level covers the transfer of packets
by management of logical channels. Logical channels
are maintained to allow several users to share
the same physical link and to provide access to
the packet switched network. Additional to the
package routing functions the services are:
- Flow control, each logical channel is flow
controlled individually.
Error detection by means of sequence numbering,
lost data is detected.
- Error recovery reset procedures are defined
to resynchronize the logical channel in the
data transfer phase.
- Dismantle of the logical channel by a clearing
procedure when they are no longer needed.
d) L̲e̲v̲e̲l̲ ̲3̲b̲,̲ ̲R̲o̲u̲t̲i̲n̲g̲,̲ ̲P̲r̲i̲o̲r̲i̲t̲y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The Routing, priority handling level of the CIDIN
procedures will be included as an additional level
to the X.25 protocol. It will provide functions
for e.g. adaptative routing and priority handling.
e) L̲e̲v̲e̲l̲ ̲4̲,̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲L̲a̲y̲e̲r̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The Transport layer protocol will provide a number
of application functions such as:
- Message Assembly.
- Message Reassembly.
- Message Analysis and Correction.
- Message Conversion and Routing.
- Handling of Service Messages.
CR will comply with guidance material related to the
CIDIN Procedure as specified in Annex A contained in
Part B of the Technical Specification of the Athinai
Automatic Message and Data Switching Centre. CR will
also implement modifications to this procedures as
appropiate to the system.
2.1.1.2 T̲h̲e̲ ̲F̲r̲a̲m̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Information transmitted or received via the CIDIN will
be handled in a format as defined for CIDIN messages.
The ASC will be capable of handling sectioned messages
of an unlimited length.
The ASC will provide interface modules to the CIDIN
which will perform a data conversion so HDLC frames
exchanged over the CIDIN will have a structure as shown
on figure 2.1.
The correspondence between the different elements of
the frame and the CIDIN protocol layers are additional
shown on the figures.
The system will provide frame formats with following
fields:
- Data Link Control Field (DLCF) in two parts.
- Packet Header (PH).
- CIDIN Frame Header (FH).
- Transport Header (TH).
- communication data Field (CDF) i.e. the information
to be transmitted.
The CIDIN Frame Header and the Transport Header form
the Communication Control Field (CCF).The Communication
Data Field is an optional field . The CCF and the CDF
will not exceed 25600 octets.
Each of the fields described above will be added to
the frame when it passes through the CIDIN protocol
layer and transparrent they will be analysed by the
corresponding protocol layer. There will be no bindings
between these data fields and thereby each layer can
be changed independently of each other.
2.1.1.3 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲L̲a̲y̲e̲r̲s̲
CR complies to implement the CIDIN protocol layers
which are specified in section 2.1.1.1. The implementation
Requirements will be according to the document:
AUTOMATED DATA INTERCHANGE SYSTEMS PANEL (ADISP) issue
9. If new issues are released before sign of contract
these issues will according to negotiations be included
as applicable for the implementation Requirements baseline.
Figure 2.1
CIDIN Frame Structure
2.2 A̲S̲C̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
2.2.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
2.2.1.1 G̲e̲n̲e̲r̲a̲l̲
2.2.1.1.1 The implementation of the ASC hardware and software
is based on the most efficient communication processor.
The architecture of the hardware provides a high
degree of flexibility based on the modular design
of the included units. The software architecture
provides capabilities for add-on and changes of
specific software processes (Modules), without
changes in other modules. Only central communication
modules will be affected, to specify the new software
configuration.
2.2.1.1.2 Each processing unit will get allocated specific
tasks to perform and will have associated peripherals
to control.
2.2.1.1.3 The software contained in the CR80 PU is written
in a high-level programing language. The X-AMOS
operating system provides though the processand
memory management, functions for relocable program,
which means that programs can be executed independent
of where in the physical memory it is allocated
and there by hardware independent code will not
exists.
The ASC software is built as a hierarchy of modules
each performing its own special task. Thereby any layers
can be added without changing code and layers can be
modified without affecting other layers.
The ASC software is to a high degree table driven both
in concern with execution of programs and in analysis
of frames.
2.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The functions performed by the ASC software is divided
into two main areas
- operating system software
- functional application software
The functional application software is divided in the
following areas:
- line control
- message processing
- traffic management
- network management
- network recovery.
2.2.1.2.1 L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲L̲C̲)̲
The Line Control module is the interface module between
the external Link Channels and the message switching
centre. It provides function for receiving and transmitting
message according to the protocol used on each link
and then queue the message for the message processing
module. The line control module will be provided with
function for handling:
- CIDIN Messages
- CBI Data Link Control Messages
- Telegraph Channel Messages.
The message processing module will based on the message
address, queue the message to the actual line control
module which then will perform the actual transmissions.
The LC has two main interfaces: The LTUs on one side
and the line input queues and line output queues on
the other side. Furthermore, LC communicates with the
system error routine and with the buffer allocation
routine.
a) L̲C̲ ̲P̲o̲l̲l̲ ̲a̲n̲d̲ ̲S̲e̲l̲e̲c̲t̲ ̲S̲t̲r̲a̲t̲e̲g̲y̲
The LC controls input and output between the external
lines and the switching centre 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 LC, 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 mescellaneous error conditions which might
have occurred on the line, e.g. framing error,
parity error, etc. Error status information is
reported to the Error and Switchover Process, refer
section 2.2.1.3.1.2.3.
The LC 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 ASC.
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:
2.2.1.2.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 switching centre is capable of recognize start
of transmission functions (beginning of messages) and
end of transmission functions (ending of messages).
The start and end transmission function may deviate
as described in section 3.3.9. If a message exides
the max. number of characters per message the system
is provided with functions for sectioning the message
into blocks. As part of the system integrity, procedures
as CRC parity check is performed on all messages transferred
in the system. Extensive capabilities is provided within
the system for routing and distribution capabilities.
It is capable of distributing messages to all terminals
within the network based on addressees within the message
and distribution tables entered into the system by
the traffic management personnel.
Routing of messages to subscribers of external networks
with CIDIN interfaces is performed by the system based
on recognized area addresses within a message.
If the system receives a message with a missing end
of transmission function it will then automatically
add a valid end of transmission function. Additionally
the message will be marked to indicate that no end
of message sequence was identified, The switching centre
contains tables of codes and formats used by all terminals
in the network. The system will enter the appropriate
indicator in the CCF of a message incoming from a specific
terminal. Code and format conversions will be provided
by the system.
The switching centre contains a Storage and Retrieval
module which automatically will store all incoming
and outgoing messages on a temporary storage system.
The messages will be stored on basis of a number of
defined retrieval key such as e.g. addressee. The messages
can be retrieved by these retrieval key and afterwards
directed for retransmission as an normal message directed
for transmission.
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̲)̲
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.
IP receives inbound messages from the Line Control
(LC), 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
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.
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.
R̲o̲u̲t̲i̲n̲g̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲R̲Q̲)̲
The routing algorithm of the ASC relays each message
on the optimum channel or channels; the decision is
based on an adaptive routing plan. To determine the
ASC 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.
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 Addressees has to be relayed, i.e. for which the
ASC has positive responsibility.
The ASC has an active Routing Directory (RD) in computer
memory. The RD consists of an Circuit Responsibility
Table (CRT) 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 ASC, 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 ASC. 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.
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 Control (LC).
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.
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.
2.2.1.2.4 N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The Network Management functions include following
- Configuration Control
- Line Control
- Journaling (Logging) and Traffic Statistics.
Through the Network Management functions the supervisory
personnel will be able to control and operate the system
and will be able to request Log and statistical information
concerning the operational aspects and the maintenance
aspects.
2.2.1.2.4.1 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The supervisor terminals will through a friendly man-machine
interface provide the operators to maintain configuration
tables specifying the status of each Channel/terminal
connected such as "In Service, Out of Service" etc..
Following information will be available in the configuration
tables.
a) - Line Assignment (connected-disconnected)
b) - Sequence number on assigned line (if a multi
point line)
c) - Call sign for alternative terminal if this terminal
is not operating
d) - Code and format indicator for the terminal
e) - Restrictions (if any) on type of traffic to be
sent to the terminal
f) - Dial code (if any) through which the terminal
can be reached by telex.
The configuration tables can be updated in two ways
either automatically by the system if e.g. a terminal
is disconnected due to error detection or by manual
intervention if the supervisory personnel whishes to
change the configuration. If a call-sign can not be
identified within the message it will automatically
be forwarded to the supervisor which then can perform
a manual distribution of the message to the appropriate
terminals.
Two versions of the configuration tables will be maintained
by the system. An initial version which will be generated
during system generation and a backup version will
be the current version.
During start-up the supervisory personnel will be provided
with function to specify whether the initial version
or the backup version shall be used by the system.
2.2.1.2.4.2 L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The operating system and the protocol layer SW contains
a number of counters by which measuring of the performance
at the lines and the circuits to external network can
be recorded. The transport layer will on the Low Speed
lines be able to detect an open line condition, noise
on the line and other symptoms of malfunctions.
If the system detects a garbled message such as unrecognisable
addresses or garbled responses on test messages or
no response at all, then the centre will update its
circuit status table and forward the message together
with an alarm to the supervisory personnel.
2.2.1.2.4.3 J̲o̲u̲r̲n̲a̲l̲i̲n̲g̲ ̲a̲n̲d̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
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.
2.2.1.2.4.4 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 ASC application program package
includes an interactive Command Interpreter submodule
(CI) which will act as an interface between the System
Supervisor and the ASC.
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.
In particular, the below listed functions have relation
to the supervisory intervention in the ASC. These functions
are further described in the following:
- Overall system supervision
- System initialization
- Message retrieval and display
- Reject message editing
- Service message generation
- Initiation of re-routing/diversion
- System time control
- Off-line diagnostic software execution
- Reject Message Editor
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 ASC 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 ASC 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) 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.
d) 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 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
e) 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.
f) 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 3.9). Statistical reports will
by default be directed to the hardcopy backup printer,
but may if desired be displayed on the terminal.
g) 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 ASC may be changed/updated
by the System Supervisor. This might for example
be desired upon schedule service on the communication
lines or ASC line interface equipment.
The RD change entry function will provide comprehensive
error checking on the entry data.
h) 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 ASC 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 ASC system
will alert the System Supervisor. Facilities are
included which enable the Supervisor to initiate
re-routing/diversion routing.
i) 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.
j) 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. (Refer section 2.2.1.3.2).
k) R̲e̲j̲e̲c̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲o̲r̲
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.
2.2.1.2.5 N̲e̲t̲w̲o̲r̲k̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Flexible variation in the size and structure of the
CR80 system used for the switching centre 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 exploitetd by the XAMOS software operating sytem
and programs to survive operational failure of individual
components.
Reliability, which is increasingly becoming of concern
in real-time and distributed network applications,
is achieved in the CR80 computer systems by applying
unique architectural concepts. The CR80 hardware/software
architecture treats all multiprocessors as equal elements
not absolutely dedicated to a specific role. Fault
tolerance and backup are achieved through a redundance
scheme without preassignment of system functions to
specific processors. This is in marked contrast to
the more common rigid dualized configurations often
encountered in dedicated applications with on-line
master/slave arrangements, or off-line backup with
switchover facility.
All redundance equipment is under control of a watchdog
micro-computer, which constantly receives information
on all subsystems status. This strategy ensures that
all units are ready to operate if any reconfiguration
is needed.
2.2.1.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The XAMOS operating system is particularly suited for
use in real time systems and the main objectives fulfilled
are high efficiency and flexibility. The processing
power is provided in two areas of the system. In the
central processor unit is allocated the software modules
which performs the traffic management, network management
and the network procedures. In the Channel Unit is
allocated the software modules which performs the line
control and message processing functions.
2.2.1.3.1 O̲n̲-̲l̲i̲n̲e̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The software provides for the swithcing centre is divided
into three areas:
Line Control Software
Network Application Handling Software
Operating System Software.
These three software subsystems will together form
the total switching centre and provide the function
as described in this offer.
2.2.1.3.1.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The communication functions are composed by the two
subsystems, line control software and Network application
handling software. The functions provided by these
two subsystems will provide the switching centre with
the capability to interface with other Network swithcing
centres and terminals.
The main functions provided by the system are:
a) Link Control (line control). This function handles
the external communication lines and performs the
protocol handling as required on the various links.
b) Message processing. This function performs the message
assembly and disassembly. Additional it provided
temporary storage of messages.
c) Message Routing. This function performs the complete
routing of messages based upon call-signs, address
code and addressing tables.
d) Message Queing. The system will maintain a number
of system queues. Queues are allocated to each Channel
and to the supervisory terminal. The queue can be
defined as priority queues.
e) Switching. The actual message swithcing function
will be performed by the Network application handling
software. The switching decisions will be based
on Routing tables which can be maintained by the
supervisory personnel.
f) Overflow handling. The overflow handling functions
will be performed by the message queueing functions
at the Message Management System and the Memory
Management System, which are part of the operating
system. The Message Management is dedicated to control
message flow in such a way that no overflow can
cause damage on any date processed.
g) Start-up shutdown. Start up and shup down functions
will be performed by a special SW module named Error
and Switchover Process. This module will constantly
control the system and if any error occurs it will
perform and switchover. The Error and Switchover
Process module will contain functions to start up
the system and to initialize all communication lines,
devices, counters etc. and initiate communication.
In the same manner the Error and Switchover Process
module provides functions for performing an ordered
close down which will allow all traffic in transit
to be processed as normal but refuse all incoming
new traffic the close down can be initiated by the
supervisory personnel.
h) Recovery. The recovery functions will be performed
by the Queue and Message Management functions together
with the Error and Switchover Process. These three
will constantly maintain a Checkpoint Log and will
provide the system with functions for recovery.
i) Message Retrieval. The Storage and Retrieval module
will maintain a Log file for all temporary stored
messages based on this Log file the supervisor personnel
will be able to retrieve message for retransmission.
If parts of messages are requested retransmitted
right after the original transmission the system
will perform the retransmission automatically.
j) Journaling. As part of each transaction on a message
a journaling file will be updated by a central logging
module. This logging file can be inspected by the
supervisory personnel.
k) Message Accountability. The message accountability
is performed by the Message Management system and
the logging module in conjunction. These two modules
together will ensure full message accountability
within the system.
l) System Supervision. The systm supervision will mainly
be performed by the Queing and Message Management
functions together with the Error and Switchover
Process modules. Through a supervisor interface
module the supervisory personnel will be capable
of tracing the monitoring performance by the modules
specified above.
m) Malfunction detection, please refer Recovery, Message
Accountability and System Supervision.
2.2.1.3.1.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
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.
2.2.1.3.1.2.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 ASC 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 ASC 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.
2.2.1.3.1.2.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/Message 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/message 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.
2.2.1.3.1.2.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 2.2.1.2.2.1. Processes in
ASC may execute the same program reentrantly, but may
not share the same process data space.
2.2.1.3.1.2.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 2.2.1.3.1.2.2.2-1 and 2.2.1.3.1.2.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 2.2.1.3.1.2.2.1-1…01…Overview Of Process Concept
Figure 2.2.1.3.1.2.2.2-1
MTCB Use, Real MTCB
Figure 2.2.1.3.1.2.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 2.2.1.3.1.2.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.
2.2.1.3.1.2.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 2.2.1.3.1.2.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 2.2.1.3.1.2.2.2-3…01…Use Of MTCB Monitor
Figure 2.2.1.3.1.2.2.3-1
General Queue Structure
2.2.1.3.1.2.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 2.2.1.3.1.2.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 2.2.1.3.1.2.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.
2.2.1.3.1.2.3 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 ASC 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 ASC, 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 ASC 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.
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 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.
2.2.1.3.1.2.4 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
On-Line Diagnostic programs will execute periodically
as part of the exchange surveillance system. On-line
diagnostics consist of a mixture of hardware module
built-in test and reporting, and diagnostic software
routines. The following on-line diagnostic capability
exists:
- CPU-CACHE diagnostic
- TRACE diagnostic
- RAM test
- PROM test
- MAP/MIA test
- Disk Controller/DCA test
- LTU/LIA test.
On-line diagnostics will report errors to the Error
and Switchover Process to take recovery/swithchover
decision in the case of failures.
2.2.1.3.2 N̲o̲n̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
H̲i̲g̲h̲l̲e̲v̲e̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲H̲I̲O̲S̲)̲
HIOS is an operating system, which provides the on-line
user interface for interactive and batch processing
on the CR80 computer.
The functions performed by HIOS are the following:
- define system volume and directory
- define system device(s)
- assign/deassign terminal device(s)
- create/delete terminal subdevices
- assign/deassign of disk
- reserve/release of disk
- mount/dismount of volume
- update bitmap and basic file directory
- display name of user directory
- change user directory
- listing of current status of system
- redefine current status of system
- redefine current input/output
- reopen original outputfile
- maintain a user catalog
- redefine filesystem dependant I/O resources
- control online log facility
- broadcast messages between terminals
- maintain a hotnews facility
- maintain a number of batch queues
- define spool files for later output
- login/logout of terminals
- load of program
- execute task
- stop and start task
- remove task
- display current date and time
- submit batch task.
HIOS is activated by the Error and Switchover Process
if specified when the sytem is bootloaded. After a
short initialization phase the production phase can
be entered.
In the production phase, two kinds of users can log
in on the sytem:
- privileged users
- non privileged users.
The privilege of the user is checked at login-time
by means of the user catalog, and the privilege determines
which functions the user can execute.
S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The utility SYSGEN-EDIT generates object files - based
upon a set of directives, a system source, and command
files - for subsequent compiling and linking. A BINDER
then binds the system object together with the application
object based upon a command file from SYSGEN-EDIT.
All the external references of the object modules are
resolved in the Binder output, which is a load module
ready for execution load modules compiled different
languages can be executed. The BINDER produces a listing
giving memory layout, module size, etc.
The following languages are presently available:
- Pascal
- SWELL, the CR80 System Programming Language
- Assembler.
D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The Maintenance and Diagnostic (M&D) package is a collection
of standard test programs which is used to verify proper
operation of the CR80 system and to detect and isolate
faults to replaceable modules.
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.
S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
In cases where the functionality is changed in a software
module this module can before inclusion in the operational
system be tested by means of a number of test programs.
A Test Command Interpreter is part of the offline programs.
Through this program the interface capability can be
verified. If error is identified a trace and memory
dump program exist by which the operator can analyse
the data of the faulty module. The Trace and Dump program
might as well be used on the operational program.
2.2.1.4 M̲o̲d̲u̲l̲a̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The hardware and software proposed for the switching
centre is based on the flexible and modular CR80 computer
and the XAMOS operating system. The system can be configurated
to encompass a broad range of characteristics to meet
the requirements of both the smaller stand alone user
and those of the largest multi-
installation network applications.
Flexible variation in the size and structure of the
CR80 systems are permitted by the unusual degree of
hardwar and software modularity. The hardware essentially
consists of fast transfer vuses joined to eachother
by adaptors which allow units on 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.
Regarding data communication expansion for the swithcing
centre CR can provide various, almost off the shelf
solutions we have implemented standard commercial and
military communication protocols of the CR80 computer.
2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
For program development and testing tools please refer
section 2.2.1.3.2.
The process concept (refer section 2.2.1.3.2.2.1) is
the fundamental concept in CR80 terminology. The process
is an execution of a program module in a given memory
area. The process is identified to the remaining software
by a unique name. Thus of the processes need not to
be aware of the actual location of a process in memory
but must refer to it by name. Through this concept
the system provides a comprehensive flexibility as
processed can be substituted by new version without
changed if the other parts of the software system.
Each process is constructed by a number of program
procedures. This is performed by a Link command, thereby
each procedure can be changed independently of others.
Only if interface conventions are changed between processes
or procedures other proceses or procedures might need
changes.
The allocation of processes onto processor units or
channel unit are performed during the system generation
phase. In the same manner the Addressing tables will
be specified during system generation.
2.2.3 C̲h̲a̲n̲g̲e̲ ̲o̲f̲ ̲C̲I̲D̲I̲N̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
The system parameters used by the ASC SW is separated
into two groups:
- System parameter specified during system generation
- System parameter specified by supervisory personnel
during operation.
The system parameters specified during system generation
are parameters as described in section 2.2.2 such as
task allocation (Process allocation) maximum number
of circuits to maintain etc.
The system parameters specified by the supervisory
personnel during operation are parameters such as changing
the duration of "time out" affecting the communication
between Entry and Exit CIDIN centres, changing the
current number of logical channels or circuit (as long
as it is below the max. specified during system generation),
changing size of the window of each locical channel,
changing the number of messages allowed to stay in
a queue etc.
The man-machine interface procedures which the supervisory
personnel shall perform to change these procedures
are as following:
The supervisor personnel will by a function key request
a system control menu. In this menu he will then select
a system function such as e.g. Queue control, channel
control etc. The system will then react by displaying
a formatted screen picture with a number of fields
to each field will be associated a text string specifying
the meaning of the field.
In the field the current contents of the entry will
be displayed and the supervisory personnel will then
have the capability to change the parameter in the
field and enter it into the system.
3̲ ̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲A̲N̲D̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
3.1 T̲R̲A̲F̲F̲I̲C̲ ̲V̲O̲L̲U̲M̲E̲
The presently handled traffic of 20.000 messages per
day is taken as the baseline for the traffic volume
calculations with the specifications as to size and
growth as in the technical specification document.
The future traffic volume is based on the annual growth
of 5%, a required period of at least 10 years and an
additional one year from today and until provisional
acceptance, e.g. the traffice volume for another 11
years. The traffic volume is defined in table 3.1-1.
Even taking into account that the baseline is a current
maximum the load of 213/365 characters per peak second
poses no load on the system since the character oriented
part of the processing and part of the message/
packet oriented processing are done locally, e.g. in
the line terminator units.
Messages Characters Characters
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲F̲u̲t̲u̲r̲e̲)̲
̲ ̲ ̲ ̲
Day 20,000 7,680,000 13,133,000
Peak hour 2,000 768,000 1,313,300
Peak second 0,5 213 365
30 Days 600,000 230 M 394 M
30 Days
(Future) 1,026,000
…06…1 …02… …02… …02… …02…
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
* Peak second = 1/3600 of Peak hour.
Figure 3.1-1
Present and Future Traffic Volume
The CPUs will take care of the scheduling of messages
based on the message priorities as described in the
chapters 2 and 3.4.
The impact of the traffic volume on the storage media
(described in part III, chapter 3) is shown in Figure
3.1-2. The system contains a short term storage for
one hour on the FSD system which also contains all
software and tables. The RSD proposed instead of a
tapedrive holds the long term storage of 30 days with
a periodic change of cartridge every 6 to 10 days,
depending on the traffic growth, the overhead on the
messages, and the influence of the MET chart traffic
and the CIDIN traffic.
The MET chart volume is shown in Figure 3.1-3, the
impact on the disc storage is difficult to estimate,
since the retention period for the MET charts is not
known. But the current charts should pose no storage
problems.
Disc Drive Type FSD RSD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Capacity per unit 160 Mbyte 80 Mbyte
Days storage (current load) 20.8 10.4
Days storage (future load) 12 6
…06…1 …02… …02… …02… …02…
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 3.1-2
Impact of the Traffic Volume on the Storage Media
Met-charts Charts Bytes Bytes
Future
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Day 100 50 Mbyte 86 Mbyte
Peak-Hour* 10 5 Mbyte 8,6 Mbyte
Peak-Second* 1390 bytes 2390 bytes
Average-Hour** 2,08 Mbyte 3,6 Mbyte
Average-Second** 580 bytes 990 bytes
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
* 10% in Peak Hour
** Even distribution
Figure 3.1-3
Met Chart Volume
The influence of the CIDIN traffic on the system will
not cause any problems as the calculations show. Depending
on the change in growth from the conventional traffic
the period for changing disc cartridges would be longer
or shorter.
The diversion traffic, to the degree it is not already
covered by the traffic volume figures above, would
be treated as a traffic increase and is taken care
of.
The main memory occupancy of the ASC is difficult to
determine due to the distributed processing in the
multiple CPUs and in the LTUs with their own buffer
memory. The ASC configuration is based on the Christian
Rovsing A/S message swithches already delivered as
well as planned for delivery.
3.2 C̲I̲R̲C̲U̲I̲T̲S̲
The circuit requirements for the ASC as detailed in
the corresponding paragraph of the Part III, Technical
Specifications, is addressed in Part II, chapter 12
as to initial volume and required and feasible additional
volume. The interface specifications can be found in
the system description in Part III, chapter 3.
3.3 C̲A̲T̲E̲G̲O̲R̲I̲E̲S̲ ̲A̲N̲D̲ ̲F̲O̲R̲M̲A̲T̲S̲ ̲O̲F̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲
3.3.1 The message handling functions provided by CR for the
ASC will contain procedurs for handling all categories
of messages used in the Aeronautical Fixed Telecomunication
Network (AFTN).
3.3.2 The message processing function within the ASC will
be capable to handle message of the ITA 2 and messages
of the 7 unit coded character set form as described
in section 2.2.1.2.2 of this offer.
3.3.3 Through the flexible and modular architecture of the
ASC software such as the process concept it will be
very easy to change or add new functions to the system
such as format changes or addition of new formats.
Inclusion of new processes will only cause changes
in the application software interface modules and afterwards
inclusion of the new process in the system generation
tables.
3.3.4 Please refer section 2.2.1.2.2 in which the ITA 2,
ITA 5 conversion is described.
3.3.5 The message analysis functions within the switching
centre will be capable of recognizing Addressee Indicators
composed of a different number of letters from 4 opto
9. All Addressee indicators will not need to have same
length.
3.3.6 The ASC software will be prepared for multiple Addressee
Indicator Lines in the lines next to the Heading line
in such a way that analysis of these lines can very
easy be included in the appropriate program.
3.3.7 As part of the channel configuration table will be
a field which will specify if the appropriate channel
sequence number shall be three or four digits. This
field can online be updated by the supervisory personnel.
3.3.8 The ASC software which is analysing the origin line
will be capable of handling optional data upto a total
of 69 characters within the line.
3.3.9 Following deviations from the ICAO Message format will
be accepted by the system without imparing message
integrity:
3.3.9.1 Deviations in Heading:
a) Existence of the maximum possible number of spurious
characters between the End of Message signal (NNNN)
of a message and the Start of Message signal (ZCZC)
of the next message.
b) Loss of one of the characters of the Start of Message
signal.
c) Proper interpretation of ZCZC in either shift.
d) Appearance of ZCZC of a place in the Heading different
from that of ICAO Message Format.
e) Recognition of two successive V's as a Diversion
Indicator.
f) Accept a spacing signal consisting of a different
number of spaces from that provided in ICAO Format
.
3.3.9.2 Deviations in Address
a) If the case described in section 3.3.9.1a is applied
the system will accept the appearance of the priority
indicator within the maximum number of characters
from the beginning of a message.
b) If the system identifies at least one of the seven
characters used for composition of a priority indicator
as a valid priority indicator then the system will
process the message according to this priority
indicator.
c) If two characters are identified by the system
as valid priority indicators then the system will
process the message according to the highest priority
indicator.
d) The ASC software will accept more than one space
between the Addressee Indicators contained in the
line next to the heading line.
3.3.9.3 T̲e̲x̲t̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲
3.3.9.3.1 The ASC will interpret the cancellation pattern
(as described in AERONAUTICAL TELECOMMUNICATIONS
ANNEX 10 VOLUME II section 4.4.1.5.2) whenever
it appears in the text ahead of the ending and
take action as approach.
3.3.9.3.2 In case the End of Message signal in ITA 2 code
messages or the End-of text character in 7 unit
coded character set messages is mutilated the ASC
will automatically apply the procedures regarding
the insertion of Forced ending.
3.3.9.3.3 If a message is received from external networks
with line of a length above 69 characters then
the system will automatically separate the received
lines into lines of less than 70 characters. The
alignment function will be two carriage returns
and one line feed.
3.3.9.3.4 If a halted message is received (more than 70 successive
identical characters) over a channel then the ASC
software will interupt the channel and forward
a report to the supervisory personnel specifying
the channel identifications together with the text
saying STUCK TAPE.
3.3.9.4 Ending of Message.
3.3.9.4.1 The ASC will interpret as normal page-feed sequence
a number of more than seven line feeds (max. 20)
between the end-of text signal and the end of message
signal.
3.3.9.4.2 Other deviations from the ICAO Message Format such
as too long messages, duplication of start of message,
signal, absence of priority indicator etc. will
cause the ASC software Automatically to generate
a SVC message and transmit it via the exit channel.
3.3.10 Material Permitted in Messages
The ASC software will be capable of handling all characters
and signal in the ITA 2 as well as ITA 5 (7-unit coded
character set).
3.3.11 Please refer section 3.3.1 for definition message categories.
3.4 M̲E̲S̲S̲A̲G̲E̲ ̲R̲O̲U̲T̲I̲N̲G̲
3.4.1 The ASC software will perform routing automatically
based on a set of routing tables. These routing tables
will be maintained by a central Table Management module.
The supervisory personnel will be provided with capabilities
for online update of these tables (refer section 2.2.1.2.4).
The routing tables will per routing indicator have
entries for such as: Priority Indicator, Addressee
Indicator and Diversion Indicator.
3.4.2 Under normal operation the system will secure that
messages are not interrupted during transmission. If
an error condition occurs on a channel, the ASC software
will cancel the message being transmitted at that time.
During retransmission a message will be assigned a
new Transmission serial number.
3.4.3 For each incoming circuit the ASC software will maintain
a separate Incoming Circuit Responsibility List. Amendments
and/or replacements of these lists may upon decision
either be updated during system generation or online
by the supervisory personnel.
3.4.4 The system will secure that no messages are returned
via the circuit on which it was received. The system
will be able to take over responsibility of all addressee
indicators in the line following the Heading.
3.4.5 The system will automatically add the appropriate shortened
address on a message which shall be transmitted on
an appropriate circuit. In cases with multiple transmissions
of the same message the system inserts the appropriate
shortened address required for each circuit transmission.
The system will avoid double delivery of messages.
3.4.6 If a message is requested retransmitted by the switching
centre, the system will be capable of transmitting
the message to this appropriate circuit with the appropriate
shortened Address. If the message original has been
multiple transmitted the system will only perform retransmission
on the circuit which had requested the retransmission.
3.4.7 All messages which are transmitted by the switching
centre will be associated with a header and ending
line inserted by the system according to the ICAO FORMAT.
3.4.8 For message with a priority indicator of type SS of
copy will be forwarded to the supervisory personnel.
The arrival of such a message will cause a visual and
audiable alarm signal.
3.4.9 If the switching centre receives a message with priority
indicator SS the system will automatically transmit
a SVC acknowledge message on the circuit on which the
SS priority message was received.
3.4.10 If the switching centre in an incoming message identifies
a Diversion Indicator (VVV), the system will then automatically
take over the responsibility for all the Addressee
indicators contained in th line following the heading.
The system will thereby neglect the normal circuit
responsibility list and route the message on basis
of the Addressee indicators and Address tables.
3.4.11 If a circuit has failed the system will automatically
route the message via the alternative circuit identified
in the Address table and insert the appropriate Diversion
Indicator and/or the appropriate shortened Address.
3.4.12 Messages will by the system be processed and transmitted
or retransmitted in the order of their priority.
3.4.13 The system will be provided with function and priority
Queues to handle AFTN messages with following priorities:
SS GG
DD JJ and KK
FF LL
Implementation of additional priority categories can
be easily performed in the system as the priority handling
will be basis on table driven programs and data.
3.4.14 Messages with same priority will be the handled on
FIFO basis (First In First Out).
3.4.15 If the switching centre receives a misrouted message
it will automatically relay the message to the normal
destinations if the shortened Addresses in the message
are known by the system. Additional the switching centre
will return a SVC message to the station from which
the misrouted message was sent and finally the supervisory
personnel will be notified that a misrouted message
has been received.
3.4.16 If the ASC receives an SVC message specifying that
a message has been misrouted the ASC will automatically
retransmit the message as necessary on the correct
outgoing channel.
3.4.17 In cases where no predetermined routing responsibility
list is associated to a circuit the supervisory personnel
will be provided with following functions to process
a message.
3.4.17.1 The supervisory personnel will be capable of redirect
all messages normally routed through one circuit to
an alternative circuit.
3.4.17.2 The supervisory personnel will be capable of temporary
to store all traffic of any circuit. All circuit in
the system will through a Message Management module
have direct access to the temporary storage for total
storage capacity. Please refer section 3.1.
3.4.17.3 The redirect and store capabilities described in section
3.4.1.7.1 and 3.4.1.7.2 will by the system be provided
on priority level so that the supervisory personnel
can specify which priorities on a circuit that shall
be stored or which that shall be redirected, and which
that shall be normally transmitted.
3.4.18 If the switching centre identifies that a circuit has
failed it will through the routing indicator table
identify the Diversion Indicator and then transmit
an SVC message via the alternative circuit to the station
and specifying the transmission serial number of the
last message received on the interrupted channel.
3.4.19 The message processing software within the switching
centre will be capable of handling Group Routing procedures
on basis of a supervisory specified collective address
list in the table management module. The message processing
software will provide function for analysis of these
Group Routing indicators and by the collective Addres
list insert the appropriate shortenend Addressees in
the messages before transmission.
If all Address Indicators cannot be accommodated in
a single line the ASC will generate new copies of the
message with the remaining Address indicators.
3.4.20 The ASC will be capable of applying stripped address
procedures i.e. to omit from the Address those addressee
indicators not required for onward transmission by
another AFTN station.
3.4.21 If the supervisory in the Addressee indicator table
specifies that a copy of all messages to that Addressee
shall be printed on a local printer then the system
will automatically distribute a copy of messages addressed
to the selected Addressee besides normal routing of
this traffic.
3.4.22 Through the circuit control table the supervisory personnel
will have the capability to specify that messages transmitted
via this circuit shall have added the Message Separation
Signal and the Tape Feed sequence required to tear
off the Tape.
3.4.23 Through the procedure described in section 3.4.22 the
supervisory personnel will also be able to specify
that the appropriate starting pulse, before message
transmission is commenced.
3.4.24 The switching centre will transmit Multi Address message
independently of each other and not waiting for all
involved circuits to be free at the same moment.
3.4.25 The system will provide functions for preemption of
message if a SS priority message is to be transmitted
via a circuit.
The message preempted will be followed by cancellation
pattern before the SS priority message is transmitted.
When the preempted message is retransmitted it will
get assigned a new transmission serial number.
3.5 T̲E̲L̲E̲X̲ ̲S̲E̲R̲V̲I̲C̲E̲
3.5.1 The ASC will also provide direct access to the HCAA
TELEX network and provide tasks as described in the
following.
3.5.2 Based on conversion table maintained by the Table Management
module and updated by the supervisory personnel, the
switching centre will provide function for conversion
of Addressee Indicators into telex calling numbers
and vice versa. The switching centre will automatically
perform the necessary dialling and relay of messages.
3.5.2.1 When the system has established a connection with a
telex subscriber then the system will transmit any
number of messages queued for that subscriber as an
uninterrupted serie.
3.5.3 The switching centre will provide function for measuring
the time each subscriber uses the telex lines and the
system will produce a monthly account separate for
each telex subscriber on basis of the rates in force.
The rates in force can be updated by the supervisory
personnel as a command to the system. The monthly account
can be requested by the supervisory personnel. The
system will then print the account on the associated
printer.
3.6 O̲P̲T̲I̲O̲N̲A̲L̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
3.6.1 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲m̲p̲o̲s̲i̲n̲g̲ ̲F̲a̲c̲i̲l̲i̲t̲y̲
Christian Rovsing A/S has produced several message
generating systens with complex message formats used
as in the CAMPS and FIKS systems. Likewise the Christian
Rovsing A/S VDUs can be delivered with word processing
and electronic mail facilities as standard. It is therefore
possible to provide a wide range of facilities for
the message composition, message generation and message
format conversions. It is therefore not possible to
provide a firm, fixed price without a detailed set
of requirements.
3.6.2 M̲u̲l̲t̲i̲c̲o̲p̲y̲ ̲F̲a̲c̲i̲l̲i̲t̲y̲
Several possibilities exist for generating multiple
copies of individual messages. A marginal cost facility
is achieved through a software multicopy facility generating
multiple copies of the message on the high speed line
printer. A high quality, high speed multicopy facility
can be achieved by attaching a laser printer to the
system such as the Rank Xerox 2700 or Rank Xerox 8700.
This laser printing system is planned for a very demanding
message processing system.
3.7 M̲E̲S̲S̲A̲G̲E̲ ̲P̲R̲O̲T̲E̲C̲T̲I̲O̲N̲
3.7.1 For each communication line a variable will be defined
in order to keep track on the sequence. Of the Transmission
Serial Number (TSN) stored in the Heading line of incoming
messages: Expected Incoming TSN.
The Expected-Incoming TSN will specify the expected
TSN stored in the Heading line of the next incoming
message. Each time a message is received, the TSN stored
in the Heading line is automatically compared to the
Expected Incoming TSN. This results in updating of
the Expected Incoming TSN if the received TSN was equal
to Expected TSN.
3.7.2 When a message with a wrong TSN is received the switching
centre will forward the received message to its destination
and transmit an SVC message to the station from which
the message was received. The SVC message will contain
the received TSN and the expected TSN.
3.7.3 If the TSN is missing in a received message the switching
centre will forward the received message to its destination
(If the rest of the message format is correct) and
transmit an SVC message to the station from which the
message was received. The SVC message will contain
the expected TSN and a notification saying that the
TSN was missing.
3.7.4 To protect the switching centre against overload, the
system will contain a Message Management system. This
system will maintain a complete description on where
and who is processing a message on a given time and
a program will only be able to access the next message
when it has released the previous one. The message
management system will have the full control and access
rights to the whole disk capacity provided for the
system. In the same manner the Queue Management system
will be controlling all queue operations and only allow
application programs to access the next message Queue
element in the queue when the application program has
released the previous message queue element. The free
message queue elements will be kept in a common pool
and thereby there will be no fixed length on each queue.
3.7.5 To ensure continuity checking of the low speed channels
the system will automatically transmit a selfaddressed
channel check messages at H+00, H+20, H+40.
3.7.6 The procedure described in section 3.7.5 will only
be used on channels which do not have implemented the
channel continuity message. On the channels which have
implemented channel continuity messages the switching
centre will perform the procedures as desribed for
these.
3.7.7 Through a command to the system the supervisory personnel
will be provided with the function to suppress the
channel check transmission on any channel it may be
required.
3.7.8 If an Automatic or manual switchover between the Active
and the standby PU is performed the system will secure
that the integrity of all messages are kept so that
no messages are lost.
3.7.9 At the end of the day (2400 Hours GMT) the ASC will
automatically send an SVC channel number reset message
on all open channels. The channel number reset message
will contain the TSN of the last message receive via
the channel. A copy of each SVC message will additional
be forwarded to the supervisory personnel.
3.7.10 In addition to the procedure described in section 3.7.9
the system will reset all local channel serial numbers
for all incoming and outgoing channels. The new series
will start daily at 0000 hours.
3.7.11 If the system do not receive a channel check or message
of the types described in section 3.7.6 during the
periods H+18-22, H+38-42 and H+58-02 on an open channel,
then the ASC will send an SVC message with a report
specifying the check is missing.
3.7.12 As part of the message processing procedures the system
will on a page printer present the Transmission Identifier
of each incoming and associated with the Transmission
Identifiers on all the channels where it is transmitted.
3.7.13 The supervisory personnel will be provided with function
for manual initiation of transmitting channel check
messages.
3.7.14 Please refer section 3.7.3.
3.7.15 If the switching centre receives an SVC message which
requests retransmission of messages with specific channel
serial numbers then the switching centre will retransmit
the messages specified if they originally had been
transmitted less than one hour ago (refer section 3.8.2.1).
The retransmitted messages will contain a new transmission
serial number.
3.7.16 The tolerance on signals for outgoing and incoming
lines are according to CCITT recommendations V28.
3.7.17 The ASC will through a control loop function test the
availability of the local teleprinters in order to
guarantee that the printing has been done without loss
of data. The control loop facility will be set up according
to the specifications as described in the specification
of the Athenai Automatic Message and data switching
centre part B section 3.7.17.a, b, c.
If the teleprinter is recognized as unavailable the
ASC will react as follows:
- The system will immediately disconnect the channel
associated to the printer
- The supervisory personnel will be notified that
the teleprinter has failed and that the associated
channel has been dismantled
- The message which was sent to the printer will
be transmitted to a stand-by printer if it exists
and is available. The routing will be performed
on basis of the Diversion Indicator in the Routing
Indicator table
- If there is no stand-by printer or if it is not
available, the ASC will queue all messages for
this channel until one printer becomes available
- Overload of the channel queue will by the central
queue management module be indicated to supervisory
personnel. The supervisory personnel will the have
the capability to redirect the messages
- As soon as a printer by the system has been recognized
as unserviceable, the system will send periodically
a test message that the printer in order to detect
when the printer becomes again available
- As soon as the printer is again available, the
ASC will automatically reconnect the corresponding
channel and send a message to the supervisory personnel.
3.8 T̲R̲A̲F̲F̲I̲C̲ ̲R̲E̲C̲O̲R̲D̲S̲
3.8.1 L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲R̲e̲c̲o̲r̲d̲s̲
3.8.1.1 All messages originated in Greece will be retained
by the ASC, in the entirety for at least thirty days.
The online retrieval time will be approximately 10
seconds.
3.8.1.2 For all messages destinated for Greece the ASC will
be retained, for a period of at least thirty days,
a record containing the Heading, the address and the
origin parts of messages. The online retrieval time
will be approximately 10 seconds.
3.8.1.3 For all transit messages the ASC will retain for a
period of at least thirty days, a record containing
the Heading, Address, and Origin parts of messages.
The online retrieval time will be approximately 10
seconds.
3.8.2 S̲h̲o̲r̲t̲ ̲T̲e̲r̲m̲ ̲R̲e̲c̲o̲r̲d̲s̲
3.8.2.1 The ASC will retain, for a period of at least one hour
a copy of all messages, in their entirety, retransmitted
or relayed by it. The online retrieval time will be
approximately 5 seconds.
3.8.2.2 After one hour the Message Management module will release
the message storage capacity. However, if there is
no need for use of the capacity the message will still
be available on short term traffic storage.
3.8.2.3 The system will through the Message Management module
be able to indicate the oldest message contained in
short term storage. The supervisory personnel will
be provided with terminal functions to request the
short term log maintained by Message Management together
with the percentage of the relevant disk storage occupancy.
3.8.2.4 Please refer section 3.7.15.
3.8.2.5 The ASC will recognise the SVC acknowledgement messages
and delete from the short term storage the messages
for which it has received positive acknowledgement.
However, the message will still be available on Long
Term Storage.
3.9 S̲T̲A̲T̲I̲S̲T̲I̲C̲S̲
3.9.1 The ASC will be capable to maintain and print out on
request from the supervisory personnel or periodically
statistical information.
3.9.1.1 Daily Statistics at 2400 GMT HRS
a. Total number of incoming/outgoing messages.
b. Total number of incoming/outgoing messages per
channel.
c. Number of messages rejected to the Service Position
by the ASC, sorted in reason of rejection.
d. Number of messages during Peak Hours and Peak minute,
per channel.
e. Occupancy time per channel in percentage.
f. Percentage of incoming/outgoing messages in each
priority group.
g. Maximum and Mean time of messages in queue.
h. Maximum and Mean Percentage of occupancy of the
Short Term Store.
i. The number of failures, the duration (Hours/
minutes) of each failure and the percentage of
failure per channel.
The same statistical information will be calculated
on monthly basis. The statistical information can be
printed out any time on request both based on daily
calculation or monthly calculation.
3.9.1.2 Recommended Additional Statistics
- Average length of messages in characters
- The number of messages requiring assistance.
3.10 SYSTEM SUPERVISION AND CONTROL
Please refer section 2.2.1.3.1.1.
