top - download
⟦e4a270287⟧ Wang Wps File
Length: 98177 (0x17f81)
Types: Wang Wps File
Notes: PC/SDS/001
Names: »4346A «
Derivation
└─⟦71042c85e⟧ Bits:30006244 8" Wang WCS floppy, CR 0251A
└─ ⟦this⟧ »4346A «
WangText
F…09…F…0e…F…05…E…0a…E…00…D…08…D…0e…D
C…09…C…02…B…0a…B…0f…B A…0a…A…0c…A…02…A…05…@…0a…@…0f…@
?…08…?…01…>…09…>…01…=…08…=…0e……86…1
…02…
…02…
…02…
…02…PC/SDS/001
…02…851105…02……02…#
PROTOCOL
CONVERTER
SYSTEM
SPECIFICATION…02…Issue
2.5…02…
PC
PROTOCOL CONVERTER
SYSTEM SPECIFICATION
CONTRACT SHNMO-82-9205-INF
PC/SDS/001
Erik Holgersen
Jan Lauridsen
SHAPE (5), JAL, EHO, OJG, LRS
3
851105
PC/SDS/001
…02…851105…02… ii
PROTOCOL CONVERTER
SYSTEM SPECIFICATION…02…Issue 2.5…02… PC
4346A/251A
820714 All First issue of Document
820810 All Second issue of Document
821011 DN14 29 Preemption buffer
clearance
DN17 24,27,28 Too long message reaction
DN38 43, 39 . Turn of circuit
114 arrow
. Transmitter clock(DCE)
DN39 48 SCI check
. 22 Super-ack to CCIS
. 24 Super-ack from CCIS
. 19 Cls alignment
. 25 Editorial:converted
from
. 25 No Cls-convertion
821126 Telecom
SHAPE/
Flabat 46,47,64 Memory page incl.
in DUMP syntax
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2.3 830125 PDS Changes
resulting
from
PDS
rev.
14,22,1,22.2,26,47,48,60,61,64,68,69,70,71,72
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2.4 831108 Editorials iv Table
of
Contents
32L
-
64L
EPROM
v SYNTAX removed
32 32K - 64K EPROM
35 43K - 64K EPROM
46 LTUA/LTUB definition
47 Improvements of prompt
for password.
.48 - " -
55 MAC bootloading
64 Default parameter
descriptions
65 Display of result
lines and error codes
65.1-6 Sections 4.1.5.1.4
Error Codes included
73 SGI package contents
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2.5 840430 65.4, New
error
codes.
65.6
PC/SDS/001
…02…851105…02… iii
PROTOCOL CONVERTER
SYSTEM SPECIFICATION…02…Issue 2.5…02… PC
851105 All General
update
of
original
document.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…02…PC/SDS/001
…02…851105…02… iv
PROTOCOL CONVERTER
SYSTEM SPECIFICATION…02…Issue 2.5…02… PC
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
P̲a̲g̲e̲ ̲N̲o̲.̲
1 GENERAL ......................................
1
1.1 PURPOSE AND SCOPE ........................
1
1.2 APPLICABLE DOCUMENTS .....................
2
1.3 TERMS AND ABBREVIATIONS ..................
3
1.3.1 Terms ................................
3
1.3.2 Abbreviations ........................
3
2 SUMMARY OF REQUIREMENTS ......................
5
2.1 SYSTEM DESCRIPTION .......................
5
2.1.1 End-Systems Survey ...................
6
2.1.1.1. CAMPS/SCARS Protocols ..........
6
2.1.1.1.1 Transaction Flow .............
7
2.1.1.1.2 Transaction Acknowledgement ..
8
2.1.1.1.3 Transaction Error Handling ...
8
2.1.1.1.4 Preemption ...................
8
2.1.1.1.5 Transaction Sequence Control .
8
2.1.1.1.6 Service Messages .............
9
2.1.1.1.7 System Constants .............
9
2.1.1.2 CCIS Protocols ................... 10
2.1.1.2.1 Transaction Flow ............. 11
2.1.1.2.2 Transaction Acknowledgement .. 12
2.1.1.2.3 Transaction Error Handling ... 12
2.1.1.2.4 Preemption ................... 13
2.1.1.2.5 Transaction Sequence Control . 13
2.1.1.2.6 Service Messages ............. 13
2.1.1.2.7 Transaction Override ......... 14
2.1.1.2.8 System Constants ............. 14
…02…PC/SDS/001
…02…851105…02… v
PROTOCOL CONVERTER
SYSTEM SPECIFICATION…02…Issue 2.5…02… PC
P̲a̲g̲e̲ ̲N̲o̲.̲
2.1.2 Message Structure .................... 14
2.1.2.1 Message Type ..................... 14
2.1.2.2 Message Format ................... 15
2.1.2.3 Alphabet ......................... 16
2.1.2.4 Message Length ................... 16
2.1.3 CAMPS/SCARS Message Fragmentation .... 16
2.1.3.1 Frame Structure .................. 16
2.1.4 CCIS Message Fragmentation ........... 19
2.1.4.1 Segment Structure ................ 19
2.1.4.2 Frame Structure .................. 22
2.2 SYSTEM FUNCTIONS ......................... 23
2.2.1 System Control ....................... 23
2.2.1.1 System Modes ..................... 23
2.2.2 Message Processing ................... 24
2.2.2.1 Transaction Flow ................. 24
2.2.2.2 Transaction Acknowledgement ...... 24
2.2.2.3 Transaction Precedence Handling .. 25
2.2.2.4 Transaction Sequence Control ..... 25
2.2.2.5 Service Messages ................. 26
2.2.2.6 Protocol Functions ............... 26
2.2.2.7 Message Control Field Conversion . 27
2.2.3 Initialisation and Close Down ........ 28
2.2.3.1 Initialisation ................... 28
2.2.3.2 Close Down ....................... 28
2.2.4 Error Detection and Error Handling ... 29
2.2.4.1 Unrecoverable Errors ............. 29
2.2.4.2 Frame Transmission Errors ........ 29
2.2.4.3 Message Control Errors ........... 29
2.2.5 Recovery ............................. 31
2.2.6 Statistics Collection ................ 31
2.2.7 Security ............................. 31
2.3 CHARACTERISTICS .......................... 33
2.3.1 Timing ............................... 33
2.3.2 Throughput ........................... 33
2.3.3 Flexibility .......................... 34
…02…PC/SDS/001
…02…851105 vi
PROTOCOL CONVERTER
SYSTEM SPECIFICATION…02…Issue 2.5 PC
P̲a̲g̲e̲ ̲N̲o̲.̲
3 ENVIRONMENT .................................. 35
3.1 EQUIPMENT ................................ 35
3.1.1 CPU-SCM .............................. 37
3.1.2 128K RAM ............................. 37
3.1.3 64K EPROM ............................ 38
3.1.4 LTU .................................. 38
3.1.5 LIA-N ................................ 38
3.1.6 CSA .................................. 38
3.1.7 Mini Crate ........................... 38
3.1.8 V28 L/L Adaptor ...................... 38
3.1.9 Opto T/R, OM-2 ....................... 39
3.1.10 Adaptor Power Supply ............... 39
3.1.11 Adaptor Crate ...................... 39
3.1.12 Tempest VDU ........................ 39
3.2 SOFTWARE ................................. 39
3.2.1 System Software ...................... 40
3.2.1.1 AMOS ............................. 40
3.2.1.2 LTU/TTY Drivers .................. 41
3.2.2 Development Support Software ......... 41
3.3 ELECTRICAL INTERFACES .................... 42
3.3.1 CCITT V24/PC Pin Connections ......... 42
3.3.2 PC to End-Systems I/F ................ 43
3.3.2.1 CAMPS to PC I/F .................. 43
3.3.2.2 SCARS II to PC I/F ............... 44
3.3.2.3 CCIS to PC I/F ................... 45
4 SOFTWARE SYSTEM DESIGN ....................... 46
4.1 SOFTWARE SYSTEM DESCRIPTION .............. 46
4.1.1 Functional Specification ............. 46
4.1.1.1 System Modes and Commands ........ 46
4.1.1.2 Maintenance Mode ................. 48
4.1.1.3 Local Mode ....................... 49
4.1.1.4 Operational Mode ................. 50
4.1.1.5 Test Mode ........................ 51
…02…PC/SDS/001
…02…851105 vii
PROTOCOL CONVERTER
SYSTEM SPECIFICATION…02…Issue 2.5 PC
P̲a̲g̲e̲ ̲N̲o̲.̲
4.1.2 Software Specification ............... 53
4.1.3 Data Flow and Control Logic .......... 56
4.1.3.1 Message Data Flow ................ 56
4.1.3.2 Control Logic .................... 58
4.1.4 Common Data .......................... 60
4.1.4.1 PC Message Buffer ................ 60
4.1.4.1.1 Message Descriptor ........... 60
4.1.4.1.2 Message Text ................. 63
4.1.5 Interfaces ........................... 65
4.1.5.1 Operator Interface ............... 65
4.1.5.1.1 Prompt ....................... 65
4.1.5.1.2 Command Syntax ............... 65
4.1.5.1.3 Error Messages ............... 67
4.1.5.1.4 Error Codes .................. 68
4.2 PACKAGE SPECIFICATIONS ................... 73
4.2.1 Command Interpreter (CI) ............. 73
4.2.2 Traffic Controller (TRC) ............. 74
4.2.3 CAMPS/SCARS Protocol Adaptor (CSPA) .. 75
4.2.4 CAMPS/SCARS Low Level Protocols (CSLP) 77
4.2.5 CCIS Protocol Adaptor (CPA) .......... 77
4.2.6 CCIS Low Level Protocols (CLP) ....... 79
4.2.7 Maintenance Controller (MAC) ......... 79
4.2.8 System Generator and Initialiser (SGI) 80
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
This chapter describes the general information applicable
to this document. Purpose, Scope, Document References,
Terms and Abbreviations are defined.
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
a) P̲u̲r̲p̲o̲s̲e̲
The System Specification for the Protocol Converter
(PC) is written to fulfil the following objectives:
To provide the top level design of the application
software to be developed. The functional aspects
are described in detail. The overall structure
and breakdown into software packages and related
interfaces is described. Packages are descrbed
to a level sufficient for individual subsequent
detailed design.
To provide user operational and development personnel
details of the ongoing analysis.
b) S̲c̲o̲p̲e̲
This System Specification is based upon the PC
System Requirements Specification (Reference 2)
and constitutes the basis for the Package Design
Specifications document where procedural aspects
of the software packages will be detailed to a
level sufficient for programming.
The System Specification is predicated and application
software to be developed. The hardware, the system
software and the development support software is
outlined in chapter 3 describing the environment.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
1. Protocol Converter Contract SHNMO-82-9205-INF.
1982-04-29.
2. System Requirement Specification (SRS)
Appendix G of Reference 1. 1982-04-29.
3. SCARS II System Design Baseline Vol. IIIA
Rev A , B and C.
1981-06-30, 1982-07-15, 1982-04-28. Burroughs
or
CPS/ICD/006, 1982-05-18 Christian Rovsing A/S
4. Functional Description for the SCARS, CAMPS, ACCIS
Interface. 1981-02-05. As Appendix E to Reference
3.
5. Remote Terminal Supervisor (GRTS).
Honeywell DD40B Rev. 0, July, 1976.
6. DINDAC CCTC TR-01, 1978-06-30.
7. ACE Security Directive 70-1.
1979-08-31 with change 2 dated 1981-02-06.
8. ACE ADP Standards Manual 96-1-1, part no. 007-3,
1980-01-14.
9. AMSG 720A. January, 1977.
10. AMSG 719B. September, 1976.
11. AQAP 1 and 13.
12. MIL-STD188C. 1969-11-24.
13. WWMCCS ADP Telecom Standard Engineering Practices,
DCA November, 1979.
(p. 6-01 to 6-09, 10-18 to 10-19, 10-92 to 10-108).
14. Control wires and functions for WWMCCS-PC link
(delivery by SHAPE on or before 3 May, 1982)
15. X25 LAP (CAMPS) Product Specification.
CCS-MIC/0422/PSP/1027. 1982-05-28. Chr. Rovsing
A/S.
16. DINDAC Interface Parameter Document.
Telex CAMPS Log: 640, PC: 003. SHAPE 14 May, 1982.
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
This section defines the terms and abbreviations to
be used in this document.
1.3.1 T̲e̲r̲m̲s̲
The following terms are defined:
E̲n̲d̲-̲S̲y̲s̲t̲e̲m̲ designates any of the three systems to which
PC is connected, i.e. CAMPS or SCARS II in one end
and CCIS in the other.
F̲r̲a̲m̲e̲ designates the smallest logical unit of information
to be transferred on the physical link. A frame corresponds
to what is called a subsegment in DINDAC terminalogy
(cf. Reference 6).
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
The following abbreviations are used:
ACCIS Automated Command and Control Information
System
ACE Allied Commands Europe
ACK Acknowledgement
ADP Automated Data Processing
AMOS Advanced Multiprocessor Operating System
ASPL Approved Spare Parts List
CAMPS Computer Aided Message Processing System
CCIS Command and Control Information System
CI Command Interpreter
CLP CCIS Low Level Protocols
CLS Message Classification
CPA CCIS Protocol Adaptor
CR Christian Rovsing A/S
CR80 CR80 Minicomputer (Christian Rovsing)
CSA CPU SCM Adaptor
CSLP CAMPS/SCARS Low Level Protocols
CSPA CAMPS/SCARS Protocol Adaptor
DCE Data Circuit-terminating Equipment
DTE Data Termi`nal Equipment
DINDAC AUTODIN-WWMCCS Direct Access Communications
Module
DN355 Honeywell Front-End Processor
EOM End of Message
EPROM Erasable Programmable Read-only Memory
GRTS/355 General Remote Terminal Supervisor of DN
355
I/F Interface
ICD Interface Control Document
IVSN Initial Voice Switched Network
LIA-N Line Interface Adaptor Non-switching
LTU Line Terminating Unit
MAC Maintenance Controller
NAK Negative Acknowledgement
PC Protocol Converter
PIP Project Implementation Plan
PROM Programmable Read-only Memory
QA Quality Assurance
RAM Random Access Memory
RCI Remote Computer Interface (to Honeywell)
RSPL Recommended Spare Parts List
R&M Reliability and Maintainability
SCARS Status and Control Alerting and Reporting
System
SCI Station Channel Indentifier
SCM System Controle Module
SGI System Generator and Initializer
SHAPE Supreme Headquarters Allied Powers Europe
SUSDUP Suspected Duplicate
SRS System Requirement Specification
SWELL Software Engineering Low Level Language
TBD To Be Defined
TSN Transmission Serial Number
TRC Traffic Controller
VDU Visual Display Unit.
WWMCCS World Wide Military Command and Control System
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
This chapter concerns the software requirements to
PC. A survey of the interfacing systems is included
for the sake of reference and completeness.
2.1 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
In the following, the system and its relations to interfacing
systems are outlined. The characteristics of the interfacing
systems are outlined and the data exchanged between
end-systems are described.
The three systems interfacing to the protocol converter
are:
a) CAMPS implemented on CR80 equipment.
b) SCARS II implemented on Burroughs equipment.
c) CCIS implemented on Honeywell equipment.
Transactions are required to be exchanged between any
two of these systems.
CAMPS and SCARS II interfaces to the external environment
in the same way based upon an X25 protocol as described
in Reference 3 and outlined in section 2.1.1.2. These
two systems can therefore be interlinked directly without
involving the PC.
CCIS as implemented on a Honeywell 6000 configuraton
with a DN 355 or a DN 6678 front-end network processor
interfaces to the external environment through the
DINDAC and RCI protocols, as described in Reference
6 and Reference 5 and outlined in section 2.1.1.2.
These protocols are incompatible with the ones used
by CAMPS and SCARS II.
The objective of the protocol converter is thus to
provide a facility to support automated exchange of
transactions between CAMPS or SCARS II on one side
and CCIS on the other.
This objective is accomplished by connecting each end
system to the converter which shall compensate for
differences in protocols in a way that allows the end
system to operate as if transactions were exchanged
with a matching system.
The relationship between PC and environment is shown
in Figure 2-1.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
CAMPS or ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ PC ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ CCIS
SCARS II
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
FIGURE 2.1-1
SYSTEM CONNECTIVITY
PC and the end-systems are collocated and physically
connected by direct cabling. The characteristics of
the physical interfaces are described in section 3.3.
2.1.1 E̲n̲d̲-̲S̲y̲s̲t̲e̲m̲s̲ ̲S̲u̲r̲v̲e̲y̲
The following two subsections outlines the message
exchange protocols of the two end-systems.
2.1.1.1 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
The Protocol is composed of the following four layer
given in top-down order:
a) Level 4
Handles complete transactions.
- Formatting (message header and trailer).
- Traffic Control.
- Transaction acknowledgement.
- Transaction sequence control (TSN processing).
- Transaction recovery (retransmission).
b) Level 3
Handles blocking of messages.
- Assembly/Disassembly of message blocks.
- Supply/Removal and check of control information
of each text block (framing/deframing).
- Sequence control of frame transmission/reception.
c) Level 2
Handles individual frames.
- Supply/Removal and check of additional control
information of a frame.
- Frame transmision/reception control.
- Frame acknowledgement.
- Frame recovery (retransmissions)
- Statistics control.
d) Level 1
Physical line control.
- Bit stuffing/removal.
- Bit stream transmission/reception.
In the following the characteristics of the transaction
exchange is described.
2.1.1.1.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲F̲l̲o̲w̲
Transmissions may take place simultaneously in both
directions (full duplex) in synchronous mode. The following
scenario shows a typical level 4 exchange of transactions
between two CAMPS/SCARS II systems A and B. A has two
transactions A1 and A2 to transmit, B has one B1:
A B
transmit A1
transmit B1
receive B1
receive A1
transmit ack(B1)
receive ack(B1)
transmit ack(A1)
receive ack(A1)
transmit A2
2.1.1.1.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
After transmit the sender will wait for acknowledgement
before next transaction is transmitted. It may, however,
transmit acknowledgement to a received transaction
(this is necessary to avaoid a deadlock situation).
Also if an acknowledgement is not received within a
certain time interval after transmission (timeout situation),
a retransmission of the transaction in the SUSDUP (suspected
duplicate) form may take place.
2.1.1.1.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
There is no control message for communicating detected
errors in a received transaction to the other end.
Negative acknowledgement can only be done by not sending
an acknowledgement message so that the other end will
timeout and retransmit. This may be done if the information
received is insufficient to send the acknowledgement.
The receiver will normally send the acknowledgement
and present the transaction in error to the service
position.
2.1.1.1.4 P̲r̲e̲e̲m̲p̲t̲i̲o̲n̲
An initiated transmission of a message may be stopped
(preempted) by the sender if it needs to transmit a
high precedence transaction and the one in transmission
is lower. Preemption is done by transmitting a frame
with a special character sequence after the last transmitted
frame. The sender will wait for an acknowledgement
before the new message is transmitted.
2.1.1.1.5 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲e̲
Each message is by the sender given an identification
which is composed of a Station Channel Identifier (SCI)
and a Transaction Serial Number (TSN). This transmission
identifier is used by the receiver to control accountability
and is sent back to sender in the transaction acknowledgement.
The TSN is a number in the range 001-999. For each
transaction sender increments TSN by 1 (wrapping around
to 001 after 999). The receiver and the sender apply
a specific algorithm for running the TSN control.
2.1.1.1.6 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Three types of service messages may be exchnaged:
a) Transaction acknowledgement
b) Channel check message
c) Final number message.
The channel check is transmitted when no message has
been received for a specific time interval. The transaction
acknowledgement of the channel check is the indication
that the link is still intact.
Final number message is sent by the end of day holding
TSN of the last transmitted message to be checked with
the TSN of the message last received by the other end.
A transaction acknowledgement message does not have
a TSN itself.
A channel check message does have a normal TSN.
A final number message has itself TSN = 001 (which
causes a wrap around of receivers expected TSN).
2.1.1.1.7 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲s̲t̲a̲n̲t̲s̲
a) Max. message size is 12000 bytes.
b) Max. text size in a frame is 120 bytes.
c) Max. number of outstanding (non acknowledged) frames
at level 2 is 3.
d) Max. number of frame retransmissions at level 2
is 3.
e) Timeout value for frame acknowledgement at level
2 is 3 seconds.
f) Timeout value for transaction acknowledgement at
level 4 will be 2 times the transmission time of
a 12000 character message.
2.1.1.2 C̲C̲I̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
The Protocol is composed of the following layers given
in top-down order:
a) Level 5
Handles segmentation of transactions.
Segments linked on disk.
- Assembly/disassembly of messages into segments.
- Supply/removal of segment header to each segment.
- Request transport of message segments to/from
disk.
- Request transmission of messages.
- Transaction acknowledgement to level 4 (DINDAC).
b) Level 4 (DINDAC)
Handles transmission/reception of transactions.
- Validity check of segment header.
- Traffic control.
- Transacation sequence control.
- Transaction acknowledgement.
- Character conversion (ASCII-BCD).
- Transaction disk storage control.
- Provision of tape fall-back facility.
c) Level 3 (GRTS/355)
Handles blocking of segments.
- Assembly/disassembly of message segments into
frames (subsegments).
- Control of transmission/reception of frames.
- Frame acknowledgement.
d) Level 2 (RCI)
Handles individual frames.
- Supply/removal and check of frame control information.
- Frame transmission/reception
- Frame recovery (retransmissions)
- Parity generation/check
e) Level 1
Physical line control.
Note that transactions are passed between DINDAC and
the application via a disk unit. When picked from disk
by DINDAC transactions are already split up into segments
each segment having a partially filled in header.
In the following the characteristics of the transaction
exchange is described.
2.1.1.2.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲F̲l̲o̲w̲
Transmission may only take place in one direction at
a time (half duplex). Therefore, a master-slave relation
is implemented the CCIS computer acting as master and
the remote computer as slave.
When the system is idle the remote will be ready to
receive. If CCIS needs to transmit a transactions this
can be done immediately. If remote needs to transmit
it sends a 'break' control message to the master who
then responds by requesting the remote to transmit
and the remote can now start transmission.
When both sides have transactions to transmit apart
from the one in transmission, the decision of whom
shall transmit next is based on comparing precedences
of next transaction to be transmitted from either side.
…86…1 …02… …02… …02… …02…
When transmitting one transaction the sender may inform
the other side of the precendence of next transaction
in queue. A special field in the added segment header
is used for this purpose. When the sender receives
acknowledgement of the transaction send he is at the
same time told whether he shall continue transmitting
or switch to receive. It is therefore the side sending
the acknowledgement that ultimately decides which side
shall transmit next.
2.1.1.2.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
The reception of a transaction is acknowledged either
positively or negatively. This is done by sending one
of the two service messages SUPER-ACK or SUPER-NAK.
If a SUPER-ACK is returned from CCIS this means that
DINDAC has taken responsibility for the correct reception
of the transaction (and stored it on disk for delivery
to the application).
If a SUPER-NAK is returned the transaction has not
been received correctly, the SUPER-NAK containing a
reason code for explanation.
The SUPER-ACK/SUPER-NAK contains also a 'next-to-transmit'
field indicating whether the receiver of the SUPER
shall transmit or receive next.
2.1.1.2.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Errors detected by receiver on transaction level are
communicated to sender by transmitting a SUPER-NAK
explaing the error. The SUPER-NAK can be sent only
after a complete segment is received. If a SUPER-NAK
is received before all segments of the transaction
is transmitted, the sender shall not continue transmitting
the transaction. If an error is detected in an incoming
transaction, the transaction may be removed or presented
to the service position.
If sender detects error in a transactio being transmitted
he can cancel the transmission by sending a BUST control
message. The BUST can only be sent after a complete
segment. The sender will receive a SUPER-NAK in response
to the BUST. The receiver of the BUST will delete all
references to the transaction.
2.1.1.2.4 P̲r̲e̲e̲m̲p̲t̲i̲o̲n̲
An initiated transmission of a transaction may be stopped
by the sender because the sender wants to transmit
a high precedence transaction and the one in transmission
has lower precedence. Preemption is done by transmitting
a BUST control message. The BUST message will hold
the precedence of the next transaction if any. The
BUST can only be transmitted after a complete segment.
The sender of the BUST shall receive a SUPER-NAK with
reason code indicating bust condition and instruction
of whom to transmit next. The receiver of the BUS message
will delete all references to the transaction in reception
and send the SUPER-NAK back.
2.1.1.2.5 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Each transaction is by the sender given an identification
which is composed of a Channel Designator (CSD) and
a Channel Sequence Number (CSN). This information corresponds
to the SCI and TSN of the CAMPS/SCARS II Protocol and
serves the same purpose of accountability. However,
while the SCI and TSN is part of the E1 format, the
CSD and CSN is part of the segment header and controlled
at the DINDAC level. The CSN is a number in the range
000..999 (unlike the TSN). For each transaction sender
increments CSN by 1 (wrapping around to 000 after 999)
and receiver checks with expected CSN. Exceptions to
the increment by one procedure is that CSN is set to
previous value when a SUPER-NAK or BUST message is
received.
2.1.1.2.6 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The following service messages may be exchanged between
DINDAC and the remote computer:
a) Super-ack
b) Super-nak
c) Bust-message
d) No-message.
The No-Message is sent when the side expected to transmit
next does not have a transaction to transmit.
2.1.1.2.7 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲O̲v̲e̲r̲r̲i̲d̲e̲
If one side during reception of a long transaction
needs to transmit a transaction for some reason such
as having a high priority transaction to transmit,
the receiver may override the reception of the current
message. The procedure is to send a SUPER-NAK with
reason code equal 'stop transmission' and 'next-to-transmit'
equal sender (of SUPER-NAK).
2.1.1.2.8 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲s̲t̲a̲n̲t̲s̲
a) Max. message size is 12000 bytes.
b) Max. size of text in segment is 1106 bytes.
c) Max. size of text in frame is 324 bytes.
d) Max. number of outstanding (non acknowledged) frames
is 1.
e) Timeout value for frame acknowledgement is 7 seconds.
f) Max. number of frame retransmissions is 7.
2.1.2 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
In the following the structure and characteristics
of the messages exchanged between the end-systems and
passing through PC are described.
2.1.2.1 M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲s̲
The transactions exchanged between the end-systems
are of four types:
a) Narrative messages
b) Data messages
c) VDU displays
d) Comments
Furthermore, the following service messages may be
exchanged between CCIS, PC and CAMPS/SCARS II:
e) Transaction acknowledgement messages
f) Channel check messages
g) Final number messages
Note that transaction acknowledgement message is not
sent from CCIS through PC to CAMPS/SCARS II.
2.1.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
All messages except transaction acknowledgements are
transmitted and received in E1 format as defined in
appendix A of Reference 3.
The E1 format divides a message into three parts:
a) header with varying content dependent on message
type.
The following attributes are always present:
1) Station Channel Identifier (SCI)
2) Transmission Serial Number (TSN)
3) Message Classification (CLS)
4) Message Precedence (PRC)
Classification levels are:
U: Nato unclassified
R: Nato restricted
C: Nato confidential
S: Nato Secret
T: Cosmic Top Secret
b) Text containing the information to be communicated.
c) Trailer indicating end-of-message.
2.1.2.3 A̲l̲p̲h̲a̲b̲e̲t̲
All messages passing the protocol converter are coded
in the NATO-7-bit alphabet. This alphabet is defined
on page 3-A-4-2 of Reference 3.
2.1.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲e̲n̲g̲t̲h̲
The length of a message is limited to a maximum value
which depends on the transaction type as follows:
a) Data and narrative messages contain a maximum
of 12000 characters E1 header and trailer included.
Narrative messages contain a maximum of 69
characters per line of text (excluded the line
delimiting characters).
Data messages have no limit on line length.
b) Displays and comments contain a maximum of
20 lines of text E1 headear and trailer excluded.
Each line contains a maximum of 80 characters
per line.
2.1.3 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲r̲a̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Here the fragmentation of messages between PC and CAMPS/SCARS
II is described.
Messages are divided into consecutive blocks of information
for transfer on the link. To these blocks are added
control information by the protocol layers. A data
block with control information is called an information
frame and is described in the following section.
2.1.3.1 F̲r̲a̲m̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
An Information Frame is composed of the following components:
HEADER
Flag Sequence 1 byte
Address 1 byte
Control 1 byte
INFORMATION FIELD
Line Control Field 2 bytes
Message Control Field 6 bytes
Text 1..120 bytes
TRAILER
Frame Check Sequence 2 bytes
Flag Sequence 1 byte
Line Control Field is not used (=0).
The contents of the message control field is described
in the following figure 2-2.
DESCRIPTION BYTES TYPE VALUE
-------------------------------------------------------------
IFL - Information Field Length 1 num 9..128
Number of bytes contained in the
INFORMATION FIELD (see 2.1.3.1)
of a frame.
BSN - Block Sequence Number 1 num 1..100
Numeric value indicating the
relative position of this block
within the message.
Spare 1
Not used
BTY - Block Type 1 char
Defines the following conditions:
SOM - Start of message block A
MID - Mid message block B
EOM - End of message block C
SOM-EOM - Single block message D
PRC - Message precedence 1 char
Legal values are:
Flash override and superflash 1
Flash 2
Immediate 3
Superpriority 4
Priority 5
Routine 6
TYP - Message type 1 char
Legal values are:
Display in E1 C
Comment in E1 D
Transaction acknowledgement E
Channel check message F
Final number message G
Narrative message in E1 M
Data message in E1 N
Susdup display in E1 O
Susdup comment in E1 P
Susdup narrative message in E1 Q
Susdup data message in E1 R
FIGURE 2-2
CAMPS/SCARSII MESSAGE CONTROL FIELD
2.1.4 C̲C̲I̲S̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲r̲a̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The fragmentation of messages between PC and CCIS is
described.
Messages are blocked in two levels.
Each message is divided into one or more segments with
added control information.
Each segment is divided into one or more frames (called
subsegments in Reference 6) with added control information.
2.1.4.1 S̲e̲g̲m̲e̲n̲t̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A message segment is composed as follows:
SEGMENT HEADER 34 bytes
DATA 1..1106 bytes
The content of the segment header is shown in the following
figure 2-3.
DESCRIPTION BYTES TYPE VALUE
-------------------------------------------------------------
CDN - Channel Designator. 3 char
Three letter code identification.
The value is a constand
identifying the sending station.
CSN - Channel Sequence Number 3 char 000-999
Message sequence number increased
by 1 for each transaction
transmitted. (wrap around to 0).
SEG - Message segment number 2 char 01-99
Indicates the relative position
of this segment within the
message.
END - Last segment indicator 1 char
Legal values are:
EOM - End of message segment T
Non-EOM space
PRC - Message precedence 1 char
Legal values are:
Emergency Y
Flash Z
Immediate O
Priority P
Routine R
CLS - Message classification 1 char
Legal values are:
Cosmic top secret T
Secret S
Confidential C
Restricted R
Unclassified U
FIGURE 2-3 (1 of 2)
DINDAC SEGMENT HEADER
DESCRIPTION BYTES TYPE VALUE
-------------------------------------------------------------
TYP - Message type 1 char
Legal Values are:
Display in E1 C
Comment in E1 D
Transaction acknowledge E
Channel check message F
Final number message G
Narrative message in E1 M
Data message in E1 N
Susdup display in E1 O
Susdup comment in E1 P
Susdup narrative message in E1 Q
Susdup data message in E1 R
KEY - Program keyword 8 char
Identifies the application
to communicate with TBD
SUB - Message subject code 2 char TBD
PRN - Precedence of next message 1 char
in transmission queue.
Legal values are:
Emergency 5
Flash 4
Immediate 3
Priority 2
Routine 1
No message to transmit 0
Unused 1
PSN - Internal processing
sequence number. 6 char
SIZ - Length of segment 4 char 0035-
Number of bytes header included 1140
FIGURE 2-3 (2 of 2)
DINDAC SEGMENT HEADER
2.1.4.2 F̲r̲a̲m̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The general format for frames transmitted on the PC-CCIS
link is as follows:
FIELD BYTES TYPE VALUE
-----------------------------------------------------------
SYN - Synch. character 1 octal 026
SYN - Synch. character 1 octal 026
SYN - Synch. character 1 octal 026
SYN - Synch. character 1 octal 026
SOH - Start of header 1 octal 001
FC - Format code 1 octal varying
SC - Alternate sequence code 1 octal 101 &
102
AC - Operation code 1 octal 100
OC - Operating 1 octal varying
IC - Ident code 1 octal 100
STX - Start of text 1 octal 002
TEXT 0..324 char
ETX/ETB - End/more text 1 octal 003/027
BCC - Frame check sequence 1 octal varying
FIGURE 2-4
RCI FRAME FORMAT
2.2 S̲Y̲S̲T̲E̲M̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲
The System will be controlled by operator interaction.
Commands and responses are communicated via a VDU screen
and keyboard. The VDU to system interface will operate
with speed up to 9600 baud. The VDU will not be required
once the system is brought into normal operation and
may therefore be shared among several converters.
2.2.1.1 S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲e̲s̲
The system will be controllable at various levels called
modes, each mode providing specific control facilities.
The following modes will be implemented:
a) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲M̲o̲d̲e̲
Provides for basic test and analysis at a low level
(hardware module tests, memory dump).
b) L̲o̲c̲a̲l̲ ̲M̲o̲d̲e̲
Reflects the state where the system is initialised
but still offline. A logon command from the operator
will initiate the sequence to bring the system
online.
c) O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲M̲o̲d̲e̲
The system is online. The end-systems are connected
and transactions may be exchanged.
d) T̲e̲s̲t̲ ̲M̲o̲d̲e̲
The system is online but not in normal operation.
Provides for individual test of the links PC-CAMPS/SCARS
II and PC-CCIS by transmitting and receiving test
messages prestored in PC.
2.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The requirements to the message processing capability
of PC is summarised in this section.
2.2.2.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲F̲l̲o̲w̲
With the system online transactions may arrive from
end-systems to PC simultaneously. PC will therefore
be prepared to handle two transactions, one from each
side at a time. Since the PC-CCIS link is half duplex
this implies that PC may have to store a transaction
coming in from CAMPS/SCARS until the CCIS link is available.
PC will therefore be designed to have the capacity
for storing two complete transactions, one for each
direction.
2.2.2.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
Transactions will be acknowledged by end-systems. PC
will never generate and send transaction acknowledgement,
as this is a responsibility of the receiving end-system.
When PC has passed a transaction the receiver shall
send a transaction acknowledgement in accordance with
its protocol.
CAMPS/SCARS will acknowlege by transmitting a transaction
acknowledgement service message from its level 4 protocol.
PC sends SUPER-ACK to DINDAC when it has received a
transaction from CCIS. The transaction acknowledgement
service message sent from CAMPS/SCARS is by PC passed
on, transparantly through DINDAC, to the CCIS application.
When the CCIS application has received the transaction
acknowledgement service message the next transaction
may be submitted for transmission.
CCIS will acknowledge by letting the SUPER-ACK service
message generated by its DINDAC protocol act as the
final transaction acknowledgement. This SUPER-ACK is
by PC converted to a CAMPS/SCARS transaction acknowledgement
service message (this requires that PC saves the TSN
number of the transaction being acknowledged) and sent
to CAMPS/SCARS. The reason for not letting the CCIS
application generate the CAMPS/SCARS transaction service
message and pass this transparently through DINDAC
and PC is not to violate the timeout on transaction
acknowledgement applied in CAMPS/SCARS.
2.2.2.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
As mentioned under transaction flow, a transaction
from CAMPS/SCARS will be stored in PC if the CCIS-PC
link is not available due to incoming transaction from
CCIS.
PC will assure the CAMPS/SCARS transaction to get through
to CCIS in the following way:
a) If the CAMPS/SCARS transaction is of precedence
Flash ̲override / superflash or Flash and the incoming
CCIS transaction is of lower precedence, then PC
will apply override facility of the CCIS protocol
to stop reception of the incoming CCIS transaction
and start transmission of the CAMPS/SCARS transaction.
Note that the override can only be done after a
complete segment has been received, which is why
one-segment transactions (size up to 1140 bytes)
can not be overridden.
b) If a) does not apply (i.e. no override) PC receives
the complete transaction from CCIS, sends the SUPER-ACK/SUPER-NAK
with the 'next ̲to ̲transmit' field set to PC. PC
starts transmission of the waiting transaction
from CAMPS/SCARS when the 'transmit ̲data' request
is received from CCIS.
On reception of transaction acknowledgement service
message from CAMPS/SCARS the following is done:
the PRN field of the outgoing transaction will
contain the precedence of the transaction acknowledgement
on queue in PC.
2.2.2.4 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
It is the responsibility of the end-systems to run
the transaction sequence control as the transaction
sequence number (TSN) is part of the E1 format. However,
since the DINDAC level runs a separate transaction
sequence control based on the channel sequence number
(CSN) of the segment header, PC will handle the CSN
processing on the PC-CCIS link.
2.2.2.5 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Channel check and final number service messages will
be passsed on transparently by PC. Transaction acknowledgement
service message sent from CAMPS/SCARS will also be
passed on to the CCIS end. A SUPER-ACK received from
CCIS (DINDAC) will, on the other hand, be converted
to a transaction acknowledgement service message and
sent to CAMPS/SCARS; CCIS shall therefore not generate
any further transaction acknowledgement, however, the
SUPER-ACK acknowledging a transaction acknowledgement
service message is not passed on towards CAMPS or SCARS.
2.2.2.6 P̲r̲o̲t̲o̲c̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
PC will handle transactions to/from CAMPS/SCARS in
accordance with the level 1, 2 and 3 protocols of Reference
3. Message fragmentation will be as defined in section
2.1.3.
PC will handle transactions to/from CCIS in accordance
with the level 1, 2 and 3 (RCI Reference 5) and that
part of level 4 (DINDAC Reference 6) that concerns
validity check/generation of segment headers, segment
sequence control, transaction sequence control and
handling of DINDAC service messages. Message fragmentation
will be as defined in section 2.1.4.
The RCI facility for data compression will not be implemented.
PC will pass on the full E1 format unmodified. It is
a duty of both end-systems to handle the E1 formatting.
PC will check on the total length of a transaction,
where total length is defined as the number of characters
(including header, trailer, and line delimiters) of
the largest transaction of a given type. Total length
is for data and narrative messages 12000 characters,
for displays and comments approx. 2000 characters (exact
values to be specified in the Package Design Specification).
2.2.2.7 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲i̲e̲l̲d̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Control information is contained in the DINDAC segment
header for messages to/from CCIS and in the Message
Control Field of level 3 frames for messages to/from
CAMPS/SCARS as described in sections 2.1.4.1 and 2.1.3.1.
There is not a one-to-one mapping between these fields.
How PC will supply the information required is described
here.
For CAMPS/SCARS to CCIS transmission PC will provide
the DINDAC segment header contents as follows (cf.
figure 2-3):
CDN is SCI of E1 format line B.
CSN is generated by PC.
SEG is generated by PC.
END is generated by PC.
PRC is converted from PRC of figure 2-2.
CLS is CLS of E1 format line C.
TYP is TYP of figure 2-2.
KEY is 'PCTHDL ' in operational mode
'KEN ' in test mode
SUB is 'AA' in operational mode
'QQ' in test mode
PRN is generated by PC (= [)
PSN is TBD
SIZ is generated by PC
For CCIS to CAMPS/SCARS transmission PC will provide
the Message Control Field contents as follows (cf.
figure 2-2):
IFL is generated by PC.
BSN is generated by PC.
BTY is generated by PC.
PRC is converted from PRC of figure 2-3.
TYP is TYP of figure 2-3.
Precedence (PRC) is converted as follows:
CAMPS /SCARS CCIS/DINDAC)
Flash override/superflash ---- Emergency
Flash ---- Flash
Immediate ---- Immediate
Superpriority ---- Priority
Priority ---- Priority
Routine ---- Routine
2.2.3 I̲n̲i̲t̲i̲a̲l̲i̲s̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
2.2.3.1 I̲n̲i̲t̲i̲a̲l̲i̲s̲a̲t̲i̲o̲n̲
System initialisation requires operator interaction
via VDU.
Power-on will bring the system into maintenance mode.
An Init command from the operator will initialise the
system i.e. bring up the operating system, start up
the application processes and load the LTU's. The system
will then be in local mode still offline but ready
to receive a logon command.
A logon sequence from the operator will bring the system
online. The logon command will have the following parameters:
CCIS parameters:
- SCI for the CCIS to CAMPS/SCARS channel
- userid, password for logon to DINDAC
- baud rate for outgoing line (2400, 4800
or 9600).
CAMPS/SCARS parameters:
- SCI for the CAMPS/SCARS to CCIS channel
- baud rate for outgoing line (2400, 4800
or 9600).
2.2.3.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
Close down will bring the system from online to offline
local mode. The action performed when closing down
is to disconnect the links to the end-systems.
Close down will be performed on occurrence of one of
the following events:
- Logoff command from operator.
- Disconnect from one of the end-systems.
- Link failure on one of the two links.
- Internal malfunctioning detected in PC.
2.2.4 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
2.2.4.1 U̲n̲r̲e̲c̲o̲v̲e̲r̲a̲b̲l̲e̲ ̲E̲r̲r̲o̲r̲s̲
These are errors due to PC internal malfunctioning,
link failures and failures of end-systems. If PC detects
an unrecoverable error it will close down the system
as described in section 2.2.3.
2.2.4.2 F̲r̲a̲m̲e̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲s̲
These errors are detected by low level protocols as
frame check sequence error on CAMPS/SCARS side and
block check error on the CCIS side. The protocols in
question will perform recovery in terms of retransmission
requests on occurrence of these errors.
2.2.4.3 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲E̲r̲r̲o̲r̲s̲
These are errors detected as inconsistence or invalidity
in content of the message control field of CAMPS/SCARS
level 3 frames and the segment header of CCIS segments.
Message control errors are detected and reported by
PC, but end-systems are responsible for recovery. In
the following the actions to be taken by the systems
on occurrence of a message control error are defined.
CCIS detects error in CCIS-to-CAMPS/SCARS transmission:
CCIS PC CAMPS/SCARS
BUST -
preempt -
- transaction ack
- SUPER-NAK
PC detects eror in CCIS-to-CAMPS/SCARS transmission:
CCIS PC CAMPS/SCARS
preempt -
- transaction ack
- SUPER-NAK
CCIS detects error in CAMPS/SCARS-to-CCIS transmission:
CAMPS/SCARS PC CCIS
- SUPER-NAK
- accept and
discard
until EOM
no action
timeout
PC detects error in CAMPS/SCARS-to-CCIS transmission:
CAMPS/SCARS PC CCIS
- accept and
discard
until EOM.
BUST -
- SUPER-NAK
no action
timeout
The problem in CAMPS/SCARS-to-CCIS transmissions is
that there is no way of telling the send that the transmission
went wrong. The only way is to suppress the transaction
cknowledgement, which implied that the sender will
wait until he times out.
Messages exceeding the total length limits are handled
as follows by PC:
a) For transmission towards CCIS the above procedure
for PC detected errors in CAMPS/SCARS-to-CCIS transmission
is followed.
b) For transmission towards CAMPS/SCARS the first
maximum length characters are transmitted following
by the CAMPS/SCARS preemption sequence. The remaining
part is discarded by PC.
2.2.5 R̲e̲c̲o̲v̲e̲r̲y̲
Recovery due to errors detected in the message exchange
will be implemented on frame level. PC will implement
the recovery facility contained in the CAMPS/SCARS
level 2 protocol and the CCIS RCI protocol to ensure
error free transmission of frames.
Recovery of entire transactions will not be done by
PC, this being a responsibility of the end-systems.
Recovery on detection of software failures internal
to PC will not be done. On such occurrences the system
will be closed down.
2.2.6 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
PC will implement a facility for collecting statistics
concerning frame transmission/reception to/from both
end-systems. The data collected for each side is the
number of frames transmitted, the number of frames
retransmitted, the number of error-free received frames
and the number of frames received with error.
The statistics will be displayed on the VDU on demand
and a separate command for resetting the counters will
be implemented.
2.2.7 S̲e̲c̲u̲r̲i̲t̲y̲
The security requirement is covered by the following
facilities:
a) Internal buffer memory used to store a message
in transit will be cleared as soon as the message
has passed PC. Buffers will also be cleared whenever
a preemption occurs and when a new mode is entered.
b) There will be no possibility of displaying message
content on the maintenance VDU. Neither will it
be possible to enter message text from the VDU
to be sent to the end-systems. Logon sequences
will, however, be entered from VDU and sent to
end-systems to bring the system online.
c) Data will not be lost due to PC failures since
transactions are acknowledged by the end-systems.
d) All software resides in EPROM. The system does
not contain any removable storage units such as
disk packs.
e) The converter is enclosed in TEMPEST rack when
connected to the end-systems. The VDU is the type
approved for CAMPS. The VDU is connected to the
converter by fibreoptic cable.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
In the following subsections system characteristics
are covered in terms of timing, throughput and flexibility.
2.3.1 T̲i̲m̲i̲n̲g̲
The delay in message transfer due to processing in
the converter will, in normal conditions, less than
one second. This time is defined as the time elapsed
between the last information frame received by the
converter and the last information frame transmitted
by the converter and from which is deducted the transmission
transfer time, the link turn around time and the time
that the frames are buffered up in the Protocol Converter
due to unavailability of the halfduplex PC-CCIS link.
The response time for the keyboard operation will be
within 5 sec. on 95 percent of cases.
The time required to bring a converter online will
not exceed 3 minutes.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
Message throughput is maximalised by keeping the delay
caused by the protocol conversion as low as possible.
Thus incoming messages are not collected and stored
completely in the converter before transmitted to the
other end-system. The system will allow for a message
to flow continuously through the converter with parallel
transmission and reception of the same message. As
soon as the converter has received a portion of a message
sufficient for the outgoing protocol to handle, transmission
will start. The amount of message information to be
stored in the converter depends only on the protocols
of the end-systems. It should be observed in this connection
that for transfer from CAMPS/SCARS to CCIS PC will
have to collect a whole segment (1140 bytes) since
the PC generated segment header shall contain information
about length of segment and whether more segments are
to follow or not.
The converter will be able to support data transfer
between the end-systems at up to 9600 baud line speed.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The application software will be composed of functional
components with well defined interfaces between them.
The protocols functions will be isolated and there
will be no direct interaction between the protocols
of the CAMPS/SCARS side of the converter and protocols
of the CCIS side. In this way future changes in protocols
may be implemented without having to modify the functionally
unaffected part of the system.
Since the software is located in EPROM, any modification
in software will, however, require regeneration of
EPROM.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲M̲M̲E̲N̲T̲
Environment is understood as the environment of the
application software. Therefore, this chapter describes:
- equipment on which the PC is implemented
- system software used
- electrical interfaces towards end-systems.
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
One protocol converter requires the following hardware:
One CR80S CPU/SCM Processor.
One 64K EPROM Memory Unit.
One 128K RAM Memory Unit.
Two Line Terminating Units (LTUs).
One Visual Display Unit (VDU) for start up, test
and maintenance. The VDU is shared by several converters.
The converter configuration is outline in figure 3-1.
A complete list of hardware modules used for one converter
is given in Table 3-1.
A brief description of these modules is given in sections
3.1.1 through 3.1.12.
FIGURE 3-1
CONVERTER CONFIGURATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
^
^
^ Quanity Module CR no.
^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲^
^
^
^ 1 CPU-SCM, single bus CR8002M ^
^ 1 128K W RAM CR8016M ^
^ 1 64K W EPROM CR8013M ^
^ 2 Synchronous LTU, 16K W CR8066M ^
^ 2 Line I/F Adaptor, LIA-N CR8082M ^
^ 1 CPU-SCM Adaptor, CSA CR8070M ^
^ 1 Mini Crate, single bus CR8115M ^
^ 2 V28 L/L Adaptor, 1 channel CR80110S ^
^ 1 OPTO T/R adaptor, OM-2 CR80108S ^
^ 1 Adaptor power supply CR1102S ^
^ 1 Adaptor Crate CR1104S ^
^ ̲1̲ ̲p̲e̲r̲ ̲s̲i̲t̲e̲ ̲ ̲T̲e̲m̲p̲e̲s̲t̲ ̲V̲D̲U̲,̲D̲E̲L̲T̲A̲ ̲7̲2̲6̲0̲T̲C̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲^
TABLE 3-1
CR80 EQUIPMENT FOR ONE PROTOCOL CONVERTER
3.1.1 C̲P̲U̲-̲S̲C̲M̲
Central Processing Unit and System Control Module.
Bit sliced processing unit with eight general purpose
registers. Responsible for real time clock processing,
P-Bus Control and handling of I/O interrupts.
The module contains up to 6K words of memory of which
2K W must be PROM or EPROM for the bootstrap loader.
The maintenance VDU communicates asynchronously with
the CPU-SCM at speeds up to 9600 bps.
3.1.2 1̲2̲8̲K̲ ̲R̲A̲M̲
Random Access Memory accessed from the CPU-SCM via
the Processor Bus. Address space is defined by switches
on the H/W. Each location is 16 + 2 bits for data and
parity of lower/upper bytes.
3.1.3 6̲4̲K̲ ̲E̲P̲R̲O̲M̲
64K 16 bits works of UV-ereasable PROM. Address space
is defined by a switch. Used for permanent program
storage for CR80 CPU- as well as LTU software.
3.1.4 L̲T̲U̲
Line Terminating Unit electrically interfaced by V28
L/L via metallic cables to the end-systems. The LTU's
each contains 32K bytes of RAM and 2K bytes of PROM.
16K bytes are accessible from CR80 and used for loading
application dependant processor SW. Bootloading the
LTU is accomplished by the PROM resident bootloader.
The LTU operates synchronously at 2400, 4800, or 9600
bps towards end-systems.
3.1.5 L̲I̲A̲-̲N̲
Line Interface Adaptor. Interfaces the LTU to the V28
L/L adaptor. See section 3.1.8.
3.1.6 C̲S̲A̲
CPU-SCM adaptor for I/F to operators console.
3.1.7 M̲i̲n̲i̲ ̲C̲r̲a̲t̲e̲
Single bus crate including 60A power supply and fan
unit for rackmounting of modules. See figure 3-1.
3.1.8 V̲2̲8̲ ̲L̲/̲L̲ ̲A̲d̲a̲p̲t̲e̲r̲
Low level adaptor for V24/V28 I/F to MIL-188C voltage
levels including waveshaping circuits.
3.1.9 O̲p̲t̲o̲ ̲T̲/̲R̲,̲ ̲O̲M̲-̲2̲
Optical transmitter/receiver optical modem version
2. The tempest VDU includes a similar opto I/F, OM-1
(not shown in figure 3-1).
This opto link will operate at transmission speeds
up to 9600 bps as indicated in section 3.1.1 for the
CPU-SCM.
3.1.10 A̲d̲a̲p̲t̲o̲r̲ ̲P̲o̲w̲e̲r̲ ̲S̲u̲p̲p̲l̲y̲
Separate power supply for the adaptor crate shown in
figure 3-1.
3.1.11 A̲d̲a̲p̲t̲o̲r̲ ̲C̲r̲a̲t̲e̲
Separate crate for OPTO T/R and two V28 L/L adaptors.
3.1.12 T̲e̲m̲p̲e̲s̲t̲ ̲V̲D̲U̲
Delta 7260TC TEMPEST proof VDU.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
Distinction is made between application software, system
software and development support software. Application
software is the subject of this document. System software
consists of the operating system and drivers providing
input/output facilities. Development support software
is standard software used for development of the application
software (compiler, linker etc.).
The components of system software and development support
software to be used are listed in the following.
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The system software components used are:
AMOS, Advanced Multiprocessing Operating System,
LTU drivers,
TTY driver.
3.2.1.1 A̲M̲O̲S̲
In AMOS all processes (running programs) are part of
a hierachical structure of parent and child processes.
The KERNEL process is started at system initialization
time. The KERNEL is responsible for:
o Implementation of processes,
o communication and synchronization of processes,
o I/O interrupt handling.
Implementation of processes is accomplished by creating
a process control block containing all information
necessary for process administration.
Processes may be started, stopped or totally removed
by their creator, the parent.
Memory allocation and creation of process headers are
the responsibilities of the ROOT process that resides
in the system at initialization time. ROOT is loaded
by KERNEL.
Communication and synchronization between processes
are accompleished by the send/await mechanism in the
KERNEL.
I/O interrupt handling is performed in KERNEL as well
by preempting the currently running process. The KERNEL
inspects if any processes are in a position waiting
for the interrupt. If a process is waiting for an interrupt
from the interrupting I/O device, this process is started.
3.2.1.2 L̲T̲U̲/̲T̲T̲Y̲ ̲D̲r̲i̲v̲e̲r̲s̲
LTU drivers are device handlers for the CR80 LTU. The
LTU drivers interface and application program to a
channel thereby enabling data communication between
the program and the devices attached to the channel.
The TTY driver provides the means for interfacing the
operator to the PC command interpreter.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The following development support software is used:
SWELL compiler,
CR80 linker,
CR80 editor,
AMOS Terminal Operating System (TOS),
CR80 debugger.
3.3 E̲L̲E̲C̲T̲R̲I̲C̲A̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
This section describes the electrical interfaces between
PC and the three end-systems CAMPS, SCARSII, and CCIS.
Applicable I/F control documents are:
CAMPS/PC : Reference 3
SCARSII/PC : Reference 3
CCIS/PC : Reference 12, 13, and 14
3.3.1 C̲C̲I̲T̲T̲ ̲V̲ ̲2̲4̲/̲P̲C̲ ̲P̲i̲n̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲s̲
V̲2̲4̲ P̲I̲N̲ A̲B̲B̲R̲E̲V̲.̲ N̲A̲M̲E̲
101 1 PG Protective Ground
102 7 SG Signal Ground
103 2 TD Transmitted Data
104 3 RD Received Data
105 4 RTS Request to Send
106 5 CTS Clear to Send
107 6 DSR Data Set Ready
108.2 20 DTR Data Terminal Ready
109 8 CD Carrier Detect
113 24 TC Transmitter Clock (DTE)
114 15 TC Transmitter Clock (DCE)
115 17 RC Transmitter Clock (DCE)
TABLE 3-2
V24/PC CONNECTIONS
3.3.2 P̲C̲ ̲t̲o̲ ̲E̲n̲d̲-̲S̲y̲s̲t̲e̲m̲s̲ ̲I̲/̲F̲
3.3.2.1 C̲A̲M̲P̲S̲ ̲t̲o̲ ̲P̲C̲ ̲I̲/̲F̲
FIGURE 3.3.2.1-1
CAMPS TO PC I/F
3.3.2.2 S̲C̲A̲R̲S̲ ̲I̲I̲ ̲t̲o̲ ̲P̲C̲ ̲I̲/̲F̲
FIGURE 3.3.2.2-1
SCARS II TO PC I/F
3.3.2.3 C̲C̲I̲S̲ ̲t̲o̲ ̲P̲C̲ ̲I̲/̲F̲
FIGURE 3.3.2.3-1
CCIS TO PC I/F
4̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲I̲G̲N̲
This chapter contains the top level system design.
The system is described functionally. The implementation
of the functions is defined in terms of software packages.
The package descriptions will be described in details
in a separate document.
4.1 S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The following subsections describe the system as a
whole.
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.1.1.1 S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲e̲s̲ ̲a̲n̲d̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The system will at any time be in one of four modes,
each mode defining a state with certain capabilities.
The system modes are:
a) Maintenance mode
b) Local mode
c) Operational mode
d) Test mode
The system is controlled by an operator who via the
VDU communicates with the system giving commands and
receiving responses. The execution of a command may
change the current mode of the system and the current
mode defines which commands are accepted. The system
will display a prompt on the VDU when ready to receive
a command. This prompt will also show the current mode
of the system.
Once the system is brought into operational mode, the
VDU may be removed from the converter which will continue
operating unaffected.
The relationship between modes and commands is depicted
in figure 4-1, and further described in the following
sections.
FIGURE 4-1
GRAPH SHOWING COMMAND INDUCED MODE TRANSITIONS
4.1.1.2 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲M̲o̲d̲e̲
This is the initial mode entered as a result of a 'power
up' or 'restart button activation'.
This mode provides the means to check out the functioning
of the hardware modules by running test programs. The
test programs are activated by commands entered from
the VDU. Included is also a command for dumping out
memory.
In maintenance mode the requirements to the functioning
of the software is kept at a minimum. Neither the application
software nor the operating system is required when
running maintenance mode. The CPU communicates directly
with the VDU not involving the driver.
Commands accepted:
a) C̲h̲e̲c̲k̲
Format: CHECK module name
where module name ::= CPU EPROM RAM LTUA
LTUB
(see section 4.1.5.1 for notation used in format).
F̲u̲n̲c̲t̲i̲o̲n̲: A test program checking the indicated
module is activated and the result is displayed
on the VDU.
LTUA is the CAMPS/SCARS LTU at HW address 17. LTUB
is the CCIS LTU at HW address 16.
Resulting mode: MAINTENANCE
b) D̲u̲m̲p̲
Format: DUMP start addr stop addr + no of
words
where start addr ::= hex integer
stop addr ::= hex integer
no of words ::= hex integer
F̲u̲n̲c̲t̲i̲o̲n̲: A hexadecimal memory content dump is
displayed within the limits specified. Upper limit
may be specified as either stop address or number
of words from start address.
Resulting mode: MAINTENANCE
c) I̲n̲i̲t̲
Format: INIT
F̲u̲n̲c̲t̲i̲o̲n̲: The system is initialized i.e. the operating
system is started up and the application system
is generated and initialized. The system will still
be off-line end-systems not connected).
Resulting mode: if ok LOCAL otherwise MAINTENANCE.
4.1.1.3 L̲o̲c̲a̲l̲ ̲M̲o̲d̲e̲
In this mode the system is generated and initialized
but off-line.
Commands accepted:
a) L̲o̲g̲o̲n̲
Format: LOGON CAMPS SCARS = sci S= speed
CCIS= sci S= speed
where sci is a three letter Station Channel Identifier
used in transactions originating from related
end-system,
and speed ::= 2400 4800 9600 (default 2400)
System responds by following text on next line:
$*$LOGid$password/DNM=
and operator continues the line by entering:
$*$LOG id $ password /DNM
This information will not be visible on the VDU since
blanks will be echoed following '='.
Example:
LOGON CAMPS=ABS S=4800; CCIS=DEF S=4800
$*$LOGid$password/DNM=
F̲u̲n̲c̲t̲i̲o̲n̲: Logon to the end-systems specified is performed.
Outgoing baud rates may be specified. If omitted the
default value 2400 will be used.
The string containing $*$LOG id $ password /DNM is
passed on the CCIS during the LOGON sequence.
The distinction between CAMPS and SCARS is verified
when messages are received from CAMPS/SCARS by comparing
SCI of incoming message with the value specified in
the LOGON parameter string.
For messages in the opposite direction a similar check
is performed. Failure of the SCI check results in a
close down of the system.
If both ends are opened successfully transactions may
start flowing. If one side fails, the other is closed
again. The result is displayed on the VDU.
Resulting mode: If ok OPERATIONAL otherwise LOCAL.
b) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Format: MAINTENANCE
F̲u̲n̲c̲t̲i̲o̲n̲: The system is brought into maintenance
mode.
Resulting mode: MAINTENANCE
4.1.1.4 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲M̲o̲d̲e̲
In this mode the system is online with end-systems
connected and transaction flow open.
Commands accepted are:
a) S̲h̲o̲w̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Format: SHOW STATISTICS
F̲u̲n̲c̲t̲i̲o̲n̲: For each side the accumulated values
of the following statistics counters are displayed:
No. of frames transmitted.
No. of frames retransmitted.
No. of frames received error free.
No. of frames received with error.
Resulting mode: Unchanged.
b) R̲e̲s̲e̲t̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Format:
RESET STATISTICS
Function:
The statistics counters are all reset to 0.
Resulting mode: unchanged
c) L̲o̲g̲o̲f̲f̲
Format: LOGOFF
F̲u̲n̲c̲t̲i̲o̲n̲: The end-systems are disconnected from
PC.
Resulting mode: LOCAL
d) T̲e̲s̲t̲
Format: TEST
F̲u̲n̲c̲t̲i̲o̲n̲: The system is brought into test mode.
Resulting mode: TEST
4.1.1.5 T̲e̲s̲t̲ ̲M̲o̲d̲e̲
In this mode the system is on-line with end-systems
connected.
This mode provides the means for testing each link
individually.
The test is performed by applying a loop-back procedure
to testmessages built into PC. Since PC in test mode
will violate the rule of end-to-end acknowledgement
and treat each link individually, and furthermore will
distrub the TSN numbering, this mode requires the cooperation
of the operator of the CAMPS/SCARS system. When receiving
a test message the operator at the CAMPS/SCARS side
shall send it back to the channel identifying the other
end system. The operator must also make sure that
normal transaction is suspended during test. This manual
supervision of test mode is necessary since the CAMPS/SCARS
system have no
facilities in the form of special service messages
to support an automated test procedure.
For test of the PC-CCIS link the DINDAC reflect mode
will be used for automatic loop-back. This requires
the DINDAC utilities named KEN and SAM to be available
in CCIS.
Commands accepted are:
a) V̲e̲r̲i̲f̲y̲
Format: VERIFY destination L= message length
where: destination ::= CCIS CAMPS SCARS
message length ::= integer
F̲u̲n̲c̲t̲i̲o̲n̲: One of three prestored standard messages
in E1 format is selected in accordance with the
destination specified i.e. CCIS, CAMPS, or SCARS.
The message is modified to contain the number of
bytes indicated by message length . This is done
by truncation or repetition of the standard contents
of the message.
The message is transmitted to the destination and
when acknowledged PC will wait to receive a message
from the same side. When this happens PC will acknowledge
the reception and compare in length and content
the message received with the message transmitted.
If equal the test was successful, otherwise the
test failed.
The result is displayed on the VDU.
Resulting mode: TEST
b) S̲h̲o̲w̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
See 4.1.1.4 a)
c) R̲e̲s̲e̲t̲ ̲s̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
See 4.1.1.4 b)
d) L̲o̲g̲o̲f̲f̲
See 4.1.1.4 c)
Note that it is not possible to reenter operational
mode directly. However, a logoff followed by a logon
will bring the system into operational mode.
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The approach to the implementation is based upon the
following consideration:
To ensure generality and flexibility a standard message
format will be used internally in PC. Instead of having
protocols at each side interact directly with each
other, each protocol will interact with a standard
interface. This entire separation of the protocols
at either side ensures that changes introduced in the
protocol at one side will not affect the protocols
at the other side.
The application software is divided into packages as
shown in figure 4-2. These packages are functional
units. One package may contain several processes.
FIGURE 4-2
APPLICATION SOFTWARE PACKAGES
C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲I̲)̲
CI handles communication between operator VDU and system
in local, operational , and test mode. CI sends commands
to packages responsible for their execution and receives
responses, which are converted to textual form and
displayed.
T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲T̲R̲C̲)̲
TRC monitors the system and performs the message traffic
control functions.
C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲ ̲(̲C̲S̲P̲A̲)̲
CSPA handles the blocking/deblocking of messages on
the CAMPS/SCARS side. CSPA supplies/removes and checks
the message control field of an information frame.
C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲S̲L̲P̲)̲
CSLP implements the X25 level 1 and 2 protocols used
towards CAMPS or SCARSII. CSLP is responsible for an
error free transmission/reception of frames.
CSPA resides in the LTU towards CAMPS/SCARSII.
C̲C̲I̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲ ̲(̲C̲P̲A̲)̲
CPA handles the blocking/deblocking of messages on
the CCIS side. CPA supplies/removes and checks the
DINDAC segment header.
C̲C̲I̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲L̲P̲)̲
CLP implements the RCI protocol used towards CCIS.
CLP is responsible for an error free transmission/reception
of information frames.
CLP resides in the LTU towards CCIS.
M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
MAC controls the facilities for hardware test when
the system is in maintenance mode.
MAC bootloads the application software and operating
system from EPROM.
S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲ ̲a̲n̲d̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲r̲ ̲(̲S̲G̲I̲)̲
SGI is activated by the MAINTENANCE command or a power-up
master clear. SGI sets the RAM parity and bootloads
the MAC software from EPROM.
4.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
4.1.3.1 M̲e̲s̲s̲a̲g̲e̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲
Message data flows through the system in two directions,
CAMPS/SCARS to CCIS and CCIS to CAMPS/SCARS.
Incoming frames are checked and control information
is stripped off and the resulting blocks are added
sequentially to an internal PC message buffer (described
in section 4.1.4.1). From this internal message buffer
the outgoing side picks blocks of information, adds
relevant control information and sends the frames to
the other side.
Figure 4-3 depicts the message data flow through PC.
FIGURE 4-3
MESSAGE DATA FLOW
4.1.3.2 C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Inter package control logic is designed in terms of
commands and responses.
A package will wait for a command to arrive. When this
happens the command is handled by the package (possibly
involving command requests to other packages). When
result is obtained this is communicated back in the
form of a response to the package that issued the command.
The implementation of commands and responses is based
on the interprocess communication facilities offered
by AMOS. Command requests are issued by calling the
send-message or send-signal functions. Responses are
given by calling the send-answer or send-signal functions.
Accept of commands as well as responses is performed
by call of the wait-event function.
Two processes may share a command buffer containing
command parameters on request and response parameters
on return, the access to the buffer being controlled
by the send and wait functions.
Figure 4-4 depicts the inter package control flow.
FIGURE 4-4
INTER PACKAGE CONTROL FLOW
4.1.4 C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲
4.1.4.1 P̲C̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲B̲u̲f̲f̲e̲r̲
Messages in transit are stored internally in message
buffers. There are two message buffers, one for each
direction of message transfer.
A message buffer is a data structure containing:
- message descriptor
- message text
4.1.4.1.1 M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲
The message descriptor contains the general message
attributes to be supplied as control information and
furthermore contains ststus information and current
pointers to the message text. The following figure
4-5 describes the content of the message descriptor.
DESCRIPTION BYTES TYPE VALUE
-------------------------------------------------------------
SCI - Station/channel identifier 3 char
Three letter code identification
of the sending station (defined
by operator at logon).
Fill 1 num 0
TYP - Message type 1 char
Legal values are:
Display in E1 C
Comment in E1 D
Channel check message F
Final number message G
Narrative message in E1 M
Data message in E1 N
Susdup display in E1 O
Susdup comment in E1 P
Susdup narrative message in E1 Q
Susdup data message in E1 R
PRC - Message precedence 1 char
Legal values are:
Emergency Y
Flash Z
Immediate O
Priority P
Routine R
CLS - Message classification 1 char
Legal values are:
Top secret T
Secret S
Confidential C
Restricted R
Unclassified U
STATE - State of transfer 2 num
Values TBD
FIGURE 4-5 (1 of 2)
MESSAGE DESCRIPTOR
DESCRIPTION BYTES TYPE VALUE
-------------------------------------------------------------
BLIM - Block limit 2 num
Max block size
Towards CCIS 1104
Towards CAMPS/SCARS 120
CIN - Current input 2 num
Index in message text for
next input.
COUT - Current output 2 num
Index in message text for
Text output.
FIGURE 4-5 (2 of 2)
MESSAGE DESCRIPTOR
4.1.4.1.2 M̲e̲s̲s̲a̲g̲e̲ ̲T̲e̲x̲t̲
The message text is a byte array of length TEXT ̲SIZE
(12000).
Incoming frames are loaded to the message buffer using
and updating the CIN field of the message descriptor.
Outgoing frames are taken from the message buffer using
and updating the COUT field of the message descriptor.
Figure 4-6 depicts the layout of a message buffer.
Message Descriptor
CIN
COUT
1
Message Text
text limit (12000)
FIGURE 4-6
PC MESSAGE BUFFER
4.1.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.5.1 O̲p̲e̲r̲a̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Here the operator interface to the system is described.
Format of commands and responses are defined.
4.1.5.1.1 P̲r̲o̲m̲p̲t̲
Commands to the system are entered from the keyboard
in response to a prompt on the screen indicating that
the system is ready for input. If the prompt is not
visible it will be proviked by pressing the 'attention'
key.
The prompt will indicate the current mode of the system
as shown below:
M̲o̲d̲e̲ P̲r̲o̲m̲p̲t̲
Maintenance M -
Local L -
Operational O -
Test T -
4.1.5.1.2 C̲o̲m̲m̲a̲n̲d̲ ̲S̲y̲n̲t̲a̲x̲
A command consits of one or two keywords followed by
zero or more parameters and terminated by 'return'
(pressing return key).
A command is entered on the same line as the prompt
and may not continue on the next line. Free format
is used i.e. one or more spaces between keywords and
parameters. Keywords may be abbreviated to the first
character of the keyword except for LOGON and LOGOFF
which must be written completely.
In the notation used for specifying the syntax of the
commands the symbols:
::=
have the following special meaning and are not be considered
part of the commands:
::= means is defined to be.
xxx xxx is a syntax parameter to be replaced
by what is elsewhere is defined to be.
xxx means xxx is optional and may be ommitted.
xxx yyy means either xxx or yyy.
command ::=
CHECK module name
DUMP page start addr stop addr
no of words
INIT
MAINTENANCE
LOGON CAMPS SCARS = sci S= speed ;
CCIS= sci S= speed
LOGOFF
SHOW STATISTICS
RESET STATISTICS
TEST
VERIFY destination L= message length
module name ::=
CPU EPROM RAM LTUA LTUB
page ::= hex number
start addr ::= hex number
stop addr ::= hex number
no of words ::= hex number
sci ::= a three letter station & channel id.
speed ::= 2400 4800 9600 , default is 2400
baud
destination ::= CCIS CAMPS SCARS
message length ::= integer , default 40 characters
4.1.5.1.3 E̲r̲r̲o̲r̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
In response to entering a command the following syntax
error messages may be displayed:
UNKNOWN COMMAND
meaning: The command keyword(s) is not recognised.
UNACCEPTABLE COMMAND
meaning: The command is ok but not accepted in
current mode.
PARAMETER ERROR
meaning: The keyword part is ok but the parameter(s)
is incorrect.
An error message is followed by a prompt for a new
command.
Execution of commands is terminated by printing the
following line on the VDU:
command keyword EXECUTED, RESULT = XXX
where
command keyword is 'CHECK', 'DUMP', 'INIT', etc.
and
XXX is 0000 for OK result.
In case of a non-successful execution of a command,
the package responsible will generate error codes as
follows:
CI: #9000
TRC: #A000
CPA: #B000
CSPA: #C000
MAC: #D000
SCADRV,
CSLP: #E000
CISDRV,
CLP: #F000
The three rightmost digits will contain an error code
for a further explanation of the error.
4.1.5.1.4 E̲r̲r̲o̲r̲ ̲C̲o̲d̲e̲s̲
" CI completion codes "
" ------------------- "
UNEXPECTED ̲ANSWER = #9001;
ILLEGAL ̲ID = #9002;
LTU ̲DRIVER ̲TIMED ̲OUT = #9003;
UNEXPECTED ̲EVENTTYPE = #9004;
" TRC completion codes "
" -------------------- "
TRC ̲WRONG ̲COMMAND ̲ID " #A001;
TRC ̲ALREADY ̲PENDING " #A002;
TRC ̲STATE ̲INCONSISTENCE " #A003;
TRC ̲RESPONSE ̲INCONSISTENCE " #A004;
TRC ̲WRONG ̲PARAMETER " #A005;
TRC ̲WRONG ̲MODE " #A006;
TRC ̲SCI ̲ERROR " #A007;
TRC ̲TRANSACTION ̲LENGTH ̲ERROR " #A008;
TRC ̲TIMEOUT " #A009;
TRC ̲TEST ̲FAILED " #A00A;
" CPA completon codes "
------------------- "
CPA ̲WRONG ̲COMMAND ̲ID = #B001;
CPA ̲ALREADY ̲PENDING = #B002;
CPA ̲STATE ̲INCONSISTENCE = #B003;
CPA ̲RESPONSE ̲INCONSISTENCE = #B004;
CPA ̲MESSAGE ̲CONTROL ̲ERROR = #B005;
CPA ̲NEW ̲TRANSACTION = #B006;
CPA ̲CANCELLED = #B007;
CPA ̲PROTOCOL ̲FAULT = #B008;
CPA ̲OVERRIDE ̲RAISED = #B009;
CPA ̲BUSTED = #B00A;
CPA ̲TIMEOUT = #B00B;
CPA ̲WRONG ̲PARAMETER = #B00C;
" CSPA completion codes "
" --------------------- "
CSPA ̲WRONG ̲COMMAND ̲ID = #C001;
CSPA ̲ALREADY ̲PENDING = #C002;
CSPA ̲STATE ̲INCONSISTENCE = #C003;
CSPA ̲RESPONSE ̲INCONSISTENCE = #C004;
CSPA ̲MESSAGE ̲CONTROL ̲ERROR = #C005;
CSPA ̲NEW ̲TRANSACTION = #C006;
CSPA ̲CANCELLED = #C007;
CSPA ̲TIMEOUT = #C008;
CSPA ̲WRONG ̲PARAMETER = #C009;
" MAC completion codes "
" -------------------- "
CPU TEST MOVE ERROR = #D001;
CPU TEST JUMP ERROR = #D002;
CPU TEST ARITHMETIC ERROR = #D003;
CPU TEST SHIFT ERROR = #D004;
CPU TEST SINGLE BIT ERROR = #D005;
RAM ADDRESSING ERROR = #D006;
RAM ACCESS ERROR = #D007;
RAM NOT RESPPONDING = #D008;
EPROM NOT RESPONDING = #D009;
EPROM ILLEGAL CHECKSUM = #D00A;
LTU COMPARE ERROR = #D00B;
LTU ADDRESSING ERROR = #D00C;
LTU ACCESS ERROR = #D00D;
LOCAL INTERRUPT IN PATCH = #D00E;
UNEXPECTED DUMP STATUS = #D00F;
TIME OUT IN CPU TEST = #D010;
EPROM BOOTLOAD ERROR = #D011;
UNKNOWN MODULE = #D012;
ILLEGAL CAUSE CODE = #D013;
ILLEGAL INSTRUCTION = #D014;
PARITY ERROR = #D015;
TIMEOUT LOCAL ACTION = #D016;
OTHER ERRORS = #D017;
" CSLP completion codes "
" --------------------- "
TX ̲CANCELLED = #E001
RX ̲PROTOCOL ̲DISCONNECTED = #E001
PROTOCOL ̲NOT ̲DISCONNECTED = #E001
TX ̲PROTOCOL ̲DISCONNECTED = #E002
PROTOCOL ̲NOT ̲CONNECTED = #E002
PARAMETER ̲ERROR = #E003
ILLEGAL COMMAND = #E004
" SCADRV completion codes "
" ----------------------- "
TIMEOUT ̲ERROR = #E101;
BAD ̲PROCESS = #E102;
BAD ̲RESERVEINTERRUPT = #E103;
BOOTLOAD ̲NOT ̲IMPLEMENTED = #E104;
BOOTLOAD ̲FAILED ̲FIRST ̲STATUS = #E105;
BOOTLOAD ̲FAILED ̲BYTE ̲COUNT = #E106;
BOOTLOAD ̲FAILED ̲LAST ̲STATUS = #E107;
FLOW ̲ERROR ̲C = #E108;
BUFFER ̲ERROR ̲C = #E109;
BUFFER ̲SIZE ̲ERROR = #E10A;
OPERATION ̲CANCELLED = #E10B;
NOT ̲PENDING = #E10C;
LTU ̲DEAD ̲C = #E10D;
TX ̲SEM ̲ERROR = #E111;
" CLP completion codes "
" -------------------- "
CENTRAL SYSTEM DISCONNECTED = #F011;
RECEIVED DIS GRTS II CNTRL REC. = #F012;
INVALID COMMAND T/F CENTRAL SYS = #F013;
DID NOT RECEIVE USER ID PASSWORD= #F014;
NO SNUMB ON ABORT CONTROL CARD = #F015;
MISSING SNUMB OR IDENT CARD = #F016;
OUTPUT NOT AVAILABLE = #F017;
INVALID CONTROL CARD = #F018;
INVALID MESSAGE FORMAT = #F019;
SALVE PROGRAM NOT IN SYSTEM
(DAC ONLY) = #F01A;
OUTPUT COMPLETE = #F01B;
LINK SPACE DENIED = #F01D;
LINK NUMBER ERROR = #F01D;
CENTRAL SYSTEM UNAVAILABLE = #F01E;
RETRY COUNT EXHAUSTED = #F01F;
DEVICE OFF-LINE = #F020;
END-OF-FILE (EOF STATUS
CANNOT RECOVER) = #F021;
TERMINAL NOT KNOWN = #F022;
REMOTE COMPUTER MODULE = #F023;
LINE ACTIVE = #F024;
LINE NOT COMPLETELY
DISCONNECTED) = #F025;
MEDIA CODE ERROR = #F026;
BLANK OR ZERO ID = #F027;
DUPLICATED ID = #F028;
NO PAT ENTRIES AVAILABLE
FOR INPUT = #F029;
MISSING $ SNUMB CARD = #F02A;
JOB SOURCE TO LONG = #F02B;
NO AVAILABLE PROGRAM NUMBER
FOR JOB = #F02C;
EXCESSIVE DISK ERRORS = #F02D;
DUPLICATE SNUMB'S = #F02E;
NO DISK LINKS AVAILABLE = #F02F;
LTU ERROR CODES:
CR80 BYTECOUNT RANGE ERROR = #F032;
CR80 COMMAND SYNTAX ERROR = #F042;
CR80 STATUS TYPE ERROR = #F052;
CR80 MULTIPLE COMMAND = #F062;
OPEN LINK TIMEOUT = #F072;
DATA TRANSMISSION ERROR = #F082;
OPEN LINK ERROR = #F090;
NUMBER OF NAK'S EXCEEDED = #F0A2;
CR80 ILLEGAL BAUDRATE CODE = #F0B0;
CLOSED CAUSE TOO MANY RETRANS. = #F0C2;
CURRENT STATE ERROR = #F0D2;
CLOSED LINK = #F0E2;
FATAL ERROR = #F0F2;
" CISDRV completion codes "
" ----------------------- "
TIMEOUT ̲ERROR = #F101;
BAD ̲PROCESS = #F102;
BAD ̲RESERVEINTERRUPT = "F103;
BOOTLOAD ̲NOT ̲IMPLEMENTED = #F104;
BOOTLOAD ̲FAILED ̲FIRST ̲STATUS = #F105;
BOOTLOAD ̲FAILED ̲BYTE ̲COUNT = #F106;
BOOTLOAD ̲FAILED ̲LAST ̲STATUS = #F107;
FLOW ̲ERROR ̲C = #F108;
BUFFER ̲ERROR ̲C = #F109;
BUFFER ̲SIZE ̲ERROR = #F10A;
OPERATION ̲CANCELLED = #F10B;
NOT ̲PENDING = #F10C;
LTU ̲DEAD ̲C = #F10D;
TX ̲SEM ̲ERROR = #F111;
4.2 P̲A̲C̲K̲A̲G̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
In the following subsections the tasks performed by
the software packages are described. This entire section
will be detailed in the Package Design Specification
document.
A Data Dictionary will be developed according to the
Package Design Specification. The Data Dictionary will
list global constants, variables, types and import
procedures. An alphabetic reference list is generated
as a SWELL compiler output print and will be available
during the coding phase.
4.2.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲I̲)̲
CI handles the communication between the operator VDU
and the system in local, operational and test mode.
CI sends the current mode prompt to the VDU when ready
to receive a command.
When the VDU line buffer is ready CI performs the syntax
analysis of the content in accordance with command
syntax described in section 4.1.5.1 and checks if the
command is acceptable in the current mode. If one of
these checks fails, an error message is written to
the VDU and the prompt is sent out indicating ready
for new command.
If checks are CI encodes the command and sends a request
to the package responsible for its execution.
CI waits for the reply and when received sends result
in textual form if any to the VDU.
If the result of the command implies a change of mode
CI will switch mode and prompt accordingly.
The cycle then repeats itself.
If the system is brought offline due to an unrecoverable
error, CI will send an error message to the VDU and
local mode is entered.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CI interfaces to the VDU accepting commands and giving
replies in textual form.
The commands are despatched for execution by other
packages as follows:
logon - TRC
logoff - TRC
show statistics - CSLP and CLP
reset statistics - CSLP and CLP
verify - TRC
test - TRC
maintenance - MAC no return
4.2.2 T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲T̲R̲C̲)̲
TRC performs the traffic control functions and supervises
the system when online.
TRC drives CSPA and CPA by issueing commands to these
packages and monitors the two PC-message buffers. TRC
and the PC-message buffers represent the protocol independent
part of PC.
TRC handles commands received from CI as follows:
- Logon.
Send logon command to CPA and CSPA.
If both are replied ok, send request ̲input command
to CPA and CSPA.
If one logon fails and the other is ok, send logoff
command to the latter.
Send reply to CI.
- Logoff.
Send cancel ̲operation command to CPA and CSPA if
they have unanswered requests.
Send logoff command to CPA and CSPA.
Send reply to CI.
- Test.
Send cancel ̲operation command to CPA and CSPA if
they have unanswered requests.
Switch to test mode.
- Verify.
Generate test message and load into the appropriate
PC-message buffer.
Activate output and when acknowledgeed request
input from the same side. When input is received
in the other PC-message buffer, send acknowledgement
and compare the contents of the two PC-message
buffers. If they contain the same text the test
has passed. Send reply to CI.
During normal operation TRC will sned request ̲input
commands to CSPA and CPA. When one of these is replied
a block of data corresponding to a frame has been added
to the corresponding PC-message buffer and the input
pointer CIN of the message descriptor updated. TRC
will if sufficient data are available in the buffer
send a request ̲output command to the CSPA/CPA of the
other side. If more input is expected TRC sends a new
request ̲input command.
When the last part of the message has been output and
acknowledge by receiver, TRC sneds a send ̲acknowledge
command to the other side. After this the PC-message
buffer is cleared and a new request ̲input command is
sent.
In case of an unrecoverable error TRC closes down the
links and sends error cause code to CI.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
TRC accepts the following commands from CI:
- Logon
- Logoff
- Test
- Verify
TRC issues the following commands to CSPA, CPA:
- Logon
- Logoff
- Request input
- Request output
- Cancel operation
- Send acknowledgement
4.2.3 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲o̲r̲ ̲(̲C̲S̲P̲A̲)̲
CSPA is responsible for the CAMPS/SCARS level 3 protocol
functions. Data transfer is handled blockwise CSPA
being responsible for the message control field of
the level 3 information frame.
CSPA consists of a control, an input and an output
part. The input and output part are independant of
each other and may execute concurrently.
C̲o̲n̲t̲r̲o̲l̲
The control part is responsible for opening and closing
the link towards CAMPS/SCARS and monitors the input
and output part.
I̲n̲p̲u̲t̲
Handles input requests from TRC. Issues input requests
to CSLP. When CSLP responds with a frame ready, the
level 3 control information fields are checked for
consistency, block sequence is checked and frame length
is checked. If first frame of message the PC message
buffer descriptor is loaded with control information.
The text is transferred to the PC message text buffer.
O̲u̲t̲p̲u̲t̲
Handles output requests from TRC. Takes message block
from PC message buffer and adds level 3 message control
information. Some of the control fields are taken from
the PC message buffer descriptor. When a frame is ready
an output request is issued to CSLP.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CSPA accepts the following commands from TRC:
- Logon.
- Logoff.
- Request input.
- Request output.
- Cancel operation.
- Send acknowledgement.
The commands sent from CSPA to CSLP includes:
- Reopen.
- Set up lines.
- Disconnect lines.
- Set up link.
- Disconnect link.
- Request input.
- Request output.
- Cancel input request.
- Cancel output request.
4.2.4 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲S̲L̲P̲)̲
CSLP is responsible for transmission/reception of individual
frames between PC and CAMPS/SCARS according to the
CAMPS/SCARS level 2 and level 1 protocols.
CSLP performs connect and disconnect of the link towards
CAMPS/SCARS on request from CSPA.
CSLP accepts input and output requests from CSPA. Frames
are transmitted/received and acknowledged. Recovery
is performed by retransmission of frames.
CSLP keeps account of statistics concerning frame transmission
/reception. Command for collect and reset of statistics
are accepted.
CSLP is implemented as the CAMPS X25 LAP (level 1 &
2) described in Reference 15.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Commands accepted by CSLP includes:
- Reopen
- Set up lines
- Disconnect lines
- Set up link
- Disconnect link
- Request input
- Request output
- Cancel input request
- Cancel output request
- Statistics
4.2.5 C̲C̲I̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲o̲r̲ ̲(̲C̲P̲A̲)̲
CPA is responsible for the CCIS level 3 protocol functions
and the DINDAC segment control functions.
CPA consists of a control, an input and an output part.
The input part and the output part can not be active
concurrently due to the half duplex link to CCIS.
C̲o̲n̲t̲r̲o̲l̲
The control part is responsible for opening and closing
the link towards CCIS and also controls the input and
output part.
I̲n̲p̲u̲t̲
Handles input requests from TRC. Issues input request
to CLP. When CLP responds with a segment ready, the
segment header is stripped off and checked for consistency,
sequence and length. If first segment of message, the
PC message buffer descriptor is loaded. The text part
is moved to the PC message text buffer.
O̲u̲t̲p̲u̲t̲
Handles output requests from TRC. Output is not requested
by TRC until sufficient data is available to form a
segment. A segment header is generated partly from
the information contained in the PC message buffer
descriptor. Data is transferred from PC message buffer
and out request sent to CLP.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CPA accepts the following commands from TRC:
- Logon
- Logoff
- Request input
- Request output
- Cancel operation
- Send acknowlegdement
The commands sent from CPA to CLP includes:
- Open link
- Close link
- Request input
- Request output
- Cancel input request
- Cancel output request.
4.2.6 C̲C̲I̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲L̲P̲)̲
CLP is responsible for the transmission/reception of
individual frames between PC and CCIS according to
the RCI protocol used.
CLP performs the RCI part of the logon, logoff processing
towards CCIS.
CLP accepts output requests from CPA. The output block
(segment) received from CPA is split up into frames
(sugsegments) and added frame control information before
transmitted. Frame acknowledgement is awaited and recovery
in terms of retransmission of frame may take place.
CLP accepts input requests from CPA. The incoming frame
is stripped for control information and acknowledged
if ok. Frames are assembled into a segment which is
delivered to CPA.
CLP keeps account of statistics concerning from transmission/reception.
Commands for collect and reset of statistics information
are accepted.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The commands accepted includes:
- Open link
- Close link
- Request input
- Request output
- Cancel input request
- Cancel output request
- Show statistics
- Reset statistics
4.2.7 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲M̲A̲C̲)̲
MAC controls the system in maintenance mode and handles
the communication to/from the operator VDU. The functions
performed are similar to those performed by CI, but
the MAC package runs without the support of the operating
system.
MAC is envoked either by system start/restert or by
CI receiving a MAINTENANCE command.
MAC sends the maintenance mode prompt ( M - ) to the
VDU when redy to receive a command.
When it has received a line of text from the VDU the
content is checked for syntax in accordance with the
command format in section 4.1.5.1 for maintenance mode
commands. If an error is detected, an error message
is sent to the VDU followed by the prompt indicating
ready for new command.
If command is accepted the routine responsible for
its execution is envoked.
When control is returned the cycle repeats itself.
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
MAC accepts the following commands from operator:
- Check
- Dump
- Init
The INIT command will envoke the AMOS ROOT and result
in switch to local mode with control transferred to
CI.
4.2.8 S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲ ̲a̲n̲d̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲s̲e̲r̲ ̲(̲S̲G̲I̲)̲
SGI is responsible for setting the RAM parity and for
bootloading MAC.
Before allowing the operator access to the MAC DUMP
facility the RAM part containing message buffers is
cleared as a part of the parity setting routine. This
will also be done during power up or a manual master
clear.
