top - download
⟦b7a6f3bc8⟧ Wang Wps File
Length: 120000 (0x1d4c0)
Types: Wang Wps File
Notes: Crossfox Tilbud
Names: »1814A «
Derivation
└─⟦03f37a045⟧ Bits:30006227 8" Wang WCS floppy, CR 0138A
└─ ⟦this⟧ »1814A «
WangText
APPENDIX I OF VOL IV
1982-03-05
MESSAGE SUBSYSTEM
TECHNICAL PROPOSAL
4. M̲E̲S̲S̲A̲G̲E̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲;̲ ̲E̲Q̲U̲I̲P̲M̲E̲N̲T̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
4.1 S̲Y̲S̲T̲E̲M̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
The following subsections describe system configuration
with respect to:
- connectivity and expandability
- Typical Layout
- Equipment Matrix
- Physical Characteristics
- Incoming Message Processing
4.1.1 C̲o̲n̲n̲e̲c̲t̲i̲v̲i̲t̲y̲ ̲a̲n̲d̲ ̲E̲x̲p̲a̲n̲d̲a̲b̲i̲l̲i̲t̲y̲
The connectivity and modularity of the proposed MPF
hardware support the required terminal and line connections
and allow future expansion in incremented steps matching
growth in system usage.
The proposed system will be wired and equipped according
to the required connection capacity as outlined in
table 4.1.1-1. This table lists the number of lines
(circuits) connected to the MPF processor via the line
termination units. The total of internal as well as
external communication lines is 34.
To facilitate software maintenance and system configuration
control each site will be supplied with a maintenance
position which will be equipped with one VDU, one printer
and one floppy disc unit. These terminals are not
included in table 4.1.1-1.
The proposed MPF hardware configuration is very modular
and allows for many expansion possibilities. The expansion
capabilities are at various levels covering a wide
field from basic units to subsystems, such as:
o adding CPU, for increase of process power
o adding RAM, for memory expansion
o adding DISKS, for extra storage facilities
o adding LTU, for increase of connected lines to
terminals and circuits
o adding Power Supply, Bus, Crate and Rack, for support
of housing additional units.
These wide expansion possibilities make a flexible
system which can be expanded in steps matching the
growth in message traffic.
The proposed hardware will allow a 25% expansion of
internal and external communication lines without any
addition of extra hardware or software.
In table 4.1.1-1 a possible, expanded connectivity
is listed, meeting the 25% increase in total number
of lines.
To make it easy to expand the number of communication
lines, each logical circuit and channel number will
be parameterized.
The dimensioning of the system will be such that a
30% increase in future message traffic can be accommodated
by the system without any additional software or H/W
changes.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Communication systems Required Expanded
and terminals ̲C̲o̲n̲n̲e̲c̲t̲i̲v̲i̲t̲y̲ ̲ ̲ ̲ ̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲v̲i̲t̲y̲
̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲n̲u̲m̲b̲e̲r̲ ̲o̲f̲ ̲l̲i̲n̲e̲s̲ ̲ ̲n̲u̲m̲b̲e̲r̲ ̲o̲f̲
̲l̲i̲n̲e̲s̲
SHIP-TO-SHORE 4 5
MCU MONITOR 4 5
BROADCAST 8 10
MRL 2 3
NICS TARE 1 2
TRC 6 7
STANDBY MC 1 1
VDU 5 6
PRINTER 3 4
Total of lines 34 43
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Connectivity Matrix
Table 4.1.1-1
4.1.2 T̲y̲p̲i̲c̲a̲l̲ ̲L̲a̲y̲o̲u̲t̲
A variety of layouts are possible within the space
allocated for the equipment. A typical site layout
for the MPF room is illustrated in figure 4.1.2-1.
It includes:
- 3 computer racks
- 2 disk cabinets
- 4 operator positions consisting of:
4 visual display units (VDU)
2 medium speed printers (MSP)
- 1 MCSF work station consisting of:
1 tempest VDU
1 tempest MSP
- 1 Engineering Work station consisting of:
1 VDU
1 Printer
The typical layout reflects the floor space required
by cabinets and the operator positions.
The racks are positioned so that sufficient clearance
is maintained for access to front and rear of the equipment.
Otherwise, only few constraints as to the placement
of the equipment exist. The final layout will take
into account human factors, segregation of functional
activities, access for maintenance and other considerations
or preferences of the operating personnel.
Besides the equipment shown in figure 4.1.2-1, four
Message Compilation Units (MCU) will be installed in
the crypto room.
Typical Layout…01…Figure 4.1.2-1
4.1.3 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲M̲a̲t̲r̲i̲x̲
The equipment matrix is compiled to correspond with
the requirements in the IFB and to fulfill the equipment
need for the proposed Message Subsystem.
The equipment to be supplied for site 101 and site
301 is identical.
The equipment matrix contains figures for one site.
The number of pieces of equipment must be multiplied
by two to get the total amount of equipment to be supplied
for the two sites.
E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲M̲a̲t̲r̲i̲x̲ ̲p̲e̲r̲ ̲S̲i̲t̲e̲
Item Number Description
…06…1…02… …02… …02… …02…
1 3 CR8101-/036/00 Rack
2 2 CR8125M/225PC/00 PU-CRATE
3 2 CR8125M/425AB/00 CU-CRATE
4 4 CR8105M/020-/00 FAN
UNIT
5 3 CR8106-/220-/00 MAINS
FILTER
6 8 CR8050M/010-/00 POWER
SUPPLY
7 3 CR8107-/010-/00 POWER
DIST.
PANEL
8 2 CR8020M/000PC/00 MAP
9 2 CR8071M/010-/00 MIA
10 4 CR80030M/040PC/00 CPU
CACHE
11 6 CR8016M/128PC/00 RAM
128K
12 2 CR8081M/010A-/00 CIA-A
13 2 CR8081M/010-B/00 CIA-B
14 2 CR8211M/738-/00 DATA
CHANNEL
TERM.
15 4 CR8211M/015-/00 CABLE
DATA
CHANNEL
16 20 CR8201M/015-/00 CABLE
RACK
POWER
17 12 CR8055M/020-/00 MBT
18 3 CR8044M/040AB DISC
CONTROLLER
19 3 CR8084M/010 DCA
20 1 CR8047M/040AB FLOPPY
DISC
CONTR.
21 1 CR8087M/010 SFA
22 11 CR8066M/010AB LTU
23 11 CR8082M/010 LIA-N
24 1 CR8309/104 WATCHDOG
25 1 DELTA DATA
7260TC TEMPEST
VDU
26 1 TRACOR 8000 TEMPEST
PRINTER
27 5 DELTA DATA
7301 VDU
28 3 CR8330/200 PRINTER
29 1 CR8300/080
80
MB
SMD
DISC
DRIVE
30 2 CR8300/150 150
MB
SMD
DISC
DRIVE
31 2 CR8300/001 ACOUSTIC
CABINET
32 5 CR8319/80
80
MB
DISC
PACK
33 2 CR8319/150 150
MB
DISC
PACK
34 3 sets CABLES
FOR
DISC
35 1 CR8308/232 DUAL
FLOPPY
DISC
36 1 CR1081S/020 S-CRATE
37 3 CR8105S/010 S-FAN
38 1 CR8022S/000 S-POWER
SUPPLY
39 2 OPTO
MULTIPLEXER
40 3 CR1086S/000 BACK
PANEL
ADAPTOR
41 3 L/L
ADAPTOR
42 4 CR2560/008 MCU's
BOX
4.1.4 P̲h̲y̲s̲i̲c̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
The physical characteristics of the proposed equipment
are well known to the supplier since the MPF installation
will be configured with existing hardware elements.
This equipment information will be used in conjunction
with site data to plan each installation.
Hardware units are mounted in standard 19" racks except
for the disk units (150 MB) which are contained within
acoustic cabinets. Either top or bottom cable entrance
to the racks can be accomodated, depending on whether
or not the equipment room is provided with a computer
floor. Servicing and maintenance of the equipment
is performed from the front of the racks. Access to
the rear is only required to connect or disconnect
interrack cables.
The physical characteristics of the individual MPF
unit including power consumption, weight, height, width
and depth are described in section 6.1.10 in this appendix.
4.2 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
4.2.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The following functions are included in full compliance
with the IFB
- Reception and analysis of messages from all input
channels in format according to ACP127 NATO Supplement
3 .
- Reception and analysis of messages in format ACP126
(modified) from SHIP-TO-SHORE and MRL input channels.
- Local Message Delivery
- Service Message Handling
- Message Servicing (refer section 4.2.4)
- Support functions are provided as interfaces to
the above functions (refer sections 4.2.4 to 4.2.7)
Fig. 4.2.1-1 presents the functional relationships.
Christian Rovsing A/S will propose that an incoming
message, as part of the analysis, is converted to an
internal ACP127 format. Thus this format in the case
of an ACP126 formatted message is the result of the
ACP126 to ACP127 conversion. One advantage of this
solution is that less processing is needed when the
conversion is done at the time where the parameters
are detected for the first time. Especially the number
of disk accesses is decreased for the following reason:
Each message is written to disk after analysis; part
of the message is later retrieved for conversion and
routing and then written to disk, thereby providing
the information necessary for transmission on the low
speed channel(s) whenever available for transmission;
if the basic conversion is done as part of the analysis
less disk accesses will be needed to perform the final
conversion and routing.
Fig. 4.2.1-1 Incoming message handling functions
(A simplified block diagram)
It is further suggested that, apart from sequences
for initial transmission (refer ship to shore reception
in section 4.2.1.1.2), incoming messages for local
display be also displayed in an extract of this internal
format which is, for most of the lines just a "cleaned
up" version of the incoming message.
A major advantage of an internal ACP127 message format
would be that a message normally (garbled messages
excepted) will be stored only once in a format which
is the basis for all later processing, i.e. retrieval
for retransmission and/or local display (refer section
4.7.3 for further discussion). The storage format
will allow for field extensions for additional header
information in case of multiple transmissions.
The IFB section 5.1.2.1.7, however, requires that the
local delivery of incoming messages be without conversion
and CHRISTIAN ROVSING A/S has assumed the design to
be in compliance with this requirement. Thus each
incoming message will be stored in its initial format
and the internal ACP127 format is used for the retransmission
handling. Garbled incoming messages will be stored
twice, before and after correction.
The possible contents of an internal ACP127 display
format is presented in section 4.2.1.3. Further discussion
of the tasks of analysis and conversion in connection
with the internal ACP127 format will be found in section
4.2.2.
CHRISTIAN ROVSING A/S' interpretation of the ACP127
format is presented in ANNEX B to this Appendix.
This annex includes the basic format, possible deviations,
incoming analysis, and generation of format for outgoing
messages.
A preliminary interpretation of the ACP126 format (modified)
has been prepared by Rovsing A/S as well, refer ANNEX
A.
This annex presents on a line by line basis the format
parameters and additionally the insertion of these
parameters into the ACP127 format on conversion.
4.2.1.1 R̲e̲c̲e̲p̲t̲i̲o̲n̲
The main subfunctions are
- message detection
- message accounting
- message quality evaluation
- traffic evaluation & control
- temporary storage
The TARE & TRC incoming traffic will be discussed separately
from the incoming traffic from Ship-to-Shore and MRL
circuits. In general, messages are stored in the"internal
ACP127 format" which is most useful for fast and safe
processing. Garbled messages are always stored as received,
as well.
4.2.1.1.1 T̲A̲R̲E̲ ̲&̲ ̲T̲R̲C̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
a) Message start detection will be based on the Start
of Transmission sequence (SOTF) "VZCZC" or "VV(Sp)(Sp)(Sp)".
If not found then the characters are discarded
until next SOTF.
b) Message accounting will be based on the Transmission
Identification of format line 1: "TI" = "Station/Channel
Designator "(CD)" and "Transmission Serial number"
(TSN). The TI uniquely defines a message
A counter will be maintained by the system for
each incoming channel giving the expected TSN of
the next message.
1) The counter will be reset to 001 (0001) at
the start of day or as decided by the supervisor
upon receipt of a service message (refer to
section 5 for the appropriate interface description).
2) For an incoming message where the TSN is not
present or not equal to the counter, a warning
will be printed out at the supervisor position
- indicating both the expected number and the
received incorrect number (if any). A log entry
will be made.
3) If the received TSN is less than the counter,
the message will not be stored on reception
and the counter will not be changed.
4) If the received TSN is equal to the counter,
the message will be stored on reception and
the counter will be incremented by one.
5) If the received TSN is greater than the counter,
the message will be stored. The counter will
be reset to the received TSN plus one.
6) If the message is received without a TSN, the
expected TSN will be allocated to the message
by the system. The message will be stored,
and the counter will be incremented by one.
c) Apart from case b 3) above, garbled messages will
always be kept and stored in the initial non-corrected
version.
d) Message quality evaluation will determine whether
the incoming message is suitable for further processing
or, alternatively, whether queuing for the message
service position (MSO) is necessary for manual
message corrections. Criteria for manual corrections
are
- consecutive SOTF sequences
- oversized messages
- halted messages
- consecutive identical characters
- lines are too long
- non-standard EOTF (End of Transmission Function).
The EOTF for preempted messages is accepted
as standard.
These cases are discussed in detail in ANNEX B.
Traffic evaluation and control are concerned with
the monitoring of channel traffic. If no traffic
has been detected for a predefined period on an
open channel, the proper service message will be
transmitted on the outgoing channel. For further
details refer to the appropriate interface descriptions
in section 5.
4.2.1.1.2 S̲h̲i̲p̲-̲T̲o̲-̲S̲h̲o̲r̲e̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
a) Message Detection may be based on the sequences
described in section 4.2.1.1.1. However, in some
cases a message may be received without a format
line 1. According to ANNEX 5I of the IFB the first
line is then detected on the prosign "DE".
b) Message accounting may be based on the TSN in format
line, or, if no format line 1 is present, on the
following format line 3 parameters for ACP 127
messages:
- originating stations RI
- station serial number
- Time of File (for originator)
CHRISTIAN ROVSING A/S suggests that the format
line 3 parameters always be used for reference
(as secondary keys on retrieval with the receiving
station TOF as primary key.)
Similarly, the same format line 2 parameters may
be used for ACP 126 message accounting.
Continuity checks are, due to the type of traffic,
not performed. Lack of accounting information,
as specified above, will lead to queuing for the
MSO, which may request retransmission(request automatic
generation of service message, refer para 14 of
ANNEX 5I of the IFB).
c) It is suggested by CHRISTIAN ROVSING A/S that the
message quality evaluation criteria of section
4.2.1.1.1.d also apply to this case.
Furthermore, the following evaluation of incoming
messages will be performed:
d) According to section 4.4 the MCU delivers, on a
separate monitor channel for each incoming ship-to-Shore
data channel, the following information
- for each character: whether it is ambiguous
or not
- for a TBD number of characters: the confidence
level for each of the 4 external lines feeding
the MCU.
The above information will be used as follows:
1) Any change in confidence level of an external
line exceeding a threshold value, to be set
by the supervisor, will result in a warning
report to the supervisor.
2) The sum of ambiguous characters expressed as
a percentage of total number of characters
per message will be compared to a supervisor
set threshold value applicable for all channels
- if directed so by supervisor, the value
exceeded shall result in queuing for the
MSO.
The message lines with ambiguous characters
are highlighted when displayed. This does
n̲o̲t̲ apply to initial transmissions (see
below).
- the value exceeded will on the supervisors
decission result in the automatic transmission
of a retransmission request on the service
channel of the broadcast (ANNEX 5I, section
14 of the IFB). This will n̲o̲t̲ apply to
initial transmissions.
CHRISTIAN ROVSING A/S suggests a warning
report indicating the number of repeated
retransmisson requests during a session.
This will assist the supervisor in proper
use of the manual channel availablitity
setting option (refer f2 below).
- the value exceeded for reception of initial
transmission will result in queuing of
the message for display to the supervisor
together with a note on the relative number
of ambiguous characters and the present
external channel confidence levels. Also
refer to e2) below.
- n̲o̲t̲ exceeding the value will result in
the automatic transmission of a receipt
message on the service channel of the broadcast
(ANNEX 5I, section 13 of the IFB). This
does n̲o̲t̲ apply for reception of initial
transmissions.
- not exceeding the value will for reception
of initial transmissions result in the
automatic transmission of a transmit instruction
(ANNEX 5I, section 11) over the service
channel of the broadcast. This automatic
transmission may be inhibited by the supervisor
(refer below).
e) The initial transmission sequence may correspond
to the one in ANNEX 5I, section 10 of the IFB,
and will include the following parameters:
- indefinite call sign
- number of messages to transmit
- precedence of the messages
At the start of an initial transmission, i.e. having
received a finite stream of characters corresponding
to the above sequence or having recieved a predefined
max. number of characters, the following actions
will be taken:
1) The supervisor is informed on his display of
the arrival or
2) if decided by the supervisor, the input character
stream is instead displayed at the supervisor
position together with the relative number
of ambiguous characters and the actual channel
confidence limits. This display will replace
the display in the case of ambiguous character
errors , refer d2) and the "2 minutes delay"
display mentioned below. The automatic response
to evaluations is inhibited.
3) the character stream, in the case where the
character ambiguity level is not exceeded (refer
section d2 above), will be evaluated to isolate
the above mentioned parameters. If not possible,
a request for retransmission is sent over the
service channel for broadcast. If the supervisor
has inhibited the automatic response, he is
informed on his display of the non-success
of parameter isolation.
4) each repeated sequence received during the
initial transmission phase is treated as mentioned
above in section d) and this section. If 2
minutes have elapsed since reception of the
first sequence, and the wanted parameters have
not been found, the last message and the character
ambiguity measure together with the channel
confidence assessment will be queued for the
supervisor display unless already displayed
at the supervisor's direction, refer above.
5) The supervisor may also select to have all
MPF initiated messages to the afloat station
displayed during the initialization phase.
6) The supervisor may at any time during the initialization
sequence prepare and edit service messages
(prestored if required) for the afloat station.
f) Traffic evaluation and control will include the
maintenance of an "Access Circuit Assignment List"
containing the actual status of S/S channels. This
list will be displayed at the supervisor's request.
The following status items will be shown:
- channel assigned for common use or dedicated
traffic, including not-assigned.
- channel in use or available for common use;
this only applies to common use channels.
The status of common use channels will automatically
be changed as follows:
1) status changes from "available" to "in use"
as a result of the reception of an initial
transmission sequence (whether good or bad).
2) status changes back to "available" as a result
of any of the following three cases
- the receipt of a specific end-of-transmission
sequence from the afloat station, e.g.
the operating signal QRU (refer to para
8 of annex 5I of the IFB)
- no traffic received for a period of 2 minutes.
- the supervisor instructs the MPF that the
circuit is again available for common use.
The MPF will automatically transmit a service message
over the BROADCAST service channel showing the current
availability status for common use channels under the
following conditions:
- at each change of status
- at times during each hour to be specified by the
supervisor
The format of this servicemessage will be in accordance
with para 9 of ANNEX 5I of the IFB, including the designation
of the lowest procedure of messages that may currently
be transmitted by ships as specified by the supervisor.
4.2.1.1.3 M̲R̲L̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
Sections 4.2.1.1.2 a), b), and c) will apply for MRL
reception as well.
4.2.1.2 A̲n̲a̲l̲y̲s̲i̲s̲
Incoming message analysis covers the detection of all
parameters necessary for:
- handling of messages according to precedence and
security.
- proper conversion to an "internal ACP 127 format"
for storage. This format will be defined to allow
for fast and safe conversion for retransmission
or display, immediately or as a result of retrieval.
Refer to the introduction in secton 4.2.1 concerning
the usage of the internal ACP 127 format.
- logging and retrieval catalog maintenance.
The analysis will mainly depend on the kind of received
format, ACP 127 or ACP 126, and only in some special
cases on the kind of incoming circuit; these cases
are clearly indicated in the following text.
4.2.1.2.1 A̲C̲P̲ ̲1̲2̲7̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
a) ANNEX B presents the CHRISTIAN ROVSING A/S interpretation
of the ACP 127 format: The format presentation,
possible deviations, and procedures to be applied
at reception.
b) Detection of format lines will be based on the
line detection criteria of table 4.2.1.2.1-1.
c) Until detection of the security level (classification
of a message), a message will be treated as having
the level of the input channel.
d) In general a message will be queued for message
service in the following cases
- non-detectable classification/special handling
- errors according to ANNEX B
- formal routing errors. When detecting local delivery.
- detection of special handling designators - a set
which may be specified by the supervisor. The MSO
may by assigning proper routing information determine
the retransmission and/or local delivery.
e) The message precedence is detected from format
line 2 as follows
P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲l̲e̲v̲e̲l̲ P̲r̲o̲s̲i̲g̲n̲ N̲a̲m̲e̲
1 Z FLASH
2 O IMMEDIATE
3 P PRIORITY
4 R ROUTINE
Detection of format lines during the analysis of messages
in ACP 127 format shall be based on the "character
sequences" specified below:
F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲C̲r̲i̲t̲e̲r̲i̲a̲
1 VZCZC or VV(Sp)(Sp)(Sp)
2 ZZ or OO or PP or RR
3 DE
4 ZNR or ZNY
5 Precedence prosign Z, O, P, R for action addressees
6 FM
7 TO
8 INFO
9 XMT
10 GR or "combination of letters"
11 BT
12 (text; no interest to MPF except SERVICE messages)
13 BT
14 C
15 (FS)
16 EOTF sequence
Table 4.2.1.2.1-1
f) The following rules will apply for precedence processing.
1. based on time of detection (EOM), a message
will be treated in the order of reception within
each level. This rule is format independent.
2. when a message of precedence FLASH is received
from TARE or TRC and the operating signal ZGC
is n̲o̲t̲ contained in format line 4, the MPF
will automatically initiate the transmisson
of a receipt message of the following format:
ASM of precedence IMMEDIATE with format line
12g
R(sp)Z(sp)(TI)(EOLF)
No receipt shall be given for a receipt.
3. an audible alarm will be given to the supervisor
when a flash message is received.
g) As a result of comparing the procedures related
to messages with expiry time/no expiry time (section
5.1.2. 1.5.2 of the IFB) with the procedures concerning
screening and vetting (section 5.1.2.2.7.8 of the
IFB) CHRISTIAN ROVSING A/S propose to implement
a general set of procedures. For this purpose
the following function will be implemented:
An incoming message may contain in format line
5 the operating signal ZPW followed by a date time
group (DTG): "The expiry time" indicating the latest
time of retransmission of the message. The message
analysis will detect the ZPW signal and the expiry
time. As selected by the supervisor on a network
basis, outgoing messages with ZPW may then be subject
to the screening and vetting and related procedures
for expired messages, refer section 4.2.2.
4.2.1.2.2 A̲C̲P̲ ̲1̲2̲6̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
a) ANNEX A presents the preliminary CHRISTIAN ROVSING
interpretation of the ACP 126 format: The format
parameters to be detected are listed on a line
by line (physical and format line) basis with some
possible variations/deviations. Furthermore the
corresponding ACP 127 parameters at conversion
(if any) and their location in the message are
shown.
The conversion to an "internal ACP 127 format"
as basis for further handling is considered part
of the analysis.
b) Detection of format lines will be based on the
line detection criteria of table 4.2.1.2.2-l
Detection of format lines during the analysis of
messages in ACP 126 (modified) will be based on
the "character sequences" specified below:
F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲C̲r̲i̲t̲e̲r̲i̲a̲
1 VZCZC
2 Z or O or P or R
4 ZNR or ZNY
5 (precedence prosign combinations)
6 FM
7 TO
8 INFO
9 XMT
10 GR (or Accounting Signal)
11 BT
12 (text; no interest to MPF except SERVICE messages)
13 BT
14 (no interest to MPF)
15 (FS)
16 (2CR)(8BLF)(4N)...(EOMF sequence)
Table 4.2.1.2.2-1
c) The procedures of sections 4.2.1.2.1 b) to f1)
will also apply to ACP126 analysis.
d) Incoming messages from Ship-to-Shore channels may
contain in format line 5 the operating signal ZPW
followed by a date time group (DTG): "The expiry
time" indicating the latest time of retransmission
of the message. The supervisor will have the facility
to select on a circuit type basis the detection
of ZPW and expiry time. Messages with ZPW may
then be subject to screening, Vetting, and related
procedures for Expired Messages, refer section
4.2.2.2.b. Also refer to section 4.2.1.2.1.g (first
paragraph) for the reason behind the introduction
of these procedures (which are selectable by the
supervisor on a circuit basis).
4.2.1.3 L̲o̲c̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲
The MPF will deliver incoming messages to terminals
based on specific RI's detected in format line 2 of
an incoming message.
The supervisor will have the facility to maintain a
table associating these RIs to the proper terminal
(via Terminal Designator) for delivery. CROSSFOX users
may be informed of the assignments via a supervisor
initiated service message.
CHRISTIAN ROVSING A/S will comply fully with display
of incoming messages as received if so desired by purchaser.
As described in 4.2.1, however, we propose the use
of an internal ACP 127 format display which is almost
identical with the format forwarded via BROADCAST:
Format lines 5 to 13 as received plus a special easily
readable format for information concerning special
handling, security level, other message handling instructions,
and internal MPF item reference.
Data messages are not subject to local delivery.
4.2.1.4 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Certain service messages will be detected and acted
upon automatically at reception. Such messages are
normally connected with traffic control.
Refer to ANNEX 5D and 5N of the IFB for a description
of these messages for TARE and TRC, respectively.
The contents of these annexes concerning service messages
are identical to documents CPS/ICD/007 and CPS/ICD/004
issued by CHRISTIAN ROVSING A/S for the CAMPS project.
In addition, the FLASH receipt message (section 4.2.1.2.1)
will be detected automatically. Also a service message
in ACP 127 for retransmission request will be defined
together with the purchaser for initiation of automatic
retrieval and retransmission.
For Ship-to-Shore and BROADCAST the service messages
are defined in ANNEX 5I of the IFB: Retransmission
request for automatic retrieval and retransmission,
End-of-Transmission from ships, Initialization Sequence
from ships.
Automatic service messages on the MRL channels are
not known, but are assumed to be the same types as
for Ship-to-Shore.
Other service messages are subject to local delivery
based on Routing Indicator detection, i.e. the station
RI. They are queued to the supervisor position for
display.
4.2.2 O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The following functions are included in full compliance
with the IFB:
- convert messages received in format ACP 126 to
format ACP 127 for retransmission.
(Refer to sections 4.2.2.1.1 and 4.2.2.2)
- retransmit message received in format ACP 127.
(Refer to section 4.2.2.1.2 and 4.2.2.3)
- provide capabilities for local service message
preparation and entry to the MPF for transmission.
(refer to section 4.2.2.4)
- Message Servicing (routing assignment assistance)
(Refer to sections 4.2.2.1, 4.2.2, 4.2.2.3, 4.2.2.4.1,
and 4.2.4)
- Support Functions are provided as interface to
the above functions (refer to section 4.2.4 to
4.2.7).
- provide the capability to produce on request a
hardcopy record of the outgoing traffic on a channel
basis.
Fig. 4.2.2-1 presents the functional relationships.
4.2.2.1 C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲&̲ ̲R̲o̲u̲t̲i̲n̲g̲
Conversion and routing are closely connected and both
are dependent on message format as well as message
origin.
Fig. 4.2.2-1 Outgoing message handling
(A simplified block diagram)
It will be shown, however, that in all cases the conversion
may be based on an internal ACP 127 format derived
during incoming message analysis or produced as a result
of local message generation. This internal format has
a layout which, although it differs somewhat from case
to case, is constant enough to be adopted as a proper
working tool as it will be seen from the discussion.
Any incoming message presented for conversion and routing
has been subjected to detailed analysis and has possibly
also been handled at the message service position.
Refer to sections 4.2.1.2.1 and 4.2.1.2.2 for details.
The conversion to an internal ACP 127 format is considered
part of the incoming message analysis and will be explained
in the following sections.
4.2.2.1.1 A̲C̲P̲ ̲1̲2̲7̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲&̲ ̲R̲o̲u̲t̲i̲n̲g̲
a) Table 4.2.2.1.1-1 presents the task of format line
detection and parameter isolation. This is performed
by incoming message analysis to provide an internal
message format containing the necessary information
for conversion and transmission and for local message
presentation. The table also shows the message
format compilation to be performed in conversion
and routing.
b) The information in the above table shall be referred
to together with the flow of Fig. 4.2.2.1.1-1 which
provides an overview of the routing principles
for an incoming message in format ACP 127.
Table 4.2.2.1.1-1
Fig. 4.2.2.1.1-1 Routing of Messages Received in ACP 127 format
Routing will be based on the RIs in format line
2 and format line 4 (T-instructions) as will be
explained below.
c) In case 1 of Fig. 4.2.2.1.1-1 there are no T-instructions.
The RIs may be of 4 types which are
1) Local RIs which are defined by the supervisor.
For these RIs local delivery will take place.
2) RIs in messages from TARE/TRC which do not
point to BROADCAST, MRL, or MPF. In these cases
the message shall be queued at the message
service position from where the message may
be returned to the TARE network (with the proper
ACP 127 pilot). This only applies for those
RIs which are not accepted; for the proper
RIs transmission will take place automatically
on return from the service position.
3) RIs which are unknown to MPF i.e. for which
MPF has no responsibility or which are garbled.
In this case the message will be queued at
the message service position for correction.
As in the case c 3), the message may on return
from
the message service position be transmitted
automatically on the proper RIs and transferred
to the TARE network on the non-correctable
RIs.
d) In case 2 of Fig. 4.2.2.1.1-1, T-instructions provide
RIs which replace the RIs of format line 2. Otherwise
the routing is the same as in C1, C2 and C3.
e) Procedures for channel selection based on the known
RIs and other transmission procedures are discussed
in sections 4.2.2.2 and 4.2.2.3.
4.2.2.1.2 A̲C̲P̲ ̲1̲2̲6̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲&̲ ̲R̲o̲u̲t̲i̲n̲g̲
a) Table 4.2.2.1.2-1 presents the task of format line
detection and parameter isolation. This is performed
by incoming message analysis to provide an internal
message format containing the necessary information
for conversion and transmission, and for local
message presentation. The table also shows the
message format compilation to be performed in conversion
and routing.
b) The information in the above table shall be referred
to together with the flow of Fig. 4.2.2.1.2-1 which
provides an overview of the routing principles
for an incoming message in format ACP 126.
Routing will be based on the RIs which may be taken
directly from the incoming message or derived via
the address information as explained below.
Table 4.2.2.1.2-1
Fig. 4.2.2.1.2-1, Routing for Message Received in ACP126 format
c) In case 1 of Fig. 4.2.2.1.2-1 the message is routed
to a local terminal based on the detection of an
RI belonging to a supervisor specified set of RIs.
d) In case 2 of Fig. 4.2.2.1.2-2 the RIs of format
line 2 may be of 4 types, which are:
1) RIs belonging to a set of RIs specified by
the supervisor for which full conversion to
ACP 127 shall take place. RIs of the destination
will then be derived from PLAs and indirectly
from AG/AIGs via tables maintained by the supervisor.
ZEN PLAs and PLAs from format line 9 will be
excluded when searching RIs.
There will be selected one and only one RI
per PLA and per circuit.
If, during the process of finding RIs corresponding
to the PLAs, certain PLAs are not found, the
system will enter a dummy sequence in front
of the PLA and the processing will then continue
as follows:
- for high precedence messages (level decided
by supervisor) the copy of the message
with the dummy sequence may be forwarded
to the TARE, if this option is chosen by
the supervisor.
- the message is always queued to the message
service position for possible replacement
of the dummy sequence. The message service
may also decide to have a copy sent to
TARE (in this case a pilot will be added
to the ACP 127 format).
2) RIs belonging to a set of RIs specified by
the supervisor for which modified conversion
shall take place. The RIs for the outgoing
message are in this case identical to the incoming
message RIs.
3) RIs known to the system but not belonging to
the above groups will not lead to any conversion
of the ACP 126 format. It is not quite clear
in the IFB whether this group of RIs exist;
in any case the transmission on Broadcast is
not allowed without conversion.
4) If RIs are not known or garbled, the message
shall be queued to message service for correction.
It will be possible to have a message with
unknown routing transmitted to the TARE for
further handling.
e) CHRISTIAN ROVSING A/S proposes the following organization
principle of the PLA/RI table: If more than one
RI exists per PLA then they should be listed in
order of priority; RIs will always be listed together
with the minimum routing classification and a pointer
to the circuit, i.e. TARE, TRC, BROADCAST or MRL.
This table arrangement will allow an early decision
on the most preferred circuit with the proper classification.
Even if only one circuit exists the classification
is important since a decision on queuing for message
service assistance may then be taken with a small
amount of processing.
The above RI selection procedure is the first step
in selection of the proper channel. Each circuit
may have one or more channels, each possible with
a separate classification, which will be h̲i̲g̲h̲e̲r̲
̲t̲h̲a̲n̲ or equal to the classification associated
the RIs of the PLA/RI table pointing to the channels.
Procedures for channel selection based on the known
RIs and other transmission procedures are discussed
in sections 4.2.2.2 and 4.2.2.3.
4.2.2.2 G̲e̲n̲e̲r̲a̲l̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
a) Channel selection will in general be based on the
following principles:
1) Each RI will be pointing to one or more channels
within a circuit, each channel having its own
classification. From the channels satisfying
the level of message classification, final
channels may be selected on basis of priority
or, as in case of BROADCAST, on basis of an
algorithm for minimizing the number of transmissions.
Other principles such as selection on basis
of channel load for otherwise equally qualified
channels may be considered.
2) The RI/Channel table is organized on a per
circuit basis thus taking advantage of prima
facie knowledge of circuit, whether this is
known from the PLA/RI table or from the composition
of the RI itself.
3) If for one or more RIs of a message no channel
is found due to classification the message
shall be queued for routing assignment at a
service position.
4) The system will maintain a table entry for
channel status. If a channel selected for
transmission is found not open/available then
the message will be queued for routing assignment
at a service position.
b) As mentioned in section 4.2.1.2.1g), CHRISTIAN
ROVSING A/S suggest to make the procedures of Screening
& Vetting and related procedures generally available
as follows:
1) The supervisor will be able to select, on a
circuit basis, the non automatic transmission
of messages where the expiry time has been
exceeded, i.e. messages with operating signal
ZPW and expiry time which for some reason (e.g.
diversion to message service, no channels available)
have been kept from transmission. Such messages
will then, dependent on supervisor choice,
either be
- filed without retransmission (except that
the supervisor may retrieve and retransmit
the message).
A log entry will be made and the supervisor
will be informed by a suitable message.
- or presented for SCREENING. A log entry
will be made.
2) The supervisor will be able to select, on a
circuit basis, to have all messages without
ZPW operating signal treated the same way as
expired messages.
3) The supervisor will be able to select, on a
circuit basis, to have all messages or optionally
all messages below a certain level of precedence
presented for screening.
4) The supervisor will select the messages service
position to be used for screening.
5) SCREENING means presentation of the message
at a display for the operator decision of either
- release of message for transmission or
VETTING if this function has been activated
by the supervisor
- or message filing
6) VETTING gives the operator the possibility
to place messages in a "hold" position. These
messages are first presented to the operator
for decision on transmission when vetting is
deactivated by the supervisor.
CHRISTIAN ROVSING A/S suggest that messages
which are not selected for transmission on
the operator's decision then be put in a further
"hold" or filed without transmission.
7) In the case of the response to a retransmission
request from an external station (refer below)
the MPF will as for all other transmissions
and dependent on the supervisor's decision
perform the functions mentioned above in b.
If the expiry time has been reached for a message,
a service mesage will be sent to the requesting
station containing the operating signal ZPW
followed by the expiry time.
c) Retransmission Requests
1) Automatic retransmission of stored messages
will take place on receipt of a service message
in an agreed form provided the supervisor has
activated this function.
2) The supervisor will be able to retrieve and
initiate transmission of any specific message
from store at any time.
3) Except for BROADCAST and MRL the retransmission
format is ACP 127 with a pilot.
d) Rules concerning precedence.
1) On any channel messages will be transmitted
in order of precedence and within each level
of precedence on a FIFO basis relative to the
time of queuing (which is normally also relative
to the time of reception for relayed messages).
2) In case of queuing for transmission of messages
with precedence FLASH, all other traffic of
lower precedence queued to the same channel
will be delayed, and messages which are being
transmitted will be interrupted unless:
- Format lines 1-4, pilot lines or the
End-of-Transmission is being sent.
- The rest of the message may be transmitted
within 30 sec. (or another time limit
controlled by the supervisor).
- the channel is operating at medium
or high speed.
3) messages preempted by FLASH traffic will be
terminated by the following sequence:
2 carriage returns, line feed, letter shift,
ZPH, space, 2 carriage returns, 8 line feeds,
NNNN, 12 letter shifts.
Interrupted messages will be retransmitted
immediately after the interrupting FLASH traffic.
4) Messages of FLASH precedence with operating
signal ZYA in format line 4 will be transmitted
before other FLASH messages but without preemption.
5) In the case of transmission of flash messages
with operating signal ZGC (option selectable
by the supervisor), a receipt message is expected.
If not received within a time period specified
by the supervisor he will be informed by the
MPF and a log entry will be made.
e) The supervisor will have the option at any time
for messages of IMMEDIATE precedence to choose
that they will be treated the same way as FLASH
messages concerning preemption of lower precedence
traffic.
f) Each transmission may have a maximum of 200 RIs
in format line 2.
g) Long messages will be automatically sectioned and
paged according to the rules of ACP127 supplement
3.
h) All messages transmitted will be allocated a TSN
on a per channel basis starting with number 001
(or 0001) or as reset by the supervisor. The TSN
will be incremented by one for each transmission.
i) The TSN of a cancelled transmission will be considered
used. An entry will be made in the log concerning
the cancelled transmission.
4.2.2.3 B̲r̲o̲a̲d̲c̲a̲s̲t̲/̲M̲R̲L̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The general procedures of section 4.2.2.2 will apply
for BROADCAST and MRL transmission as well.
The following additional information/procedures will
be considered as well. Any reference to BROADCAST shall
be taken to include MRL as well.
It should be noted that the PLA/RI/CHANNEL table layout
and related procedures for minimisation of transmission
are CHRISTIAN ROVSING A/S proposals. This is also
true for the invocation of Screening & Vetting for
messages that cannot be transmitted at times where
the candidate recipient is not listening.
a) The following types of RIs will exist:
1) RIs associated with individual channels. There
will be provision for up to 10 RIs per channel
and a total maximum of 40 RIs. Refer to section
b) below for the routing associated to these
RIs.
2) One collective Routing Indicator (CRI) pointing
to all ships and authorities copying the broadcast.
Routing will in this case be effectuated as
in section b) below assuming all PLAs of the
table are included in the message.
3) One RI associated with the MPF supervisory
position. If this RI is detected the message
will be displayed at a supervisory position
for operator selection of channels for transmission,
i.e. insertion of the proper RIs enabling the
MPF to select the proper channels as discussed
in section b) below.
b) The RI and Channel Selection may be combined as
indicated in table 4.2.2.3-1. PLAs as well as
RIs may serve as entry keys to this table.
1) For each PLA there is one RI, and for each
RI there is one and only one possible channel.
Channel attributes are in this context classification
and status.
2) The assignment of RIs to PLAs is entered by
the supervisor. The supervisor also enters
the channel assignment based on information
forwarded by ships and other authorities to
the MCS. In periods where reception is closed
down the V̲A̲L̲I̲D̲ ̲B̲I̲T̲ for the PLA in question
shall be set to zero by the supervisor.
3) The Channel classification will be compared
to the message classification; only channels
with the proper classification are considered.
The classification is possibly the same for
all Broadcast and for all MRL channels in which
case the table may be simplified
If no channel is found for one or more RIs
the message will be queued at a message service
position for RI or channel assignment with
indication of RIs in question.
4) If the VALID BIT is set to zero the message
will for the PLAs in question only, be subject
to an automatic screening & vetting, i.e. the
screening directive and the vetting directive
is each assumed always to be the given one
for these messages. The function suggested
here is a CHRISTIAN ROVSING A/S proposal.
5) The channel status is indicating the channel
availability as follows:
- status = 0 will indicate that a channel
is not available or overloaded. The overload
status is based on the queue length information.
The queue length is available to the supervisor,
and the status may be set by him or automatically
based on a threshold value set by him.
- status = 1 will indicate the channel being
available.
If for a RI no channel with a status different
from 0 is found, the message will be queued
at a message service position for RI or channel
assignment.
6) The channel status will be checked again at
the time of transmission. If a channel is found
with status = 0, i.e. closed or overloaded,
one or more alternative channels may be used
if so indicated by the supervisor. This method
may be used as an alternative for changing
the above table, but the success is, of cause,
dependent on whether all ships and authorities
using the channel with status = 0 have been
assigned to the alternative channel.
c) The table 4.2.2.3-1 may also be used for the extraction
of information to be inserted in the following
service messages used for informing users of the
routing and channel assignments.
1) ZOU-LIST. This message contains a listing
of the PLA/RI relation. It is transmitted to
authorities designated by the supervisor. The
authorities in question may be e̲n̲t̲e̲r̲e̲d into
the message by means of the supervisor function
for retrieval and editing of prestored service
messages. The ZOU list may be released by the
supervisor of 0300 hours each day. Refer para
3 of ANNEX 5I of the IFB for the format. Released
by supervisor at 0030 hours.
2) CHANNEL ALLOCATION LIST. This message is prepared
in the same m̲a̲n̲n̲e̲r̲ as the ZOU-list, but will
contain the PLA to Channel relations from the
table. Secondary channels may be indicated
if the purchaser decides so. This message will
be sent periodically, after each change in
allocation and on supervisor command. Refer
para 2 of ANNEX 5I of the IFB for the format.
CHANNEL ALLOCATION LIST
ZOU-LIST
PLA RI CH 1 .... CH N VA-
CLASS CLASS LID
STATUS STATUS
PLA1 RI1 X X
PLA2 RI2 . X X
PLA3 RI1 X
.
.
.
.
.
PLAM RI1 X
TABLE 4.2.2.3-1 CHANNEL ALLOCATION FOR BROADCAST & MRL
d) The Broadcast Serial Number is contained in format
line 2 of a BROADCAST message (i.e. the line preceeding
the ACP 127 format line 5). It is a three digit
serial number specific to the channel selected
and will be incremented by one for each new transmission.
The serial number will be preceded by the channel
designator digit (1 to 8) which again will be
preceeded by the broadcast call sign.
CHRISTIAN ROVSING A/S proposes the insertion of
the STATION SERIAL NUMBER as a unique identification
of Broadcast messages in format line 2 (in lieue
of the channel serial number repetition). In this
way multiple transmissions of the same message
over any channel thus will allow ships and other
authorities listening to more than one channel
to identify possible dublicates.
The above inclusion of a station serial number
will also apply in the case of retransmission in
response to a request (in which case the same channel
may be used).
e) Automatic retransmission will take place as decided
by the supervisor.
In addition to the procedures of section 4.2.2.2.b7
and c, the following information/procedures will
also apply
1) A retransmission request will be detected by
the reception of a service message of the format
shown in para 4 of ANNEX 5I to the IFB.
The resulting retransmission will be forwarded
by the operating signal ZFG.
2) With certain intervals or on the supervisors
decision those messages may be RERUN (retransmitted)
which were originally transmitted within a
given time window starting at a given point
in time in the past. The window and the start
time will be decided by the supervisor.
Messages which are expired will not be rerun
automatically. The same will be the case for
messages below a level of precedence to be
set by the supervisor.
The final rules for rerun is considered a matter
of discussion with the purchaser, such rules
will be in accordance with ACP 176.
f) A BROADCAST TRAFFIC CHECK LIST will be transmitted
periodically for each traffic channel in use, referencing
messages which have been transmitted since the
previous traffic list. The period between transmissions
will be set by the supervisor.
The transmission of the format will be as in par.
5 of ANNEX 5I to the IFB.
This message will include
1) time interval of applicability
2) the following entries per item
- broadcast channel/serial number
- precedence
- DTG of the message
- expiry time of the message (if applicable)
- PLAs of the ships and authorities to whom the
transmission was intended.
g) The following procedures for change of crypto key
card will be implemented per channel:
1) The supervisor will have the facility to command
the automatic, orderly closedown of BROADCAST
transmission for a specified period of the
day.
2) The supervisor will have the facility to select
the layout of a CONDITION MESSAGE to be automatically
transmitted immediately after the traffic close-down.
The format and possible variations are shown
in par. 6 of ANNEX 5I to the IFB.
3) Operational traffic which has not been transmitted
before the change may be transmitted afterwards.
However, special attention shall be given
to messages of precedence FLASH or IMMEDIATE:
- these messages may, if decided by the supervisor,
be transmitted automatically in the start-up
period for key change and repeated after the
period, in accordance with the rules of ACP127
Supp-1 page 224.
- the arrival of such messages for relay will
give rise to a warning (to the supervisor)
if transmission during the start up period
has not been enabled.
h) The supervisor can inform ships and other authorities
of frequency changes. This will be done by means
of a service message prepared at the supervisors
position or based on editing a prestored format.
Refer par. 7 of ANNEX 5I to the IFB for the format.
This message will be sent via the service channel.
i) The creation and usage of BROADCAST Service Channels
shall be as follows:
1) Any of the BROADCAST channels may be selected
by the supervisor as a service channel.
2) The service channel is reserved for transmission
of service messages as defined in this
section 4.2.2.3. It may also carry any
other message, which is designated from
a supervisory position for transmission
via this channel.
3) There is no routing based on RIs to the
Service channel.
j) The precedence procedures of section 4.2.2.2 a
will apply with the following additions:
1) The supervisor may specify that messages below
a certain precedence shall not be transmitted.
When decided by the supervisor these messages
will subsequently be transmitted and will then
be subject to the general rules of transmission
(such as the rule for expired messages in section
4.2.2.2.b1).
2) Messages of Precedence FLASH will be transmitted
twice, the second transmission following immediately
after the first. The second transmission will
have the same Broadcast transmission identification
(same channel and same serial number).
3) The supervisor may apply the rule of section
j2 above to messages of IMMEDIATE precedence
as well.
k) Cycling Emissions on the Broadcast channels will
be transmitted in periods of no traffic every
15 minutes starting on the hour.
The message will consist of the general call in
first line, the Broadcast call sign, channel designator
digit and the serial number in the second line.
Refer par. 1.4 of ANNEX 5I of the IFB.
4.2.2.4 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Service messages will be of three types:
a) Precedural service messages are those messages
which are generated automatically by the MPF (in
certain cases based on supervisory decisions or
previously entered data) and transmitted on a BROADCAST
service channel or other BROADCAST or MRL channel(s)
according to tables, the contents of which may
be controlled by the supervisor. These messages
have been discussed in section 4.2.2.3. They are
listed in ANNEX 5I to the IFB. The general format
is ACP127 for BROADCAST (refer to table 4.2.2.1.2-1
and annex B) in the abbreviated plaindress version
but deviations from this format exist.
b) Formal service messages prepared interactively
on VDUs at the MPF and then converted, routed and
transmitted to the appropriate destination automatically
by the MPF. Refer to section 4.2.2.4.1 for details.
c) Service messages associated with the MPF/TRC or
MPF/TARE interface traffic control. These messages
are listed in ANNEX D and ANNEX N of the IFB, where
the texts correspond to the CPS/ICD/007 and CPS/ICD/004
interface documents for the CAMPS project, respectively.
4.2.2.4.1 F̲o̲r̲m̲a̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Service messages may be prepared at the MCSF terminal
and at the supervisory terminals.
Message generation consists of the following steps:
a) Guided by a menue or by direct selection the message
preparation format is presented to the user VDU
for the preparation session, which will consist
of two parts:
- message header preparation
- message text preparation
The selection of preparation format will determine
the conversion of the message after preparation,
i.e. conversion to Plaindress, Abbreviated plain
dress, or abbreviated service messages (the latter
only for messages to TRC and TARE).
A special format is provided for the supervisor
preparation of the kind of service messages, the
format of which may differ somewhat from the above
formats. These messages are prepared in the final
format for transmission with a separate additional
indication of routing mechanism: Channel selection
based on RIs or transmission on the BROADCAST service
channel.
The preparation format presented to the user has
protected areas with guiding information and non-protected
areas for parameter insertion.
Having entered the format the user will have to
wait only a short time for parameter validation,
which is syntactic and semantic (including validation
of addressees for existence).
After validation the header format is presented
again for possible editing; errors detected during
validation have been indicated. The message text
is free and not subject to validation.
Messages which are not released or forwarded for
release (refer b below) will be stored temporarily
and may be subject to later retrieval for editing
and release, or they may be deleted. Retrieval
will be based on the transaction ID presented to
the user during preparation.
Also assigned is a message item ID which may be
used for retrieval after release.
The supervisor will have the additional option
of having the prepared message stored as a preformatted
message which will be presented repeatedly for
editing and/or release on his request (a number
will be used as reference).
There will be a limit on the storage provided for
preformatted messages.
b) The execution of message release will depend on
the kind of user doing the preparation or editing.
1) Release at the MCSF and the supervisor position
will be performed at the end of the preparation
or edit session by entering the appropriate
release keywords assigned to the users.
2) A release request at the message service positions
will result in the presentation of the message
to the supervisor (in the preparation format)
for decision of release which is then executed
as in b1.
3) Non released messages are available for further
editing or deletion.
c) Messages are subject to conversion and routing
after release, the exception to this rule being
the messages prepared in final format (refer to
section a above).
Routing will except for transmissions via the Broadcast
Service Channel be based on PLAs or AIG/AG'S, (refer
to fig. 4.2.2.4.1-1.)
In case of AIG/AG'S the "exempted PLAs" will be
deleted from the PLAs extracted from the AIG(AG)/
PLA table.
Based on the PLAs the RIs will be isolated. The
channels for transmission will be identified as
part of the RI isolation (BROADCAST/MRL, refer
to section 4.2.2.3) or subsequently in the RI/channel
tables (TARE/TRC, refer to section 4.2.2.2).
Fig. 4.2.2.4.1-1
Flow of locally prepared messages are regards "addressing" scheme
The transmission format(s) will depend on the circuit,
i.e. whether the TARE/TRC or the BROADCAST/MRL
circuits are selected or both (refer to sections
4.2.2.2 and 4.2.2.3.)
d) Routing and/or channel assignment assistance will
be needed for messages where:
- no RI is found which corresponds to a PLA
- RI or channel does not have the proper classification
- selected channel is not open or status 0.
4.2.3 A̲d̲d̲r̲e̲s̲s̲i̲n̲g̲ ̲S̲c̲h̲e̲m̲e̲s̲ ̲t̲o̲ ̲b̲e̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲e̲d̲
A detailed discussion of the addressing (routing) schemes
associated with incoming and outgoing messages (relayed
or locally generated) have been presented in sections
4.2.1 and 4.2.2.
This section will present the identification parameters
associated with users, user terminals, and external
channels, and the related procedures.
Refer to fig. 4.2.3-1 for an overview.
The following identification parameters will be used.
a) External channels connecting the MPF to TARE, TRC,
SHIP-TO-SHORE, BROADCAST, MRL, or the OTHER MCs
are identified by a Channel Designator (CD).
Fig. 4.2.3.-1
Addressing data associated with external channels and terminal positions
CDs identify channel control tables; are used for
message accounting purposes for incoming messages,
and they are used for channel selection (RIs pointing
to CDs) for outgoing messages.
b) User terminals are identified by a Terminal Designator
(TD).
TDs identify terminal control tables (including
T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲r̲o̲f̲i̲l̲e̲s̲); they are used for transaction
accounting purposes and for message delivery.
Delivery of incoming messages to the MCSF, the
supervisor position, and any of the message servicing
positions is based on a set of RIs, each RI pointing
to one TD. A pseudo TD may exist thus allowing
common queuing for all message servicing positions
and the supervisor position for certain RIs.
c) Terminal Profiles will contain:
- classification/spec. handling categories
- User Identifications (UIDs)
- Functions of Terminal
d) User Profiles will contain:
- UID
- Password (PW)
- Release keyword (RKW)
- Classification/Spec. Handling Categories
- Functions of user.
User profiles will be matched to the terminal profiles
on user sign on. The combination of terminal and
user profile will be used for decision on delivery
of messages to terminals.
Log records will be marked with UIDs to enable
audit trails.
Each user will only be assigned to one terminal
(ROPs excluded) at a MPF site, the maximum number
of users being 25.
4.2.4 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The supervisor and the supervisory staff of the MPF
is able to control the main activities and the special
secure and reliable functions which are related to
terminal positions and associated operators.
The supervisory functions will be divided into three
categories:
- supervisor functions
- message service functions
- engineering functions
The man/machine interface for these functions as regards
commands and procedures in general is described in
ANNEX F. This annex also include a detailed description
of the VDU screen layout and associated dialog for
each of the appropriate commands and procedures. Use
of function keys are described as well.
ANNEX G provides the detailed layout of reports, including
warnings, presented to the VDU of the supervisor position.
A precedence ranking of all transactions originated
or received at supervisory position will be proposed
as part of system design.
4.2.4.1 C̲o̲m̲m̲a̲n̲d̲s̲,̲ ̲G̲e̲n̲e̲r̲a̲l̲
Supervisor commands are achieved by issuing a command
mnemonic code and filling out corresponding command
format. Completion of command format followed by entry
of the confirmation code will cause the execution of
the command.
a) V̲D̲U̲ ̲S̲c̲r̲e̲e̲n̲ ̲H̲e̲a̲d̲i̲n̲g̲
The MPF VDU's will show a permanent identification
of the key traffic related to the workstation.
Depending on the type of workstation, information
will be presented in the headlines of the screen.
The information is such as:
- time
- workstation function
- task in progress
- queued messages for either presentation, servicing,
screening or vetting per precedence.
b) C̲o̲m̲m̲a̲n̲d̲ ̲F̲o̲r̲m̲a̲t̲
After the mnemonic command code (two to eight characters
in length) has been issued, the corresponding command
format will be displayed. This command display
format contains optional and mandatory fields depending
on which command shall be carried out.
A suitable command language facilitates the access
and implementation of each command format which
is pertinent to the supervisor.
This section 4.2.4, Annex F, and section 4.3.5.1(VDU
facilities) provides detailed information on the
set of commands available and man/machine interface
facilities. Also refer section 2.3.
c) C̲o̲m̲m̲a̲n̲d̲ ̲E̲n̲t̲r̲y̲
Access to a command format can be gained by entering
the mnemonic command. For certain commands as specified
by the supervisor, the entry of a permissive entry
code is required. Data can now be entered to the
format and will be retained and displayed until
the format confirmation code is entered. Characters
or entries in format can be deleted or changed
before command completion.
A command can be cancelled at any point before
the command completion with the result that no
action will be performed.
d) C̲o̲m̲m̲a̲n̲d̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
A command will be executed when a confirmation
code has been entered. Unacceptable commands or
formats will be returned to the display with an
indication of the erroneous field. The field can
then be altered as described under command entry,
and the format re-entered for new validation.
Response time to release of command or validation
of the command will be within 1 second for 99%
of all cases and 2 seconds for the remainder.
Accepted commands will be executed and a command
acknowledgement returned. This command acknowledgement
will include the execution time in case the execution
time is less than 10 seconds.
The command acknowledgement will be printed out
on the system log.
e) S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲c̲o̲m̲m̲a̲n̲d̲
The operators at the VDU terminals will have the
facility to suspend transactions entered by a command.
When suspend is requested the transaction in progress
is terminated and new commands leading to new transactions
may be entered. While a function is suspended,
the MPF will remind the operator of the incomplete
transaction in a dedicated field of the VDU.
In order to adjust the use to the actual situation
and for to take into account security considerations
(suspended transactions might be continued by unauthorized
operators) the suspend function will have different
effect according to the transaction in progress.
The VDU transactions, in this respect, can be divided
into three categories:
- message entry transactions (operator entry
of data)
- message presentation transactions (no entry
of data)
- request transactions (i.e. sign on/off security
procedures, retrieval, status requests, table
updates).
Suspend in connection with message entry transactions:
The suspended transaction will be interrupted in
such a way that it later may essentially be resumed
from the point at which it was interrupted.
Suspend in connection with message presentation transactions:
If the suspend function IS entered when a message
is displayed on the screen, the message is returned
to the display queue. When later accessed, presentation
will be commenced with display of the first page.
Suspend in connection with request transactions:
It will not be valid to enter the suspend function,
when a request transaction is in progress. This
event will cause an error message.
4.2.4.2 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
A number of supervisor control functions make the supervisor
fully able to control the MPF. Those control functions
are compliant with all requirements stated.
The following sections will describe all the commands
for the different supervisor functions, which are:
- supervisor command control
- message control
- terminal control
- operator control
- external connection control
- supervisor print control
- off-line storage control
- security/warning control
- special handling control
a) S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
PROTECT/UNPROTECT COMMAND specifies whether a command
shall be protected or not.
DISPLAY AND UPDATE RESTRICTIVE EFFECT COMMAND LIST.
This command displays the restrictive effect command
list and enables the supervisor to alter the restrictive
warning text of a command.
MONITOR COMMAND enables the supervisor to select
commands to indicate which application he requires
to be monitored. The MPF will maintain a list of
currently applied commands together with the time
of application.
This list is periodically or on request displayed
on the supervisor's terminal.
b) M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
MODIFY SYSTEM TABLE Command enables the supervisor
to display, modify and print the contents of following
tables:
- PLA table
- AIG table
- AG table
- External RI table
- Local RI table
MODIFY ACP 127/126 (mod) command enables the supervisor
to modify already existing values which are associated
with the ACP127/126 (mod) format parameters. Refer
appendix I annex A and B for candidate parameters.
RESET COUNTER command enables the supervisor to
reset the following counters to 0001:
- system print control number which is common
to all hardcopy reception terminals
- special handling category control number which
is common to all hardcopy reception terminals.
c) T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲
The supervisor is able to display and update the
terminal profile parameters associated with each
terminal by use of following commands:
SELECT TERMINAL CAPABILITY. The terminal capabilities
can be selected for:
- message reception
- message preparation
- message release
- message service
SELECT TD AND CLASSIFICATION specifies the terminal
designator and the highest classification for each
local terminal.
SELECT OPERATOR IDENTIFICATION specifies the operators
which may sign in at each local terminal.
SELECT TERMINAL IDENTIFICATION specifies the equipment
identification for each local terminal, and terminal
characteristics.
BLOCK/UNBLOCK TERMINAL specifies which terminal
to be blocked or unblocked.
DISPLAY QUEUE LENGTH specify that the queue length
per precedence for a terminal shall be displayed.
DISPLAY OPERATIONAL STATUS specifies that the operational
status of the terminal will be shown (in service
or out of service).
d) O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
By use of the operator command the supervisor is
able to control the MPF operators, i.e. their profiles.
SELECT OPERATOR CAPABILITY selects the capability
of the operator, i.e.
- message preparation
- message release
- message service
SELECT OPERATOR CLASSIFICATION specifies the highest
classification the operator may handle.
SELECT PASSWORD, KEYWORD specifies the operator
password and, in case he has release capability,
his keyword and validation duration time.
PRINT OPERATOR PROFILES initiates the print of
all operator identifications, passwords and possibly
keywords. The command will be protected by default.
e) E̲x̲t̲e̲r̲n̲a̲l̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
By use of this set of commands the supervisor is
able to control the following external channels,
on a channel by channel basis:
- Ship-To-Shore
- MRL
- Broadcast
- NICS-TARE
- TRC
- Standby MC
SELECT CHANNEL DESIGNATOR specifies the terminal
designator and whether it is incoming or outgoing
for the channel.
SELECT TRANSMISSION SERIAL NUMBER specifies whether
the transmission serial number type shall be 001
through 999 or 0001 through 9999 per channel.
SELECT RESET SCHEDULE specifies when the TSN shall
be reset, i.e. either daily or by wrap around.
SELECT CHANNEL CLASSIFICATION specifies the highest
classification of messages which may be transmitted
over the channel.
CHANNEL SERVICE MESSAGE selects the periodicity
and parameters for the channel service message.
DISPLAY QUEUE LENGTH specify that the outgoing
channel queue per precedence concerning message
awaiting to be transmitted, will be displayed.
DISPLAY PRECEDENCE RESTRICTION specify that the
precedence restriction in force will be displayed.
f) S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲P̲r̲i̲n̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
The supervisor will be able to control the supervisor
print by use of following commands:
SELECT PRINT OR ORF specifies if supervisor data
shall be printed in real time or stored on the
outstanding report file (ORF) for each category
of print.
SELECT ROP specifies which of the Receive Only
Printers ROP's that shall be associated with the
supervisor position.
g) O̲f̲f̲l̲i̲n̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
By use of these commands the supervisor is able
to control the offline storage.
PERFORM OFFLOAD specifies that messages more than
seven days old will be dumped to the off-line volume.
STOP DUMP specifies that a previously incarnated
dump shall be stopped.
OFFLINE RETRIEVAL OFF specifies that offline retrieval
is intermediately impossible.
LIST VOLUME TABLE specifies that the table which
contains volumes and time intervals will be displayed.
Further offline storage commands will be included
as agreed between contractor and purchaser.
OFFLINE RETRIEVAL OFF specifies that off-line retrieval
is temporarily impossible due to use of off-line disk
for other purposes or due to the execution of mounting
procedures for an off-line retrieval volume.
h) S̲e̲c̲u̲r̲i̲t̲y̲ ̲W̲a̲r̲n̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲
Following commands exist for the supervisor to
control the security warnings:
SELECT SECURITY WARNING LEVEL specifies the classification
to be selected, above which the security warning
text shall be displayed.
SELECT SECURITY WARNING TEXT displays the security
warning text and associated response code to be
updated.
i) S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲
The supervisor is able to initiate and change up
to a maximum of 20 special handling designators.
An online menu exists for modifying the contents
of the special handling table.
4.2.4.3 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Handling of service messages by supervisor is facilitated
by use of following commands and functions:
- Reception of service messages
- Preparation and editing of service messages
- Release of service messages for transmission
- Storage of service messages
- Retrieval of service messages
4.2.4.4 M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Retransmission of previously stored outgoing message
by supervisor can be achieved by use of the following
tools
- Retrieval of identified message
- Automatic pilot generation
- Release and transmission of message
4.2.4.5 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲D̲a̲t̲a̲ ̲P̲r̲i̲n̲t̲
Supervisory reports, statistics and system log will
be printed at the supervisor printer, if specified
by supervisor. The printout is queued on a First In
First Out basis.
4.2.4.6 M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲i̲n̲t̲
Messages will be printed at low speed, when requested,
at the printer position specified by the supervisor.
Message will be queued on a FIFO basis and will be
either printed every 30 minutes, or upon request in
real time.
The message printed out on hard-copy will be paged
and sized as specified by the supervisor.
4.2.4.7 M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲
The message service positions will be fully compliant
to support the requirements related to their positions.
a) M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Messages sent for message service will be queued
per precedence level and per type, i.e. either
incoming or outgoing. Messages without recognizable
precedence level will be queued with IMMEDIATE
precedence. Message will be displayed in the format
in which the message is received or transmitted.
The message displayed includes an indication of
reason why the message has been sent for servicing:
- Garble correction
- RI assignment
- Entry of channel information
- Group count assignment (if required, for encrypted
messages).
Detection of errors will be performed during the
incoming ACP127/ACP126(mod) analysis by inspection
of the format lines.
Both the original and the corrected version of
the message will be stored on disk. An entry will
be supplied in the message log with sufficient
details to ensure complete accountability for all
messages sent for message service.
b) M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The workload of the message service position will
depend on the amount of automatic processing being
possible/allowed and the nature of the interactive
procedures provided in those cases where message
service is necessary.
The incoming message reception and analysis is
directed towards parameter isolationa and not fault
finding except when it concerns security parameters.
This is illustrated by the tables 4.2.1.2.1-1,
4.2.1.2.2-1, 4.2.2.1.1-1, and 4.2.2.1.2-1. Documents
like annex b have been worked out and agreed upon
with the camps system. Likewise, we expect to discuss
with the crossfox purchaser the importance of the
format line parameters in order to determine which:
1. have to be correct
2. may be corrected automatically by the mpf system
based on redundandant information
3. may be left incorrect in the message
Category 1 in the above list should preferably be limited
to security and routing/distribution parameters. Since
only parameters belonging to the categories 1 lead
to presentation for message service in this context.
The minimization of parameters in this category will
be pursued.
The following procedures are necessary in order to
fullfill specific requirements and specifically designed
to execute those functions with a minimum of manual
interaction. The use of the garble correction procedure
will be limited to a minimum.…86…1 …02… …02… …02… …02…
- Service message handling (refer 4.2.4.3)
- Request of message from the incoming message
queue
- Request of message from the outgoing message
queue
- Correction procedure according to the previously
mentioned reasons for message service. For
the garble correction procedure, lines with
garbled characters will be highlighted.
- Entry of routing indicators for messages.
- Vetting/screening of messages and associated
procedures for message filing with and without
retransmission (refer section 4.2.2.2.b and
4.2.1.2.1.g).
- Entry of channel information for messages
- Message retransmission preparation.
- Initiation of automatic generation of retransmission
request (service message)
- Print of message and/or VDU page.
The management of Ship-to-Shore circuits resides as
one of the supervisor capabilities.
The management of ship-to-shore circuits resides as
one of the supervisor capabilities, which, however,
may be delegated to the message service positions.
4.2.4.8 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲R̲e̲p̲o̲r̲t̲s̲
Report will be produced to draw the attention of the
supervisory staff to the following events:
- warning reports
- channel status reports
- queue status reports
- command completion reports
- security reports.
Each report will contain the following information:
- identification of the report
- time of occurrence of the reported event
- event description
- recommended action, if possible
Each report format will be subject to agreement by
purchaser during design print out on the supervisory
printer will be preceeded by "BELL" signal.
Each report will be either printed out or stored in
the ORF for later print.
Printing reports from the ORF will be performed in
groups of maximum 30 reports or every 30 minutes to
be agreed by the purchaser.
Entries in the system log will be made for each report
a) O̲u̲t̲s̲t̲a̲n̲d̲i̲n̲g̲ ̲R̲e̲p̲o̲r̲t̲ ̲F̲i̲l̲e̲
The outstanding report file (ORF) may consist of
up to 10 separate addressable files containing
reports related to, for example,channel status,
traffic activity, storage loading, message statistics,
security, etc. Each file will be able to retain
up to 24 hours of traffic after which the oldest
is overwritten. Procedures which may be performed
by the supervisor on the ORF are:
- CREATE AND NAME FILE creates a new file and
names it. The file can now be used for the
specified report type.
- DISMANTLE FILE specifies that the file is dismantled
with the result that the entries are deleted
and this type of report will not be stored
in ORF.
- CLEAR FILE specifies that all entries in the
file are deleted. The file is ready for receiving
new reports.
- PRINT ORF selects type of report in ORF and
the print mode. The print mode is either in
groups of maximum 30 reports or every 30 minutes.
b) W̲a̲r̲n̲i̲n̲g̲ ̲R̲e̲p̲o̲r̲t̲s̲
Warning Reports will be generated by MPF supervisor
commands individually or periodically to draw the
attention of the supervisory staff to specific
events related to management of the system.
Warning reports will be queued for print out as
they occur at one of the Receive Only Printers
(ROPs), specified by the supervisor.
The supervisor will have facilities for specifying
types of reports which shall be retained for printing
out in batches of 30 reports or printed at specified
time.
Warning reports will be retained at least 24 hours
after their generation.
The supervisor will be able to trace warning reports
individually by type and serial number, and all
reports of a given type to a specified time. Warning
report will be of following types:
- Table, queue or message file capacity exceeding
preset threshold values.
- Preemption on external channels requiring supervisory
action for retransmission of preempted messages
- Receipt of 100 characters on an incoming channel
after EOM, but without detection of SOTF.
- Occurrence of halt in transmission to MPF of
a message for more than 5 or 30 seconds on
medium speed and low speed channels respectively.
- Receipt of more than 50 identical consecutive
characters over a channel (except for data
messages identified by format line 4)
- Non-receipt of Flash acknowledgement message
within required time.
- System being unable to find a channel available
for transmission.
- Mounting of off-line storage media required
for retrieval.
c) C̲h̲a̲n̲n̲e̲l̲ ̲S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲
Channel status reports will be produced by the
MPF for each channel upon occurrence of following
events:
- Discontinuity of incoming messages.
- Missing transmission serial numbers in incoming
messages.
- No service messages received within the period,
starting at 23:45 and ending 00:15 hours, on
those channels specified by the supervisor.
- A message prematurely terminated.
- Receipt of incoming messages exceeding a length
of 12000 characters.
d) Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲s̲
The supervisor will have facilities for requesting
a queue status report. Contents of this report
are:
- For each internal channel: total queue length
of message/transaction to be delivered
- For each external channel: total queue length
for outgoing messages to be transmitted.
e) C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲R̲e̲p̲o̲r̲t̲
Upon each supervisor command completion, the system
will generate a command completion report.
f) S̲e̲c̲u̲r̲i̲t̲y̲ ̲R̲e̲p̲o̲r̲t̲s̲
A security report will be generated upon occurrence
of the following events:
- unsuccessful sign-on attempt
- unsuccessful security interrogation, whether
due to time-out or faulty password
- unsuccessful release keyword entry by release
operator during release procedure
- attempt by the system to transmit messages
in classification/special handling category
not permitted on channel
- unsuccessful system integrity check.
4.2.4.9 E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲
a) E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲,̲ ̲G̲e̲n̲e̲r̲a̲l̲
The engineering position consists of a VDU and
an associated printer, separate from the supervisory
position. The responsibilities of the engineer
are mainly to control the hardware components and
handle error situations. The responsibilities of
the engineer are mainly to monitor and control
from this position the system components and handle
error situations. The monitor and control of the
system queues, routing tables, etc. are handled
by the supervisor.
b) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲
The Processor Units and the watch-dog assembly
in coorporation will facilitate the execution of
on-line automatic selfdiagnosis based on equipment
monitoring and the analysis of software completion
codes. Special emphasis will be put an fault isolation
and performance degradation evaluation in connection
with periferal equipment. Consequent automatic/semiautomatic
reconfiguration actions are described in section
4.2.4.9.c). Further to the selfdiagnosis (and possibly
as a result of a diagnostics report) the operator
at the engineering position may start the execution
of automatic on-line test programs which will not
interrupt the normal operation of the system. Same
programs may be run at the redundant PU (status
changed from operationa to off-line or from stand-by
to off-line) and will include the execution of
test of off-lined periferal equipment.…86…1
…02… …02… …02… …02…
c) R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The detection of a fault condition will result
in the automatic withdrawal of the faulty equipment
from service and in many cases switch over to redundant
units. A report is always issued at the printer
of the engineering position with details concerning
the possible need for operator intervention. The
needs for manual intervention are reduced to a
minimum and in any such case the report will suggest
the procedure to be used. The operator at the engineering
position will have the facilities to specify equipment
switchover and/or the withdrawalin an orderly way
of equipment from service as a result of possible
error/degradation indications, need for maintenance,
or other purposes. System monitoring will be performed
automatically to ensure the existence of at least
the minimum configuration for maintaining proper
service, such as the continuation of message accountability.
In case of violations a report will be issued to
the engineering position.
Optionally it is possible to select the supervisor
position for output of diagnostics information/error
reports and the execution of reconfiguration commands.
The supervisor position is in any case backup in
case of faults at the engineering position.
The operator at the engineering position will have
the facilities to specify equipment switchover
and and/or the withdrawal in an orderly way of
equipment from service as a result of possible
error/degradation indications, need for maintenance,
or other purposes. System monitoring will be performed
automatically to ensure the existence of at least
the minimum configuration for maintaining proper
service, such as the continuation of message accountability.
In case of violations a report will be issued to
the engieering position.
d) S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲
The software development facility will be provided
on both the active MC or at the alternate MC.
The equipment used on both the active and the alternative
MC will be the engineering position working on
the standby computer. Tools available to the engineer
includes editor, compiler, linker, floppy disk,
etc. For security reasons only engineers with
software development clearance will be able to
sign in for software development.
The modified system software is loaded into the
standby processor at both the active and alternative
MC. A manual switchover at the active MC will
bring the modified software into operation.
The engineer may de-assign equipment for maintenance
or other purposes. The MPF will then check that
normal operation can continue without loss of message
accountability.
e) O̲t̲h̲e̲r̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Commands related to the engineering position are
the following:
- CLOSE DOWN specifies that the MPF will close
down in an orderly fashion without loss of
stored data or messages.
- RESTART specifies that the MPF activities will
be restarted in a well defined way.
- PRINT DATA is a supervisor command as described
under the supervisor functions, section 4.2.4.6.
- GENERATE TRANSMISSION TEST MESSAGE specifies
that a transmission test message will be generated.
- TRANSMIT TRANSMISSION TEST MESSAGE specifies
that a test message will be transmitted over
a specified channel
- ASSIGN CHANNEL specifies that a specified channel
may be used for traffic
- DE-ASSIGN CHANNEL specifies that a specified
channel is not available for normal traffic
- MONITOR CIRCUIT specifies that a selected circuit
will be monitored
Detailed definitions of engineering functions and
commands will be provided by the contractor.
4.2.5 L̲o̲g̲g̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The message and accounting function, i.e. log function,
has the overall responsibility for the accounting in
the CROSSFOX operational software.
The logging function will perform the collection of
log records related to transmission and reception of
messages, transactions on terminal devices, for the
alerting of supervisory staff and system fault condition.
Log records will be printed on the supervisor's printer
and may be retrieved for inspection.
a) M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲
The message log will include records of received
and transmitted messages. The log records are collected
when the appropriate action has been performed.
Contents of log records are an identification of
the message sent or received and time of transmission
or reception.
b) S̲y̲s̲t̲e̲m̲ ̲L̲o̲g̲
The system log will include records of the supervisor
reports, such as warning reports, channel status
reports, queue status reports, command completion
reports and security reports. Further, log records
for retransmission request, system messages alerting
supervisory staff and system fault conditions,
regardless whether the supervisor is alerted or
not will be included. The contents of the log record
will be an identification of the report and time
of generation.
c) L̲o̲g̲ ̲P̲r̲i̲n̲t̲o̲u̲t̲
Log records will be queued for printing at the
supervisor assigned printer and printed if the
supervisor has requested printout. Otherwise the
log records will be stored on the outstanding report
file (ORF).
d) L̲o̲g̲ ̲R̲e̲c̲o̲r̲d̲s̲ ̲L̲a̲y̲o̲u̲t̲,̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
The contents of each log record will be sufficient
to ensure accountability.
The storage of log records will be implemented
suitable for a later retrieval mechanism. Contractor
will develop the storage procedure.
The log records stored may be retrieved by the
supervisor.
For message log records following sets of retrieval
keys are available:
- channel
- time interval
- message type, incoming or outgoing
and
- terminal
- time interval
- terminal procedure.
For system log records following retrieval key
is available:
- report type
- time interval
e) L̲o̲g̲ ̲R̲e̲c̲o̲r̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲f̲o̲r̲ ̲A̲c̲c̲o̲u̲n̲t̲a̲b̲i̲l̲i̲t̲y̲
The supervisor will have following additional trace
facilities to be able to achieve message accountability,
across the MPF
- retrieve the last log entry recorded
- retrieve the log entries within a specified
period of time, for which an initial log record
exists but not a final log record.
4.2.6 S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The CROSSFOX statistical module will contain all the
current and historical information necessary to comply
with the statistical reporting requirement. Information
which must be retained for hourly daily and weekly
periods will be collected, accumulated and stored by
the statistical maintenance module.
Statistical data on messages received and transmitted
on channel traffic and system actions will be recorded.
Print-out of hourly, daily and weekly statistical data
will be on the supervisor's printer.
4.2.6.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Statistical data will be maintained for each incoming
channel.
a) P̲e̲r̲i̲o̲d̲i̲c̲i̲t̲y̲
The incoming message statistics will be generated
for:
- the current day for each complete hour from
0001 hours
- the previous day
- each week with a predefined starting day for
the last four weeks
b) M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
The information maintained for each channel will
be:
- number of messages received (operational and
service)
- number of messages received by each precedence
level
- number of messages received by each security
classification category
- number of messages received by each special
handling category.
- number of messages routed to message service.
- number of service messages received.
4.2.6.2 T̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Statistical data will be maintained for each outgoing
channel.
a) P̲e̲r̲i̲o̲d̲i̲c̲i̲t̲y̲
The same as for incoming messages, refer 4.2.6.1a
b) M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
The same as for outgoing messages, refer 4.2.6.1
b.
4.2.6.3 S̲t̲o̲r̲a̲g̲e̲ ̲O̲c̲c̲u̲p̲a̲n̲c̲y̲
Storage occupancy with respect to messages is defined
as the percentage of allocated message storage capability
which is occupied. It will be maintained.
a) P̲e̲r̲i̲o̲d̲i̲c̲i̲t̲y̲
The storage occupancy will be returned and printed
on the supervisor's printer at the supervisor's
request.
b) M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
The storage occupancy maintained will be for the
previous hour. Upon request the previous hour's
occupancy and the current hour to time of request
occupancy will be delivered.
4.2.6.4 C̲h̲a̲n̲n̲e̲l̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Statistical data will be maintained to be able to calculate
the channel availability.
a) P̲e̲r̲i̲o̲d̲i̲c̲i̲t̲y̲
The channel availability will be generated for:
- each hour, for the current day
- each day, for the previous seven days.
b) M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
The information maintained is the channel open/close
time.
4.2.6.5 S̲y̲s̲t̲e̲m̲ ̲A̲c̲t̲i̲o̲n̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Statistical data will be maintained concerning supervisory
reports on a per type basis.
a) P̲e̲r̲i̲o̲d̲i̲c̲i̲t̲y̲
The supervisor report statistics will be generated
for:
- each complete hour for the current day
- the previous day's total
b) M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
The number of messages generated per supervisor
action.
4.2.6.6 S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲R̲e̲p̲o̲r̲t̲ ̲F̲o̲r̲m̲a̲t̲
Refer ANNEX E for an example of a statistical report
for the incoming message statistics.
Refer Annex E for the format of the statistical report
for each of the above categories.
4.2.7 S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The message storage and retrieval module will maintain
a historical data base on the mass storage of the CROSSFOX
file management system. A catalogue will ensure the
accountability and security of the messages and transactions.
The mass storage covers both online and offline storage
media. Online covers at least a period of 7 days, offline
a period of at least 30 days.
4.2.7.1 S̲t̲o̲r̲a̲g̲e̲
a) S̲u̲b̲j̲e̲c̲t̲ ̲t̲o̲ ̲S̲t̲o̲r̲a̲g̲e̲
Following messages will be stored:
- incoming messages after analysis according
to ACP127 or ACP126 (modified) procedures except
for CTS and ATOMAL messages. If message is
sent for correction both the garble and corrected
versions will be stored
- service message received and generated except
for the automatically generated service messages
- message locally generated and released
- outgoing (retransmitted) messages
b) S̲t̲o̲r̲a̲g̲e̲ ̲M̲e̲d̲i̲a̲
Message will be stored online and offline. Messages
will reside online for at least 7 days from the
time of receipt.
After seven days messages will be offloaded to
offline storage media where they will reside for
at least 30 days.
Concerning the requirement for 20% spare capacity:
Refer to section 1.2.2.
c) S̲t̲o̲r̲a̲g̲e̲ ̲K̲e̲y̲s̲
Storage keys will be kept in a catalogue to be
able to execute a later retrieval.
4.2.7.2 R̲e̲t̲r̲i̲e̲v̲a̲l̲
a) The previously stored messages can be retrieved
from either online or offline
Storage media. Retrieval can be requested by either
the supervisor manually or automatically by a received
service message. The format of this message shall
for ACP 127 be of type abbreviated service message
(FL1, 2, 3, 4 and 5 only) with a suitable and
easely detectable text in format line 5. A similar
format is proposed for an ACP 126 service message.
The final layout is subject to agreement with purchaser.…86…1
…02… …02… …02… …02…
b) R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲K̲e̲y̲s̲
The sets of retrieval keys used by supervisor or
message servicing operators are:
1) internal message number
2) - channel identification
- transmission sequence number
- time of (TOF)
3) - originating station routing indicator
- time of file (TOF)
4) - action addressee (TO) (automatic retrieval)
- DTG
5) - channel identification
- time of file window (TOF window)
The complete list of retrieval keys will be determined
by purchaser and contractor during requirement
validation phase.
The time of file (TOF) will be assigned by the
MPF storage function when the message is sent for
storage.
The date time group (DTG) is the release DTG without
Zone Suffix derived from format line 5 of the ACP127
ACP126 (mod) formats.
c) R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲R̲e̲s̲u̲l̲t̲
A retrieval request will result in a retransmission
or a local display of the message. If requested
by a service message the message will be retrieved
if it is online resident, and the originator is
one
of the addressees of the message, otherwise the
service message will be displayed at the supervisor's
terminal. In case retrieval for retransmission
takes place automatically a suitable report will
be forwarded to the supervisors terminal informing
the supervisor of performed retrieval and retransmission.
Data messages are only retrievable for retransmission
and will not be displayed locally.
d) R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲T̲i̲m̲i̲n̲g̲.
Retrieval from the online storage media for message
display or retransmission will not exceed 10 sec.
Retrieval from off-line storage media will not
exceed 10 minutes including the time for volume
mounting. The time alotted for volume mounting
assumes the presense of volume in easy accessable
location and will then not exceed 5 minutes.
e) R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲C̲a̲t̲a̲l̲o̲g̲u̲e̲s̲
Retrieval catalogues will contain retrieval keys
collected during storage of messages. A possible
suitable file or catalogue structure will be fully
described in section 4.6.3.3.
4.2.8 S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
4.2.8.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Initialization is the process of bringing the system
into operational use without recovery.
Three types of initialization may be used:
D̲E̲A̲D̲1̲:̲ For the very first start of the system
from an offline disk with the initial system
parameters.
D̲E̲A̲D̲2̲:̲ From an offline disk containing updated
system parameters reflecting the state
of tables at the time of the latest OFF-LOAD
(ref. IFB sec. 5.1.2.8.4).
This type start-up makes use of mirrored,
on-line disks that are preformatted (cleared)
prior to the initialization process.
C̲O̲L̲D̲:̲ From one of the mirrored on-line disks.
This is based on the current system parameters
and includes the proper purging of the
historical data base.
Once a DEAD-start has been performed, the MPF site
software package will be available on the mirrored
on-line disks for future COLD-starts or recovery
situations.
The data held on-line will initially be from the
appropriate off-line MPF site software package.
As described under "DEAD" and "COLD", the system
will be initialized with an empty, historical data
base.
As for the MPF site software package, the LSDB
will be established as well.
The maximum duration of initialization from an
off-line disk will not exceed 5 minutes.
The initialization Procedure will progress as follows:
Having switched on the power, the supervisor must
make sure that the proper disks are physically
mounted, i.e.:
- on the "off-line drive" should be mounted the
original system-parameter-disk or a disk containing
an off-loaded version for DEAD1 and DEAD2,
respectively.
- on the mirrored on-line drives should be mounted
a set of cleared and preformatted disks or
just the currently used on-line disks for DEAD
or COLD, respectively.
He then presses the "start" button on the disk
drives where a disk is mounted, and he presses
the "reset" button on the watchdog processor and
on the Processing Units. Thereafter he can interactively
choose the appropriate start-up type from the watchdog
console (Engineering Position). When initialization
is finished he will be notified.
4.2.8.2 L̲o̲c̲a̲l̲ ̲S̲y̲s̲t̲e̲m̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲(̲L̲S̲D̲B̲)̲
The LSDB contains the appropriate values of system
parameters and address and routing information and
is administered by the "Table Management Package".
4.2.8.3 S̲t̲o̲r̲a̲g̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲S̲/̲W̲ ̲a̲n̲d̲ ̲D̲a̲t̲a̲ ̲R̲e̲q̲u̲i̲r̲e̲d̲ ̲f̲o̲r̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The means and the media used for the standard procedures
have been described above, i.e. a procedure where the
software resides on the off-line disk drive.
New software versions or data may be loaded/stored
from Off-line disk or floppy disk. The storage arrangements
employ the use of various checks e.g. Cyclic Redundancy
Check to detect corruption of data.
Once loaded, the data is available on-line.
4.2.8.4 S̲t̲o̲r̲a̲g̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲r̲o̲g̲r̲a̲m̲m̲e̲ ̲a̲n̲d̲ ̲C̲u̲r̲r̲e̲n̲t̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲.̲
It will be possible to "OFF-LOAD" these data as required.
This can be performed periodically, but we recommend
that the supervisor be notified periodically and that
the off-load command will then be issued by a deliberate
action. The off-loading is a back-ground activity (low
priority process), which will not impact the concurrent
normal processing. The transfer is basically a transfer
from on-line to off-line storage media.n.
4.2.9 R̲e̲c̲o̲v̲e̲r̲y̲
Extensive use of checkpointing to the two mirrored
disks is employed.
The processing flow of the message processing system
consists of a well defined set of successive steps
where output for one step serves as input for one or
more succeeding steps.
In a message related checkpoint, the state resulting
from a step is recorded so that the processing can
be repeated and continued from the latest step initiated
before the failure. The message checkpoints will make
it possible to recover all necessary information about
the various incarnations of a message and to recover
"application process data" concerning queue status,
for example.
4.2.9.1 I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
As the recovery information in the normal mode of operation
is recorded on both on-line disks it will only be lost
(at that site) in case of corruption of both disk packs.
To minimize this risk the MPF is equipped with the
following facilities:
- separate power supplies to redundant units.
- system integrity is verified through checksumming
of read-only system software; this is done periodically
and on request.
- Cyclic Redundancy Checks and Read-after-Write is
incorporated into the storage procedure to ensure
the detection of corrupted data.
The messages are kept in acknowledged checkpoints
to the mirrored disks. So, whenever an incarnation
of such a message is being handled, it is very
unlikely that the message will be lost due to H/W
faults.
The probability that a message is lost, wholly
or in part, misdirected, or corrupted as a result
of equipment error, will be less than 1 in 10…0e…7…0f….
4.2.9.2 S̲c̲o̲p̲e̲ ̲o̲f̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
The MPF recovery procedures will comply with the IFBs
requirements.
4.2.9.3 R̲e̲c̲o̲v̲e̲r̲y̲ ̲P̲o̲i̲n̲t̲s̲
The checkpointing philosophy will determine the extent
to which information is recoverable. The following
two methods of checkpointing will be employed:
a) checkpointing of log records containing an extract
or a pointer the corresponding transaction is checkpointing
itself, refer b) below). Checkpointing is performed
after 5 log entries or every 30 sec., whichever
comes first.
b) direct checkpointing of the transaction is performed
in case of messages. The checkpointing mechanism
to message data of received and stored messages
(including partly received) will that no such data
will belost, and no data from a partly finished
message preparation session lost.
4.2.9.4 R̲e̲c̲o̲v̲e̲r̲y̲ ̲P̲r̲o̲g̲r̲a̲m̲m̲e̲
The system will be designed to minimize the need for
operator intervention. For that purpose, a number
of different recovery levels are used.
a) A̲f̲t̲e̲r̲ ̲p̲a̲r̲t̲i̲a̲l̲ ̲f̲a̲i̲l̲u̲r̲e̲s̲
This group of errors call for automatic recovery.
The site will become or stay operational without
operator intervention. However, the operator will
be notified and may have to take action to replace
and/or test redundant equipment.
b) A̲f̲t̲e̲r̲ ̲o̲r̲d̲e̲r̲e̲d̲ ̲c̲l̲o̲s̲e̲d̲o̲w̲n̲
The supervisor may deliberately have performed
an ordered closedown. In that case the supervisor
actions required for restart are very similar to
those of COLD-start.
c) A̲f̲t̲e̲r̲ ̲a̲ ̲t̲o̲t̲a̲l̲ ̲s̲y̲s̲t̲e̲m̲ ̲e̲r̲r̲o̲r̲ ̲
Recovery based on the latest uncorrupted checkpoints
and historical data base is possible.
4.2.9.5 R̲e̲c̲o̲v̲e̲r̲y̲ ̲A̲c̲t̲i̲o̲n̲s̲
F̲o̲r̲ ̲a̲n̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲s̲y̲s̲t̲e̲m̲
Operator intervention may be needed to re-establish
full redundant backup.
The actions include reconfiguring (e.g. requesting
"degraded availability mode"), repair, testing and
verification as appropriate. Afterwards the "normal
mode" should be set via the operator console.
F̲o̲r̲ ̲a̲ ̲n̲o̲n̲-̲o̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲s̲y̲s̲t̲e̲m̲
Here the recovery action calls for two stages of operator
intervention:
1) Repair/testing and verification of the appropriate
parts of the configuration.
2) Initiation of the restart procedure.
Facilities exist for thorough testing of the validity
and integrity of stored data, system S/W, and H/W components
(refer to diagnostic software).
Initiation of the restart procedure requires mounting
and starting of one or both mirrored disks, resetting
of the PU(s) and specification of the restart category
(the latter being a sigle command/from the operators
console). Further actions are automatics.
When the system is ready, a security interrogation
procedure will have to be performed at the terminals
(for security reasons).
4.2.9.6 C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲a̲f̲t̲e̲r̲ ̲F̲a̲i̲l̲u̲r̲e̲
Message traffic continuity after failure will be ensured
in a manner which depends on the failure category as
follows:
a) A total system failure involves the loss of traffic
data base, partly or in full, up to the time of
failure. In this case a service message is sent
to the alternate MPF requisting the transfer of
its data base, System users will be informed of
the status concerning messages in preparation at
this MPF as soon as the data base has been established.
b) Other failures, where the historical database is
intact to the moment of failure, will result in
the following recovery actions:
- transmission of not fully transmitted outgoing
messages with new transmission sequence number.
- resumption of retransmission of not yet transmitted
relay traffic.
- retransmission of messages of the highest precedence
levels for which receipts are still pending
(the possible recovery of receipts as a result
of retransmission requests (refer below) will
be ignored and the duplicate nature of the
message will be indicated).
- the supervisor may inhibit the retransmission
of relay traffic received earlier than a specified
point in time. He may also prevent retransmission
on basis of addressee, routing or precedence.
Each message thus treated will result in a
log entry with suitable annotation.
- system users will be informed of the status
of messages in preparation at this MPF..
4.2.9.7 C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲ ̲o̲f̲ ̲S̲t̲o̲r̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Messages, log data and statistics stored prior to failure
can be recalled in the normal way after failure.
4.2.9.8 C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲ ̲o̲f̲ ̲t̲h̲e̲ ̲r̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲s̲y̲s̲t̲e̲m̲ ̲
The reporting system continuity is essential for the
maintenance after message accounting system in so far
that lack of reporting in case of a discontinuity in
the message sequence numbering might lead to loss of
a message in case retransmission (based an automatic
service message request or manually) is not initiated.
However, a sequence numbering and annotation of all
reports will support the detection of missing reports,
and a following log trace or retrieval action will
then reveal any discontinuities this may then result
in retransmission requests.
4.2.9.9 C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲D̲a̲t̲a̲.̲
All such tables will have a well defined state so that
a failure occurring during update/reorganization will
not lead to ambiguity. System data tables will be residing
on dual disks which in connection with frequent back-up
of dynamic system data to the same disks will provide
the continuity in recovery situations.
4.2.9.10 R̲e̲s̲u̲m̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲l̲o̲c̲a̲l̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲ ̲a̲f̲t̲e̲r̲ ̲f̲a̲i̲l̲u̲r̲e̲.̲
Transactions at local, supervisory workstations may
be resumed at the latest well defined checkpoint depending
on the nature of the failure.
However, we propose that a renewed security interrogation
be performed.
A notification as described in the IFB will be performed.
4.2.10 M̲C̲-̲H̲a̲n̲d̲l̲i̲n̲g̲
This is a common name for the functions related to
the communication with the alternative site.
The MC-Handling at a particular site utilizes one of
two different sets of functional capabilities.
The set to be used depends on the present state at
that site: Controlling or Receiving. The functions
are covered by two SSC-subpackages: MC-Transmission
and MC-Reception respectively.
The functions of the controlling subpackage will be
outlined here. This description will also indicate
the corresponding functions of the receiving subpackage
at the standby site.
The MC-controlling subpackage is concerned with the
communication with the standby site.
This includes the following categories of data:
- M̲e̲s̲s̲a̲g̲e̲ ̲d̲a̲t̲a̲ ̲
To enable the reestablishment from disk of completely
processed messages.
- S̲t̲a̲t̲u̲s̲ ̲a̲n̲d̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
To enable a correct take-over at any time and continue
operation from the last completed message transaction.
- K̲e̲e̲p̲-̲a̲l̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲.̲
To monitor the status of the MC-link and of the
other site (mode of operation).
In addition it handles an interface to the supervisor
and to the terminal for the MCSF supervisor.
4.2.10.1 M̲o̲d̲e̲s̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
Each of the two supplied MPFs will have the capability
of operating in three different modes, i.e.:
- Active mode
- Stand-by 1 mode
- Stand-by 2 mode
At any given time only one MPF will be in Active mode.
A̲c̲t̲i̲v̲e̲ ̲M̲o̲d̲e̲:̲
In the Active Mode, the MPF will operate normally as
described in this technical proposal i.e. receive,
process, store and transmit messages.
S̲t̲a̲n̲d̲-̲b̲y̲ ̲1̲ ̲M̲o̲d̲e̲:̲
In thew stand-by 1 Mode, the MPF will receive and store
messages and status information from the active MPF
and be in a state ready to assume Active Mode of operation.
There will be no traffic on any excternal channel except
for the MC link.
S̲t̲a̲n̲d̲-̲b̲y̲ ̲2̲ ̲M̲o̲d̲e̲:̲
In the Stand-by 2 Mode, the MPF will receive and store
messages and status information from the active MPF
in the same way as in stand-by 1 Mode and further receive,
process, store and print messages from the SHIP-to-SHORE
stations. The system will be in the state ready to
assume Active Mode of operation. The messages received
from SHIP-to-SHORE stations will not replace in the
data base the messages received from the Active MPF,
but they will be stored separately and printed out
on supervisor request.
The state of operational mode will be selectable by
a supervisory command from the local supervisory position.
When the mode of an MPF is changed the supervisor of
the other MPF will be alerted automatically via the
link between the MC's.
If a supervisor of a stand-by MPF tries to switch the
MPF to active mode while the other MPF is still operating,
the supervisor will get a warning response at his terminal,
and the mode change will not be executed until a confirming
command has been entered.
A change-over, i.e. the stand-by MPF goes active, will
be based on signals received via the MC informing of
the state of the other MPF.
The supervisors will coordinate change-over actions
via telephone or other communication means. It will
be the responsibility of the "stand-by" supervisor
to ensure that his MPF does not enter the Active Mode
while the other MPF is in Active Mode.
When communication between the MC's are lost the supervisors
of both MPF's will be alerted automaticlly.
4.2.10.2 C̲h̲a̲n̲g̲e̲-̲o̲v̲e̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
To achieve a smooth change-over to the stand-by MPF
the supervisors at the two MPF's will have facilities
for:
P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲a̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲b̲e̲f̲o̲r̲e̲ ̲c̲h̲a̲n̲g̲e̲-̲o̲v̲e̲r̲ ̲c̲o̲m̲m̲a̲n̲d̲
A̲t̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲ ̲M̲P̲F̲:̲
- Dissemination of time of change-over and possibly
new addressing schemes to be used,
- close down of incoming channels,
- empty delivery queues for the local terminals,
- initiate a change from active mode to stand-by
1 or 2 mode.
A̲t̲ ̲t̲h̲e̲ ̲s̲t̲a̲n̲d̲-̲b̲y̲ ̲M̲P̲F̲:̲
- Initiate a change from stand-by 1 or 2 mode
to Active Mode.
P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲a̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲a̲f̲t̲e̲r̲ ̲c̲h̲a̲n̲g̲e̲-̲o̲v̲e̲r̲ ̲c̲o̲m̲m̲a̲n̲d̲
A̲t̲ ̲t̲h̲e̲ ̲s̲t̲a̲n̲d̲-̲b̲y̲ ̲M̲P̲F̲:̲
- stand-by mode 1 or 2 procedures
A̲t̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲ ̲M̲P̲F̲:̲
- The system goes automatically into a change-over
recovery phase, which is an attempt to reestablish
under the new configuration the traffic situation
of the previously active MPF with respect to
messages i.e.:
* data base take-over
* recovery of queues to the extent possible
- Final, supervisory controlled, reorganization
of external and internal queues
- Opening of channels
- Initialization of message accounting control
- Dissemination of new addressing schemes.
The execution of the procedures before change-over
command will only apply without modification in case
of an ordered change-over. A subset may be executed
in case of system failures.
A N N E X E
STATISTICAL REPORT FORMAT
A N N E X F
SUPERVISORY COMMANDS AND PROCEDURES
I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This annex will contain the documentation (ICD = Interface
Control Document) provided for the definition of the
Supervisory commands and procedures on the level of
man-machine interface for the CAMPS project.
A similar interface will be proposed for the CROSSFOX
supervisory positions. Changes will be necessary; certain
commands and procedures will not apply, e.g. SDL and
SCD table updates, SCARS/CCIS oriented commands and
procedures, MDCO commands and procedures; the addition
of Vetting and Screening procedures are foreseen as
a change. Consequently this annex does not present
the final interface documentation, but is rather the
basis for discussion between contractor and purchaser.
A N N E X G
REPORTS AND WARNINGS
I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This annex will contain the layout, i.e. text and data
of the reports, including warnings, to be presented
at the supervisors VDU in the CAMPS project.
A similar set of reports will be proposed for CORSSFOX.
Certain reports will not apply in case of CROSSFOX
and additions will have to be made, however. Consequently
this annex does not present the final interface documentation,
but is rather the basis for discussion between contractor
and purchaser.
