top - download
⟦dbb94e58a⟧ Wang Wps File
Length: 49420 (0xc10c)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »1376A «
Derivation
└─⟦2c95d9416⟧ Bits:30006059 8" Wang WCS floppy, CR 0091A
└─ ⟦this⟧ »1376A «
WangText
…0c……08……0c……0d……0c……02……0c……07……0b……0c……0b……86…1
…02…
…02…
…02…
…02…CPS/SDS/001
…02…FH/811020…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02…ISSUE
1.1…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
5.11 SYSTEM STATUS AND CONTROL ...............
499
5.11.1 General .............................
499
5.11.1.1 Purpose and Scope ...............
499
5.11.1.2 Applicable Documents and Project
References, Special for Section
5.10 ............................
499
5.11.1.2.1 Applicable Documents ........
499
5.11.1.2.2 Project References ..........
500
5.11.1.3 Terms and Abbreviations Special
For Section 5.11 ................
501
5.11.1.3.1 Terms .......................
501
5.11.1.3.2 Abbreviations ...............
502
5.11.2 Summary of Requirements .............
503
5.11.2.1 Package Description .............
503
5.11.2.1.1 Block Diagram ...............
504
5.11.2.2 Package Functions ...............
506
5.11.2.2.1 Main Functions ..............
506
5.11.2.2.1.1 Checkpoint Transmission .
508
5.11.2.2.1.2 Checkpoint Reception ....
508
5.11.2.2.1.3 On-Line Diagnostics .....
509
5.11.2.2.1.4 Line Monitoring and
Control .................
509
5.11.2.2.1.5 Reception of Technical
Error Reports ...........
510
5.11.2.2.1.5.1 Active PU Handling ..
511
5.11.2.2.1.5.1.1 SW Error Reports
511
5.11.2.2.1.5.1.1.1 Child Action
511
5.11.2.2.1.5.1.1.2 DAMOS/CSF
Action ......
514
5.11.2.2.1.5.1.1.3 COPSY Hand-
ling of SW
Reports .....
514
5.11.2.2.1.5.1.2 HW Error Reports
515
5.11.2.2.1.5.2 Handling of Errors
Reported by Other
Packages to the
SSC in the SB PU ....
516
5.11.2.2.1.6 Operator Commands to an
On-Line PU ..............
516
5.11.2.2.1.7 Off-Line PU Operation ...
517
5.11.2.2.1.7.1 Commands to the Off-
Line PU .............
517
5.11.2.2.1.7.2 Allocation of Re-
sources to the
Off-Line PU .........
517
5.11.2.2.1.8 Watchdog Firmware
Functions ...............
518
5.11.2.2.1.8.1 Watchdog Line
Communication .......
518
5.11.2.2.1.8.2 Switch Logic ........
519
5.11.2.2.1.8.3 Switchover ..........
519
5.11.2.2.1.8.4 WDP Standard Firmware
520
5.11.2.2.2 Functional Responsibilities .
520
5.11.2.2.2.1 Initialization, Close-
Down, and Restart .......
520
5.11.2.2.2.1.1 Start-Up (Initializa-
tion and Restart) ...
521
5.11.2.2.2.1.1.1 Boot Load .......
521
5.11.2.2.2.1.1.2 Start-Up of Ac-
tive and Stand By
PU ..............
524
5.11.2.2.2.1.1.3 Disk Start-Up
Information .....
529
5.11.2.2.2.1.2 Ordered Close-Down ..
530
5.11.2.2.2.1.2.1 AC PU Ordered
Close-Down ......
530
5.11.2.2.2.1.2.2 SB PU Ordered
Close-Down ......
533
5.11.2.2.2.2 Checkpointing and
Recovery ................
533
5.11.2.2.2.2.1 Checkpointing .......
533
5.11.2.2.2.2.2 Recovery ............
535
5.11.2.2.2.2.2.1 Cold ............
535
5.11.2.2.2.2.2.2 WARM1 ...........
535
5.11.2.2.2.2.2.3 WARM2 ...........
535
5.11.2.2.2.2.2.4 WARM3 ...........
536
5.11.2.2.2.2.2.5 SB1 .............
536
5.11.2.2.2.2.2.6 SB2 .............
536
5.11.2.2.2.3 Handling of SSC Internal
Detected Errors ...........
536
5.11.2.2.2.3.1 In the AC PU ..........
538
5.11.2.2.2.3.2 In the SB PU ..........
538
5.11.2.2.2.3.3 In the WDP ............
538
5.11.2.2.2.4 Integrity of Operation ....
538
5.11.2.2.2.5 Data Collection ...........
541
5.11.2.2.2.5.1 LOG ...................
541
5.11.2.2.2.5.2 Statistics ............
541
5.11.2.2.2.5.3 Reports ...............
543
5.11.2.2.2.6 Security ..................
543
5.11.2.2.2.6.1 Security on DAMOS
Objects ...............
543
5.11.2.2.2.6.2 Security on CAMPS
Queues ................
543
5.11.2.3 Characteristics ...................
544
5.11.2.3.1 Timing ........................
544
5.11.2.3.1.1 Switchover ................
544
5.11.2.3.1.2 Initialization ............
544
5.11.2.3.1.3 Recovery/Restart ..........
544
5.11.2.3.1.4 Watchdog Line Speeds ......
544
5.11.2.3.1.5 Response Time .............
545
5.11.2.3.1.6 Start-Up and Close-Down
Sequence ..................
545
5.11.2.3.1.7 Priorities of Input .......
545
5.11.2.3.2 Throughput ....................
545
5.11.2.3.2.1 Increase of Software Size .
545
5.11.2.3.2.2 Equipment Capacity ........
546
5.11.2.3.3 Flexibility ...................
546
5.11.2.3.3.1 Hardware Configuration
Changes ...................
546
5.11.2.3.3.2 Operator Commands .........
546
5.11.2.3.3.3 Loading of New Versions of
Software ..................
546
5.11.2.3.4 Accuracy and Validity .........
547
5.11.2.3.4.1 Accuracy of Input Data ....
547
5.11.2.3.4.2 Accuracy of Transmitted
Data ......................
547
5.11.3 Environment ...........................
548
5.11.3.1 Equipment .........................
548
5.11.3.2 Software ..........................
548
5.11.3.2.1 System Software ...............
548
5.11.3.2.2 Development Software ..........
548
5.11.3.3 Interfaces ........................
548
5.11.3.3.1 External Interfaces ...........
548
5.11.3.3.2 Package Interfaces ............
549
5.11.3.3.2.1 SSC to TEP ................
549
5.11.3.3.2.2 TEP to SSC ................
549
5.11.3.3.2.3 SSC to MMON/MMS ...........
549
5.11.3.3.2.4 MMON/MMS to SSC ...........
549
5.11.3.3.2.5 SSC to SFM ................
550
5.11.3.3.2.6 SSC to CSF Process ........
550
5.11.3.3.2.7 SSC to QMON ...............
550
5.11.3.3.2.8 SSC to Timer Monitor ......
550
5.11.3.3.2.9 SSC to TMP ................
550
5.11.3.3.2.10 SSC to MDP ................
551
5.11.3.3.2.11 SSC to LOG ................
551
5.11.3.3.2.12 LOG to SSC ................
551
5.11.3.3.2.13 SSC to THP ................
551
5.11.3.3.2.14 SSC to SAR ................
551
5.11.3.3.2.15 SSC to STP ................
552
5.11.3.3.2.16 SSC to IOC ................
552
5.11.3.3.2.17 SSC to SSP ................
552
5.11.3.3.2.18 SSC to OLP ................
552
5.11.3.4 Functions Maintained by Other
Packages ..........................
552
5.11.3.4.1 Recovery ......................
552
5.11.3.4.2 Error Detection and Handling ..
553
5.11.3.4.3 Security ......................
553
5.11 S̲Y̲S̲T̲E̲M̲ ̲S̲T̲A̲T̲U̲S̲ ̲A̲N̲D̲ ̲C̲O̲N̲T̲R̲O̲L̲
5.11.1 G̲e̲n̲e̲r̲a̲l̲
5.11.1.1 P̲u̲r̲p̲o̲s̲e̲ ̲a̲n̲d̲ ̲S̲c̲o̲p̲e̲
N/A.
5.11.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̲,̲ ̲S̲p̲e̲c̲i̲a̲l̲
̲f̲o̲r̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲5̲.̲1̲1̲
5.11.1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
The SSC implements the operator commands defined in:
CPS/230/ICD/0001
User Procedures and Associated Formats
CSS/3500/PSP/0029
DAMOS Boot Loader
CSS/3400/PSP/0028
DAMOS Initialization
CSS/3450/PSP/0057
DAMOS Root
CDS-MIC/003/USM/0003
Watchdog Standard Firmware
5.11.1.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
The SSC interfaces to the following packages:
- CR80D
- Watchdog Processor
- Kernel Package (KERNEL)
- I/O Control Package (IOC)
- CAMPS System Function Package (CSF)
- Storage and File Management Package (SFS)
- Traffic Handling Package (THP)
- Distribution Package (MDP)
- Terminal Package (TEP)
- Table Management Package (TMP)
- Storage & Retrieval Package (SAR)
- Log and Accountability Package (LOG)
- Statistics Package (STP)
- Support Software Package (SSP)
- Off-Line Package (OLD)
5.11.1.3 T̲e̲r̲m̲s̲ ̲a̲n̲d̲ ̲A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲ ̲S̲p̲e̲c̲i̲a̲l̲ ̲f̲o̲r̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲5̲.̲1̲1̲
5.11.1.3.1 T̲e̲r̲m̲s̲
Connection (DAMOS A connection is a logical channel
TMS term) to a "terminal" on a channel.
A terminal can be:
- an EXC
- a VDU or VDU split
- an SAD
- a PU
Two types of connections exist:
- System connection
- User connection
Dead Start-up Initialization from the off-line
disk.
Line A line refers to a physical
V24 wire from an LTU or LTUX.
Monitoring and Control Monitoring refers to a status
inspection, whereas control
refers to an execution. Supervision
includes monitoring and control.
Port A port refers to a line, a disk,
a TDX bus, an IOBUS, or a PU.
For lines a port may be visualized
as a physical wire relating
to a specific slot again relating
to a specific crate.
System View Refers to the data parts of
a process, which is visible
for a system component (e.g.
Kernel, IOS, QMON, MMON procedures).
User View Refers to the data part of a
process, which is visible for
a non system component.
5.11.1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
AC Active
CCB Configuration Control Bus
CPT Checkpoint Transmission
CMD Command Dispatcher
CMI Command Interface
CRT CAMPS Remote Terminal
EHD Error Handler and Command Dispatcher
ERQ Error Queue
EXC External Channel
FCT Function
M&C Monitoring and Control
OLD On-line diagnostics
PSE Parent Synchronization Element
PTOP Point to Point
SAD Stand Alone Device
SB Stand By
SDSE Secondary Device Synchronization
Element
5.11.2 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
5.11.2.1 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The SSC package starts, allocates resources to, monitors
and controls the CAMPS on-line and off-line system
through interaction between the two PUs, the peripherals,
the watchdog, and the operator.
The on-line modes of operation handled are:
- a dualized system consisting of an active PU and
associated peripherals and a stand-by PU
- a degraded system consisting of an active PU and
associated peripherals and an off-line PU and associated
peripherals
In the degraded system the SSC controls the off-line
operations:
- software development and test
- table generation
- maintenance and diagnostics
- offline utilities
The monitoring of the active and the standby system
includes:
- reception of error reports from other packages
- reception of hardware status from crates
- display of system status
- execution of on-line diagnostics programs
The control of the dualized and degraded system includes:
- physical connection of hardware modules
- allocation of resources to other packages e.g.
external and terminal lines
- execution of operator commands
The start-up of the dualized and degraded system includes:
- all forms of initialization
- ordered switchover to a stand-by processor and
corresponding recovery and restart actions
- recovery/restart actions during an emergency switchover
or after a total system error or after a disastrous
error
5.11.2.1.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
The SSC functional relationship to other packages is
depicted on the block diagram 5.11.2.1.1-1 overleaf.
The block diagram only defines on-line interfaces,
whereas start-up/close-down interfaces are not covered.
However, SSC interfaces to all application and system
software packages during start-up/close-down.
Also, error-handling interfaces are not shown. SSC
interfaces to all applications and system packages
during error-handling.
figure 5.11.2.1.1-1
5.11.2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
5.11.2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The SSC functions are depicted on figure 5.11.2.2.1-1
overleaf.
The SSC functions are separated in 3 groups:
- on-line functions
- off-line operation
- watchdog functions
The on-line functions include the CAMPS top level operating
system COPSY, which
- is the parent of all processes
- handles allocation of all types of resources, including
specification of security and access control
- determines hardware and software reconfiguration
after the reception of an error report or an operator
command
- implements logical access - and distribution control
on lines.
figure 5.11.2.2.1-1
As resource management is one of the major SSC responsibilities,
the resources are specified.
- CAMPS queues
- Processes
- CPUs
- Memory
- Security and Access Control Specification
- Lines and Devices
- Users of FMS and MMS
- Files
- Synchronization Elements and Queues
COPSY updates a Configuration table for all hardware
and software components and updates in conjunction
with the watchdog a system status display on the operator
VDU.
Section 5.11.2.2.1.1 through 5.11.2.2.1.8 describe
the SSC functions.
5.11.2.2.1.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
Application and system packages in the active PU transfers
checkpoint data to the standby PU to enable fast recovery
in case of switchover.
The SSC receives checkpoint records and transmits the
records via the TDX bus to the standby PU.
5.11.2.2.1.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
The SSC in the standby PU receives checkpoint records
from the active PU via the TDX bus. The SSC updates
a number of tables based on the type of the checkpoint
records.
5.11.2.2.1.3 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
Generally the on-line diagnostics test programs aim
at limiting the effect of an error by
- timely detection of errors
- reporting the error condition
Specifically the test programs participate in meeting
the availability and integrity of operation requirements.
The test programs operate as low priority tasks together
with the application software. Error conditions are
reported to the technical error processing software.
A specific test program to verify system integrity
through a checksumming of read-only system software
is available. The program is executed on request from
the supervisor and periodically.
5.11.2.2.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̲ ̲(̲L̲I̲M̲C̲O̲)̲
LIMCO monitors and controls
- L̲T̲U̲ ̲L̲i̲n̲e̲s̲
- A line corresponds to an EXC
- L̲T̲U̲X̲ ̲L̲i̲n̲e̲s̲
- a VDU
- an SAD (i.e. ROP, PTR, PTP, OCR)
- an EXC on low speed lines
- the WDP
- the WDP ̲VDU
- the WDP ̲LP
- the SB ̲PU
The LIMCO functions are divided into two areas:
- Execution of logical control on behalf of other
packages e.g. access control (block/unblock) and
delivery control (security functions)
- Monitoring of the system connection and subsequent
execution of control.
The system connection is used by applications to
communicate to the system software, which handles
security functions.
For VDUs COPSY handles:
- sign on/off
- supervisor terminal assignment
- specification of functional capabilities
Also, error conditions and key lock events are
reported on a system connection.
5.11.2.2.1.5 R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
Technical errors refer to errors resulting from
- system calls
- instruction execution
- validity checks
- WDP monitoring
The SSC performs the following common handling for
all received error reports:
- The configuration table is updated (by COPSY in
the AC PU)
- The configuration display at the WDP ̲VDU is updated
(by COPSY in the AC PU)
- An error report is printed at the WDP-LP
The COPSY error fix up for technical error reports
is divided into two sections:
1) Active PU handling
2) Standby PU handling
5.11.2.2.1.5.1 A̲c̲t̲i̲v̲e̲ ̲P̲U̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
COPSY receives HW and SW error reports. The HW error
reports originate from DAMOS or from the WDP.
The SW error reports originate from DAMOS/CSF or from
a COPSY child.
5.11.2.2.1.5.1.1 S̲W̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
This section describes:
1) the child error handling
2) DAMOS/CSF error handling
3) the corresponding COPSY reaction
5.11.2.2.1.5.1.1.1 C̲h̲i̲l̲d̲ ̲A̲c̲t̲i̲o̲n̲
A child reaction to SW errors depends on the process
type, the system mode and the error type. Processes
are divided into three types:
1) Vital
2) Dummy
3) Retirable
V̲i̲t̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲
Vital processes cannot be retired or executed in dummy
mode without inhibiting normal processing.
D̲u̲m̲m̲y̲ ̲P̲r̲o̲c̲e̲s̲s̲
Dummy type processes are processes (e.g. log, statistics),
which
- do not influence message processing
- cannot be retired without changing the behaviour
of other processes
- can execute in a mode, where no other processing
is performed, but answering requests as if they
are sucessfully executed (i.e. transparent for
a user).
R̲e̲t̲i̲r̲a̲b̲l̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
Retirable processes can be retired, without changing
the behaviour of other processes (e.g. processes serving
VDUs or channels).
The system is able to execute in two modes:
- NORMAL
- AT ̲RISK
In normal mode any SW error will imply an emergency
switchover.
In AT ̲RISK mode the SW action depends on the error
type and the process type.
The process-type is a start-up parameter. The AT ̲RISK/NORMAL
mode setting is performed by the operator.
The operator may determine to set AT ̲RISK mode
- During load of new software (e.g. patches)
- During a WARM1/3 start-up, when the SB PU has failed
subsequent to a switchover.
For users the actual setting is available through TMP.
E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲s̲
Child process errors are divided into 2 types.
- External program logic errors
Covers validity check errors in input data
- Internal program logic errors
Covers internal program logic errors detected during
validity checks or system calls.
C̲h̲i̲l̲d̲ ̲A̲c̲t̲i̲o̲n̲
A child error action depends in AT ̲RIST mode on the
error type and the process type as defined below.
Three child actions are defined:
- Retire
- Dummy-action
- Partial-recovery
A RETIRE action implies:
- Report error to COPSY
- Retire
A DUMMY ̲ACTION implies:
- Report error to COPSY
- Perform dummy operation
A PARTIAL ̲RECOVERY action implies:
- Report error to COPSY
- Send NACK (not acknowledge) to caller
- Continue processing
PROCESS
TYPE VITAL DUMMY RETIRABLE
ERROR
TYPE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
INTERNAL RETIRE DUMMY-ACTION RETIRE*
RETIRE*
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
EXTERNAL PARTIAL ̲ PARTIAL ̲ PARTIAL ̲
RECOVERY RECOVERY RECOVERY
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
* A process of dummy type, retires if it can foresee,
that it is not able to execute in dummy mode (e.g.
error detected during reading from input queue).
5.11.2.2.1.5.1.1.2 D̲A̲M̲O̲S̲/̲C̲S̲F̲ ̲A̲c̲t̲i̲o̲n̲
DAMOS/CSF reports are sent due to a security violation
upon which the process in question is retired and the
parent (COPSY) is notified.
5.11.2.2.1.5.1.1.3 C̲O̲P̲S̲Y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲S̲W̲ ̲R̲e̲p̲o̲r̲t̲s̲
In NORMAL ̲MODE COPSY performs an emergency switchover
for any type of report.
In AT ̲RISK mode the COPSY action depends on the child
action and the reporting process type:
PROCESS
TYPE VITAL DUMMY RETIRABLE
CHILD
ACTION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
RETIRED SWT SWT CONT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DUMMY ̲ACTION NA CONT NA
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PARTIAL CONT CONT CONT
RECOVERY
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SWT: Switchover
CONT: Continue CAMPS Processing
NA: Not applicable
5.11.2.2.1.5.1.2 H̲W̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
DAMOS reports HW errors
- For peripherals detected by handlers
- For a PU detected by error interrupts due to instruction
execution
to COPSY
The WDP reports HW errors, which are detected:
- Via its configuration control bus
- Via protocols to the PUs
For handler detected errors the users of the peripheral
are notified via a system call completion code specifying:
"line/file unavailable".
P̲e̲r̲i̲p̲h̲e̲r̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
The COPSY and child actions depend on the type of error.
The following types are foreseen:
1 - LTU-line
2 - LTU
3 - LTUX-line
4 - LTUX
5 - BSM-X
6 - TDX-bus
7 - OFFLINE DISK
8 - OFFLINE DISK VOLUME
9 - MIRRORED DISKs
10 - MIRRORED DISK VOLUME
11 - FLOPPY DISK
12 - FLOPPY DISK VOLUME
13 - WDP
14 - WDP ̲VDU
15 - WDP ̲LP
16 - ACTIVE PU
17 - STANDBY PU
The detailed COPSY/child actions are described in section
4.1.1.5.
5.11.2.2.1.5.2 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲E̲r̲r̲o̲r̲s̲ ̲R̲e̲p̲o̲r̲t̲e̲d̲ ̲b̲y̲ ̲O̲t̲h̲e̲r̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
̲t̲o̲ ̲t̲h̲e̲ ̲S̲S̲C̲ ̲i̲n̲ ̲t̲h̲e̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲
The handling of errors reported to the standby COPSY
is a subset of the handling in the active PU as the
only SB-peripheral is the TDX bus and as the SB PU
only contains system software.
5.11.2.2.1.6 O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲a̲n̲ ̲O̲n̲-̲L̲i̲n̲e̲ ̲P̲U̲
Operator commands control the CAMPS hardware and software
configuration. The execution of the control is shared
between the active PU and the WDP. The SSC in the active
PU directs the WDP to execute hardware control (e.g.
BSM-X Control).
The basis for execution of operator commands is status
information displayed on the operator VDU and detailed
error reports printed at the operator printer.
The following types of operator functions are foreseen:
- start-up of all modes of the system
- ordered close down of the system
- switch between hardware units, when dualization
is used
- device control
- connection of devices to buses
- enable/disable operational use of a device
line
- control of line attributes (e.g. speed)
- load of new software
- set NORMAL/AT ̲RISK mode.
- define generation of trace information
- print system status
- set time of day
- commands directly to the watchdog
SSC start-up and close-down responsibilities are defined
in section 5.11.2.2.2.1.
5.11.2.2.1.7 O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The SSC provides a command interface to the support
software package (SSP) and the offline package (OLP)
in the off-line PU and allocates resources to enable
the off-line operations.
The SSP commands includes low level M&D (maintenance
and diagnostic) commands to the MAP and MIA (MAP interface
processor).
5.11.2.2.1.7.1 C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲
Operator commands exist to control:
- support software
- off-line utility software
The initialization of off-line PU operation is covered
in section 5.11.2.2.2.1.1.1.
The commands control execution of maintenance and diagnostics
software and off-line utility software (control of
development and test software and table generation
software are executed from the development VDU at the
IO-BUS). The communication with the off-line PU is
implemented by using a protocol like the transperant
WDP protocol described in the IOC.
5.11.2.2.1.7.2 A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲
a) To support maintenance and diagnostics software
operations the following resources may be allocated:
- floppy disk
- off-line disk
- an IO-BUS and an LTU
- a TDX bus, a TDX controller and 2 LTUXs
- an on-line disk
The floppy disk or the off-line disk may be used
for load of SSP or OLP software. To support offline
utility operation, the floppy disk or the offline
disk is allocated.
b) To support development and test software and table
generation software operations the following resources
must be allocated:
- floppy disk
- off-line disk
- development VDU and printer at the CSSI Site.
c) The execution of off-line PU software will not
influence CAMPS on-line operations as an electrical
isolation of on-line hardware modules and off-line
hardware modules are provided. Refer to CAMPS System
Design Specification: CPS/SDS/001 for a description
of resources allocated to off-line operation.
5.11.2.2.1.8 W̲a̲t̲c̲h̲d̲o̲g̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
5.11.2.2.1.8.1 W̲a̲t̲c̲h̲d̲o̲g̲ ̲L̲i̲n̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲
a) The watchdog line communication firmware supports
communication to two PUs, the operator VDU and
the operator printer
The communication firmware will be designed to
be mainly transparent to the operator VDU and the
printer.
1) The operator may direct commands to either
of the PUs
2) The VDU is used for system status display and
for the command dialogue
3) The printer is used for print out of
- detailed error reports
- detailed system status
- maintenance and diagnostics output
- off-line utilities output
5.11.2.2.1.8.2 S̲w̲i̲t̲c̲h̲ ̲L̲o̲g̲i̲c̲
The switch logic firmware in the watchdog controls
the physical connection of hardware modules based on:
- commands from PUs
- no keep alive message received from either of the
PUs
- commands from the operator
- direct monitoring of discrete points in the crates
through the CCB
The monitoring of the crates through the configuration
control bus is performed by a periodic scanning.
5.11.2.2.1.8.3 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
The switch logic enforces a switchover to the stand
by PU in the following cases:
- no keep alive message received from the active
PU within predefined time interval
- non recoverable hardware error in active PU or
IO-BUS
- non recoverable software error in active PU
The watchdog performs the following actions automatically
during an emergency switchover:
- isolate the current active PU
- notify the current stand by PU to become active
Hereafter the current stand by will direct the watchdog
to switchover the peripherals previously owned by the
active PU to itself.
5.11.2.2.1.8.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲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 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.
5.11.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̲
5.11.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̲
The section is divided into two:
- Start-up
- Close-down
5.11.2.2.2.1.1 S̲t̲a̲r̲t̲-̲U̲p̲ ̲(̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲)̲
The start-up actions relate to the following modes
of operation:
- a dualized system consisting of an active PU and
a stand-by PU
- a system containing an active PU and an off-line
PU
The start-up phase is divided into two phases:
- boot-load of on-line or off-line PU
- subsequent on-line start-up actions.
5.11.2.2.2.1.1.1 B̲o̲o̲t̲ ̲L̲o̲a̲d̲
Boot load functions are illustrated on figure 5.11.2.2.2.1.1.1-1
overleaf.
The boot loading functions are invoked via operator
commands directly to the MAP PROM.
Via the Boot operator command either
- on-line software
- off-line OLP or SSP software
is booted.
The disks and disk boot files are described in section
5.11.2.2.2.1.1.3.
An on-line boot implies that that Kernel process ROOT
is loaded and started. ROOT loads and starts CAMPS
system software, including the CAMPS operating system
COPSY. COPSY performs an initialization, which enables
the reception of the operator command start-up.
Also, the boot load functions include the execution
of a memory dump to disk.
The MAP PROM functions are described in:
CSS/3500/PSP/0029
The ROOT functions are described in:
CSS/3400/PSP/0028
DAMOS Initialization
CSS/3450/PSP/0057
DAMOS ROOT OS
Figure 5.11.2.2.2.1.1.1-1
5.11.2.2.2.1.1.2 S̲t̲a̲r̲t̲-̲U̲p̲ ̲o̲f̲ ̲A̲c̲t̲i̲v̲e̲ ̲a̲n̲d̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲
The modes of start-up which relate to on-line operations
are illustrated in figure 5.11.2.2.2.1.1-1 Initialization
modes of start up are named dead whereas start-up actions
including recovery/restart are named cold or warm.
The start-up configuration is either
- an active and a stand-by PU, or
- an active PU
Figure 5.11.2.2.2.1.1-1
In figure 5.11.2.2.2.1.1.2-2 and 3 the start up AC
and SB PU functions are detailed.
During initialization COPSY creates system files on
the mirrored disks and initializes these by copying
files from the off-line disk.
COPSY creates, loads, and starts all child processes
and assigns all types of resources, i.e. DAMOS objects
and CAMPS queues to the processes.
During the loading of processes SW patches (residing
on disk) are loaded if so defined by the operator.
Loaded files are sum-checked.
The process start-up specified here is independent
of start-up type. It includes an internal process initialization.
COPSY starts packages by issuing a sequence of start
commands to package processes.
In the standby PU only the system software supporting
standby functions are started. Some start-up types
include recovery. The SSC responsibility for recovery
is defined in section 5.11.2.2.2.2.2.
5.11.2.2.2.1.1.2-2 to -3
5.11.2.2.2.1.1.3 D̲i̲s̲k̲ ̲S̲t̲a̲r̲t̲ ̲U̲p̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
On-line start up is either performed from the off-line
or from the on-line (mirrored) disks.
The off-line disk pack contains a pregenerated (at
the CSSI site) system including the following files:
- Initial system parameter file, which contains
- hardware configuration
- software configuration
- a back-up of the current system parameter file
- system software library
- application software library
- a back up of the current system software library
- a back up of the current application software library
- software patches
- empty historical data files
- support software library
- offline utility library,
- storage of memory dump and trace records
The on-line disks include the following files:
- current systems parameter file
- current system software library
- a modified system software library
- application software library
- a modified application software library
- software patches
- historical data files, including
- log
- statistics
- CIFs in intermediate and short term storage
The operator start-up command specifies whether the
initial system parameter (DEAD1, DEAD2) or current
system parameter file is to be used. As a parameter
in BOOT it is specified, whether the unmodified or
modified system software is to be used.
As a parameter during start-up of the active PU it
is specified, whether unmodified or modified application
software is to be used.
5.11.2.2.2.1.2 O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲
The SSC is responsible for close-down of the CAMPS
system. The handling of close-down is divided into
two sections:
- active PU close-down
- standby PU close-down
5.11.2.2.2.1.2.1 A̲C̲ ̲P̲U̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲(̲R̲e̲f̲e̲r̲ ̲f̲i̲g̲u̲r̲e̲ ̲5̲.̲1̲1̲.̲2̲.̲2̲.̲2̲.̲1̲.̲2̲.̲1̲-̲1̲)̲
An ordered close-down command makes the SSC issue a
sequence of stop processing commands to other packages.
In the operator command a time period is specified,
within which the TEP and THP have to terminate processing.
The non-arrival of a reply from TEP or THP is handled
as a process communication error during sending refer
section 5.11.2.2.1.5.1.
THP will use the period to (if possible) terminate
the processing of a complete message. TEP will use
the period to (if possible) terminate the processing
of a complete transaction.
Remaining packages are given a fixed close-down period.
Having completed close-down a reply is sent to the
SSC by the package in question. When all packages are
closed the SSC notifies the operator and issues a programmed
master clear.
Figure 5.11.2.2.2.1.2.1-1
…01…and…01……01……01……01…Figure 5.11.2.2.2.1.2.2-1
5.11.2.2.2.1.2.2 S̲B̲ ̲P̲U̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲(̲R̲e̲f̲e̲r̲ ̲f̲i̲g̲u̲r̲e̲ ̲5̲.̲1̲1̲.̲2̲.̲2̲.̲2̲.̲1̲.̲2̲.̲2̲-̲1̲
The operator command is directed to the active PU,
which stops transmission of checkpoints and commands
the WDP to disable the SB PU via the CCB.
5.11.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̲
In figure 5.11.2.2.2.2-1 is summarized the SSC responsibilities
for checkpointing and recovery.
5.11.2.2.2.2.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲
The SSC provides service facilities for transportation
of checkpoint records to the standby PU. Also, the
checkpoint records, are collected in tables in the
SB PU.
The SSC is responsible for checkpointing the time of
day. Periodically the time of day is transferred to
disk (via TMP) and to the SB PU.
Figure 5.11.2.2.2.2-1
5.11.2.2.2.2.2 R̲e̲c̲o̲v̲e̲r̲y̲
The SSC contributes to recovery during the restart
start-up types:
- COLD
- WARM1
- WARM2 (after switchover)
- WARM3 (after ordered close-down)
- SB1 (SB inserted prior to the active PU start-up)
- SB2 (SB inserted subsequent to the active PU start-up)
5.11.2.2.2.2.2.1 C̲O̲L̲D̲
The SSC contains no other actions, but notifies the
CAMPS software packages of this type of start-up.
5.11.2.2.2.2.2.2 W̲A̲R̲M̲1̲
The SSC notifies the CAMPS software packages of this
type of start-up.
Also, the SSC requests MMS to update (restore) the
MMS checkpoints in the standby PU (if existing).
After 30 seconds the log checkpoints are automatically
restored.
5.11.2.2.2.2.2.3 W̲A̲R̲M̲2̲ ̲(̲A̲f̲t̲e̲r̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲)̲
The SSC notifies the CAMPS software packages of this
type of start-up.
Also, the SSC transfers collected checkpoint records
to the LOG and MMON respectively.
5.11.2.2.2.2.2.4 W̲A̲R̲M̲3̲ ̲(̲A̲f̲t̲e̲r̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲)̲
From the SSC point of view this type of start-up is
identical to WARM1.
5.11.2.2.2.2.2.5 S̲B̲1̲ ̲(̲S̲B̲ ̲S̲t̲a̲r̲t̲e̲d̲-̲U̲p̲ ̲P̲r̲i̲o̲r̲ ̲t̲o̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲ ̲P̲U̲)̲
The Standby PU awaits checkpoints from the action PU.
5.11.2.2.2.2.2.6 S̲B̲2̲ ̲(̲S̲B̲ ̲S̲t̲a̲r̲t̲e̲d̲-̲U̲p̲ ̲S̲u̲b̲s̲e̲q̲u̲e̲n̲t̲ ̲t̲o̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲
̲P̲U̲)̲
The MMS in the active PU is requested to restore the
MMS checkpoints in the standby PU.
5.11.2.2.2.3 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲S̲S̲C̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲s̲
Refer to figure 5.11.2.2.2.3-1 overleaf.
The SSC responsibility for error detection and handling
is divided into the following areas:
1) Handling of errors detected by the SSC in the active
PU
2) Handling of errors detected by the SSC in the standby
PU
3) Handling of errors detected internally in the WDP.
Figure 5.11.2.2.2.3-1
5.11.2.2.2.3.1 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲s̲ ̲i̲n̲ ̲t̲h̲e̲
̲S̲S̲C̲ ̲i̲n̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲ ̲P̲U̲
The handling of the errors are included in section
5.11.2.2.1.4 and 5.11.2.2.1.5.
For SW errors COPSY is handled as a VITAL process,
whereas SSC checkpoint transmission process is of the
DUMMY type. The remaining SSC PU processes are of RETIRABLE
or Dummy type.
5.11.2.2.2.3.2 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲s̲ ̲i̲n̲ ̲t̲h̲e̲
̲S̲S̲C̲ ̲i̲n̲ ̲t̲h̲e̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲
All SB processes are handled as VITAL.
5.11.2.2.2.3.3 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲E̲r̲r̲o̲r̲s̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲l̲y̲ ̲i̲n̲ ̲t̲h̲e̲
̲W̲a̲t̲c̲h̲d̲o̲g̲
An internal detected SW error will make the WDP issue
a programmed master clear.
Validity check errors for PU input will make the WDP
handle the PU as erroneous i.e. as if no keep active
message is received.
5.11.2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The SSC contributes to the ensurance of integrity of
operation by:
a) Detection of errors by on-line diagnostics program
b) Detection of errors by monitoring hardware modules
(via the WDP)
c) Electrical isolation of erroneous hardware modules
(executed by the WDP)
d) Reporting all detected errors to the WDP-LP
e) Performing an error fix-up subsequent to the detection
of an error
E.g. switchover, disable VDU
f) Validity Checks
Input data to the SSC (e.g. operator commands and
error reports) are syntax and semantic checked
for the data field used in processing the data.
Functions a to e are covered elsewhere in the document.
The validity checks are depicted in figure 5.11.2.2.2.4-1
overleaf.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VALIDITY CHECKS
18.0
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 5.11.2.2.2.4-1…01…SSC VALIDITY CHECKS FUNCTIONS
5.11.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̲)̲
The handling SSC data collection functions are shown
on the figure overleaf. Operator commands contributions
to data connections are handled elsewhere.
5.11.2.2.2.5.1 L̲o̲g̲
SSC will generate statistics during execution of the
following user procedures:
- Security interrogation (I1)
- Security warning (I2)
- Sign-on (K1)
- Sign-off (K2)
For operator commands a log record is printed at the
WDP-LP, defining the execution of the command in question.
The ASSIGN SUPERVISOR command (ASSG) is logged.
5.11.2.2.2.5.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
SSC will generate statistics during execution of the
following terminal procedures:
- Security interrogation (I1)
- Security warning (I2)
Figure 5.11.2.2.2.5-1
5.11.2.2.2.5.3 R̲e̲p̲o̲r̲t̲s̲
SSC will generate security reports to be printed at
the supervisor report printer as specified below:
- Unsuccessful sign-on attempt
- Unsuccessful security interrogation and whether
it was due to time-out or faulty password
- Security warning time out or invalid entry code
Technical error reports are printed at the WDP-LP.
The error reports are numbered sequentially and are
time stamped.
5.11.2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The SSC handles security related to:
1) DAMOS objects
2) CAMPS queues
5.11.2.2.2.6.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲o̲n̲ ̲D̲A̲M̲O̲S̲ ̲O̲b̲j̲e̲c̲t̲s̲
During any type of start-up the SSC specifies:
- the classification of DAMOS objects and subjects
(processes)
- the access rights for processes to DAMOS objects
5.11.2.2.2.6.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲o̲n̲ ̲C̲A̲M̲P̲S̲ ̲Q̲u̲e̲u̲e̲s̲
During
- any type of start-up
- sign on/off on VDUs
- specification of accept/not accept input/output
on EXC/SADs
the SSC specifies:
- queue profiles and subprocess profiles
- access capabilities for a subprocess to queue elements.
5.11.2.3 C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
5.11.2.3.1 T̲i̲m̲i̲n̲g̲
5.11.2.3.1.1 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
A switchover is to be performed within 60 seconds.
5.11.2.3.1.2 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Initialization is to be performed within 15 minutes.
5.11.2.3.1.3 R̲e̲c̲o̲v̲e̲r̲y̲/̲R̲e̲s̲t̲a̲r̲t̲
Recovery/restart subsequent to a total system failure
is to be performed within 15 minutes.
5.11.2.3.1.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲L̲i̲n̲e̲ ̲S̲p̲e̲e̲d̲s̲
The watchdog shall support the following line speeds:
- to PUs: 9.6 K Baud
- to operator printer: 300 lines per minute with
100 chars per line
- to operator VDU: variable 50-9600 Baud; a fixed
value will be defined during detailed design
5.11.2.3.1.5 R̲e̲s̲p̲o̲n̲s̲e̲ ̲L̲i̲n̲e̲
The response line for user procedures is defined in
section 3.4.1.6.3 in the CAMPS System Requirements
CPS/210/SYS/0001.
The response line for supervisory commands is defined
in section 3.4.1.6.5 in the CAMPS System Requirements
CPS/210/SYS/0001.
5.11.2.3.1.6 S̲t̲a̲r̲t̲-̲U̲p̲ ̲a̲n̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲
CAMPS software components are started/closed in a specific
sequence, which is defined in section 4. Generally
terminal and traffic handling packages are started
latest/closed first, whereas service software e.g.
log, statistics are started first/closed latest.
5.11.2.3.1.7 P̲r̲i̲o̲r̲i̲t̲i̲e̲s̲ ̲o̲f̲ ̲I̲n̲p̲u̲t̲
Input to the SSC arrives via queues or via synchronization
elements.
Queues are prioritized and are used by the SSC to enable
fast processing of error reports.
Synchronization element queues use a first-in first-out
strategy.
5.11.2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
5.11.2.3.2.1 I̲n̲c̲r̲e̲a̲s̲e̲ ̲o̲f̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲i̲z̲e̲
Application and system software will have sufficient
capacity to allow for a 10 per cent increase.
5.11.2.3.2.2 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
The SSC software allows operation of equipment corresponding
to wired capacity.
Via operator commands an equipment can be brought into/out
of operational use.
5.11.2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
5.11.2.3.3.1 H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲h̲a̲n̲g̲e̲s̲
The system is designed to be able to handle the wired
capacity configuration.
Expansion beyond this maximum
- May require auxiliary PU capacity
- Requires software regeneration
The actual configuration control is mainly table driven.
5.11.2.3.3.2 O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Changes in operator formats (except for field contents)
can be performed by changing an appropriate format
on the initialization disk.
New formats or changes in field contents in existing
formats require inclusion of new procedures, which
syntax/semantic checks the commands, respectively executes
the command.
5.11.2.3.3.3 L̲o̲a̲d̲i̲n̲g̲ ̲o̲f̲ ̲N̲e̲w̲ ̲V̲e̲r̲s̲i̲o̲n̲s̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲
̲F̲i̲r̲m̲w̲a̲r̲e̲
Loading of new versions of system software is possible
in all types, except WARM2 (after switchover) start-up.
Loading of new versions of application software is
possible in all start-up cases.
The level of modification possible depends on the start-up
type.
5.11.2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲ ̲a̲n̲d̲ ̲V̲a̲l̲i̲d̲i̲t̲y̲
5.11.2.3.4.1 A̲c̲c̲u̲r̲a̲c̲y̲ ̲a̲n̲d̲ ̲I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲
Commands and reports received by the SSC package are
validated for the data range required for an internal
processing of the input. E.g. type and function code
are checked to be within certain ranges.
For operator commands a syntax and semantic check is
performed either in the VDU or in the SSC on all input
data.
A protocol is used between the WDP and a PU to ensure
an error free transmisison of data.
5.11.2.3.4.2 A̲c̲c̲u̲r̲a̲c̲y̲ ̲o̲f̲ ̲T̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ ̲D̲a̲t̲a̲
Data to be transmitted to other packages must be checked
by the receiver.
5.11.3 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
5.11.3.1 E̲q̲u̲i̲p̲m̲e̲n̲t̲
As SSC initially owns all resources, all CAMPS equipment
may be used in the operation of SSC.
5.11.3.2 S̲o̲f̲t̲w̲a̲r̲e̲
5.11.3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
N.A.
5.11.3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
N.A.
5.11.3.3 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
5.11.3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
a) The SSC implements the operator commands described
in CPS/230/ICD/0002: Supervisor Commands and Procedures.
b) The SSC implements the
- Sign on
- Sign off
- Security interrogation
- Security Warning
procedures in CPS/230/ICD/0001: User Procedures
and Associated Formats.
5.11.3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
5.11.3.3.2.1 S̲S̲C̲ ̲t̲o̲ ̲T̲E̲P̲
a) Start-up of VDU, SAD subprocess
b) Close-down of VDU, SAD subprocess
c) Handling of mount/dismount on the off-line disk
d) Error reports, when the WDP ̲LP is out of service.
5.11.3.3.2.2 T̲E̲P̲ ̲t̲o̲ ̲S̲S̲C̲
a) Execution of supervisor control of VDU, SAD instances
b) Release security interrogation
c) Perform system integrity check
5.11.3.3.2.3 S̲S̲C̲ ̲t̲o̲ ̲M̲M̲O̲N̲/̲M̲M̲S̲
a) Start-up
b) Handling of SB checkpoint records
c) Close-down
d) Standby available/unavailable
5.11.3.2.2.4 M̲M̲O̲N̲ ̲t̲o̲ ̲S̲S̲C̲
a) Security interrogation/warning
5.11.3.3.2.5 S̲S̲C̲ ̲t̲o̲ ̲M̲M̲S̲
Via MMON as specified in 5.11.3.3.2.3.
5.11.3.3.2.6 S̲S̲C̲ ̲t̲o̲ ̲C̲S̲F̲ ̲P̲r̲o̲c̲e̲s̲s̲
a) Start-up
b) Close-down
5.11.3.3.2.7 S̲S̲C̲ ̲t̲o̲ ̲Q̲M̲O̲N̲
a) Start-up
b) Close-down
c) Initialize queues
5.11.3.3.2.8 S̲S̲C̲ ̲t̲o̲ ̲T̲I̲M̲E̲R̲ ̲M̲O̲N̲I̲T̲O̲R̲
a) Periodic invocation
b) Set/get time of day
5.11.3.3.2.9 S̲S̲C̲ ̲t̲o̲ ̲T̲M̲P̲
a) Start-up
b) Close-down
c) Search/update
- profiles
- configuration table
- supervisor parameters (only search)
d) Load modified system or application software
e) Copy modified software
f) Set trace mask
g) Set time of day clock on disk
h) Set AT ̲RISK/NORMAL mode
5.11.3.3.2.10 S̲S̲C̲ ̲t̲o̲ ̲M̲D̲P̲
a) Start-up
b) Close-down
5.11.3.3.2.11 S̲S̲C̲ ̲t̲o̲ ̲L̲O̲G̲
a) Start-up
b) Close-down
c) Handling of SB log checkpoints
5.11.3.3.2.12 L̲O̲G̲ ̲t̲o̲ ̲S̲S̲C̲
a) Sending of log checkpoint records
5.11.3.3.2.13 S̲S̲C̲ ̲t̲o̲ ̲T̲H̲P̲
a) Start-up package and channels
b) Close-down package and channels
5.11.3.2.14 S̲S̲C̲ ̲t̲o̲ ̲S̲A̲R̲
a) Start-up
b) Close-down
5.11.3.3.2.15 S̲S̲C̲ ̲t̲o̲ ̲S̲T̲P̲
a) Start-up
b) Close-down
5.11.3.3.2.16 S̲S̲C̲ ̲t̲o̲ ̲I̲O̲C̲
a) Use of the format handler on WDP-VDU splits
b) In addition to standard DAMOS separate connections
are provided to the:
- WDP
- WDP-LP
- WDP-VDU Splits
5.11.3.3.2.17 S̲S̲C̲ ̲t̲o̲ ̲S̲S̲P̲
a) Via operator commands the resources necessary for
SSP operation can be allocated.
b) Via the WDP ̲VDU and WDP the operational commands
relating to SSP operations are directed to an off-line
PU, where they are executed.
5.11.3.3.2.18 S̲S̲C̲ ̲t̲o̲ ̲O̲L̲P̲
As 5.11.3.3.2.17.
5.11.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̲
5.11.3.4.1 R̲e̲c̲o̲v̲e̲r̲y̲
The TMP handles updates in configuration and profile
tables such that partial updates are avoided i.e. an
update is either completed or has not changed the table.
5.11.3.4.2 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The Kernel retires a process automatically in the following
cases:
- Security violation in system call
- PU error, which can be localized within a single
user process
and sends a report to a process synchronization element.
For PU errors, which cannot be localized to within
a single user process, an automatic PU-SHUT ̲DOWN is
executed by the KERNEL.
A PU ̲SHUT ̲DOWN implies
- an error message is issued to the WDP-LP
- a programmed master clear is issued
5.11.3.4.3 S̲e̲c̲u̲r̲i̲t̲y̲
Low level security checks are performed by the KERNEL
based on:
- classification of DAMOS objects and subjects (processes)
- access rights for processes to a DAMOS object
High level security checks are performed by the queue
monitor based on:
- queue profiles and subprocess profiles
- access capabilities for a subprocess to queue elements
