top - download
⟦35df6b0b0⟧ Wang Wps File
Length: 32306 (0x7e32)
Types: Wang Wps File
Notes: CPS/SDS/004
Names: »1076A «
Derivation
└─⟦3697aa7b2⟧ Bits:30006041 8" Wang WCS floppy, CR 0066A
└─ ⟦this⟧ »1076A «
WangText
@…09…@…0f…*…09…*…0a…*…0d…*…0e……0a……0c……0a……00……0a……01……0a……05……0a……06……0a……07……09……08……09……0e……09……02……09……06……08……86…1
…02…
…02… …02…
…02…CPS/SDS/004
…02…FH/810801…02……02…
SYSTEM
STATUS
AND CONTROL
…02……02…CAMPS
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̲
Sections 4.1.1.1 to 4.1.1.9 describes the functions
derived in section 2.2.1 and 2.2.2 to a level of detail,
which enables an allocation of the functions to process
or coroutine software structures.
Section 4.1.1.9 describes requirements derived from
the functional responsibilities defined in section
2.2.2.
The sections, in which SSC functions (identified by
a number) are described, are defined in figure 4.1.1-1.
4.1.1.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
SSC receives checkpoint records from MMS, LOG and
TIMER - MON and transfers the checkpoints records to
the standby PU via the TDX-bus. Having transmitted
a record, an acknowledgement from the SB PU is awaited
and a reply is sent to the caller.
The SSC does not await acknowledgement before transmitting
a new checkpoint (CP) record. However, only a limited
number of outstanding acknowledgements are allowed.
4.1.1.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
SSC receives checkpoint records from the active PU.
The checkpoint records are received via the TDX bus
from the active PU. Having received a checkpoint record,
a table is updated according to the checkpoint record
type and an acknowledgement is sent to the active PU
via the TDX bus.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FCT
NO. TITLE DESCRIBED IN SECTION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 Overview 2.2.1
2 Check point transm. 2.2.1.1 4.1.1.1
3 Checkpoint reception 2.2.1.2 4.1.1.2
4 Online diagnostics 2.2.1.3 4.1.1.3
5 Line M&C 2.2.1.4 4.1.1.4
6 Technical error
processing 2.2.1.5 4.1.1.5
7 Operator commands 2.2.1.6 4.1.1.6
8 Offline PU operation 2.2.1.7 4.1.1.7
9 WDP FW 2.2.1.8 4.1.1.8
10 Bootload 2.2.2.1.1.1
11 Start active 2.2.2.1.1.2 4.1.1.6.3.1
12 Common start active 4.1.1.6.3.1
13 Start standby 2.2.2.1.1.2 4.1.1.6.3.3
14 Common start standby 4.1.1.6.3.3
15 Recovery 2.2.2.2
16 Close active 2.2.2.1.2.1 4.1.1.6.3.2
17 Close standby 2.2.2.1.2.2
18 Validity checks 2.2.2.4
19 Data collection 2.2.2.5
20 Own error handling 2.2.2.3
21 Peripheral recon-
figuration 4.1.1.5
22 Common peripheral
reconfiguration 4.1.1.5
23 Common line M&C 4.1.1.4.2
24 Common SSC functions 4.1.1.9.1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 4.1.1-1 SSC Function to Section Table
4.1.1.3 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
The functions covered by on-line diagnostic are defined
in section 2.2.1.3.
4.1.1.4 L̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
The line M&C functions are depicted on figure 4.1.1.4-1.
The two line M&C functional categories:
- external commands
- system connection M&C
are detailed on figure 4.1.1.4.1-1 and figure 4.1.1.4.2-1
and explained below.
Fig. 4.1.1.4-1…01…Line Monitoring and Control Functions
4.1.1.4.1 E̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲o̲f̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The external commands control:
- VDUs
The TEP (supervisor) can request block/unblocking
of a VDU.
The TEP (release VDU) can request security interrogation.
During presentation CSF (MMON) can request security
interrogation/warning.
- SADs
The TEP (supervisor) can specify accept/non-accept
of input/output
- EXCs
The TEP (supervisor) can specify accept/non-accept
of input/output on a line or on a circuit.
- WDP
The CSF (timer monitor) periodically invokes the
SSC and a keep-alive message is sent to the WDP.
Fig. 4.1.1.1.1-1…01…External Line Control COMMNOS
4.1.1.4.2 M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲
COPSY has one or more (if different VDU splits exist)
system connections to a line.
The system connections are constantly monitored.
The conditions to be monitored on a system connection
depend on the type of line. A common condition is
error.
A HW error on a line implies three error notifications:
1 - on a user connection
2 - on a system connection
3 - a technical error report to the SDSE.
User connection detected errors are handled in TEP
or THP line handling subprocesses.
System connection detected errors imply that COPSY
updates a profile by a sign off or by specification
of non-accept of input/output.
Technical error reports imply that the HW configuration
table and the WDP ̲VDU configuration display are updated,
and an error report is sent to the WDP-LP.
For VDUs, the following auxiliary conditions are received:
- sign on/off
- assign supervisor terminal
- specify terminal capability
- key lock
For SADs, the following auxiliary conditions are received:
- key lock (only for PTR and MTP-ROP).
For the WDP, the following auxiliary conditions are
received as a result of WDP own monitoring:
- AC PU down
This condition is signalled to the SB PU and activates
same. (WARM 2 start-up).
- SB PU down
The AC PU stops checkpointing.
- BSM-X down
The BSM-X is taken out of service i.e. up to 8
lines are deassigned.
- Warning
A switch is set in manual mode without disturbing
normal operation. The configuration table is updated.
- WDP, WDP ̲VDU, WDP ̲LP up/down
The WDP equipment is reported erroneous and back
in service.
Also COPSY uses the system connection for commands:
- WDP to PU commands
The WDP sends commands to the PU in various cases
e.g. SB PU up, last error report number, crate
status etc. When the SB PU is reported up, the
AC PU starts sending checkpoints.
- PU to WDP commands
The PU sends commands to the WDP in various cases
e.g. during start up it is examined whether the
WDP ̲VDU is connected directly to the PU.
Fig. 4.1.1.4.2-1…01…System Connection M&C
4.1.1.5 T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
A functional breakdown for technical error report handling
is depicted in figure 4.1.1.5-1.
In figure 4.1.1.5-2 common peripheral reconfiguration
functions are depicted.
The "receive error reports" functions are detailed
in section 4.1.1.5.1.
The "isolate error" function isolates an error to one
of the categories defined in section 2.2.1.5.1.1.1
(SW error types) and in section 2.2.1.5.1.2 (HW error
types).
The "report error" function sends an error report to
the WDP ̲LP. If the WDP ̲LP is down, then error reports
are printed at the supervisor report printer.
The "hardware reconfiguration" functions are detailed
in section 4.1.1.5.2.
Remaining functions are described in section 2.2.1.5.
Figure 4.1.1.5-1…01…Technical Error Report Processing
Fig. 4.1.1.5-2…01…Common Peripheral Device Functions
Fig. 4.1.1.5-2 (Continued)
4.1.1.5.1 E̲r̲r̲o̲r̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
COPSY receives error reports in:
1- SDSE: secondary device status element. The reports
describe hardware errors. COPSY reactions are
described in section 4.1.1.5.2.
2- PSE: parent synchronization element. The reports
describe a retired process and the cause of retirement.
- security violation (DAMOS or CSF retires)
- errors, which can be localized to a single
user process. (DAMOS retires)
- own child retires (refer below)
COPSY reactions are described in section 2.2.1.5.1.1.3.
3- ERQ: error report queue. Child processing reports
error in this queue. The report contains a child
action.
- RETIRED
- DUMMY (only possible in AT-Risk mode)
- PARTIAL-RECOVERY (only possible in AT-Risk
mode)
and a detailed description of the error.
COPSY reactions are described in section 2.2.1.5.1.1.3.
4.1.1.5.2 H̲W̲ ̲E̲r̲r̲o̲r̲ ̲F̲i̲x̲-̲u̲p̲
4.1.1.5.2.1 L̲T̲U̲-̲L̲i̲n̲e̲
LTU lines are of EXC type. An error implies that the
line is deassigned and the line is logically signed
off by specifying non-accept of input/output in the
profile table.
There is no interface to THP as its user connection
is disabled and is used by TMP to clean-up current
channel operations.
4.1.1.5.2.2 L̲T̲U̲
Handled as above per LTU line.
4.1.1.2.2.3 L̲T̲U̲X̲-̲L̲i̲n̲e̲
For LTUX-lines used as EXC or SAD, a "non-accept of
input/output" is set in the profile table. The line
is deassigned.
LTUX VDU lines are signed off. There is no interface
to TEP/TMP as they sense the state of a device user
connection and perform a clean-up (EXC, SAD) or suspend
action (VDU).
4.1.1.5.2.4 L̲T̲U̲X̲
Handled as above per LTUX line.
4.1.1.5.2.5 B̲S̲M̲-̲X̲
Handled as above per LTUX, but the BSM-X is set out
of service by the WDP.
4.1.1.5.2.6 O̲f̲f̲l̲i̲n̲e̲ ̲D̲i̲s̲k̲ ̲V̲o̲l̲u̲m̲e̲
If the volume is used by COPSY, the volume is dismounted.
If the volume is used by TEP, COPSY informs TEP, which
dismounts the volume and issues a warning report.
4.1.1.5.2.7 O̲f̲f̲l̲i̲n̲e̲ ̲D̲i̲s̲k̲
The disk is deassigned and TEP is informed.
4.1.1.5.2.8 F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲k̲ ̲V̲o̲l̲u̲m̲e̲
The volume is dismounted.
4.1.1.5.2.9 F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲k̲
The disk is deassigned.
4.1.1.5.2.10 W̲D̲P̲
Operator command handling is cleaned up. Error reports
are directed to the supervisor report printer. Keep
alive messages are not sent.
The configuration display is not updated.
A subsequent error reconfiguration may involve the
WDP to execute a:
- TDX bus switchover
- PU switchover
- BSM-X switch
For TDX bus and PU error the SSC performs a non-ordered
close down of the system. BSM-X switch actions are
ignored.
4.1.1.5.2.11 W̲D̲P̲-̲V̲D̲U̲
Operator Command handling is cleaned up. Update of
the configuration display is terminated.
4.1.1.5.2.12 W̲D̲P̲-̲L̲P̲
Operator commands are not logged.
Error reports are directed to the supervisor report
printer. LP output resulting from operator commands
is ignored.
4.1.1.5.1.13 T̲D̲X̲ ̲B̲u̲s̲
The actions in the active PU depend on:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
BUS STATE ACTIVE + ACTIVE +
ERROR STANDBY OFFLINE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
IN ACTIVE TDX CLOSE
SWITCHOVER DOWN
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
IN STANDBY UPDATE HW N.A.
CONF.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
IN OFFLINE N.A. UPDATE HW
CONF.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
The TDX bus switchover is performed by the WDP on COPSY
request. The switchover is transparent to users.
A "close down" error will make COPSY force a fast "ordered"
close down where TEP and THP instances handling a line
clean-up (SAD,EXC) or suspend (VDU) the current transaction.
A TDX bus error will in the "close down" error case
make the standby PU perform an emergency close down.
4.1.1.5.2.14 M̲i̲r̲r̲o̲r̲e̲d̲ ̲D̲i̲s̲k̲ ̲V̲o̲l̲u̲m̲e̲
An error in one of the mirrored volumes will imply
a dismount and is transparent to users.
An error in both of the mirrored volumes is a disastrous
error, where the operator is notified and an emergency
PU close down is performed.
4.1.1.5.2.15 M̲i̲r̲r̲o̲r̲e̲d̲ ̲D̲i̲s̲k̲
An error in one of the mirrored disks will imply a
deassignment of the disk. It is transparent to users.
An error in each of the mirrored disks is handled as
an error in each of the mirrored volumes, except that
a WARMS start-up may later be used instead of DEAD
1 or DEAD 2 start-up.
4.1.1.5.2.16 S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲
An emergency close down of the standby PU is performed.
The sending of checkpoints to the standby PU is terminated
without any change in the interface to checkpoint requestors.
4.1.1.5.2.17 A̲c̲t̲i̲v̲e̲ ̲P̲U̲
Errors in the active PU are divided into two types:
- Errors which can be localized to a single user
process (PU-U-MEM)
- Remaining (PU-TOTAL)
For PU-TOTAL error, an emergency close-down of the
active PU is performed and a switchover to the standby
PU (if existing) is requested via the WDP.
PU-U-MEM errors will in NORMAL mode imply an emergency
switchover as above.
In AT-Risk mode, a retirable process will be retired
and the system continue. For other types of processes,
an emergency switchover is executed.
4.1.1.6 O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Operator command functions are decomposed on figure
4.1.1.6-1.
Received operator commands are syntax and semantic
checked. If an error is detected, an error message
is sent to the operator VDU and the command is terminated.
If the command is error free, an appropriate module
is invoked and the command executed. Upon completion
an acknowledgement is sent to the operator VDU.
Operator commands are logged at the operator printer.
4.1.1.6.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Commands exist to COPSY
- modified application software
- modified system software
- software patches
from the
- floppy disk to the offline or mirrored disk
- offline disk to the mirrored disks
4.1.1.6.1.1 L̲o̲a̲d̲ ̲o̲f̲ ̲N̲e̲w̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Refer to section 4.3.1.6.
4.1.1.6.1.2 D̲e̲f̲i̲n̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲r̲a̲c̲e̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Operator commands exist to define the amount of trace
information to be produced by invocation of the SET
MASK procedure in the CAMPS system functions package.
4.1.1.6.1.3 P̲r̲i̲n̲t̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲u̲s̲
The operator VDU displays the main system status.
An operator command exists to print detailed system
status at the operator printer. Also, a command to
print statistics information about peripherals collected
by drivers/handlers exists.
4.1.1.6.1.4 T̲i̲m̲e̲ ̲o̲f̲ ̲D̲a̲y̲
The time of day command sets the active PU software
clock. Regularly, the time of day is transferred via
checkpoints to the stand-by PU.
4.1.1.6.1.5 D̲e̲f̲i̲n̲e̲ ̲N̲O̲R̲M̲A̲L̲/̲A̲T̲-̲R̲i̲s̲k̲ ̲M̲o̲d̲e̲
The CAMPS on-line system can operate in NORMAL or AT-risk
mode.
The command specifies the actual mode.
4.1.1.6.2 P̲e̲r̲i̲p̲h̲e̲r̲a̲l̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The execution of peripheral device reconfiguration
command includes enabling/disabling and specification
of attributes for:
- BSM-X
- LTUX
- LTUX-line
- LTU
- LTU-line
- TDX-bus
- OFFLINE DISK
- Mirrored Disk
- Floppy Disk
Enabling specifies, that a line/device is configurationally
available and is ready for logically access. For a
device chain e.g. LTU and LTU-line, the line is configurational
available, when the complete chain is available.
For disks mounting/dismounting/insert mirrored volume
is supported.
For the TDX-bus switchover is supported.
4.1.1.6.3 P̲U̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Start-active, close-active and start-standby functions
are detailed in sections 4.1.1.6.3.1-3.
"Switchover" is implemented by:
1- an ordered close-down of the AC PU
2- a notification of the SB PU via the WDP
3- the active PU is master cleared
4- a WARM2 start-up is executed in the SB PU.
The "close SB PU" operator command to the active PU
implies that:
1- the checkpointing to the standby PU is terminated.
2- the active PU commands the WDP to disable the SB
PU.
Fig 4.1.1.6-1…01…Operator Command Functions
4.1.1.6.3.1 S̲t̲a̲r̲t̲-̲u̲p̲ ̲A̲c̲t̲i̲v̲e̲ ̲P̲U̲
Start-up active PU is defined in section 2.2.2.1.1.2
and is detailed in figure 4.1.1.6.3-1 overleaf.
The start-up processes functions are detailed. Processes
are divided into two types:
- line processes i.e. processes which administer
a VDU, SAD, EXC, SB PU or WDP
- non line processes
The start-up of a line process is divided into two
corresponding to:
- the configuration access control implemented by
operator commands
- the logical access control implemented via e.g.
sign on.
The configurational control includes:
- line assignment
- for LTUs a boot load is executed
COPSY resource management for lines and files is implemented
by the DAMOS offer-accept concept.
Fig. 4.1.1.6-2…01…Start-up Operator Command Functions
4.1.1.6.3.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲A̲c̲t̲i̲v̲e̲ ̲P̲U̲
The functions depicted in figure 4.1.1.6.3.2-1 are
defined in section 2.2.2.1.2.1.
As for start-up active PU processes are divided into
line and non-line processes.
Fig. 4.1.1.6-3…01…Close Down Active PU Functions
4.1.1.6.3.3 S̲t̲a̲r̲t̲ ̲S̲t̲a̲n̲d̲b̲y̲
The start standby PU command execution is implemented
as start-up active PU, except that only system software
is loaded and started.
For start-up SB PU (SB2) subsequent to the active PU
start-up, the SB PU notifies the AC PU via the WDP,
when it is available for checkpoint reception.
The standby PU can only be booted from the offline
disk during SB2 as the mirrored disks are owned by
the AC PU.
The standby PU performs its online functions without
the use of a disk.
4.1.1.7 O̲f̲f̲l̲i̲n̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The offline functions are covered in section 4.1.1.8.
Fig. 4.1.1.6-4…01…Start Standby Functions
4.1.1.8 W̲D̲P̲ ̲F̲W̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The WDP FW functions are depicted on figure 4.1.1.8-1.
Fig. 4.1.1.8-1…01…WDP Functions
4.1.1.8.1 W̲D̲P̲ ̲I̲n̲p̲u̲t̲ ̲f̲r̲o̲m̲ ̲P̲U̲s̲ (refer to figure 4.1.1.8.1-1)
4.1.1.8.1.1 O̲f̲f̲l̲i̲n̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The WDP receives output produced during operation of
OLP and SSP software. The output is directed to the
WDP-VDU and a hard copy is generated at the WDP-LP.
Offline communication uses the transparent WDP protocol
(refer IOC).
4.1.1.8.1.2 K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The WDP receives keep-alive messages from both PUs.
The non-arrival of a keep-alive message makes the WDP
disable the PU and either execute an emergency switchover
or a SB PU close-down.
4.1.1.8.1.3 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲D̲i̲s̲p̲l̲a̲y̲ ̲U̲p̲d̲a̲t̲e̲
COPSY updates a VDU split, which displays the overall
system status.
Fig. 4.1.1.8.1-1…01…PU In Functions
4.1.1.8.1.4 V̲D̲U̲ ̲F̲o̲r̲m̲a̲t̲ ̲O̲u̲t̲p̲u̲t̲
During execution of operator commands to the online
PUs, the PU displays formats on the WDP-VDU.
In addition to the configuration display split, two
splits are assigned to operator command execution:
- one for command input
- one for handling of formats
4.1.1.8.1.5 L̲P̲ ̲R̲e̲p̲o̲r̲t̲s̲
The following print-out is foreseen:
- error reports
- logs of operator commands
- detailed system configuration
Error reports are time stamped and serial numbered.
The last error report number is displayed at the configuration
display.
4.1.1.8.1.6 C̲r̲a̲t̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
COPSY can request the status of a crate monitored through
the CCB.
4.1.1.8.1.7 C̲O̲P̲S̲Y̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
COPSY can request the WDP to:
- execute direct CCB control
- perform a switchover
- notify the AC PU, that the SB PU is down/up
Refer to section 4.1.6.3.2 for a detailed I/F description.
4.1.1.8.2 I̲n̲p̲u̲t̲ ̲f̲r̲o̲m̲ ̲t̲h̲e̲ ̲W̲D̲P̲-̲V̲D̲U̲
Refer figure 4.1.1.8.2-1.
The WDP-VDU directs operator commands to the WDP itself
or to either of the PUs (active, standby or offline).
The direct WDP commands are used to:
- enable system start-up.
- perform emergency close-down/switchover during
CAMPS operation.
- define which PU to communicate with and whether
offline communication is to be used.
Fig. 4.1.1.8.2-1…01…VDU in Functions
4.1.1.8.3 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲u̲s̲ ̲I̲n̲p̲u̲t̲
A CCB driver (standard software) periodically scans
crates.
Exceptions are given to CAMPS application FW. The
application determines a TYPE:
1- error in active PU
2- error in active PU peripheral
3- error in standby Pu
4- error in offline Pu
5- manual intervention, which does not interfere with
the CAMPS operation.
Type 1 makes the WDP force an emergency switchover:
- the AC PU is disabled
- the SB PU is commanded to go active
Types 2, 3, 4, 5 make the WDP send a report to the
AC PU of one of the following types:
- SB down
- BSM-X down
- TDX CTR down
- Manual intervention
- SB CU down
4.1.1.8.4 S̲t̲a̲n̲d̲a̲r̲d̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲
The watchdog standard firmware consists of the watchdog
kernel and start up firmware.
The Kernel contains:
- a VDU driver
- an LP driver
- two PU drivers, which can execute in protocol mode
(on line PU communication) or in transparent protocol
mode (offline communication)
- a CCB driver, which periodically scans the configuration
control bus
The watchdog employs two start up modes:
- initialization
- recovery/restart
The recovery/restart mode is entered, if the watchdog
has been removed and later is reinstalled. Recovery/restart
is executed without affecting the ongoing CAMPS operation.
4.1.1.9 C̲o̲m̲m̲o̲n̲ ̲S̲S̲C̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The function responsibilities defined in section 2.2.2
can in most cases be allocated to a specific software
structure. However, own error handling and validity
checks are common functions for any SSC Software structure.
The functions are defined above in figure 4.1.1.9-1.
Fig. ????????
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The SSC PU functions are allocated onto 5 processes
as defined in figures 4.1.2-1 and 4.1.2-2.
Figure 4.1.2-2 defines the allocation of COPSY functions
onto coroutines and an initialization procedure.
Figure 4.1.2-3 defines the allocation of WDP functions
onto 4 processes.
Finally, figure 4.1.2-4 defines SSC subpackages based
on the above processes, coroutines and initialization
procedure.
Figs. 4.1.2-1/4.1.2-4
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̲
The section is divided into 5 subsections:
- COPSY data flow and control logic
- CMI data flow and control logic
- CPT and CPR data flow and control logic
- OLO data flow and control logic
- WDP data flow and control logic
4.1.3.1 C̲O̲P̲S̲Y̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲s̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The COPSY coroutines data flow and control logic are
illustrated on figure 4.1.3.1-1 overleaf.
The following subsections handle:
- the SEH coroutine
- the CMD coroutine
- the M&C coroutines
- the CFH coroutine and INIT-COPSY
Fig. 4.1.3.1-1…01…COPSY Coroutines Data Flow and Control Logic
4.1.3.1.1 C̲M̲D̲ ̲C̲o̲r̲o̲u̲t̲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̲
The command dispatcher coroutine services:
- SYSE (system synchronization element), which contains
MMON security commands.
- SYQ (system queue), which contains operator commands,
TEP subprocess control commands and periodic timer
requests.
The MMON security commands are sent to an appropriate
VDU-M-C coroutine for execution. The periodic timer
requests are sent to the WDP-M-C (implies a keep alive
message to the WDP).
TEP circuit commands are directed to the CFH. TEP
blocking and security interrogation commands are directed
to an appropriate VDU-M-C coroutine.
Supervisor accept commands are sent to an appropriate
SAD-M-C or EXC-M-C coroutine.
4.1.3.1.2 S̲E̲H̲ ̲C̲o̲r̲o̲u̲t̲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̲
The system error handler coroutine services:
- SDSE (secondary device synchronization elements),
which contains HW error reports from DAMOS/CSF
- PSE (parent synchronization element), which contains
retired process reports from DAMOS/CSF
- ERQ (error queue), which contains error reports
from COPSY children
The SEH coroutine sends error reports to the CFH in
an operation semaphore (CFH-OS).
4.1.3.1.3 M̲-̲C̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲s̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
An M-C coroutine performs the following tasks:
- receives commands via an operation semaphore
- controls a subprocess by sending operational commands
to a subprocess input queue. A reply is awaited
in a reply queue.
- monitors a system connection and performs a succeeding
control.
4.1.3.1.3.1 R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲i̲n̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲
The CFH controls a M-C coroutine by a start and a stop
command. A start/stop command signals that a line
is configurational/enabled or is to be disabled (due
to an operator command). Via the CMD coroutine (or
CFH) a M-C receives and executes the commands described
in section 4.1.3.1.1.
The execution of the above commands is implemented
by a profile update and by communication to a subprocess,
the CPT or the CMI.
Having executed a command, a reply is either sent to
CFH (in CFH-S) or directly to TEP or MMON.
Execution of supervisor commands and user procedures
is logged and statistics generated.
4.1.3.1.3.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲a̲ ̲S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲,̲ ̲C̲P̲T̲,̲ ̲C̲M̲I̲
The following types of commands are sent from all M-C
coroutines:
- line configurational enabled/disabled
For lines with logical access control (VDU, SAD, EXC)
the following auxiliary commands are sent:
- line logical accessable/inaccessable
For VDU lines, the following auxiliary commands are
sent:
- VDU blocked
- security interrogation to be performed or is performed.
The communication is via separate request/reply queues
per subprocess, CPT or CMI.
4.1.3.1.3.3 M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲
One M-C coroutine handles one line to:
- a VDU or
- a SAD or
- an EXC or
- the SB PU
except for the WDP-M-C coroutine which handles three
lines to:
- the WDP and
- the WDP-VDU and
- the WDP-LP
One VDU-M-C, SAD-M-C or EXC-M-C coroutine communicates
to one subprocess in TEP or THP. The SB-PU-M-C coroutine
communicates to the CPT process, whereas WDP-M-C coroutine
communicates to CMI.
The system connection monitoring and subsequent control
functions are described on figure 4.1.1.4.2-1.
The control functions are entirely handled in an M-C
coroutine by profile table updates and for VDUs by
direct VDU communication.
However, the WDP-M-C coroutine receives the result
of WDP internal monitoring. This monitoring information
is directed to the CFH in the CFH-OS.
4.1.3.1.4 T̲h̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲(̲C̲F̲H̲)̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
̲L̲o̲g̲i̲c̲
The configuration handler includes:
- an initialization procedure COPSY-INIT
- the CFH coroutine
4.1.3.1.4.1 C̲O̲P̲S̲Y̲-̲I̲N̲I̲T̲
COPSY-INIT is started by the ROOT process in the Kernel.
COPSY-INIT initializes all COPSY coroutines, loads
the CMI and starts the WDP-M-C coroutine.
A start-up command to the "CHF" is user awaited.
4.1.3.1.4.2 C̲F̲H̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The main task for the CFH is to:
- execute an error fix-up
- execute operator commands including start-up, close-down
and peripheral reconfiguration commands
based upon commands in its input operation semaphore
CFH-OS.
The CFH loads and initializes child processes based
on load files and configuration files on disk.
The start-up/close-down of processes is divided into
two categories:
- non-line processes are started/closed via separate
request queues and a single reply queue.
- line processes are started/closed by starting/closing
an appropriate COPSY M-C coroutine. An M-C coroutine
sends a reply to a CFH-S (single coroutine semaphore)
when having executed a command.
Reconfiguration due to operator commands or an error
includes:
- updating the HW and SW configuration tables
- updating the WDP-VDU system configuration (via
a system connection)
- issuing of WDP-LP error reports (via a system connection)
- sending of commands directly to the WDP (via a
system connection)
- starting/stopping subprocesses
The CFH sends replies to the CMI, when having executed
an operator command.
The CFH sends replies to the TEP, when having executed
a circuit command.
Reconfigurations related to the offline disk are sent
to TEP (in a supervisor subprocess).
4.1.3.2 C̲M̲I̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Figure 4.1.3.2-1 overleaf defines the environment for
the CMI process. The CMI process receives operational
commands (e.g. start-up) from COPSY in its input queue
CMIQ and sends replies to the CMIRQ at COPSY.
The CMI receives operator commands via the WDP-VDU
command split (refer section 4.1.4.2.3) and operator
command formats via the format split. CMI validates
operator commands against the HW configuration table.
Having validated a command COPSY is requested via
the SYQ to execute the command. COPSY sends a command
execution reply to the CMIQ, whereupon CMI logs the
command on the WDP-LP.
Fig. 4.1.3.2-1…01…CMI Block Diagram
4.1.3.3 C̲P̲T̲ ̲a̲n̲d̲ ̲C̲P̲R̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Blockdiagram 4.1.3.3-1 illustrates the environment
for the checkpoint transmission and reception processes.
CPT and CPR receive operational commands (e.g. start-up)
from COPSY in an input queue (CTQ, CRQ) and returns
a reply to a COPSY reply queue.
The CPT process transfers time-of-day checkpoint log
records and CIF records on behalf of TMON, LOG and
MMON. The checkpoints are received in the CTQ or CTSE
as depicted overleaf. CPT transfers the checkpoints
via the TDX-bus to the CPR process, which stores the
checkpoints in various checkpoint tables. Having received
an acknowledgement from CPR, CPT sends a reply to the
callers i.e. LOG or MMS. During a switchover, the
collected checkpoints are returned to the senders.
Fig. 4.1.3.3-1…01…CPT and CPR Environment
