top - download
⟦85bcc1711⟧ Wang Wps File
Length: 77619 (0x12f33)
Types: Wang Wps File
Notes: CPS/SDS/004
Names: »1094A «
Derivation
└─⟦3697aa7b2⟧ Bits:30006041 8" Wang WCS floppy, CR 0066A
└─ ⟦this⟧ »1094A «
WangText
!…0c…!…05… …0f……1f……09……1f……02……1e……0c……1e……05……1d……0f……1c……09……1c…
…1b……0c……1b……01……1b……06……1a……0b……1a……00……1a……05……19……0a……19……0f……19… …18……09……18……0e……18… …17……0a……17……0c……17……00……17……05……16……09……16……0a……16……0d……86…1
…02…
…02…
…02…
…02…CPS/SDS/004
…02…FH/810801…02……02…
SYSTEM
STATUS
AND CONTROL
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .......................................
15
1.1 PURPOSE AND SCOPE .........................
15
1.2 APPLICABLE DOCUMENTS AND PROJECT
REFERENCES ................................
16
1.2.1 Applicable Documents ..................
16
1.2.2 Project References ....................
16
1.3 TERMS AND ABBREVIATIONS ...................
17
1.3.1 Terms .................................
17
1.3.2 Abbreviations .........................
27
2 SUMMARY OF REQUIREMENTS .......................
28
2.1 PACKAGE DESCRIPTION .......................
28
2.1.1 Block Diagram .........................
29
2.2 PACKAGE FUNCTIONS .........................
31
2.2.1 Main Functions ........................
31
2.2.1.1 Checkpoint Transmission ...........
33
2.2.1.2 Checkpoint Reception ..............
33
2.2.1.3 On-Line Diagnostics ...............
34
2.2.1.4 Line Monitoring and Control .......
34
2.2.1.5 Reception of Technical Error
Reports ...........................
35
2.2.1.5.1 Active PU Handling ............
36
2.2.1.5.1.1 SW Error Reports ..........
36
2.2.1.5.1.1.1 Child Action ..........
36
2.2.1.5.1.1.2 DAMOS/CSF Action ......
39
2.2.1.5.1.1.3 COPSY Handling of SW
Reports ...............
39
2.2.1.5.1.2 HW Error Reports ..........
40
2.2.1.5.2 Handling of Errors Reported
by Other Packages to the
SSC in the SB PU ..............
41
2.2.1.6 Operator Commands to an On-Line PU
41
2.2.1.7 Off-Line PU Operation .............
42
2.2.1.7.1 Commands to the Off-Line PU ...
42
2.2.1.7.2 Allocation of Resources to the
Off-Line PU ...................
42
2.2.1.8 Watchdog Firmware Functions .......
43
2.2.1.8.1 Watchdog Line Communication ...
43
2.2.1.8.2 Switch Logic ..................
44
2.2.1.8.3 Switchover ....................
44
2.2.1.8.4 WDP Standard Firmware .........
45
2.2.2 Functional Responsibilities ...........
45
2.2.2.1 Initialization, Close-Down, and
Restart ...........................
45
2.2.2.1.1 Start-Up (Initialization and
Restart) ......................
46
2.2.2.1.1.1 Boot Load .................
46
2.2.2.1.1.2 Start-Up of Active and
Stand By PU ...............
49
2.2.2.1.1.3 Disk Start-Up Information .
54
2.2.2.1.2 Ordered Close-Down ............
55
2.2.2.1.2.1 AC PU Ordered Close-Down ..
55
2.2.2.1.2.2 SB PU Ordered Close-Down ..
58
2.2.2.2 Checkpointing and Recovery ........
58
2.2.2.2.1 Checkpointing .................
58
2.2.2.2.2 Recovery ......................
60
2.2.2.2.2.1 Cold ......................
60
2.2.2.2.2.2 WARM1 .....................
60
2.2.2.2.2.3 WARM2 .....................
60
2.2.2.2.2.4 WARM3 .....................
61
2.2.2.2.2.5 SB1 .......................
61
2.2.2.2.2.6 SB2 .......................
61
2.2.2.3 Handling of SSC Internal Detected
Errors ............................
61
2.2.2.3.1 In the AC PU ..................
63
2.2.2.3.2 In the SB PU ..................
63
2.2.2.3.3 In the WDP ....................
63
2.2.2.4 Integrity of Operation ............
63
2.2.2.5 Data Collection ...................
66
2.2.2.5.1 LOG ...........................
66
2.2.2.5.2 Statistics ....................
66
2.2.2.5.3 Reports .......................
68
2.2.2.6 Security ..........................
68
2.2.2.6.1 Security on DAMOS Objects .....
68
2.2.2.6.2 Security on CAMPS Queues ......
68
2.3 CHARACTERISTICS ...........................
69
2.3.1 Timing ................................
69
2.3.1.1 Switchover ........................
69
2.3.1.2 Initialization ....................
69
2.3.1.3 Recovery/Restart ..................
69
2.3.1.4 Watchdog Line Speeds ..............
69
2.3.1.5 Response Time .....................
70
2.3.1.6 Start-Up and Close-Down Sequence ..
70
2.3.1.7 Priorities of Input ...............
70
2.3.2 Throughput ............................
70
2.3.2.1 Increase of Software Size .........
70
2.3.2.2 Equipment Capacity ................
71
2.3.3 Flexibility ...........................
71
2.3.3.1 Hardware Configuration Changes ....
71
2.3.3.2 Operator Commands .................
71
2.3.3.3 Loading of New Versions of Software
71
2.3.4 Accuracy and Validity .................
72
2.3.4.1 Accuracy of Input Data ............
72
2.3.4.2 Accuracy of Transmitted Data ......
72
3 ENVIRONMENT ...................................
73
3.1 EQUIPMENT .................................
73
3.2 SOFTWARE ..................................
73
3.2.1 System Software .......................
73
3.2.2 Development Software ..................
73
3.3 INTERFACES ................................
73
3.3.1 External Interfaces ...................
73
3.3.2 Package Interfaces ....................
74
3.3.2.1 SSC to TEP ........................
74
3.3.2.2 TEP to SSC ........................
74
3.3.2.3 SSC to MMON/MMS ...................
74
3.3.2.4 MMON/MMS to SSC ...................
74
3.3.2.5 SSC to SFM ........................
75
3.3.2.6 SSC to CSF Process ................
75
3.3.2.7 SSC to QMON .......................
75
3.3.2.8 SSC to Timer Monitor ..............
75
3.3.2.9 SSC to TMP ........................
75
3.3.2.10 SSC to MDP ........................
76
3.3.2.11 SSC to LOG ........................
76
3.3.2.12 LOG to SSC ........................
76
3.3.2.13 SSC to THP ........................
76
3.3.2.14 SSC to SAR ........................
76
3.3.2.15 SSC to STP ........................
77
3.3.2.16 SSC to IOC ........................
77
3.3.2.17 SSC to SSP ........................
77
3.3.2.18 SSC to OLP ........................
77
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES ....
77
3.4.1 Recovery ..............................
77
3.4.2 Error Detection and Handling ..........
78
3.4.3 Security ..............................
78
4 PACKAGE DESIGN ................................
79
4.1 PACKAGE OVERVIEW ..........................
79
4.1.1 Functional Specification ..............
79
4.1.1.1 Checkpoint Transmission ...........
79
4.1.1.2 Checkpoint Reception ..............
79
4.1.1.3 On-Line Diagnostics ...............
81
4.1.1.4 LINE M&C ..........................
81
4.1.1.4.1 Execution of External Commands
Monitoring of System Connection
83
4.1.1.4.2 Technical Error Report Handling
85
4.1.1.5 Technical Error Report Handling ...
88
4.1.1.5.1 Error Reception ...............
92
4.1.1.5.2 HW Error Fix-Up ...............
92
4.1.1.5.2.1 LTU Line ..................
92
4.1.1.5.2.2 LTU .......................
93
4.1.1.5.2.3 LTUX Line .................
93
4.1.1.5.2.4 LTUX ......................
93
4.1.1.5.2.5 BSM-X .....................
93
4.1.1.5.2.6 Off-Line Disk Volume ......
93
4.1.1.5.2.7 Off-Line Disk .............
93
4.1.1.5.2.8 Floppy Disk Volume ........
94
4.1.1.5.2.9 Floppy Disk ...............
94
4.1.1.5.2.10 WDP .......................
94
4.1.1.5.2.11 WDP-VDU ...................
94
4.1.1.5.2.12 WDP-LP ....................
94
4.1.1.5.2.13 TDX-Bus ...................
95
4.1.1.5.2.14 Mirrored Disk Volume ......
95
4.1.1.5.2.15 Mirrored Disk .............
96
4.1.1.5.2.16 Standby PU ................
96
4.1.1.5.2.17 Online Pu .................
96
4.1.1.6 Operator Commands .................
96
4.1.1.6.1 Software Control ..............
97
4.1.1.6.1.1 Load of new SW ............
97
4.1.1.6.1.2 Define Generation of Trace
Information ...............
97
4.1.1.6.1.3 Print of System Status ....
97
4.1.1.6.1.4 Time of Day ...............
98
4.1.1.6.1.5 Define NORMAL/AT ̲RISK Mode
98
4.1.1.6.2 Peripheral Reconfiguration ....
98
4.1.1.6.3 PU Reconfiguration ............
99
4.1.1.6.3.1 Start ̲Up Active PU ........
101
4.1.1.6.3.2 Close ̲Down Active PU ......
103
4.1.1.6.3.3 Start Standby .............
105
4.1.1.7 Off-Line PU Functions .............
105
4.1.1.8 WDP FW Functions ..................
107
4.1.1.8.1 WDP Input from PUs ............
109
4.1.1.8.1.1 Off-Line Communication ....
109
4.1.1.8.1.2 Keep Alive Messages .......
109
4.1.1.8.1.3 Configuration Display
Update ....................
109
4.1.1.8.1.4 VDU Format Output .........
111
4.1.1.8.1.5 LP Reports ................
111
4.1.1.8.1.6 Crate Status Requests .....
111
4.1.1.8.1.7 COPSY Control Commands ....
111
4.1.1.8.2 Input from the WDP-VDU ........
112
4.1.1.8.3 Configuration Control Bus Input
114
4.1.1.8.4 Standard Firmware .............
114
4.1.1.9 Common SSC Functions ..............
115
4.1.2 SW Structure ..........................
117
4.1.3 Data Flow and Control Logic ...........
123
4.1.3.1 COPSY Coroutines Data Flow and
Control Logic .....................
123
4.1.3.1.1 CMO Coroutine Data Flow and
Control Logic .................
125
4.1.3.1.2 SEH Coroutine Data Flow and
Control Logic .................
125
4.1.3.1.3 M-C Coroutine Data Flow and
Control Logic .................
126
4.1.3.1.3.1 Reception of Commands in
Operational Semaphores ....
126
4.1.3.1.3.2 Operational Commands to a
Subprocess, CPT, CMI ......
126
4.1.3.1.3.3 Monitoring of System
Connection ................
127
4.1.3.1.4 CFH Data Flow and Control Logic
128
4.1.3.1.4.1 COPSY ̲INIT ................
128
4.1.3.1.4.2 CFH Coroutine .............
128
4.1.3.2 CMI Data Flow and Control Logic ...
129
4.1.3.3 CPT and CPR Data Flow and Control
Logic .............................
131
4.1.3.4 OLD Data Flow and Control Logic ...
133
4.1.3.5 WDP Data Flow and Control Logic ...
135
4.1.3.5.1 Input to the WDP from a PU ....
137
4.1.3.5.2 Input to the WDP from a VDU ...
137
4.1.3.5.3 CCB Scanning ..................
138
4.1.3.5.4 Buffer Handling ...............
138
4.1.4 Common Data Elements ..................
138
4.1.4.1 SW Configuration Tables ...........
139
4.1.4.2 HW Configuration Tables ...........
139
4.1.4.3 WDP-VDU Splits ....................
147
4.1.4.3.1 Command Split .................
147
4.1.4.3.2 Configuration Display .........
147
4.1.4.3.3 Format Split ..................
148
4.1.5 External Data Elements ................
151
4.1.5.1 QMON Buffers ......................
151
4.1.5.2 Checkpoint Area in Active PU ......
152
4.1.5.3 Checkpoint Area in Standby ........
153
4.1.5.4 System Parameters .................
154
4.1.6 Interfaces ............................
154
4.1.6.1 External Interfaces ...............
155
4.1.6.2 Package Interfaces ................
155
4.1.6.2.1 SSC to TEP ....................
155
4.1.6.2.1.1 SSC to TEP VDU Subprocess .
156
4.1.6.2.1.2 SSC to TEP SAD Subprocess .
158
4.1.6.2.1.3 Error Reports .............
158
4.1.6.2.1.4 SSC to TEP (Off-line disk)
159
4.1.6.2.1.5 SSC to TEP Non-Line
Process ...................
160
4.1.6.2.2 TEP to SSC ....................
160
4.1.6.2.2.1 TEP to SSC (System
Integrity Check) ..........
160
4.1.6.2.2.2 TEP Command to SYQ in INFO
Field .....................
161
4.1.6.2.3 SSC to MMON/MMS ...............
162
4.1.6.2.3.1 SSC to MMON/MMS ...........
162
4.1.6.2.3.2 SSC to MMON ...............
162
4.1.6.2.4 MMON to SSC ...................
162
4.1.6.2.4.1 MMON to COPSY .............
163
4.1.6.2.4.2 MMS to CPT ................
164
4.1.6.2.5 SSC to SFM ....................
164
4.1.6.2.6 SSC to CSF Process ............
165
4.1.6.2.7 SSC to QMON ...................
165
4.1.6.2.8 SSC to Timer Monitor ..........
166
4.1.6.2.9 SSC to TMP ....................
166
4.1.6.2.10 SSC to WDP ....................
167
4.1.6.2.11 SSC to LOG ....................
167
4.1.6.2.11.1 CPR to LOG ................
167
4.1.6.2.11.2 COPSY TO LOG ..............
168
4.1.6.2.12 LOG to CPT ....................
169
4.1.6.2.13 SSC to THP ....................
170
4.1.6.2.13.1 SSC to THP EXC/SAD
Subprocess ................
170
4.1.6.2.13.2 SSC to THP Non-Line
Processes .................
171
4.1.6.2.14 SSC to SAR ....................
172
4.1.6.2.15 SSC to STP ....................
172
4.1.6.2.16 SSC to IOC ....................
173
4.1.6.2.17 DAMOS HW Error Reports in SDSE
174
4.1.6.2.18 DAMOS SW Error Reports in PSE .
175
4.1.6.2.19 COPSY Child Error Reports to
COPSY in ERQ ..................
176
4.1.6.3 Subpackage Interfaces .............
177
4.1.6.3.1 WDP-COPSY Interface ...........
177
4.1.6.3.1.1 Monitoring Information to
COPSY .....................
177
4.1.6.3.1.2 WDP Reply on COPSY Crate
Status Request ............
179
4.1.6.3.1.3 Number of Last Error Report
on LP .....................
180
4.1.6.3.2 COPSY-WDP Interface ...........
181
4.1.6.3.2.1 COPSY Identification of WDP
181
4.1.6.3.2.2 Keep Alive Messages .......
182
4.1.6.3.2.3 COPSY Control Commands to
the WDP ...................
183
4.1.6.3.2.4 COPSY Request for Crate
Status ....................
184
4.1.6.3.2.5 COPSY Request for TDX-bus
Switchover ................
185
4.1.6.3.2.6 COPSY Update of Control
Table During WDP Restart...
186
4.1.6.3.2.7 Number of Last Error Report
187
4.1.6.3.3 CMI to COPSY Interface ........
188
4.1.6.3.3.1 CMI Commands to COPSY .....
188
4.1.6.3.3.1.1 Device Reconfiguration
Command ...............
188
4.1.6.3.3.1.2 PU Commands ...........
189
4.1.6.3.3.1.3 Soft Commands .........
189
4.1.6.3.4 COPSY to CMI Interfaces .......
190
4.1.6.3.4.1 COPSY Reply to CMI Command
190
4.1.6.3.4.2 COPSY Operational Commands
to CMI ....................
190
4.2.1 Checkpoint Transmission ...............
192
4.2.1.1 Functional Specification ...........
192
4.2.1.1.1 Initialization ................
194
4.2.1.1.2 Serve Input ...................
194
4.2.1.1.3 Operational Commands ..........
195
4.2.1.1.4 Send Checkpoint Records .......
195
4.2.1.1.5 Await Acknowledgment ..........
196
4.2.1.1.6 Send Reply to Caller ..........
196
4.2.1.1.7 Error Fix-Up ..................
196
4.2.1.1.7.1 SW Errors .................
196
4.2.1.1.7.2 HW Errors .................
197
4.2.1.2 Software Structure ................
197
4.2.1.3 Data Flow and Control Logic .......
198
4.2.1.3.1 Block Diagram .................
198
4.2.1.3.2 HIPO Diagram ..................
200
4.2.1.3.3 Flowgram ......................
200
4.2.1.4 Subpackage Data ...................
203
4.2.1.4.1 CPT Program and Data Layout ...
203
4.2.1.4.2 CP ̲RECORD for LOG, CIF, and
Timer .........................
205
4.2.1.4.3 TRM Record ....................
205
4.2.1.4.4 CP ̲ACK ........................
205
4.2.1.4.5 Coroutine Common Data .........
206
4.2.1.4.6 Coroutine Comman Data
(CP ̲ARRAY) ....................
207
4.2.1.5 CPT Interfaces ....................
208
4.2.1.5.1 Interfaces to Other Packages ..
208
4.2.1.5.2 Internal SSC Interfaces .......
208
4.2.1.5.2.1 COPSY Command to the CTQ ..
208
4.2.1.5.2.2 Start-Up ..................
209
4.2.1.5.3 CTQ Priority ..................
209
4.2.2 Checkpoint Reception (CPR) ............
210
4.2.2.1 Functional Specification ........
210
4.2.2.1.1 Initialization ................
212
4.2.2.1.2 Operational Commands ..........
212
4.2.2.1.3 Serve CRQ and Receive CP
Records .......................
212
4.2.2.1.4 Update Checkpoint Tables ......
213
4.2.2.1.5 Send Acknowledgement ..........
213
4.2.2.1.6 Error Fix-Up ..................
213
4.2.2.1.6.1 SW Error ..................
214
4.2.2.1.6.2 HW Error ..................
214
4.2.2.2 Software Structure ................
214
4.2.2.3 Data Flow and Control Logic .......
214
4.2.2.3.1 HIPO Diagram ..................
214
4.2.2.3.2 Flowgram ......................
214
4.2.2.4 Subpackage Data ...................
217
4.2.2.4.1 CPR Program and Data Layout ...
217
4.2.2.4.2 Checkpoint Records from the
Active PU .....................
219
4.2.2.4.2.1 LOG CP-RECORD .............
220
4.2.2.4.2.2 CIF CP-RECORD .............
220
4.2.2.4.2.3 Time of Day CP-RECORD .....
220
4.2.2.4.3 Checkpoint Acknowledgement ....
221
4.2.2.4.4 Checkpoint Tables for Log
Records .......................
221
4.2.2.4.5 Checkpoint Tables for CIF
Records .......................
222
4.2.2.4.6 Shared Data ...................
222
4.2.2.5 CPR Interfaces ....................
222
4.2.2.5.1 Interfaces to Other Packages ..
222
4.2.2.5.1.1 To MMS ....................
222
4.2.2.5.1.2 To LOG ....................
223
4.2.2.5.1.3 To Timer Monitor ..........
223
4.2.2.5.2 Internal SSC Interface ........
223
4.2.2.5.2.1 COPSY Commands in CRQ .....
223
4.2.2.5.2.2 To CPT ....................
224
4.2.2.5.3 CRQ Priority ..................
224
4.2.3 On-Line Diagnostics (OLD) .............
224
4.2.3.1 Functional Specification ..........
224
4.2.3.1.1 Initialization ................
226
4.2.3.1.2 Serve Input Queue .............
226
4.2.3.1.3 Handling of Time-Out ..........
226
4.2.3.1.4 Reception of Supervisor
Request .......................
226
4.2.3.1.5 Reception of Close-Down .......
226
4.2.3.1.6 Error Fix-Up ..................
227
4.2.3.2 Software Structure ................
227
4.2.3.3 Data Flow and Control Logic .......
228
4.2.3.3.1 HIPO Diagram ..................
228
4.2.3.3.2 Flowgram ......................
228
4.2.3.4 Subpackage Data ...................
231
4.2.3.5 Interfaces to OLD .................
231
4.2.3.5.1 Interfaces to Other Packages ..
231
4.2.3.5.2 Internal SSC Interfaces .......
231
4.2.4 Error Handler and Command Dispatcher
(EHD) .................................
232
4.2.4.1 Functional Specification ..........
232
4.2.4.1.1 Receive Line Commands .........
234
4.2.4.1.2 Dispatch On-Line Commands .....
234
4.2.4.1.3 Receive Operator Commands .....
234
4.2.4.1.4 Call Configuration Handler ....
234
4.2.4.1.5 Receive Error Reports .........
235
4.2.4.1.6 Isolate Error .................
235
4.2.4.1.7 Call Configuration Handler ....
235
4.2.4.1.8 Error Handling ................
235
4.2.4.2 Software Structure ................
236
4.2.4.3 Data Flow and Control Logic .......
239
4.2.4.3.1 HIPO Diagram ..................
239
4.2.4.4 Subpackage Data ...................
242
4.2.4.4.1 Line to Semaphore Table .......
242
4.2.4.5 Subpackage Interfaces .............
244
4.2.4.5.1 Package Interfaces ............
244
4.2.4.5.2 Internal SSC Interfaces .......
244
4.2.4.5.2.1 To CMI ....................
244
4.2.4.5.2.2 To COPSY Coroutines .......
244
4.2.7 Command Interpreter ...................
246
4.2.7.1 Functional Specification ..........
246
4.2.7.1.1 Initialization ................
248
4.2.7.1.2 Determine Format Type .........
248
4.2.7.1.3 Display Format ................
248
4.2.7.1.4 Validation ....................
249
4.2.7.1.4.1 Validation of LTUX-LINE
Format ....................
251
4.2.7.1.4.2 Validation of LTUX Format .
251
4.2.7.1.4.3 Validation of BSM-X Format
252
4.2.7.1.4.4 Validation of TDX-Bus
Format ....................
252
4.2.7.1.4.5 Validation of LTU-Line
Format ....................
252
4.2.7.1.4.6 Validation of LTU Format ..
252
4.2.7.1.4.7 Validation of VOLUME
Format ....................
253
4.2.7.1.4.8 Validation of DISK DRIVE
Format ....................
253
4.2.7.1.4.9 Validation of START ̲UP ̲AC
Format ....................
253
4.2.7.1.4.10 Validation of SWITCHOVER
Format ....................
253
4.2.7.1.4.11 Validation of CLOSE ̲DOWN
Format ....................
254
4.2.7.1.4.12 Validation of START ̲UP ̲SB
Format ....................
254
4.2.7.1.4.13 Validation of SET TIME
Format ....................
254
4.2.7.1.4.14 Validation of PRINT Format
254
4.2.7.1.4.15 Validation of SET NORMAL/
AT ̲RISK MODE Format .......
254
4.2.7.2 Software Structure ................
255
4.2.7.3 Data Flow and Control Logic .......
257
4.2.7.4 Subpackage Data ...................
270
4.2.7.5 Interfaces ........................
271
4.2.8 Watchdog Sub-Package ..................
272
4.2.8.1 Functional Specification ..........
272
4.2.8.1.1 Initialization ................
274
4.2.8.1.2 PU Handler ....................
274
4.2.8.1.3 VDU Handler ...................
275
4.2.8.1.3.1 Input from the VDU ........
275
4.2.8.1.3.2 Output to the VDU .........
277
4.2.8.1.3.3 Off-Line Communcation .....
277
4.2.8.1.3.4 Error Handling ............
278
4.2.8.1.4 LP Handler ....................
280
4.2.8.1.4.1 LP Synchronization ........
280
4.2.8.1.4.2 LP Print ..................
280
4.2.8.1.4.3 Error Handling ............
281
4.2.8.1.5 SYS M&C .......................
281
4.2.8.1.5.1 Handling of Exception .....
281
4.2.8.1.5.2 Control Commands from the
Operator ..................
282
4.2.8.1.5.3 Control Commands from the
COPSY .....................
282
4.2.8.1.5.4 Monitoring Request ........
283
4.2.8.2 Software Structure ................
285
4.2.8.3 Data Flow and Control Logic .......
287
4.2.8.4 WDP Data ..........................
322
4.2.8.4.1 Digital Input Control Table ...
322
4.2.8.4.2 Digital Output Control Table ..
323
4.2.8.4.3 Power Monitoring Table ........
324
4.2.8.4.4 System Table ..................
325
4.2.8.4.5 Message Format Between WDP
and PUs .......................
326
4.2.8.4.6 Message Format Used Inter-
nally in the WDP ..............
327
4.2.8.4.7 Control Message to CCB ........
328
4.2.8.5 Interfaces ........................
328
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The package specification for System Status and Control
(CPS/SDS/004) is written to fulfil the following objectives:
1) To provide detailed definition of the package functions
and software architecture.
2) To provide user operational and development personnel
details of the ongoing analysis.
3) To define in detail the interfaces with other packages
and to describe their facilities.
The scope of SSC package specification is to detail
the function described in CPS/SDS/001 section 4 and
5.10, and to define a software structure, which implements
the detailed functions.
The SSC package specification is an intermediate level
between systems design and detailed design.
The SSC package defines the CAMPS hardware and software
configuration file.
The SSC package interfaces to all CAMPS software packages,
as it contains the start-up, close-down and the operational
control of the CAMPS system.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CPS/210/SYS/0001
CAMPS System Requirements Specification
CPS/SDS/001
System Design Specification
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
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)
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
Access Control Control of specifically delegated
access rights before access
is allowed to an object.
Access Control List Structure associated with catalog
objects. Contains access rights
of user groups to the objects.
Active Terminal Active terminal profile is de-
Profile determined from terminal profile
and user profile.
Associated (Shared) Medium speed teleprinter, low
ROP speed teleprinter.
Auxiliary Terminal Lineprinter, PTP/PTR and OCR.
Device
CAMPS Functions Denotes the following groups
of CAMPS services:
Supervisor Function
Message Distribution Control
Function
Message Service Function
Preparation Function
Release Function
Reception Function
CAMPS information…02…A part of disk volume which is
file logically structured into a
number of variable length strings
called fields.
Channel designator Identification of an external
channel.
Checkpoint Point from which restart/recovery
can take place.
Child Process A process is child of the process
having created it.
Circuit CAMPS to node connection for
the appropriate Network. A circuit
may consist of one or more channels.
Claim A resource management term specifying
a number of objects of a given
type that a process has the
right to create.
Close-down Action taken to bring processing
(Ordered/Non-Ordered) within the system or a part
thereof to a stop - can be either
an ordered sequence of steps
or an abrupt termination.
Cold start-up Initialization from the on-line
disks.
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.
Designator A designator is a logical representation
of a line. The designator to
line connection is subject to
change during a reconfiguration.
Device Designator Identification of a stand-alone
device.
Device Profile To each device a device profile
is associated.
Directory A file containing identifications
and control information about
files or items.
External Channel A channel in a telegraph circuit
or non telegraph circuit.
File An unstructured, logically contiguous
part of a disk volume.
File Management Part of SFM handling Files
System
Historic Data Data which have been completely
processed and subsequently kept
for retrieval purposes.
Initial Start up System Start up based on initial
data.
Initialization The definition in the CPS/SDS/001
and subsequent documents are
described as follows: Brings
the system from dead start into
operational use. No recovery
actions are included.
The definitions replace the
one used in the CPS/210/SYS/0001:
Brings the system from cold
start into operational use.
Intermediate Storage areas for items within
Storage SFM.
Line A line refers to a physical
V24 wire from an LTU or LTUX.
Logical Line The software aggregate representing
a physical connection to an
external device, network, or
system.
Low Speed Media Low speed teleprinter (PTP,
PTR, ROP), Point-to-point connection
and TRC.
Main Queue A structured queue with a set
of sub queues.
Memory Segment Part of virtual memory. The
memory object to which security
and access control is applied.
Message Control A control structure in CSF
Block describing a single message
version.
Message Distribu- Denotes the total group of
tion Control Func- commands/procedures which may
be
tion performed from a VDU with Message
Distribution Control capability.
Message Management Part of SFM handling Items
System
Message monitor The part of CSF acting as interface
to message management system
within SFM.
Message Service Denotes the total group of
Function commands/procedures which may
be performed from a VDU with
Message Service capability.
Message View A subset of fields within a
message.
Monitoring and Control Monitoring refers to a status
inspection, whereas control
refers to a execution. Supervision
includes monitoring and control.
Non Telegraph CCIS and SCARS.
Circuit
Object A resource to which security
and access control apply.
Off-Line Storage The part of disk storage residing
on removable packs.
On-Line Storage The part of disk storage which
is permanently mounted.
Operating System A process making high level
decisions about dynamic allocation
of resources to a set of descendant
processes.
Operator a) Person with responsibility
for operating the central
equipment from the maintenance
position and/or control
panels (i.e. the technicians
and RST).
b) Person with responsibility
for maintenance and repair.
The term operator is identical
with Engineering in CPS/210/SYS/0001
and replaces it in the CPS/SDS/001
and subsequent documents.
Page A block of 1024 16 bits words.
Page Manager The part of kernel responsible
for memory management.
Parent Process A process is parent for those
processes which it has created.
Preparation Denotes the total group of
Functions commands/procedures which may
be performed from a VDU with
Preparation Capability.
Priority An attribute of a process used
for scheduling purposes.
Procedure Special part of a program. It
must be called with a "procedure
call" instruction which automatically
saves the return point.
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.
Process Execution of a specific program
operating on a specific set of
data. The active components of
the system to which security and
process control as well as resource
management is applied.
Program A sequence of instructions.
Protection The complete set of mechanisms
assuring that only the processes
authorized by security and access
control can access a given object.
Queue Process communication tool within
CSF.
Queue Element The elements which can be in a
queue.
Queue Element The same as queue element. Used
Reference when emphasizing the function
of the queue element as the basic
reference to objects.
Queue Monitor The part of CSF supplying Queue
facilities.
Reception Function Denotes the total group of commands/procedures
which may be performed from a
VDU with Reception capability.
Release Function Denotes the total group of commands/procedures
which may be performed from a
VDU with Release capability.
Restart Refers to a cold or warm start-up
from the on-line disks.
Recovery Reestablishes continuity in memory
and file contents.
Security Control Control of classification and
special handling categories before
access allowed to an object.
Security Profile The data Type containing classification
and certain special handling categories
for an object.
Short Term Storage Storage areas for items within
SFM.
Staff cell The SCD is the smallest addressable
designator unit in one CAMPS site.
Stand alone device Medium speed teleprinter, low
speed teleprinter (PTP, PTR, ROP)
OCR, PTR, and PTP
Start up Includes all aspects of initialization,
recovery and restart.
Sub queue Part of a Main Queue.
Supervisor Person located at supervisor terminals
in CAMPS central equipment room
Supervisor's Person with responsibility for
Assistant special Message Service.
In the CPS/210/SYS/0001 supervisor
means both supervisor and supervisor
assistant.
Supervisor Denotes the total group of
Function commands/procedures which may
be performed from a VDU with supervisor
capability.
Switchover Relates to a dualized configuration
containing an active and a stand-by
part. Switchover is the actions
of bringing the stand-by device
into active state and the other
active device off-line.
Synchronization A process communication tool used
Element as basis for high level mechanisms
such as queues.
System Control Data Tables, system parameters etc.
used to implement and control
the operation of CAMPS.
System Parameter A simple variable, holding part
of the system state, and controlled
by TMP.
System User A distinguished user group with
special privileges.
System View Refers to the non SSC system software,
which a process can execute.
Telegraph circuit NICS TARE, Point to point and
TRC.
Terminal VDU, Meduium Speed Teleprinter,
Low Speed Teleprinter, Line Printer,
PTP/PTR and OCR.
Terminal Device VDU, Medium Speed Teleprinter
and Low Speed Teleprinter.
Terminal Designa- A code identifying the terminal
po-
tor sition.
Terminal Position VDU and associated (shared) ROP.
Terminal Profile The terminal profile contains
information about an VDU and identify
a shared ROP.
Time Slice The amount of CPU-time that a
process may use before it must
give other processes the opportunity
to execute.
Time Stamp Time allocated to a transaction,
for example a storage process
or release of message.
Timer monitor The part of CSF supplying timer
facilities.
Tracing Retrieval of specific log records.
Translation Table A table used by Memory Map Module
to perform logical address to
physical address translation and
determination of access right
to memory locations.
User a) Person with responsibility
for input and output of messages.
b) Person located at the user
terminals in the staff cells.
The user is identical with the
term operator in the CPS/210/SYS/0001
and replaces it in CPS/SDS/001.
User Group A set of processes. A vehicle
for access control each process
belongs to exactly one user group.
User Group Unique identifier for a user group
Identification
User process Process within CAMPS representing
a logical line.
User profile To each user a user profile is
associated. (Identical to operator
profile in the CPS/210/SYS/0001).
User View Refers to the non SSC system software,
which a process can execute.
Virtual Memory The total amount of information
that a process may address, either
directly or indirectly via Page
Manager functions.
Volume A named entity which can either
be a complete disk pack or a specifically
addressable part of a disk pack.
Warm start-up Start-up from the online disks.
It includes recovery/restart actions.
Switchover is a type of warm start-up.
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
COPSY CAMPS Operating System
CRT CAMPS Remote Terminal
EHD Error Handler and Command Dispatcher
ERQ Error Queue
EXC External Channel
FCT Function
FW Firmware
HW Hardware
LP Line Printer
LTP Low Speed Teleprinter
M&C Monitoring and Control
MMON Message Monitor
MTP Medium Speed Teleprinter
OCR Optical Character Reader
OLD On-line diagnostics
PSE Parent Synchronization Element
PTOP Point to Point
PTP Paper Tape Punch
PU Processor Unit
ROP Receive only Printer
SAD Stand Alone Device
SB Stand By
SDSE Secondary Device Synchronization
Element
SEH System Error Handler
SSC System Status and Control
SW Software
TMON Timer Monitor
TRC Tape Relay Center
VDU Visual Display Unit
WDP Watchdog Processor
Package abbreviations are defined in section 1.2.2.
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
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
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 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 2.1.1-1
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The SSC functions are depicted on figure 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 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 2.2.1.1 through 2.2.1.8 describe the SSC functions.
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.
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.
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.
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.
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
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.
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
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).
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.
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
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.
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.
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 2.2.2.1.
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).
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 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.
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.
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̲
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
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.
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.
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.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
The section is divided into two:
- Start-up
- Close-down
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.
2.2.2.1.1.1 B̲o̲o̲t̲ ̲L̲o̲a̲d̲
Boot load functions are illustrated on figure 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
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 2.2.2.1.1.1-1
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 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 2.2.2.1.1-1
In figure 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 2.2.2.2.2.
2.2.2.1.1.2-2 to -3
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.
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
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̲ ̲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 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 2.2.2.1.2.1-1
…01…and…01……01……01……01…Figure 2.2.2.1.2.2-1
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̲ ̲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.
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 2.2.2.2-1 is summarized the SSC responsibilities
for checkpointing and recovery.
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 2.2.2.2-1
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)
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.
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.
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.
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.
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.
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.
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 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 2.2.2.3-1
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
2.2.1.4 and 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.
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.
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.
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 2.2.2.4-1
overleaf.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VALIDITY CHECKS
18.0
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 2.2.2.4-1…01…SSC VALIDITY CHECKS FUNCTIONS
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.
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.
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 2.2.2.5-1
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.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The SSC handles security related to:
1) DAMOS objects
2) CAMPS queues
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
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.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
2.3.1.1 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
A switchover is to be performed within 60 seconds.
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.
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.
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
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.
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.
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.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
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.
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.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
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.
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.
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.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲ ̲a̲n̲d̲ ̲V̲a̲l̲i̲d̲i̲t̲y̲
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.
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.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
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.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
N.A.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
N.A.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
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.
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
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.
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
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
3.2.2.4 M̲M̲O̲N̲ ̲t̲o̲ ̲S̲S̲C̲
a) Security interrogation/warning
3.3.2.5 S̲S̲C̲ ̲t̲o̲ ̲M̲M̲S̲
Via MMON as specified in 3.3.2.3.
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
3.3.2.7 S̲S̲C̲ ̲t̲o̲ ̲Q̲M̲O̲N̲
a) Start-up
b) Close-down
c) Initialize queues
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
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
3.3.2.10 S̲S̲C̲ ̲t̲o̲ ̲M̲D̲P̲
a) Start-up
b) Close-down
3.3.2.11 S̲S̲C̲ ̲t̲o̲ ̲L̲O̲G̲
a) Start-up
b) Close-down
c) Handling of SB log checkpoints
3.3.2.12 L̲O̲G̲ ̲t̲o̲ ̲S̲S̲C̲
a) Sending of log checkpoint records
3.3.2.13 S̲S̲C̲ ̲t̲o̲ ̲T̲H̲P̲
a) Start-up package and channels
b) Close-down package and channels
3.3.2.14 S̲S̲C̲ ̲t̲o̲ ̲S̲A̲R̲
a) Start-up
b) Close-down
3.3.2.15 S̲S̲C̲ ̲t̲o̲ ̲S̲T̲P̲
a) Start-up
b) Close-down
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
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.
3.3.2.18 S̲S̲C̲ ̲t̲o̲ ̲O̲L̲P̲
As 3.3.2.17.
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
3.4.1 R̲e̲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.
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
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
