top - download
⟦33273e0aa⟧ Wang Wps File
Length: 69436 (0x10f3c)
Types: Wang Wps File
Notes: CPS/SDS/028
Names: »2015A «
Derivation
└─⟦6ff65156a⟧ Bits:30006101 8" Wang WCS floppy, CR 0160A
└─ ⟦this⟧ »2015A «
WangText
#…00……00……00……00…-…02……00……00…-
-…07…,…0b…,…00…,…05…+…0b…+…00…+…06…*…0a…*…0d…*…0e…*…0f…*…05…)…0b…)…0f…)…00…)…01…)…06…)…07…(…0c…(…0d…(…00…(…01…'…09…'…0a…'…0e…'…0f…'…02…'
&…09…&…0a…&…0b…&…0e…&…0f…&…00…&…06…%…0b…%…02…%…07…$…0c…$
$…07…#…0c…#…0d…#…02…#…07…"…0d……86…1 …02… …02… …02…
…02…CPS/SDS/028
…02…840901…02……02…
I/O CONTROL
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
1.1.1 P̲u̲r̲p̲o̲s̲e̲
The Package Specification for the I/O Control package
of the CAMPS project is written to fulfil the following
objectives.
a) To provide detailed definition of the software
architecture of the I/O Control software.
b) To provide detailed definition of the CAMPS specific
I/O Control software.
c) To provide user, operational and development personnel
with details of the ongoing analysis.
d) To define in detail the interfaces with other packages
and to describe their facilities.
1.1.2 S̲c̲o̲p̲e̲
This document defines the CAMPS specific I/O Control
functions down to a level where all algorithms and
detailed logic have been defined..
Overview of the system is presented in the CAMPS systems
design.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CAMPS System Requirements
CPS/210/SYS/0001
User Procedures and Associated Formats
CPS/230/ICD/0001
Supervisor Commands and Procedures
CPS/230/ICD/0002
NICS TARE Interface
CPS/ICD/004
SCARS II
CPS/ICD/005
ACE CCIS
CPS/ICD/006
TRC, POINT-TO-POINT CONNECTION
CPS/ICD/007
OCR Interface
CPS/ICD/008
1.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
CAMPS Litsync Firmware, Detailed Design Spec.
CPS/LITS/DSP/0001
CSS-MIC/0402/PSP/1014
X25 LAP LEVEL 1 &2
CAMPS System Design Specification
CPS/SDS/001, issue I especially sections:
5.7 IOC Package
5.2 TDX Subsystem
5.1.5 I/O System
5.10 SSC Package
4.11 Error Handling
Reference manual for 7260T Video Display Terminal P/N
917M/00A000
DAMOS documents
TMS CSS/440/PSP/0037
LTU HANDLER CSS/4400/PSP/0041
TDX HANDLER CSS/4400/PSP/0038
I/O SYSTEM CSS/4400/PSP/0035
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
Access Control Control of specifically delegated
access rights before access is
allowed to an object.
Access Control List Structure associated with catalog
objects. Contains access rights
of user qroups to the objects.
Buffer List Element A descriptor of a data buffer
in memory. BLEs may be chained
to form a logically contiguous
buffer, which is not physically
contiguous.
Channel DAMOS term (TMS). Normally mapped
1 to 1 onto external electrical
channel.
Checkpoint Point from which restart/recovery
can take place.
Close-down Action taken to bring processing
within the system or a part there
of to a stop - can be either an
ordered sequence of steps or an
abrupt termination.
External Channel A channel in a telegraph circuit
or non telegraph circuit.
Field Area for input from/output to
terminal user.
File An unstructured, logically contiguos
part of a disk volume.
File Management Part of SFM handling Files
System
Initialization Brings the system from cold or
dead start into operational use.
No recovery actions are included.
Line Control Block Data item transferred within NICS
TARE.
Logical Line Multiplexed line in TDX system.
Low Speed Media Low speed teleprinter (PTP, PTR,
ROP), Point-to-point connection
and TRC.
Memory Segment Part of virtual memory. The memory
object to which security and access
control is applied.
Message Record Standard format used for CAMPS
Format internally.
Non Telegraph CCIS and SCARS.
Circuit
Operating System A process making high level decisions
about dynamic allocation of resources
to a set of descendant processes.
Priority An attribute of a process used
for scheduling purposes.
Procedure Special part of a program. It
must be called with a "procedure
call" instruction which automatically
saves the return point.
Process Execution of a specific program
operating on a specific set of
data. The active components of
the system to which security and
process control as well as resource
management is applied.
Program A sequence of instructions.
Protection The complete set of mechanisms
assuming that only the processes
authorized by security and access
control can access a given object.
Restart Reestablishes the dynamic behaviour
of the system based upon recovered
data.
Recovery Reestablishes continuity in memory
and file contents.
Security Control Control of classification and
special handling categories before
access allowed to an object.
Security Profile The data Type containing classification
and certain special handling categories
for an object.
Split Part of VDU screen separately
addressable.
Telegraph circuit NICS TARE, Point to point and
TRC.
Terminal VDU, Medium Speed Teleprinter,
Low Speed Teleprinter, Line Printer,
PTP/PTR and OCR.
In DAMOS TMS sense a Terminal
defines one connection on a shared
channel. An example is in the
X25 protocol a set of terminals
are multiplexed on one channel.
For VDUs one split is considered
to be two terminals, one for fields
input and output and one for function
keys.
User a) Person with responsibility
for input and output of messages.
b) Person located at the user
terminals in the staff cells.
The user is identical with the
term operator in the CPS/210/SYS/0001
and replaces it in CPS/SDS/001.
In DAMOS terms a USER is an application
process (see USER GROUP).
User Group A set of processes. A vehicle
for access control each process
belongs to exactly one user group.
User Group Unique identifier for a user group
Identification
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
ACP127 Allied Communication Procedures
No. 127
APPL Applications
BLE Buffer List Element
BPS Bit Per Second
CAMPS Computer Aided Message Processing
System
CC Completion Code
CCIS Command & Control Information
System
CCITT The International Telegraph and
Telephone Consultative Committee
CH Channel
CPU Central Processing Unit
CR Carriage Return
CRC Cyclic Redundancy Check
CSF In CPS/SDS/001 is the abbreviation
used to identify the CAMPS System
Functions.
CTC Counter Timer Circuit
DAMOS CR80D Advanced Multiprocessor
Operating System
DCB Device Control Block
DCE Data Circuit-terminating Equipment
DVM Device Management
DTE Data Terminal Equipment
EDC Error Detection and Correction
EOL End Of Line
EOLF End Of Line Function
ETC Et Cetera
FIFO First In, First Out
HDLC High Level Data Link Control
HW Hardware
ICD Interface Control Document
IF Interface
IFCB Interface Control Block
IO, I/O Input/Output
IOC Input/Output Control Package
IOS I/O System
ITA International Telegraph Alphabeth
LAPB Link Access Protocol B
LCB Line Control Block
LDU Logical Data Unit
LF Line Feed
LOG Log and Accountability Package
LSL Low Speed Line
LSLH Low Speed Line Handler
LTU Line Termination Unit
LTUX Line Termination Unit Wired to
the TDX bus
MAP Memory Mapping Unit
MSTP Medium Speed Tele Printer
MTBF Mean Time Between Failure
MTTR Mean Time To Repair
M&D Maintenance and Diagnostics
NA Not Applicable
NAK, NACK Negative Acknowledgement
NICS NATO Integrated Communication
System
OCR Optical Character Reader
OCH Operator Console Handler
OLP Off-line Software Package
PTCB Pending Transfer Control Block
PTP Paper Tape Puncher
PTR Paper Tape Reader
PU, P.U. Processor Unit
P-to-P, P-P Point to Point
RAM Random Access Memory
ROP Receive Only Printer
SCARS Status Control Alerting and Reporting
System
SDS CAMPS System Design Specification
SEL Synchronization Element
SIO Serial Input/Output
SOCB System Operation Control Block
SOTF Start of Transmission Function
SPI Standard Protocol Interface
SRS System Requirements Specification
SSC System Status and Control
SSP Support Software Package
STI Supra-TDX Bus Interface
SW Software
TARE Telegraph Automatice Relay Equipment
TBD To Be Defined
TDX Telecommunication Data Exchange
TEMCO Terminal Monitoring and Control
THP Traffic Handling Package
TIA TDX Bus Interface Adapter
TMS Terminal Management System
TOS Time of Occurrence
TP Tele Printer
TRC Tape Relay Center
TTY Teletype
UGI User Group Identification
VDU Visual Display Unit
WDP Watchdog Processor
X25 Protocol Name
Z80 Zilog 80
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The I/O control SW package provides the interface between
CAMPS application software and terminals and lines.
The I/O control functions can be divided into two distinct
functions:
a) Line interface control
b) Device and line control
An overview of the I/O control SW with the two main
groups is shown in figure 2.1-1.
The I/O control software break down is shown in figure
2.1-2.
FIGURE 2.1-1
FIGURE 2.1-2
2.1.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Line Interface Control covers common software for
interface to lines via LTUXs and LTUs.
It is divided into:
T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
The Terminal Management System controls logical
channels to LTUXs via the TDX system and logical
channels to the LTUs via a standard LTU handler.
The TMS supports inclusion of device/line specific
handlers.
T̲D̲X̲ ̲S̲y̲s̲t̲e̲m̲
The TDX System provides communication on logical
lines from the TDX driver via the TDX Host Interface
to a number of LTUXs or other host interfaces.
The communication is controlled by the TDX controller
firmware.
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲
The standard LTU Handler provides the means for
the Terminal Handling System to interface to LTUs
on the IO BUS. One incarnation of the Standard
LTU handler serves one LTU with up to 10 communication
lines. The standard LTU Handler interfaces up to
10 device specific Handlers.
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲M̲i̲c̲r̲o̲-̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The Standard LTU micro-processor software supports
implementation of communication line protocol software
in the CR8066D LTU. It is the IO Bus interface
for data and control information input/output.
D̲e̲v̲i̲c̲e̲ ̲&̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Device & Line Control consists of all line, channel
and device specific software and firmware.
It is divided into:
N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲C̲o̲n̲t̲r̲o̲l̲
The TARE control implements the level 2 and 3 interface
of the TARE communication (i.e. the LITSYNC protocol
and handling of messages).
S̲C̲A̲R̲S̲ ̲C̲o̲n̲t̲r̲o̲l̲
The SCARS Control implements the level 2 and 3
interface of the SCARS communication (X25 protocol
and handling of messages).
C̲C̲I̲S̲ ̲C̲o̲n̲t̲r̲o̲l̲
The CCIS Control implements the level 2 and 3 interface
of the CCIS communication (As for SCARS Control).
T̲R̲C̲/̲T̲P̲ ̲C̲o̲n̲t̲r̲o̲l̲
The TRC/TP control implements the device interface
to TRC and Teleprinter lines. This includes conversion
to and from internal record format as well as character
sequence recognition. ITA2/ITA5 Conversion.
P̲T̲P̲/̲P̲T̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲
The PTP/PTR Control implements the device interface
to PTP/PTR. This includes conversion to and from
internal record formats as well as character sequence
recognition. ITA2/ITA5 Conversion.
M̲e̲d̲i̲u̲m̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Medium Speed Teleprinter control implements
the device interface to the MSTP including conversion
from internal record format.
O̲C̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲
The OCR Control implements the device interface
to the OCR including generation of internal record
format.
V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲
The VDU Control implements the device interface
for VDUs. It consists of the format handler, VDU
handler, and VDU LTUX firmware.
S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Software Development VDU Control implements
the device interface for the software development
VDU.
S̲W̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲P̲r̲i̲n̲t̲e̲r̲ ̲H̲a̲n̲d̲l̲e̲r̲
The Printer Handler provides the device interface
to the Tracor printer used for SW development.
2.1.2 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲(̲F̲i̲g̲.̲ ̲2̲.̲1̲.̲2̲-̲1̲)̲
The IO control SW interfaces to the following external
lines (see figure).
1) NICS TARE
2) CCIS
3) SCARS
5) TRC
FIGURE 2.1.2-1
and the following devices:
4) OCR
6) TP
7) VDU
8) PTP/PTR
9) MSTP (Medium Speed Teleprinter)
10) LINE PRINTER
11) SOFTWARE DEV VDU
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲(̲N̲o̲r̲m̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲)̲
2.2.1.1 L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Line Interface Control Software interfaces the
device control software with the CR80D computer system.
It is the standard CR80 and microprocessor software
providing the interface from the application to the
line/device specific software.
For the Processor Unit, the Terminal Management System
performs the overall conversion from logical line names
to LTU or LTUX and line addresses.
The Standard LTU handlers perform the communication
with the LTUs located in the IO-crates and the TDX
driver performs the communication with the LTUX connected
to the TDX bus.
For the LTUs, a Z80 microprocessor operating system
and the CR80 interface software are common.
For the TDX, the Host interface firmware, the TDX controller
firmware, and the LTUX firmware interfacing to the
TDX bus are independent of actual devices.
Fig. 2.2.1.1-1 illustrates the Line Interface Control
Software/Firmware as distributed in a CR80D system
with LTUs on IO bus and LTUXs on the TDX bus.
FIGURE 2.2.1.1-1
T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Terminal Management System hides the physical line
characteristics for the application. The application
accesses lines by name.
The SSC package defines the relationship between names
and physical addresses, the baud rate for the external
V24 lines, the logical linespeed, protocol/device type
and security classifications. Further, the SSC package
identifies the applications to the Terminal Management
System (USER ON).
The TMS implements the security and access control
for LTU and LTUX connected lines. A request from the
application to OPEN line is validated against the capabilities
defined by SSC at the moment of USER ON.
The approach is shown in fig. 2.2.1.1-2.
Commands exist for the SSC Package to define LTUs,
LTUXs, lines, and applications.
Commands exist for the application to open and close
channels and to perform data transfer.
The TMS supports inclusion of device specific Handlers.
FIGURE 2.2.1.1-2
T̲D̲X̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The TDX system performs multiplexed data transfers
(logical lines) between the two processor units and
between the processor units and up to 242 LTUXs. It
transfers up to 819200 bps. on max. 4096 logical lines.
The transmission on the TDX bus is controlled by the
TDX controller. In the processor unit the TDX Driver
is the interface to the TDX Host Interface.
Figure 2.2.1.1-3 illustrates the TDX system.
FIGURE 2.2.1.1-3
L̲T̲U̲X̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The LTUX is the standard interface between the TDX
Bus and terminals e.g. VDU, PTP, and OCR. At the TDX
side the TDX packet protocol is used for data transport.
The smallest unit, with which the unit works, is a
TDX frame. A frame contains one protocol byte, a three
bit sequence number, five bit byte counts and up to
sixteen data bytes. (Extended HDLC protocol with CRC
check). A TDX packet may contain several frames. The
frames are numbered contiguously (module 8) in order
to ensure correct transmission.
Each LTUX interfaces to four CCITT V24/V28 external
lines and is able to handle ITA no. 2 and no. 5. The
maximum transmission speed on the external lines are
4 x 2400 bps. or 1 x 9600 bps.
The TDX Controller multiplexes the data stream on the
TDX bus in a way to allow a logical line transmission
speed up to 819200 bps. (this number depends on the
firmware configuration in the LTUX).
Each LTUX is able to interface up to 16 logical lines
by multiplexing the data stream from/to the TDX bus.
The implemented allocation of logical lines to physical
lines is shown in fig. 2.2.1.1-4 for VDUs.
T̲D̲X̲ ̲H̲o̲s̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
All traffic between a processor unit and the TDX bus
passes by the TDX Host Interface.
The Host Interface is a high band width device that
interfaces directly to the CR80D main bus.
T̲D̲X̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
The traffic on the TDX bus is controlled by the TDX
Controller.
The Controller receives all frames transmitted from
the Host Interface and LTUXs, executes CRC check and
retransmits the frames.
The main task for the TDX Controller is to control
the transmission speeds allocated by SSC for each TDX
device.
FIGURE 2.2.1.1-4
T̲D̲X̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
All errors included CRC and missing frames will result
in rejection of the complete packet immediately, without
waiting for completion of the packet. The receiving
device then requests a retransmission by replying NAK
(Negative Acknowledgement). Also the acknowledgement
sent to the transmitting device is checked for errors.
A TDX system error and switch over is handled by the
IOC and SSC in common. The watchdog continuously checks
the TDX-Controller clock and advises SSC in case of
error.
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲s̲
The Standard LTU Handlers perform the communication
to the LTUs located on the IO BUS. One incarnation
of the Handler services one LTU.
The Handler interfaces to the terminal management system
receiving request herefrom. Figure 2.2.1.1-5 illustrates
the approach.
FIGURE 2.2.1.1-5
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲M̲i̲c̲r̲o̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Standard LTU micro processor software provides
the environment for the protocol software.
a) it provides LTU initialization
b) it provides LTU on-line diagnostics
c) it provides a micro processor operating system
for executing protocol software
d) it provides pool management for buffers
e) it provides a standard queue interface to the CR80D
processor unit
f) it provides V24 drivers
The concept is shown in figure 2.2.1.1-6.
FIGURE 2.2.1.1-6
2.2.1.2 D̲e̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Device and Line Control Functions are the functions
supporting specific devices and line protocols.
In this section the device/line functions are outlined
for each device/line. In fig. 2.2.1.2-1 through 3
an overview of interface, speed, alphabet and protocols
is presented. At the end of this section (in section
2.2.1.2.14) the Internal Message Record Format is shown.
2.2.1.2.1 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the level 2 and 3 interface.
The CAMPS application (THP) sends and receives data
as a string of data in CAMPS internal message record
format. A message starts with a "Start of Message"
record and ends with an "End of Message" record.
The NICS TARE Control converts this format to the format
required for the NICS TARE line and transmits/receives
data under control of the LITSYNC protocol.
For interface details refer CPS/ICD/004.
2.2.1.2.2 S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the level 2 and 3 interface.
The CAMPS application (THP) sends and receives data
as a string of data in CAMPS internal message record
format. A message starts with a "Start of Message"
record and ends with an "End of Message" record.
The SCARS/CCIS Control converts this format to the
format required for the SCARS/CCIS line and transmits/receives
data under control of an X25 protocol.
The ACK/NAK of message is handled at the application
level.
For interface details refer CPS/ICD/005 and 006.
FIGURE 2.2.1.2-1
N̲o̲t̲e̲s̲ ̲t̲o̲ ̲F̲i̲g̲.̲ ̲2̲.̲2̲.̲1̲.̲2̲-̲1̲
1) EDC-Protocol As defined in CPS/ICD/004
2) LAP Protocol As defined in CPS/ICD/006
3) Baud Rate Underlined baud-rates shall
not be exceeded during
test.
4) Crypto I/F Interface to DOLCE as defined
in CPS/ICD/004.
5) 10 bit code Character-by-character
with odd parity. Start
bit, 7 data bit, parity
bit, and one stop bit.
6) 7 bit code Start bit, 5 data bits
and stop bit.
7) An OCR speed of 1200 baud
is for remote OCR only.
Remote OCR is an option
FIGURE 2.2.1.2-2
FIGURE 2.2.1.2-3
2.2.1.2.3 T̲R̲C̲,̲ ̲P̲o̲i̲n̲t̲-̲t̲o̲-̲P̲o̲i̲n̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the conversion to/from
CAMPS internal message record format from/to the format
required on the line. For specified lines ITA2-ITA5
conversion is performed as well.
For interface details refer to CPS/ICD/007.
2.2.1.2.4 O̲C̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the OCR segment transmission
protocol.
Data input from the OCR is returned to the application
in CAMPS internal message record format starting with
a "Start of Message" type record and ending with an
"End of Message" type record.
The protocol is in effect in the following way: When
no application input request is present ACKs to the
OCR are withheld. This gives a maximum of 512 bytes
buffered in the IOC.
Details on the interface may be found in CPS/ICD/008.
2.2.1.2.5 T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "TRC, Point-to-Point Connection Control Function".
2.2.1.2.6 P̲T̲P̲/̲P̲T̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "TRC, Point-to-Point Connection Control Function".
The PTR is equipped with a physical security key. The
activation of the key will asynchronously be reported
to the system software having initialized the PTR interface
(i.e. SSC).
2.2.1.2.7 M̲e̲d̲i̲u̲m̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲ ̲(̲M̲S̲T̲P̲)̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "TRC, Point-to-Point Connection Control Function".
The MSTP is equipped with a physical security key.
Any activation of this leads to an asynchronous report
to the system software (SSC) having initialized the
MSTP interface.
2.2.1.2.8 V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The communication method is block mode transmission.
The electrical interface is as specified in fig. 2.2.1.2-2.
Baud rates are 1200 and 2400 bps.
The VDU is equipped with a physical security key. Any
activation of this leads to an asynchronous report
to the system software (SSC) having initialized the
VDU interface.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲V̲D̲U̲.
The application SW interfaces to the VDU on split basis.
The VDU screen is divided into three splits:
VDU system area - split #0
VDU header area - split #1
VDU format area - split #2
VDU Format Area
The format area consists of a number of lines. If the
number of lines is greater than the displayed format
area (22 lines) the user may page or scroll to see
the rest.
The maximum size of the split depends on space reserved
for this split. The VDU can in total accomodate approximately
20.000 characters.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^
^ VDU SPLIT ^
^ ^
----------------------------
^ ^
^ PRESENT DISPLAYED ^ VDU
^ FORMAT AREA ^ SCREEN
^ ^
----------------------------
^ ^
^ ^ SCROLL
^ ^
^ ^
^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ^
SPLIT CONCEPT
A split consists of protected and unprotected fields
in any order. When the VDU is in format mode the user
is able to write and update within the unprotected
fields. On transmit request, only the contents of the
unprotected fields are sent to the application. The
application is able to select which fields to be transmitted
from the VDU.
Addressing
The fields in both splits are addressed by line type
numbers, incarnation numbers and field numbers. A group
of repeatable lines have the same line type number,
but different incarnation number.
Line type, Incarnation Field No.
1,1 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
1,2 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
2,1 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ 4̲ ̲ ̲ ̲
3,1 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
3,2 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
VDU SCREEN
LINE AND FIELD ADDRESSING
F̲o̲r̲m̲a̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲
The Format Handler uses the format definitions to build
up empty or filled out standard formats on the VDU
screen.
The format definitions reside in a format file. They
are fixed at system generation and contain information
about the different standard formats used by CAMPS.
The format definitions are maintained by the Offline
Package at the CSSI site.
The Format Handler keeps track of the different types
of lines in the present format and the number of lines.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The application functions listed below are given names
relative to their function.
I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲
This command defines to the Format Handler how many
VDU splits may be handled by the calling process and
the total memory available.
D̲e̲f̲i̲n̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲A̲r̲e̲a̲
This command defines the system format area to be used
in the VDU communication. The application may communicate
with more than one VDU and thus reserve more than one
format area.
The commands Initialize and Define Format area may
only be issued once per process/per split interface.
The following command may be reissued in order to redefine
the actual VDU split handled.
I̲n̲i̲t̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲
This command defines to the Format Handler which split
is actually handled via the above reserved format area.
R̲e̲m̲o̲v̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲
Cancels definition of Terminal.
G̲e̲t̲ ̲F̲o̲r̲m̲a̲t̲
This command prepares the specified format for modification
by insert lines and delete lines below as well as output
by Output Format.
O̲u̲t̲p̲u̲t̲ ̲F̲o̲r̲m̲a̲t̲
This command outputs the format obtained by Get Format
and modified as of insert and delete line. The page
now contains the text in the format with all fields
blank.
F̲i̲e̲l̲d̲s̲ ̲O̲u̲t̲p̲u̲t̲
Fields are assumed to be organized as a consecutive
sequence of records in a buffer. In parallel a list
of field identifiers (line type, incarnation, field
number) shall be specified. The Field Output function
moves the first record to the first field in the list,
the second to the second, etc.
F̲i̲e̲l̲d̲s̲ ̲I̲n̲p̲u̲t̲
The Fields Input function inputs the requested number
of fields from and including the field specified as
the first. The field content is returned as fields
in the way that trailing blanks within the fields are
omitted. If the buffer specified is not sufficiently
long the input is terminated with error.
Note that fields are not input upon depression of ENTER,
or RETURN, but that these keys are returned to the
application, which will reserve a buffer and request
the transmission.
R̲e̲c̲e̲i̲v̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Function keys destined for the application (All except
the key giving system attention) are received when
the Receive Control function is requested (pending
read).
S̲e̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
Control of VDU is performed by this command. Input
specifies either "Bell" or "Clear split".
C̲h̲a̲n̲g̲e̲ ̲F̲i̲e̲l̲d̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
If a field has been defined with changeable attributes,
they may be modified by this command. The attributes
are modified from the previous value to the specified
e.g. intensity change, flash.
I̲n̲s̲e̲r̲t̲ ̲L̲i̲n̲e̲s̲
This command inserts the specified number of lines
as incarnation of the specified line type. Calling
the specified incarnation N, the lines will be inserted
as incarnation N, N+1.... Insert Lines is allowed up
to the size of a split.
D̲e̲l̲e̲t̲e̲ ̲L̲i̲n̲e̲s̲
This command deletes the specified number of lines
from the incarnations of lines for the specified line
type calling the specified incarnation N incarnations
N, N+1.... will be deleted.
Insert Lines and Delete Lines have effect to redefine
the format obtained by Get Format and will have no
immediate effect on the VDU as long as Output Format
has not been executed. After Output Format the Insert
Lines imply an immediate shift-down of the lines on
the VDU and the Delete Lines an immediate shift-up
of lines on the VDU.
G̲e̲t̲ ̲C̲u̲r̲s̲o̲r̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲
This function is used to obtain the cursor position
and the number within the split of the first displayed
line.
S̲e̲t̲ ̲C̲u̲r̲s̲o̲r̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲
This function is used to set the first displayed line
and the cursor position.
D̲a̲t̲a̲ ̲k̲e̲y̲ ̲e̲n̲a̲b̲l̲e̲
This function enables alphanumeric keys, scroll etc.
for the VDU user.
R̲e̲p̲e̲a̲t̲ ̲l̲i̲n̲e̲g̲r̲o̲u̲p̲,̲ ̲D̲e̲l̲e̲t̲e̲ ̲l̲i̲n̲e̲g̲r̲o̲u̲p̲
This function supports Adat-P3 repetition.
C̲u̲r̲s̲o̲r̲ ̲g̲r̲o̲u̲p̲ ̲p̲o̲s̲i̲t̲i̲o̲n̲
This function determines the group that may be repeated
(Adat-P3).
2.2.1.2.9 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The Software Development VDU is interfaced according
to requirements from support software. The VDU communication
is TTY mode.
2.2.1.2.10 L̲i̲n̲e̲ ̲P̲r̲i̲n̲t̲e̲r̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "Software development VDU". The Line Printer
is as the Software development VDU interfaced via an
LTU.
2.2.1.2.11 P̲h̲y̲s̲i̲c̲a̲l̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲K̲e̲y̲
On each VDU, medium speed teleprinter, and the PTR
is a physical locking key. A terminal is activated
by turning the locking key to "ON".
2.2.1.2.12 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲o̲r̲d̲ ̲F̲o̲r̲m̲a̲t̲
All incoming information is converted from the various
types of formats, used by the external equipment, to
a standard message record format. This record format
is again converted to the proper formats when information
is transmitted to the external equipment.
The ITA no. 5 code is used. The records are separated
by a record separator.
After the record separator is a character count byte.
The byte before the text string is used to identify
the type of information. The record format is presented
in figure 2.2.1.2-4.
FIGURE 2.2.1.2-4
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
2.2.2.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The IO Control software is initialized in several steps.
The PU resident software is loaded with the system
software at time of boot load.
The PU resident software is initialized as follows.
The protocol handlers when the channels are created.
The format handler is initialized by the process in
which it logically resides (by each of the using processes).
The standard IOC software (TMS, TDX Handler) is initialized
at bootload.
The LTU microprocessor software is down-line loaded
by the PU system software and initialized for the standard
part at end of down line load, for the protocol part
when the channels are created.
The TDX firmware is initialized at power-up and when
the channels are created.
2.2.2.1.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
The IOC supports no general close-down but requires
individual close-down requests for each channel.
2.2.2.1.3 R̲e̲s̲t̲a̲r̲t̲
Refer initialization. IOC does not support restart
from a certain state but requires reinitialization
with parameters defining this state.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
NA.
2.2.2.3 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̲
The IOC reports on
Access errors (see 2.2.2.6 Security)
Request Validation errors
External interface errors
The IOC is generally set up by the SSC on a per channel
basis. The initialization commands define the channel
type, LTU, LTUX address, speed and classification.
The possible errors detected within IOC depend on initialization
prior to the validation.
2.2.2.3.1 R̲e̲q̲u̲e̲s̲t̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲s̲
During initialization, attempts to create more than
the maximum of channels of a type given at system generation,
attempts to create channels, where the software/firmware
is not configured, or attempts to classify channels
higher than maximum for the device, will be terminated
with error.
Application request to access terminals not properly
initialized will be terminated with error.
2.2.2.3.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲E̲r̲r̲o̲r̲s̲
Errors in data, i.e. parity error or irrecoverable
protocol detected errors are reported to the requestor
of the data and in form of an asynchronous report to
the system software having initialized the channel.
Unexpected change of status of the external interface,
i.e. V24 line change or detection of key on/off (either
status line or character sequence) leads to a autonomous
close of the channel with report to the creator system
software (i.e. SSC).
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
All parameters specified by the application for data
transfer and specified by the SSC for initialization
will be verified for those impacting internal data.
Data transmitted on channels at set-up (e.g. VDU initialization)
will indirectly be verified at subsequent accesses.
Parameters obtained from DAMOS for the protocol handlers
or from the System Call Monitor for the Format Handler
will not be verifed since they are already verified
by DAMOS.
The handlers within IOC are integrated in the DAMOS
with a set of maximum privileges so any error within
these may cause a total system failure.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲(̲L̲o̲g̲,̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲,̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲s̲)̲
IOC does not interface directly with LOG, STP, however
for each channel statistics on the number of transferred
characters and the number of errors of protocol or
parity type are collected and become available on request.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The Security measures within IOC can be sub-divided
into access control and other security measures.
2.2.2.6.1 A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The access control within IOC is handled by TMS. SSC
specifies for each terminal the access rights.
The application gains access in one of two ways.
1) By having access right and requesting OPEN.
2) By getting a terminal connection offered from a
process having access right.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
In this section only timing for data transfer is discussed
since initialization commands do not impact normal
operation.
2.3.1.1 P̲U̲ ̲T̲i̲m̲i̲n̲g̲
In the timing given below is included the time to transfer
the request and the response via the Input/Output System.
N̲o̲n̲-̲F̲o̲r̲m̲a̲t̲ ̲h̲a̲n̲d̲l̲e̲r̲
Input or Output request 20ms
15ms + 5 ms * DATASIZE/128(TRC,MSTP)
15ms + 5 ms * DATASIZE/512 (OCR)
F̲o̲r̲m̲a̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲
Timing depends on the size of format and the type of
operation.
O̲u̲t̲p̲u̲t̲ ̲F̲o̲r̲m̲a̲t̲
Per 512 bytes format length 1 disk access
Per 300 bytes format length 25ms
F̲o̲r̲ ̲F̲i̲e̲l̲d̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
Per consecutive group of
fields (either protected or
non-protected) 25ms
2.3.1.2 T̲D̲X̲ ̲T̲i̲m̲i̲n̲g̲
Input or output transfer of one line (one record in
internal format).
For VDU 200ms delay
For Lowspeed lines 2s delay
For OCR 100ms delay
For VDU a TDX baudwidth of 6400 baud, for Low Speed
lines 400 baud and for OCR at least 12.800 baud is
assumed.
2.3.1.3 L̲T̲U̲X̲ ̲a̲n̲d̲ ̲L̲T̲U̲ ̲T̲i̲m̲i̲n̲g̲
The LTU and LTUXs must be able to handle the prescribed
throughput.
2.3.1.4 T̲i̲m̲i̲n̲g̲ ̲E̲x̲a̲m̲p̲l̲e̲
For input of one VDU command (command line) with a
command size of 60 characters the timing will be
1. Transmission of "Return" key
to LTUX 8 characters ( 1200 baud) 66 ms
2. Transmission of function key report
to PU 15 ms
Maximum delay on TDX packed 20 ms
3. Format Handler delay receive function
key + request read 20 ms
4. Transmission of ARM to LTUX
( 20 chars) 30 ms
Max delay on TDX 20 ms
5. Transmission of ARM to VDU
1200 baud) 170 ms
6. Transmission of 60 chars to LTUX 500 ms
7. Transmission of 60 chars LTUX to PU 100 ms
Max. delay TDX 20 ms
8. Max. delay on response ̲2̲0̲ ̲m̲s̲
Total time before response starts 981 ms
Transmission time for command (60 chars) 500 ms
Assuming a transmission starts from the VDU immediately
after depression of "Return" the IOC contributes to
the response time in the sense of CPS/210/SYS/0001
section 3.4.1.6.3 by 481 ms.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
Refer CPS/210/SYS/0001 section 3.4.1.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
At system generation a maximum number of LTUs, LTUXs,
Channels of each type (protocol software) is defined
together with a set of restrictions in the configuration.
This system generation definition conforms with the
expandability requirement for the site in question.
An on-line definition of channels and terminals as
well as reconfiguration is possible within these restrictions.
The requirement for maximum equipment configuration
is reflected within IOC in a way that makes it possible
to configure this maximum configuration at system generation.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
NA.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
The IOC is the software that transforms the CR80D hardware
with CAMPS extensions to a standardized interface for
the application program. As such the IOC should be
seen as part of the environment for the application
program.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The IOC consists of Standard System Software and the
CAMPS extensions for specific channel interfaces.
This implies that the CAMPS extensions run with the
same privileges of and the same strict requirements
to the system software in which it is integrated.
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 CR80D development environment for software.
The LTU/LTUX microprocessor software development on
a HP 64000 development and emulator system.
The Off-line Package FORMAT GENERATOR for Format Generation.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The IOC implements the external interfaces and as such
the interface is part of the functional specification,
refer section 2.2.1.2.
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Requestors of IOC services are of one of two categories.
System Software (for CAMPS SSC) with privileges to
define CAMPS environment in form of channels and Application
Software, which is the software requesting data transfer.
As the task of the IOC is to provide a standard interface
to the environment any specific package interface shall
be found in the package specifications for packages
interfacing to IOC.
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
3.4.1 R̲e̲s̲t̲a̲r̲t̲
The IOC is in principle a cold start system so the
task to bring up IOC to a state reflecting a recovery
situation is left to the SSC package.
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
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̲
The IOC is divided into two major function groups.
1.1 The LINE INTERFACE CONTROL functions and
1.2 DEVICE AND LINE CONTROL functions
The LINE INTERFACE CONTROL functions are as standard
components of the CR80D system not a part of the CAMPS
software development and are only described below to
provide an understanding of the implementation of the
interfaces to DEVICE AND LINE CONTROL functions.
The DEVICE and LINE control functions for software
development are as well standard components of the
CR80D system and will not be further described.
Figures 4.1.1-1 through 11 present the breakdown of
IOC functions.
Figure 4.1.1-1 gives an overview of the IOC. The left
part presents the standard DAMOS part and the right
part the CAMPS specific functions.
The following figures present the IOC function related
to each of the terminals/lines interfaced.
FIGURE 4.1.1-1
FIGURE 4.1.1-2
FIGURE 4.1.1-3
FIGURE 4.1.1-4
FIGURE 4.1.1-5
FIGURE 4.1.1-5
FIGURE 4.1.1-6
FIGURE 4.1.1-6
FIGURE 4.1.1-7
FIGURE 4.1.1-8
FIGURE 4.1.1-9
FIGURE 4.1.1-10
FIGURE 4.1.1-10
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
4.1.2.1 O̲v̲e̲r̲v̲i̲e̲w̲
The Software Structure of the IOC is determined when
1) The external interface hardware of the equipment
is fixed, i.e. whether interfaced via LTUs in the
Channel Unit or LTUXes on the TDX.
2) The functions to be performed are defined as belonging
to one of 4 major groups.
a) Application oriented functions
b) Data conversion functions
c) Terminal definition in sense of DAMOS
d) Hardware (line) control functions
3) The functions, that are common to more than one
interface are determined (refer to section 4.1.1).
Figure 4.1.2.1-1 presents an overview of the CR80D
Hardware and Software frames for implementation of
IOC functions. The double-formed boxes are areas for
implementation of CAMPS IOC functions.
FIGURE 4.1.2.1-1
M̲o̲n̲i̲t̲o̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲,̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
Application oriented functions (refer group a above)
are implemented in either a monitor procedure in the
calling process or in a service process. As the access
rights of the application within DAMOS are checked
by TMS against the capabilities of the accessing process,
an implementation of application oriented functions
within a monitor procedure preserves the effect of
DAMOS access control mechanisms, where an implementation
within a service process would have to leave certain
access checks to this process.
T̲e̲r̲m̲i̲n̲a̲l̲ ̲H̲a̲n̲d̲l̲e̲r̲s̲ ̲a̲n̲d̲ ̲L̲T̲U̲X̲/̲L̲T̲U̲ ̲L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The terminal handlers define the terminals to TMS (refer
group c above) and application. Each terminal has a
system connection and a number of application connections.
The LTU/LTUX line interface software implements the
control of V24 lines, character transmission etc. (refer
group d above).
Either the Handlers or the LTU/LTUX software defines
the allocation of terminals to lines.
Data conversion functions (refer group b above) may
be performed at any level, i.e. there are no architectural
bindings.
4.1.2.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
Function numbers refer to section 4.1.1. Figure 4.1.2.2-1
to 4.1.2.2-4 provides an overview.
FORMAT HANDLER SUBPACKAGE:
This sub-package implements application Split interface.
1.2.1.1.1
LTUX HANDLER SUBPACKAGE:
This subpackage implements
for VDU 1.2.1.1.2 Concurrent Split Access
for MSTP 1.2.1.2.1 Control Function Handling
FIGURE 4.1.2.2-1
FIGURE 4.1.2.2-2
FIGURE 4.1.2.2-3
FIGURE 4.1.2.2-4
for PTP/PTR 1.2.1.3.1 Control Function Handling
for TRC/P-P 1.2.1.4.1 Control Function Handling
for OCR 1.2.1.5.1 Control Function Handling
LTU HANDLER SUBPACKAGE:
This subpackage implements:
for NICS TARE 1.2.2.1.1 Control Function Handling
1.2.2.1.2 Data Format Control
1.2.2.1.3.1 Message Handling
For CCIS/SCARS 1.2.2.2.1 Control Function Handling
1.2.2.2.2 Data Format Control
1.2.2.2.3.1 Message Handling
1.2.2.2.3.2 Segment/Frame Handling
LTUX FUNCTIONS SUBPACKAGE
This subpackage implements
for VDU 1.2.1.1.3 Data Transmission Control
1.2.1.1.4 Data Format Control
1.2.1.1.5 Data Transmission Verification
1.2.1.1.6 V24 Lines Control
for MSTP 1.2.1.2.2 Data Format Control
1.2.1.2.3 V24 Lines Control
for PTP/PTR 1.2.1.3.2 Data Format Control
1.2.1.3.3 V24 Lines Control
for TRC/P-P 1.2.1.4.2 Data Format Control
1.2.1.4.3 V24 Lines Control
for OCR 1.2.1.5.2 Data Format Control
1.2.1.5.3 V24 Lines Control
NICS TARE LTU FUNCTIONS SUBPACKAGE
This subpackage implements
1.2.2.1.3.2 Segment/Frame Handling
1.2.2.1.3.3 Link Access
1.2.2.1.4 V24 Control
CCIS/SCARS LTU FUNCTIONS SUBPACKAGE
This subpackage implements
1.2.2.2.3.3 Link Access
1.2.2.2.4 V24 Control
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 O̲v̲e̲r̲v̲i̲e̲w̲
A good way of viewing the IOC is as a transformer between
the application requests for communication with external
devices/lines and the electrical interface to this
external world. The top level data flow should be viewed
from this standpoint.
Figure 4.2.3-1 presents the interfaces between subpackages
within IOC as well as system application and external
interfaces.
The following major events occur:
(refer figure 4.1.3-1 for numbers in circles)
1) The application requests processing for a VDU by
calling the Format Handler (via the System Call
Monitor of CSF). The request leads to File I/O
(not shown) and to data transfers to/from VDU.
2) The application requests I/O operations on lines/devices,
that are not VDUs. By call of IO system functions
(refer Kernel) data is transferred.
FIGURE 4.1.3-1
3) The SSC specifies Create Terminal to the Terminal
Management System. The SSC may receive error information
and predefined function keys ("System") via an
asynchronous report.
4) The Format Handler uses the same IOC functions
as the application does for data transfer.
5, 7)
The SSC call of Create Terminal makes the TMS call
the specified handler specifying creation of terminal.
TMS react to "break" specified for the VDU or line.
11, 13, 15)
The Handlers initialize the channels (i.e. the
LTU or LTUX firmware) according to the TMS specification
6, 8)
The TMS directs data transfer to the Terminal specified
by the connection (Application or System)
12, 14, 16)
The Handlers initiate data transfers to the firmware.
4.1.3.2 V̲D̲U̲ ̲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.2.1 O̲v̲e̲r̲v̲i̲e̲w̲
Data processing in communication with the split screen
VDU is divided into 3 major parts.
1. The transmission and reception of VDU data (communication
control)
2. The administration of the split screen concept.
3. Administration of content of a formatted split.
The communication control is handled by the LTUX Function
Subpackage.
The split screen concept is handled by the VDU HANDLER
(in LTUX handler subpackage)
The formatting is handled by the FORMAT handler.
4.1.3.2.2 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
The dataflow for a VDU from the moment of initialization
is described below.
The SSC initialized the VDU by transmission through
APPEND ̲CONTROL to the VDU handler. The initialization
data sets up splits, function keys and other monitor
parameters, assuming that any parameter may be wrong
(except the transmission speed).
Normal flow is shown on fig. 4.1.3.2-1.
Output processing is described by event numbers 1..8
1. The FORMAT Handler calls the IOS procedure APPEND
̲BYTES for transfer of data.
2. The VDU handler reserves a buffer for the communication
and returns it to TMS. TMS loads the data and hands
it back to the VDU handler.
FIGURE 4.1.3.2-1…01…VDU DATA FLOW
3. The VDU handler adds split addressing information
in front of the buffer and sends it via TDX system
to the LTUX. One request (1) may be transmitted
in several steps (more than one buffer)
4. The LTUX transmits the buffer to the VDU and awaits
acknowledge.
5. VDU returns positive or negative acknowledge. For
negative acknowledge the buffer is retransmitted.
6. The LTUX sends a control buffer back to the VDU
handler giving the result of the transmission.
7,8 The result is returned to TMS and the FORMAT handler.
Input requests are processed as follows (events
a..j)
a+b. The FORMAT Handler requests input by a combined
READ BYTES and APPEND BYTES. The output contains
the ARM command for the VDU.
c+d. The combined request is handled to the VDU
handler, which immediately answers the output
(i).
e. The VDU handler builds a control buffer with
split address and ARM command and sends it
to the LTUX (input request)
f. The LTUX sends the ARM command to the VDU with
a buffer size.
g. The VDU sends first part of data as requested
by the LTUX. The VDU may include a more data
indication so that the LTUX will repeat f and
g until all data has been received.
h+j. All buffers received are handled back
to the VDU handler which returns it to the
FORMAT handler.
4.1.3.2.3 V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲l̲o̲w̲
Any time a function key is depressed the VDU sends
an interrupt to the LTUX indicating which key. This
report is sent back to the VDU handler in a control
buffer marked interrupt.
If it is the attention key (defined as system key)
a report is sent to the synchronization element of
SSC else the VDU handler returns the function key on
the control connection to the FORMAT handler for the
split actually in operation.
If it is a key on or key off report is is returned
to SSC as above.
4.1.3.3 L̲o̲w̲ ̲S̲p̲e̲e̲d̲ ̲L̲i̲n̲e̲ ̲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.3.1 O̲v̲e̲r̲v̲i̲e̲w̲
The Low Speed Lines Data Flow is handled by the LSL
handler (in the LTUX handler subpackage) and the LTUX
Function subpackage.
Application requests for data transfers are presented
to the LSL handler via IOS and TMS requests APPEND
̲BYTES and READ ̲BYTES.
4.1.3.3.2 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
Output flow (refer fig. 4.1.3.3-1)
1. The application calls APPEND ̲BYTES
2. TMS requests a sequence of output buffers, fills
these and returns them to the LSL handler.
3. The buffers are sent to the LTUX
4. The LTUX transmit the data on the line.
FIGURE 4.1.3.3-1…01…LSL Data Flow
5. When the last bytes of the sequence of buffers
have been transmitted a transmission status is
sent back to the LSL handler.
6. TMS/IOS is notified of the completion.
7. The requestor is notified.
For input processing:
a. The Application requests input to IOS by issuing
READ ̲BYTES.
b. TMS requests the LSL handler of input buffer.
c. The LSL handler sends an input request to the LTUX.
d. Data arrives.
e. Buffers with data are sent back to the LSL handler.
The input is only terminated if either a message
termination is detected or a too long timespan
exist between two characters.
f. Data is returned to TMS
g. Data returned to application.
If the application buffer is not big enough the
events b-c-d-e-f will still look as one request,
but IOS may terminate (g) the application request
with code (More Data). A subsequent request (a)
will for the LSL handler look as being part of
the first request.
4.1.3.4 M̲S̲T̲P̲ ̲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.4.1 O̲v̲e̲r̲v̲i̲e̲w̲
The MSTP data is handled by the LSL handler (LTUX Handler
subpackage) and the LTUX Function subpackage.
4.1.3.4.2 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
Refer fig. 4.1.3.4-1.
Output processing.
1. The application calls APPEND ̲BYTES
2. TMS requests a sequence of output buffers, fills
these and then returns to the LSL handler.
3. The LSL handler sends the buffers to the LTUX.
4. The LTUX transmits the data.
5. When the last byte has been transmitted a transmission
status is returned to the LSL handler.
6. Completion notification is returned to TMS
7. Completion returned to application.
FIGURE 4.1.3.4-1
4.1.3.4.3 C̲o̲n̲t̲r̲o̲l̲ ̲F̲l̲o̲w̲
The LTUX sends reports of key on/key off as control
buffers type interrupt to the LSL handler, who sends
a report to the synchronization element defined at
creation time (SSC).
4.1.3.5 O̲C̲R̲ ̲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.5.1 O̲v̲e̲r̲v̲i̲e̲w̲
The OCR data is handled by the OCR handler in the LTUX
Handler subpackage and the LTUX Function subpackage.
4.1.3.5.2 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
Refer fig. 4.1.3.5-1
a. The application calls READ ̲BYTES
b. The request is presented to the OCR handler.
c. The OCR handler builds an input request and sends
it to the LTUX.
d. The LTUX receives data from the OCR
e. The data is returned to the OCR Handler.
f. The data is returned to TMS
g. The data is returned to the requestor.
FIGURE 4.1.3.5-1…01…OCR DATA FLOW
The OCR interface (protocol) allows control of the
dataflow to CAMPS. This is accomplished as follows.
h. Whenever an ETB is received by the LTUX and provided
that at least 512 bytes buffer span is available
acknowledge is returned to the OCR(1). The lack
of buffers in the OCR handler then makes the TDX
bus protocol having flow control on the data.
4.1.3.6 NICS-TARE Data Flow and Control Logic.
4.1.3.6.1 O̲v̲e̲r̲v̲i̲e̲w̲
The NICS-TARE data is processed by the NICS-TARE handler
in the LTU handler subpackage and by the NICS-TARE
LTU FUNCTION Subpackage.
4.1.3.6.2 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
Refer fig. 4.1.3.6-1
The LTU sends/receives data on a block level. The data
interface LTU-Handler is on a segment level and the
Handler ̲TMS interface is on a message level.
Output processing is as follows.
1. The Application calls APPEND ̲BYTES. The data is
the first data for a message.
2. The request is transferred to the NICS-TARE handler,
who hands back a local buffer for TMS to fill.
3. After conversion and segmenting the data is handed
segment by segment to the LTU.
4. Data is transmitted and
5. Acknowledge is received.
FIGURE 4.1.3.6-1…01…NICS-TARE Data Flow
6. The LTU notifies the handler of successful transmission
of the segment.
7. All output requests except the last for a message
are acknowledged immediately. The last for a message
is acknowledged when the acknowledge has been received
from the LTU of the end of message segment.
8. The ack is returned to the requestor.
Input processing is as follows.
a. The application calls READ ̲BYTES
b. The request is transferred to the NICS-TARE
handler.
c. Input requests on a segment basis is released
to the LTU.
d. Data is received
e. Data is handed to the NICS-TARE handler.
f. After conversion data is handed to TMS.
g. Data is handed to requestor
j, k. The NICS-TARE handler releases acknowledges
to the LTU except for the last segment of a
message.
h,i,j,k.The acknowledgement of last segment is
initiated by the application.
4.1.3.6.3 C̲o̲n̲t̲r̲o̲l̲ ̲F̲l̲o̲w̲
In this section the state-events for Local and Remote
Tare are described.
4.1.3.6.3.1 S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲ ̲L̲e̲v̲e̲l̲ ̲1̲ ̲L̲o̲c̲a̲l̲ ̲T̲a̲r̲e̲
S̲t̲a̲t̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
B̲:̲ ̲ ̲E̲N̲A̲B̲L̲E̲D̲
No clocks provided
106 OFF
107 OFF
C̲:̲ ̲ ̲S̲E̲T̲T̲I̲N̲G̲ ̲U̲P̲
Immediate Transfer to Running
D̲:̲ ̲ ̲R̲U̲N̲N̲I̲N̲G̲
Transmit and Receive Clocks Provided
107 ON
106 ON
E̲:̲ ̲ ̲C̲L̲E̲A̲R̲I̲N̲G̲ ̲D̲O̲W̲N̲
Immediate Transfer to Enabled.
These states are identical to the high level states
described in section 4.1.3.6.3.3.
A̲c̲t̲i̲o̲n̲ ̲L̲i̲s̲t̲ ̲L̲e̲v̲e̲l̲ ̲1̲ ̲L̲o̲c̲a̲l̲ ̲T̲a̲r̲e̲
S̲t̲a̲t̲e̲,̲ ̲E̲v̲e̲n̲t̲ Action
B, Setup Transmit clock ON
Receive clock ON
Circuit 107 ON
Circuit 106 ON
C, Imm.st.tr. None
D, Clear Down Circuit 106 OFF
Circuit 107 OFF
Receive Clock OFF
Transmit Clock OFF
E, Imm. st.tr. None
S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲-̲D̲i̲a̲g̲r̲a̲m̲
Fig. 4.1.3.6.3.1 shows the State-Event diagram for
level 1, Local Tare.
Setup Clear Down Immediate state
Transfer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
B: Enabled C: Setting up
C: Setting
up D: Running
D: Running E: Clearing
Down
E: Clearing
Down B: Enabled
FIGURE 4.1.3.6.3.1…01…State-Event Diagram Local Tare
4.1.3.6.3.2 S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲ ̲L̲e̲v̲e̲l̲ ̲1̲ ̲R̲e̲m̲o̲t̲e̲ ̲T̲a̲r̲e̲
S̲t̲a̲t̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
1̲:̲ ̲S̲T̲O̲P̲P̲E̲D̲ ̲1̲0̲7̲ ̲O̲F̲F̲
105 OFF
108 ON
2̲:̲ ̲S̲T̲O̲P̲P̲E̲D̲ ̲1̲0̲7̲ ̲O̲N̲
105 OFF
108 ON
3̲:̲ ̲S̲E̲T̲T̲I̲N̲G̲ ̲U̲P̲ ̲
105 ON
N second timer running
108 ON
4̲:̲ ̲R̲U̲N̲N̲I̲N̲G̲
105 ON
108 ON
5̲:̲ ̲S̲Y̲N̲C̲ ̲R̲E̲T̲R̲Y̲
105 ON
N second timer running
108 ON
6̲:̲ ̲M̲A̲N̲U̲A̲L̲ ̲S̲E̲T̲U̲P̲
105 ON
108 ON
7̲:̲ ̲S̲E̲T̲U̲P̲ ̲A̲F̲T̲E̲R̲ ̲M̲A̲N̲U̲A̲L̲
105 ON
108 ON
8̲:̲ ̲C̲L̲E̲A̲R̲I̲N̲G̲ ̲D̲O̲W̲N̲
Statuslines are set to status STOPPED
T̲R̲A̲N̲S̲I̲T̲I̲O̲N̲ ̲A̲C̲T̲I̲O̲N̲ ̲L̲I̲S̲T̲
T̲R̲A̲N̲S̲I̲T̲I̲O̲N̲ A̲C̲T̲I̲O̲N̲
1, Setup "Setup Failed"
1, 107 ON None
2, Setup Clear Retry Count
Set 105 ON
Start N Second Timer
2, 107 OFF None
2, 106 + 109 ON Set 105 ON
Report "MANUAL SYNC"
3, Clear Down None
3, N S Timer Run out Increment Retry Count
105 OFF
Wait 1400 ms
105 ON
Start N Second Timer
3, 107 OFF Answer "SET UP
FAILED"
105 OFF
3, 106 + 109 UP Answer "SET UP OK"
3, RETRY COUNT EXCEEDED Answer "SET UP FAILED"
105 OFF
4, CLEAR DOWN None
4, 107 OFF 105 OFF
"LINK FAILED"
RESET RETRY COUNT
4, 106 or 109 OFF 105 OFF
Wait 1400 ms
105 ON
Start N Seconds Timer
5, CLEAR DOWN None
5, N S TIMER Run Out 105 OFF
Wait 1400 ms
105 ON
Start N Second Timer
5, 107 OFF 105 OFF
"LINK FAILED"
5, 106 + 109 ON None
5, RETRY COUNT EXCEEDED 105 OFF
"LINK FAILED"
6, Set up None
6, 107 OFF 105 OFF
6, 106 or 109 OFF 105 OFF
7, CLEAR Down None
7, IMMEDIATE STATE TRANSFER Answer "SET UP OK"
8, IMMEDIATE STATE TRANSFER 105 OFF
Answer "CLEAR DOWN OK"
S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.1.3.6.3.2-1 presents the State-Event diagram.
FIGURE 4.1.3.6.3.2-1…01…State-Event Diagram…01…Level 1 Remote Tare
4.1.3.6.3.3 H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲ ̲f̲o̲r̲ ̲L̲e̲v̲e̲l̲ ̲1̲
The Local Tare states described in section 4.1.3.6.3.1
and the Remote Tare states described in section 4.1.3.6.3.2
can be modeled in a common set of states as seen from
a higher level.
The Disabled state is the state where CAMPS is an undefined
state (Possibly Power is off).
S̲t̲a̲t̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
State A Disabled
CAMPS Equipment is passive
State B Enabled
Correspond to state B Local Tare and state
1, 2, 6 Remote Tare
State C Setting Up
Correspond to state C for Local Tare and
to states 3, 7 for Remote Tare.
State D Running
Correspond to state D for Local Tare and
to states 4, 5 for Remote Tare.
State E Clearing Down
Correspond to state E for Local Tare and
to state 8 for Remote Tare.
S̲t̲a̲t̲e̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.1.3.6.3.3-1 presents the state diagram.
FIGURE 4.1.3.6.3.3-1…01…Level 1 high Level State Diagram
L̲e̲v̲e̲l̲ ̲1̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
COMMAND ACTION RESPONSE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
E̲N̲A̲B̲L̲E̲ 108 ON ENABLE OK
(CRYPTO ONLY)
S̲E̲T̲U̲P̲ SETUP SETUP OK
SETUP FAILED
+ CODE
C̲L̲E̲A̲R̲ ̲D̲O̲W̲N̲ CLEAR DOWN CLEAR
DOWN
OK
A̲s̲y̲n̲c̲r̲o̲n̲o̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲s̲
Manual Syncronization (Crypto Only)
Link Failed + Code
4.1.3.6.3.4 S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲ ̲E̲D̲C̲ ̲a̲n̲d̲ ̲L̲e̲v̲e̲l̲ ̲1̲
S̲T̲A̲T̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
1̲:̲ C̲L̲O̲S̲E̲D̲
LEVEL 1 in state B ENABLED
EDC passive
2̲:̲ L̲E̲V̲E̲L̲ ̲1̲ ̲ ̲S̲E̲T̲T̲I̲N̲G̲ ̲U̲P̲
LEVEL 1 is setting up
(Refer level 1 description)
3̲:̲ E̲D̲C̲ ̲R̲E̲C̲E̲I̲V̲E̲R̲ ̲S̲T̲A̲R̲T̲U̲P̲
The EDC is initializing the capability of receiving
all types of EDC blocks
4̲:̲ E̲D̲C̲ ̲O̲U̲T̲G̲O̲I̲N̲G̲ ̲S̲T̲A̲R̲T̲U̲P̲
EDC is sending SET B, RR blocks
5̲:̲ A̲W̲A̲I̲T̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲S̲T̲A̲R̲T̲U̲P̲
The EDC awaits that first SET B block received
(it may already have been received)
6̲:̲ R̲U̲N̲N̲I̲N̲G̲
EDC running, level 1 running
7̲:̲ L̲E̲V̲E̲L̲ ̲1̲ ̲C̲L̲E̲A̲R̲I̲N̲G̲ ̲D̲O̲W̲N̲ ̲(̲A̲F̲T̲E̲R̲ ̲C̲L̲O̲S̲E̲)̲
The EDC has commanded level 1 to Clear Down
8̲:̲ L̲E̲V̲E̲L̲ ̲1̲ ̲C̲L̲E̲A̲R̲I̲N̲G̲ ̲D̲O̲W̲N̲ ̲(̲A̲F̲T̲E̲R̲ ̲E̲D̲C̲ ̲E̲R̲R̲O̲R̲)̲
The EDC has commanded level 1 to Clear Down.
T̲R̲A̲N̲S̲I̲T̲I̲O̲N̲ ̲A̲C̲T̲I̲O̲N̲ ̲L̲I̲S̲T̲
T̲R̲A̲N̲S̲I̲T̲I̲O̲N̲ A̲C̲T̲I̲O̲N̲
1, OPEN Command Level 1 Setup
2, CLOSE "OPEN FAILED"
Initiate Level 1 CLEAR
DOWN
2, LEVEL 1 SETUP "OPEN FAILED"
FAILED
2, LEVEL 1 SETUP Initiate EDC RECEIVER
OK
3, CLOSE Clean Up EDC
"OPEN FAILED"
Initiate Level 1 CLEAR
DOWN
4, LEVEL 1 LINK Clean Up EDC
FAILED "OPEN FAILED"
3, EDC RECEIVER None
STARTED
4, CLOSE Clean Up EDC
"OPEN FAILED"
Initiate Level 1 Clear
Down
4, LEVEL 1 LINK FAILED Clean Up EDC
"OPEN FAILED"
4, EDC OUTGOING START OK None
5, CLOSE Clean Up EDC
"OPEN FAILED"
Initiate Level 1 Clear
Down
5, LEVEL 1 LINK FAILED Clean Up, EDC
"OPEN FAILED"
5, EDC IRRECOVERABLE Clean Up EDC
ERROR Initiate CLEAR DOWN Level
1
"OPEN FAILED"
5, INCOMING STARTUP "OPEN OK"
OK
6, CLOSE Clean Up EDC
Initiate CLEAR DOWN Level
1
6, LEVEL 1 LINK Clean Up EDC
FAILED "LINK FAILURE"
6, EDC IRRECOVERABLE Clean Up EDC
ERROR Initiate CLEAR DOWN Level
1
7, LEVEL 1 CLEAR DOWN OK "CLOSE OK"
8, LEVEL 1 CLEAR DOWN "EDC FAILURE"
S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.1.3.6.3.4-1 presents the State-Event diagram
for EDC and Level 1.
FIGURE 4.1.3.6.3.4-1…01…State-Event Diagram EDC and Level 1
4.1.3.6.3.5 H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲ ̲D̲i̲a̲g̲r̲a̲m̲ ̲E̲D̲C̲ ̲a̲n̲d̲ ̲L̲e̲v̲e̲l̲ ̲1̲
S̲t̲a̲t̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
STATE A DISABLED. The CAMPS Equipment passive.
STATE B ENABLED. Correspond to
Substate 1 (refer section 4.1.3.6.3.4)
STATE C OPENING. Correspond to
Substate 2, 3, 4, 5
STATE D RUNNING. Correspond to
Substate 6, 8
STATE E CLOSING. Correspond to
Substate 7
S̲t̲a̲t̲e̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.1.3.6.3.5-1 presents the State Diagram.
FIGURE 4.1.3.6.3.5-1…01…High Level State Diagram…01…EDC and Level 1
4.1.3.7 C̲C̲I̲S̲ ̲a̲n̲d̲ ̲S̲C̲A̲R̲S̲ ̲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.7.1 O̲v̲e̲r̲v̲i̲e̲w̲
The CCIS/SCARS data is processed by the CCIS/SCARS
handler in the LTU Handler subpackage.
4.1.3.7.2 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
Refer fig. 4.1.3.7-1.
Output processing
1. Application calls APPEND ̲BYTES
2. The request is transferred to the CCIS/SCARS handler.
3. The identification of the message as included in
the first part of the message is loaded into each
databuffer before it is handed on to the LTU.
4,5.The LTU transmits data and receives acknowledges.
FIGURE 4.1.3.7-1…01…CCIS/SCARS DATA FLOW
6. The handler is notified
Event 3-6 are repeated for each databuffer formed for
the message.
7. When buffers have been transmitted the TMS is informed.
8. The requestor is informed.
For input the processing is
a,b Request is transferred to handler
c. Whenever bufferspace is available input requests
are released to the LtU.
d. Data is arriving
e. If correctly received data is acknowledged
f. Input buffers returned to the handler
g, f The handler strips off message identification
and returns data to requestor.
4.1.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Refer prefix in source listings.
