top - download
⟦06bb01e6b⟧ Wang Wps File
Length: 26112 (0x6600)
Types: Wang Wps File
Notes: CPS/SDS/004
Names: »1112A «
Derivation
└─⟦3697aa7b2⟧ Bits:30006041 8" Wang WCS floppy, CR 0066A
└─ ⟦this⟧ »1112A «
WangText
…02…CPS/SDS/004
…02…BHJ/810801…02……02…
SYSTEM STATUS AND CONTROL
…02……02…CAMPS
4.2.7 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲M̲I̲)̲
4.2.7.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 CMI serves the commands and format fields sent
from the operator VDU.
When a command is received and validated, the CMI sends
the requested format and the actual data to the operator
VDU. The operator will now update the format and hereafter
the updated fields are returned to the CMI. When the
fields are validated, they are given over to COPSY
for execution.
The last step in the fulfillment of a reconfiguration,
is to return a log to the operator LP.
The log contains information of the command executed
or rejected and the time of execution (DATE and TIME).
The initialization of the CMI and the validation of
the operator VDU input is given in the following subsections.
The functional breakdown of the CMI is shown in fig.
4.2.7.1-1.
Fig. 4.2.7.1-1…01…FUNCTIONAL DECOMPOSITION
4.2.7.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The CMI receives a start up command via its input queue
CMIQ.
Having received the start up command, the coroutines
in the CMI are started.
The start-up command specifies user connections to
the:
- WDP-VDU command split
- WDP-VDU format split
- WDP-LP
to be offered by CMI.
4.2.7.1.2 D̲e̲t̲e̲r̲m̲i̲n̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲T̲y̲p̲e̲
The commands from the command line are divided into:
- request of menu formats
- request of control formats
When the commands are interpreted, the format ID is
calculated.
If a command is illegal, an error message is returned
to the operator, and a new command has to be entered.
4.2.7.1.3 D̲i̲s̲p̲l̲a̲y̲ ̲F̲o̲r̲m̲a̲t̲
The format specified by the command is via the Format
handler sent to the VDU and if a control format is
displayed, the unprotected fields and a PORT-ID is
updated with the actual data.
4.2.7.1.4 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
When the operator has updated the format then the unprotected
fields are read. The fields are checked for syntax
and semantic errors, before a control record is handed
over to COPSY. When COPSY has executed the control
specified, the VDU is unlocked and the operator can
now enter new commands.
If the operator has entered an illegal character in
an unprotected field, a warning is sent to him and
the cursor is positioned in the actual field.
The operator can reject his choice of command (until
it is sent to COPSY) by depressing the function key
CANCEL.
During COPSY execution, the operator is notified in
the response line, that it is not possible to cancel
the current command.
The following subsection describes the semantic checks
to be done.
The functional breakdown of validation is given in
fig. 4.2.7.1.1.4-1.
Fig. 4.2.7.1.1.4-1
4.2.7.1.4.1 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲T̲U̲X̲-̲L̲I̲N̲E̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲L̲X̲L̲N̲)̲
When an LTUX line is to be inserted in the configuration,
the following checks take place:
- Type of device against LTUX
- Speed against device
- Status of device
To accept the type of device (e.g. VDU, MTP, PTR, OCR),
it is checked that the LTUX includes the device type
specified. However, any type of device is accepted
if the status of the device is "out of service". It
is checked that the speed specified to the device is
legal.
To accept any reconfiguration, the device has to be
taken "out of service" or its status has to be error.
4.2.2.1.4.2 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲T̲U̲X̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲L̲T̲U̲X̲)̲
When an LTUX has to be inserted in the configuration,
the following checks take place:
- type of LTUX against devices connected
- status of LTUX
To accept the LTUX type, it has to fit with the devices
(e.g. VDU, LP) connected to this LTUX (only devices
"in service"). If the types do not fit, the operator
is notified to set the devices "out of service" or
insert the right type of LTUX.
The status of an LTUX can either be "in service" or
"out of service". If one or more of the LTUX lines
does not fit with the LTUX type, the status of the
LTUX has to be set out of service.
To accept a reconfiguration, the LTUX has to be taken
"out of service" or its status has to be error.
4.2.7.1.4.3 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲B̲S̲M̲-̲X̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲B̲S̲M̲X̲)̲
During validation of the data from the BSM-X format,
the status is checked against the status of the TDX
Bus. If status is set "Offline", an offline TDX bus
has to exist.
4.2.7.1.4.4 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲D̲X̲ ̲B̲u̲s̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲T̲D̲X̲B̲)̲
For the TDX format all combinations of the status (error
cannot be set) are allowed if one of the TDX buses
is set active.
4.2.7.1.4.5 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲T̲U̲ ̲L̲i̲n̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲L̲T̲L̲N̲)̲
It shall be controlled that the type of LTU line inserted
(SCARS, CCIS, NICS TARE, VDU or LP) suits the LTU to
which it is connected. Any type of line can be stated
as long as status of the line is set disable. Error
status cannot be specified by the operator.
4.2.7.4.1.6 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲T̲U̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲L̲T̲U̲U̲)̲
When the data for the LTU is specified, the following
parameters are checked:
- type
- status
The type has to suit the LTU line(s) connected to the
LTU else the status has to be set "out of service".
The status of the LTU line can be set active, offline
(standby, manual) or out of service.
4.2.7.1.4.7 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲V̲o̲l̲u̲m̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲V̲O̲L̲U̲)̲
When the operator has specified a volume to be mounted,
the following conditions are checked:
- disk status
- volume name
- mount/dismount
It is checked (in COPSY) that the volume name specified
corresponds to the volume name on the actually loaded
disk pack.
The status of the disk on which the volume is to be
mounted has to be online.
4.2.7.1.4.8 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲D̲i̲s̲k̲ ̲D̲r̲i̲v̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲D̲D̲R̲I̲)̲
To accept disk drive format, the following is checked:
- disk status
If only one mirrored disk exists, it is not allowed
to take it offline. Error status cannot be specified.
4.2.7.1.4.9 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲t̲a̲r̲t̲-̲u̲p̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲S̲T̲A̲C̲)̲
When a PU is started up as ACTIVE, the following is
checked:
- state of PU specified
- mode to start from
- type of application software to be loaded
It is checked if an ACTIVE PU already exists (by the
watchdog).
4.2.7.1.4.10 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲S̲W̲C̲H̲)̲
This format only needs syntax check of the numbers
specified in the unprotected format fields.
4.2.7.1.4.11 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲l̲o̲s̲e̲-̲d̲o̲w̲n̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲C̲L̲O̲S̲)̲
This format only needs syntax check of the numbers
specified in the unprotected format fields.
4.2.7.1.4.12 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲t̲a̲r̲t̲-̲u̲p̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲S̲T̲S̲B̲)̲
Syntax check of the numbers in the format fields.
4.2.7.1.4.13 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲e̲t̲ ̲T̲i̲m̲e̲ ̲o̲f̲ ̲D̲a̲y̲ ̲F̲o̲r̲m̲a̲t̲ ̲(̲S̲T̲O̲D̲)̲
The following parameters are checked:
- month, the same as in the PU
- day, the same as in the PU
- hour, the same as in the PU
- minute, see below
- second, 00 - 60 valid
The time of day set by the operator must not differ
from the PU clock with more than 8 minutes.
4.2.7.1.4.14 P̲R̲I̲N̲T̲
Syntax only.
4.2.7.1.4.15 S̲e̲t̲ ̲N̲O̲R̲M̲A̲L̲/̲A̲T̲ ̲R̲I̲S̲K̲ ̲M̲o̲d̲e̲
Syntax only.
4.2.7.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CMI functions are implemented in one process.
The process is divided into a main program and a number
of procedures. Ref. fig. 4.2.7.2-1. The main program
serves the input queue from COPSY and the user connection
to the WDP.
When input from the operator VDU is identified, control
is given over to the VDU-INPUT procedure.
If the status of a LP or VDU is changed COPSY informs
the CMI via the input queue.
Fig. 4.2.7.2-1…01…Software Structure
4.2.7.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The CMI transfers data from the operator VDU and when
the data have been validated, they are given over to
COPSY which executes the control. When control is
executed, a reply is returned from COPSY to the CMI.
CMI sends a log to the operator LP specifying the
control executed. The interface to the CMI from COPSY
and the WDP is shown in fig. 4.2.7.3-1. The data flow
and control logic is shown in the HIPO chart fig. 4.2.7.3-2
and the flow charts fig. 4.2.7.3-3 to 4.2.7.3-11
Figs. 4.2.7.3-1…01…CMI Block Diagram
Fig. 4.2.7.3-2…01…Command Interpreter
MAIN-PROGRAM-CMI (7.0)
LOOP:
TEST INPUT-TYPE
CASE INPUT-TYPE:
VDU? - PERFORM SYNTAX & SEMANTIC PROCEDURE
COPSY? - PERFORM INITIALIZE PROCEDURE
END INPUT-TYPE
END LOOP:
END MAIN-PROGRAM-CMI
Fig. 4.2.7.3-3
SYNTAX & SEMANTIC PROCEDURE (7.1)
CASE VDU-INPUT-TYPE:
FUNCTION KEY? - PERFORM IDENTIFY-FUNCTION KEY PROCEDURE
CMD? - PERFORM DETERM-FORM PROCEDURE
COMMAND FALSE?
PERFORM SPECIFY-FORMAT PROCEDURE
DATA? - PERFORM VALIDATE-FORMAT PROCEDURE
FIELDS DATA OK? - PERFORM CONTROL PROCEDURE
PERFORM LOG PROCEDURE
END VDU-INPUT-TYPE
PERFORM VDU-CONTROL PROCEDURE
END SYNTAX & SEMANTIC PROCEDURE
Fig. 4.2.7.3-4
IDENTIFY - FUNCTION KEY PROCEDURE (7.1.5)
ENTER KEY? - CMD SPLIT? - VDU INPUT TYPE = CMD
VDU INPUT TYPE = DATA
CONTROL = INIT
COMMAND KEY? - CONTROL = CLEAR
CONTROL = NO - ACTION
END IDENTIFY FUNCTION KEY
Fig. 4.2.7.3-5
SPECIFY - FORMAT PROCEDURE (7.1.2)
READ COMMAND
CASE COMMAND:
HIME? - FORMAT = 1
TDXS? - FORMAT = 2
IOSY? - FORMAT = 3
PUSY? - FORMAT = 4
SOFT? - FORMAT = 5
WDCM? - FORMAT = 6
CONTROL = MENU
LXLX? - FORMAT = 7
LTUX? - FORMAT = 8
BSMX? - FORMAT = 9
LTLN? - FORMAT = 10
LTUU? - FORMAT = 11
DDRI? - FORMAT = 12
CONTROL = FORM-SPLIT
CHECK ID = TRUE
CONTINUE
Fig. 4.2.7.3-6a …86…1 …02… …02… …02… …02…
CASE CMD CONTINUED
TDXB ? FORMAT = 13
VOLU ? FORMAT = 14
STAC ? FORMAT = 15
SWCH ? FORMAT = 16
CLOSE ? FORMAT = 17
STSB ? FORMAT = 18
STOD ? FORMAT = 19
LMOS ? FORMAT = 20
STRM ? FORMAT = 21
PRSS ? FORMAT = 22
MODE ? FORMAT = 23
CONTROL = FORM-SPLIT
CHECK ID = FALSE
OTHERS? DISPLAY "ILLEGAL CMD"
CMD = FALSE
CONTROL = ILLEGAL
END CMD
END SPECIFY - FORMAT
Fig. 4.2.7.3-6b
DISPLAY-FORMAT PROCEDURE (7.1.3)
CHECK-ID = TRUE? GET DATA FROM CONFIG. TABLE
NO DATA? DISPLAY "ILLEGAL
ID"
CONTROL = ILLEGAL
GET FORMAT
OUTPUT FORMAT
CONTROL = FORMAT? - OUTPUT FIELDS
END DISPLAY FORMAT
Fig. 4.2.7.3-7
VALIDATE - FORMAT PROCEDURE (7.1.4)
CASE FORMAT:
7 ? - PERFORM LTUX LINE PROCEDURE
8 ? - PERFORM LTUX PROCEDURE
9 ? - PERFORM BSM-X PROCEDURE
10 ? - PERFORM LTU-LINE PROCEDURE
11 ? - PERFORM LTU PROCEDURE
12 ? - PERFORM DISK DRIVE PROCEDURE
13 ? - PERFORM TDX-BUS PROCEDURE
14 ? - PERFORM VOLUME PROCEDURE
15 ? - PERFORM START ACTIVE PROCEDURE
16 ? - PERFORM SWITCHOVER PROCEDURE
17 ? - PERFORM CLOSE DOWN PROCEDURE
18 ? - PERFORM START SB PROCEDURE
19 ? - PERFORM SET TIME PROCEDURE
20 ? - PERFORM LOAD MODE PROCEDURE
21 ? - PERFORM SET TRACE PROCEDURE
22 ? - PERFORM PRINT PROCEDURE
23 ? - PERFORM MODE PROCEDURE
END FORMAT
END VALIDATE - FORMAT
Fig. 4.2.7.3-8
EXECUTE - CONTROL PROCEDURE (7.1.7)
SEND CONTROL RECORD TO COPSY
WAIT ANSWER (TIME)
TIME OUT ? - ANSWER = NOK
END EXECUTE - CONTROL
Fig. 4.2.7.3-9
LOG PROCEDURE (7.2)
STORE TIME INTO BUFFER
STORE COMMAND-DATA INTO BUFFER
ANSWER = OK? - COMPLETED INTO BUFFER
STORE "REJECTED" INTO BUFFER
CONTROL = ILLEGAL
DISPLAY "COMMAND REJECTED"
LP - DOWN ?
SEND BUFFER TO LP
END LOG
Fig. 4.2.7.3-10
VDU CONTROL PROCEDURE (7.1.6)
CASE CONTROL:
INIT ? - PARAM = TRANSMIT, VDU-LOCK
CLEAR? - PARAM? = CMD LINE,CLEAR CMO,CLEAR FORM,
VDU UNLOCK
VDU - INPUT TYPE = FUNCTION KEY
MENU? - PARAM = CMD LINE, CLEAR CMD, VDU UNLOCK
VDU INPUT TYPE = FUNCTION KEY
FORM-SPLIT? - PARAM = FIRST FIELD, VDU UNLOCK
VDU INPUT TYPE = FUNCTION KEY
ILLEGAL? - PARAM = CMD LINE, VDU UNLOCK
VDU INPUT TYPE = FUNCTION KEY
NO-VALID? - PARAM = FIELD#, VDU UNLOCK
VDU INPUT TYPE = FUNCTION KEY
SEND VDU PARAM
END CONTROL
END VDU CONTROL
Fig. 4.2.7.3-11
4.2.7.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The data pertinent to this subpackage are contained
in the VDU table.
The data used in the validation ref. sec. 4.1.4.
VDU TABLE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VDU STATE LP STATE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VDU INPUT TYPE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CONTROL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
INPUT TYPE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CHECK ID
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
COMMAND
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELDS DATA
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VDU-INPUT-TYPE = FUNCTION KEY, CMD, DATA
CONTROL = INIT, CLEAR, MENU, FORM-SPLIT, ILLEGAL, NO.
VALID
INPUT TYPE = COPSY, VDU
CHECK ID = FALSE, TRUE
COMMAND = FALSE, TRUE
FIELDS DATA = FALSE, TRUE
VDU STATE = UP, DOWN
LP STATE = UP, DOWN
4.2.7.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲
Refer to sec. 4.1.6.3.3.
4.2.8 W̲a̲t̲c̲h̲d̲o̲g̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲(̲W̲D̲S̲P̲)̲
4.2.8.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
The WDSP contains the functions defined in fig. 4.2.8.1-1.
The WDSP receives via the V24 lines information from
the PUs and the operator VDU. Via the control CCB
the CCB driver scans the status in the different crates
via digital input ports, and if a discrepancy between
the expected status and the scanned status exists,
a report is issued. Furthermore, the WDSP checks that
the PU periodically sends "keep alive", if a PU stops
sending "keep alive" the WDP will take the following
action if:
- An active PU with a standby PU exists: switchover
- A standby PU with an active PU exists: notify
active + close standby
- An active PU with an offline PU exists: close
down
The V24 lines and the monitoring via the CCB is supported
by the WDSP standard firmware, which gives the incoming
messages to the application processes which are described
in the next sections.
Fig. 4.2.2.1-1…01…Functional Breakdown of WDP
4.2.8.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Upon power up of the WDP, a selftest procedure is started
and if the WDP is ok, initialization is started.
The initialization consists of:
- set up VDU splits
- set up control tables
- start the WDP processes
- start the Timer
Hereafter, the control is given over to the Kernel
ref. CDS-MIC/003/USM/0003, the Kernel is a part of
the standard firmware.
4.2.8.1.2 P̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲
The following kind of messages is taken care of by
the PU handler.
- reception of "Keep alive"
- control or monitoring requests from PU
If a "keep alive" message is missing from a PU, the
PU handler sets up a control command to be sent to
the SYS M&C, which controls the execution of the command.
Depending of the PU status, the following control
is sent:
- switchover
- close down
Control or monitoring requests from the PU (COPSY)
is sent to the SYS M&C.
The PU handler receives every minute the time of day
(TOD) from the PUs. The TOD is included in the "keep
alive" message.
To check the "keep alive" reception, a timer interrupt
is sent to the PU handler every second.
4.2.8.1.3 V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲
The VDU handler is the link between the operator VDU,
the WDP and the PUs. The functional breakdown of the
VDU handler is shown in fig. 4.2.8.1.2-1.
The following messages are passed through the VDU handler:
- function key from the operator VDU
- commands from the command line
- unprotected fields from the format split
- output of formats to the format split
- control message to the VDU (cursor position)
- offline communication
The following subsections describe the actions to be
taken for input from the VDU, output to the VDU and
offline communication.
4.2.8.1.3.1 I̲n̲p̲u̲t̲ ̲f̲r̲o̲m̲ ̲t̲h̲e̲ ̲V̲D̲U̲
When the operator wants to enter a command, or format,
he depresses the function key ENTER or COMMAND. ENTER
specifies that the content of the current split is
to be sent.
COMMAND is used to specify that the operator wants
to return to the command line. The format split and
the command line are cleared.
The VDU handler looks up the cursor position and if
the position is the command line, the function key
is checked, else it is sent to the CMI.
If the key received was an ENTER key the following
actions are taken by the VDU handler.
- return ack to the VDU
- initiate the transmission
- ready to received the command
when the command is received, the actions taken are:
- return ack to the VDU
- interpretation of the command
For on-line PU commands the ENTER key is sent to the
CMI. The CMI now reads the command to be handled from
the VDU memory.
The following commands to be recognized by the VDU
handler are foreseen:
- SWCH, emergency switchover from Active to Standby
Pu
- DISA, disable PU
- RSET, reset PU
- MACL, master clear PU
- MAIN, set PU in maintenance mode
- GCUA, enable access from the PU to the CU
- BOOT, bootload CAMPS
- PU#1, communication link to PU#1
- PU#2, communication link to PU#2
- OFL1, offline communication is to be used
The first seven commands are handed over to the SYS
M&C for execution.
The last three are used to define the mode of communication
and the PU link. Entering ONLINE mode is described
in section 4.2.8.1.3.3.
When the commands have been served, the VDU is given
back to the operator, i.e. the cursor is positioned
in the start of the command line.
In the following cases, the input from the VDU is sent
direct to the CMI:
- cursor positioned in the format area
- second transmission of a command.
4.2.8.1.3.2 O̲u̲t̲p̲u̲t̲ ̲t̲o̲ ̲t̲h̲e̲ ̲V̲D̲U̲
The data to be sent to the VDU through the VDU handler
are:
- FORMATS to be displayed
- DATA to the format fields
- Error message
- Control messages to the VDU e.g. cursor position
- Ack.
Data for the configuration display are sent directly
from COPSY to the VDU via the VDU driver (STD FW).
When the VDU handler receives a message to be sent
to the VDU, it checks if it is a control message. If
so, the cursor position is identified (ref. 4.2.8.1.3.1).
4.2.8.1.3.3 O̲f̲f̲l̲i̲n̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The dialogue between the PU and VDU is during offline
communication (refer section 2.2.1.7) controlled by
the VDU handler.
The offline communication is for the offline PU, the
WDP, WDP ̲VDU and WDP ̲LP referred to as the "offline
mode" of operation. The PU-WDP communication uses the
transparent WDP protocol (refer IOC). The offline dialogue
takes place in the WDP ̲VDU format split and is line
oriented.
The following actions are taken:
- check if operator wants to enter "online mode"
- send on message
- log message
The operator depresses the command function key, when
he wants to enter online mode. Hereafter, the VDU
handler specifies to the drivers that messages to/from
the PUs are controlled by a protocol.
The VDU handler logs the offline dialogue between the
VDU and PU on the WDP-LP.
4.2.8.1.3.4 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
If an error is detected in the transmission of data
to the VDU, this is reported to the PU via the protocol.
When the VDU is reinserted, a report is sent to the
Active PU. The V24 line is monitored by the VDU driver.
Fig. 4.2.8.1.3-1
4.2.8.1.4 L̲P̲ ̲H̲a̲n̲d̲l̲e̲r̲
The LP handler receives:
- serial number to be used on error reports
- error reports to be printed
- output produced during execution of operator commands
in COPSY.
- log of offline communication
The serial number is sent to the LP handler upon start
up or if the LP has been "out of service". When the
LP handler has served an error message (i.e. put on
serial number and time of day), the serial number is
sent to COPSY.
Before a message buffer is sent to the LP driver, the
LP handler looks up the type of message and takes an
appropriate action (as defined below) before the message
is printed.
4.2.8.1.4.1 S̲Y̲N̲C̲
When the sender of a message differs from the last
sender or an error report is to be printed, the LP
output is synchronized, i.e.:
- page shift
- a header on the new page
- time of day (all messages)
- serial number (only error reports)
4.2.8.1.4.2 P̲r̲i̲n̲t̲
When the type of message is defined and the action
taken, Print sends the message to the LP driver.
4.2.8.1.4.3 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
If the LP is down or out of paper, a report is sent
to the active PU and the operator VDU. The same is
done when the LP is set back in operation.
The V24 line is monitored by the LP driver.
4.2.8.1.5 S̲Y̲S̲ ̲M̲&̲C̲ (System monitoring and control)
Fig. 4.2.8.1.5-1 shows the functional breakdown of
the SYS M&C.
The SYS M&C supports:
- Handling of exceptions
- Control commands from the operator
- Control commands from the PU (COPSY)
- Monitoring requests from the PU (COPSY)
4.2.8.1.5.1 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲E̲x̲c̲e̲p̲t̲i̲o̲n̲s̲
The exceptions reported to the SYS M&C from the PU
handler (No "keep alive") or the CCB driver are handled
as described below. The control is executed via the
CCB driver and the reports are sent to the PU (COPSY).
If total system failure exists, the SYS M&C sends
a error report to the LP handler.
S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲:
1) No "keep alive" from Active PU
2) status error in the Active PU
3) status error in the active part of the CU
4) if no standby exists close down
C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲:
1) No "keep alive" from standby PU
2) status error in the standby Pu
3) status error in the standby part of the CU
T̲D̲X̲ ̲B̲u̲s̲ ̲S̲w̲i̲t̲c̲h̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲
Active TDX bus status error and a standby exists (ALL
BSM-X modules connected to the erroneous bus are switched
to the other bus)
W̲a̲r̲n̲i̲n̲g̲ ̲(̲e̲r̲r̲o̲r̲ ̲r̲e̲p̲o̲r̲t̲)̲:̲
Any manual switch out of auto, and no error situation
exists. BSM-X power down.
4.2.8.1.5.2 C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲f̲r̲o̲m̲ ̲t̲h̲e̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲
For those commands from the operator directly to the
WDP, which are used to control the HW configuration
(used before start up), the SYS M&C executes the control
via the CCB driver. When a command is completed, a
log is sent to the LP.
4.2.8.1.5.3 C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲f̲r̲o̲m̲ ̲C̲O̲P̲S̲Y̲
The last type of control commands are those sent from
COPSY in the ACTIVE PU. These control commands are
a result of a command issued via a format from the
operator VDU or a detection of an error by the active
PU.
The commands are:
- SWITCH, switchover from AC to SB PU
- TDX SWITCH, switch TDX-bus (BSM-X modules)
- SINGLE CONTROL, controls only in one crate
The control parameter is set up and sent to the CCB
driver
For these kinds of control commands, the log is sent
from either the CMI (operator command) or COPSY (error
reports).
4.2.8.1.5.4 M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲R̲e̲q̲u̲e̲s̲t̲
Monitoring requests are sent from COPSY. A request
contains the PORT ID of the crate to be monitored.
The SYS M&C reads the digital status from the scan-dig-table
ref. sec. 4.2.8.4.4.1, which is updated by the CCB
driver. The power status is taken from the pow-scan-table
ref. sec. 4.2.8.4.4.3 and converted to an ASCII character
string, before the complete status in the crate is
returned to the PU.
