top - download
⟦91e0d5621⟧ Wang Wps File
Length: 80243 (0x13973)
Types: Wang Wps File
Notes: FIX/1160/PSP/0091
Names: »3130A «
Derivation
└─⟦ea7460488⟧ Bits:30006136 8" Wang WCS floppy, CR 0270A
└─ ⟦this⟧ »3130A «
WangText
`…00……00……00……00…I…02……00……00…I
I…05…I…07…H…00…G…09…G…01…G…06…F…08…F…0b…F…0f…F
F F…06…E…0b…E…01…E
D…08…D…09…D…0d…D…0e…D…02…3…09…3…0f…3 3…07…2…08…2…09…2…0e…2…02…1…09…1…00…1
1…06……1d…
…1d……06……1c……08……1c……09……1c……0e……1b…
3130A/bna…02…FIX/1160/PSP/0091
…02…REV/850301…02……02…#
INTER SCC HANDSHAKING PROCESSES PSP
…02…Issue 1…02…FK 7809
FIKS ISH PROCESSES PSP
FIX/1160/PSP/0091
J]rgen Lindballe/Flemming Revens
Ole Eskedal
AMC (6), REV, LU, LIBRARY (2)
…0e…FIKS S/W Mgr 850301…0f…
…0e…ILS Conf.Mgr 850301
2…0f…
…0f…850301…0e…
3130A/bna FIX/1160/PSP/0091
…02… REV/850301…02……02… ii
INTER SCC HANDSHAKING PROCESSES PSP
…02… Issue 1…02… FK 7809
840518 All First issue of Document
850301 All Issue 2 of Document
includes illustrations
and editorials.
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE .........................................
4
1.1 INTRODUCTION ...............................
4
1.2 ABBREVIATIONS ..............................
6
1.2.1 General Abbreviations ..................
6
1.2.2 Special Abbreviations ..................
6
2 APPLICABLE DOCUMENTS ..........................
10
3 MODULE SPECIFICATION ..........................
11
3.1 ISH DETAILED FUNCTIONAL CAPABILITIES .......
11
3.2 INTERFACE DESCRIPTION ......................
12
3.3 PROCESSING OVERVIEW ........................
12
3.3.1 ISH Modules ............................
14
3.3.1.1 Introduction .......................
14
3.3.2 SCC Watch Dog (SCCWD) ..................
16
3.3.2.1 Introduction .........................
16
3.3.2.2 SCCWD Summary Description ..........
16
3.3.2.3 SCCWD Submodules SWD and CWD .....
20
3.3.2.3.1 SIP Watch Dog Submodule (SWD) ..
20
3.3.2.3.1.1 SWD Summary Description ....
20
3.3.2.3.1.2 SWD Detailed Design ........
25
3.3.2.3.1.2.1 Procedure SWD-Event-
Distribution(SWDED) ....
25
3.3.2.3.1.2.2 Procedure SWDR & CWDC
Status Processing ......
27
3.3.2.3.1.2.3 Procedure SWD-Timer
(SWDTIM) ...............
61
3.3.2.3.1.2.4 Procedure Send SIP/CIP…0f…C…0e…
Keep-Alive-Message .....
64
3.3.2.3.1.2.5 Procedure Send SIP/SIP…0f…R…0e…
Keep-Alive-Message .....
65
3.3.2.3.2 CIP Watch Dog Submodule (CWD) ..
66
3.3.2.3.2.1 CWD Summary Description ....
66
3.3.2.3.2.2 CWD Detailed Design ........
71
3.3.2.3.2.2.1 Procedure CWD-Event-
Distribution(CWDED) ....
71
3.3.2.3.2.2.2 Procedure CWD Command &
Status Processing ......
75
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
3.3.2.3.2.2.3 Procedure CWD-Timer
(CWDTIM) ...............
110
3.3.2.3.2.2.4 Procedure Send CIP/SIP…0f…C…0e…
Keep-Alive-Message .....
114
3.3.2.3.2.2.5 Procedure Transmit NSC
Report (XNSCREP) .......
114
3.3.3 Narrative-Message-Protocol-Machine (NMPM)
115
3.3.3.1 Introduction .......................
115
3.3.3.2 NMPM Summary Description ...........
115
3.3.3.3 NMPM Submodules SPM and CPM ........
121
3.3.3.3.1 SIP Protocol Machine Submodule
(SPM) ..........................
121
3.3.3.3.1.1 SPM Summary Description ....
121
3.3.3.3.1.2 SPM Detailed Design ........
126
3.3.3.3.1.2.1 Procedure SPM-Event-
Distribution (SPMED) ...
126
3.3.3.3.1.2.1.1 Subroutine INNMSG
(MSG,CH#) ..........
133
3.3.3.3.1.2.2 Procedure SPM Monitoring
& Control (SPMM&C) .....
136
3.3.3.3.1.2.3 Procedure Outbound-
Narrative-Message-
Processing .............
139
3.3.3.3.1.2.4 Procedure Dispatch-MSG
(CH#) (DMSG) ...........
141
3.3.3.3.1.2.5 Procedure CPM-ACK-
Processing (CPMAP) .....
142
3.3.3.3.1.2.6 Procedure Inbound-
Narrative-Message-
Processing .............
144
3.3.3.3.1.2.7 Procedure Inbound-Anti-
Message-Processing .....
146
3.3.3.3.1.2.8 Procedure SPM Timer
(SPMTIM) ...............
147
3.3.3.3.1.2.8.1 Subroutine FILTERID
(QUEUE;ID) .............
150
3.3.3.3.2 CIP Protocol Machine (CPM) .....
151
3.3.3.3.2.1 CPM Summary Description ....
151
3.3.3.3.2.2 CPM Detailed Design ........
154
3.3.3.3.2.2.1 Procedure CPM Message &
Event Distribution .....
154
3.3.3.3.2.2.1.1 Subroutine INNMSG
(MSG,CH#) ..........
165
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
3.3.3.3.2.2.2 Procedure CPM Monitoring
& Control ..............
166
3.3.3.3.2.2.3 Procedure Narrative-
Message-Accounting .....
171
3.3.3.3.2.2.4 Procedure Outbound Stuck
Message-Processing
(OSTMP) ................
175
3.3.3.3.2.2.5 Procedure Narrative
Message ACK Processing .
176
3.3.3.3.2.2.6 Procedure Inbound
Narrative Message
Processing .............
177
3.3.3.3.2.2.7 Procedure CPM Timer
Process (CPMTIM) .......
177
3.3.4. Keep Alive Messages (KAM) ............
179
3.3.4.1 Introduction .......................
179
3.3.4.2 SIP to SIP Keep-Alive-Message ......
180
3.3.4.3 SIP to CIP Keep-Alive Message ......
182
3.3.4.4 CIP to SIP Keep-Alive-Message ....
184
3.4 DATA ORGANIZATION ..........................
186
3.5 STORAGE ALLOCATION .........................
186
3.6 PERFORMANCE CHARACTERISTICS ................
186
3.7 LIMITATIONS ................................
186
3.8 ERROR CODES/ERROR LOCATIONS ................
186
3.8.1 ERROR CODES ............................
187
3.8.1.1 SPM ................................
187
3.8.1.2 CPM ................................
188
3.8.1.3 SWD ................................
188
3.8.1.4 CWD ................................
189
3.8.2 Error Locations ........................
189
3.9 LISTING REFERENCES .........................
189
4 QUALITY ASSURANCE .............................
190
5 PREPARATIONS FOR DELIVERY .....................
190
1̲ ̲ ̲S̲C̲O̲P̲E̲
The purpose of this document is to describe the functions
of the Inter SCC Handshaking Subsystem (ISH).
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The Inter SCC Handshaking Subsystem constitutes the
functional realization of the "System Monitoring &
Control" required to make the two SCC systems within
the FIKS network operate as a "System Control Center".
It is important to recognize that ISH is n̲o̲t̲ implemented
as one functional module within one computer system.
On the contrary, ISH is composed of functional submodules
physically located in each of the two SCC sytems and
the two collocated N/M systems.
All ISH functions located at the SCC are integrated
into one physical program module called "Collocated
N/M Interface Processing" (CIP). Similaryly all ISH
functions located at the collocated N/M are integrated
into a physical program module called "SCC Interface
Processing" (SIP).
SIP and CIP are physical concepts which is seen only
from the physical breakdown of the ISH, as depicted
in Figure 1.1-1. SIP and CIP does n̲o̲t̲ match a functional
breakdown of the ISH, and are as such of no importance
for the functional description of the ISH.
ISH: Inter SCC Handshaking Subsystem
SIP: SCC Interface Processing Module
CIP: Collocated N/M Interface Processing Module
Figure 1.1-1…01…ISH Physical Breakdown
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.2.1 G̲e̲n̲e̲r̲a̲l̲ ̲A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
Please refer to Ref. 4.
1.2.2 S̲p̲e̲c̲i̲a̲l̲ ̲A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
AMQ: Anti Message Queue
AMSG: Anti Message
CIP: Collocated N/M Interface Processing
Module
CIP…0f…C…0e…: Collocated CIP
CIP…0f…R…0e…: Remote CIP
CIPOPM: CIP Operational Mode
CKATIM: CIP KAM Absence Timer
COSET: CWDSP/OPCMD State/Event Table
CPM: CIP Protocol Machine
CPMAP: CPM ACK Processing
CPMM&C: CPM Montoring and Control
CPMM&ED: CPM Message and Event Distribution
CSKRTIM: CIP/SIP…0f…C…0e… KAM Release Timer
CSSET: CWDSP/SWDSM State/Event Table
CWD: CIP Watch Dog
CWD…0f…A…0e…: Active CWD
CWD…0f…C…0e…: Collocated CWD
CWD…0f…R…0e…: Remote CWD
CWD…0f…S…0e…: Standby CWD
CWDC&SP: CWD Command and Status Processing
CWDED: CWD Event Distribution
CWDSM: CWD State Message
CWDSP: CWD State Parameter
CWDTIM: CWD Timer
DMSG: Dispatch Message
IAMP: Inbound Anti Message Processing
INMP: Inbound Narrative Message Processing
NMACKP: Narative Message ACK Processing
NMACT: Narrative Message Accounting
NSC: Network Supervision and Control
OAMP: Outbound Anti Message Processing
ONMP: Outbound Narrative Message Processing
OSTMP: Outbound Stuck Message Processing
OPCMD: Operator Command
PMQ: Pending Message Queue
RESPTIM: Response Timer
RSSUPD: Remote SCC Status Update
SCC: System Control Center
SCC…0f…C…0e…: Collocated SCC
SCC…0f…R…0e…: Remote SCC
SCKRTIM: SIP/CIP…0f…R…0e… KAM Release Timer
SCSET: SWDSP/CWDSM State/Event Table
SCSKAM: Send CIP/SIP…0f…C…0e… Keep Alive Message
SIP: SCC Interface Processing Module
SIPOPM: SIP Operational Mode
SKATIM: SIP…0f…R…0e… KAM Absence Timer
SMP: SIP Message Processing
SPM: SIP Protocol Machine
SPMED: SPM Event Distribution
SPMM&C: SPM Monitoring and Control
SPMOPM: SPM Operational Mode
SSCKAM: Send SIP/CIP…0f…C…0e… Keep Alive Message
SSKRTIM: SIP/SIP…0f…R…0e… KAM Release Timer
SSSET: SWDSP/SWDSM State/Event Table
SSSKAM: Send SIP/SIP…0f…R…0e… Keep Alive Message
SWD: SIP Watch Dog
SWD…0f…A…0e…: Active SWD
SWD…0f…C…0e…: Collocated SWD
SWD…0f…R…0e…: Remote SWD
SWD…0f…S…0e…: Standby SWD
SWDED: SWD Event Distribution
SWDSM: SWD State Message
SWDSP: SWD State Parameter
SWDTIM: SWD Timer
S&CSP: SWD…0f…R…0e… and CWD…0f…C…0e… Status Processing
TMQ: Transmitted Message Queue
TR: Transition
TAS: Transition Active-to-Standby
TSA: Transition Standby-to Active
XACKT: ACK Cross Reference Table
2̲ ̲ ̲A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
1. REQUIREMENTS SPECIFICATION
FIX/0000/SPC/0002
Vol. I-III
2. FIKS SYSTEM DESIGN SPECIFICATION
FIX/1000/DSP/0001
3. FIKS SOFTWARE INTERFACE REFERENCE
FIX/0100/MAN/0003
4. FIKS DATA INTERFACE REFERENCE
FIX/0100/MAN/0004
5. FIKS SUBSYSTEM TEST
FIX/0000/TRP/0083
3̲ ̲ ̲M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
3.1 I̲S̲H̲ ̲D̲E̲T̲A̲I̲L̲E̲D̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
The ISH provides the means to maintain a "System ̲Control
Center" and a "Message Service System" within the FIKS
network.
ISH is responsible for maintaining:
o System-Control-Center Integrity
o Message-Service-System Reliability
S̲y̲s̲t̲e̲m̲-̲C̲o̲n̲t̲r̲o̲l̲-̲C̲e̲n̲t̲e̲r̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲means that one and
only one SCC is "active" and controls the network.
In order to maintain this the ISH provides:
o SCC supervisors are alarmed if no SCC is active
o Both SCC's are never active simultanously.
M̲e̲s̲s̲a̲g̲e̲-̲S̲e̲r̲v̲i̲c̲e̲-̲S̲y̲s̲t̲e̲m̲ ̲R̲e̲l̲i̲a̲b̲i̲l̲i̲t̲y̲ means that a "single
point failure" (failure of one of the SCC's) will not
cause that narrative messages, sent to Message Service,
are lost.
In order to maintain that the ISH provides:
o The SCC Message Service Systems are back-up for
each other
o The Message Service Systems are synchronized
o One, and only one, Message Service System is opened
at any time
In addition to the above mentioned capabilities, the
ISH provides interchange of status information between
the two SCC supervisors.
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
Please refer to chapter 3.3
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The functional capabilities required of the ISH are:
o A SCC Watch Dog
o A Narrative Message Protocol Machine
These two functional "units" are both composed of distributed
sub-units, located at the two SCC's and the two collocated
N/M computer systems.
T̲h̲e̲ ̲"̲S̲C̲C̲ ̲W̲a̲t̲c̲h̲ ̲D̲o̲g̲"̲ is composed of two "CIP Watch Dogs"
at the SCC's, and two "SIP Watch Dogs" at the collocated
N/M's.
T̲h̲e̲ ̲"̲N̲a̲r̲r̲a̲t̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲-̲P̲r̲o̲t̲o̲c̲o̲l̲-̲M̲a̲c̲h̲i̲n̲e̲"̲ is similaryly
composed of "CIP Protocol Machines" located at the
two SCC's and "SIP Protocol Machines" located at the
collocated N/M's.
The SCC Watch Dog maintains the "System-Control-Center-
Integrity" and performs the exchange of status information
between the two SCC supervisors.
The Narrative Message Protocol Machine provides "Message
Service System Reliability".
The SCC Watch Dog submodules are made to operate as
one integrated unit (SCC Watch Dog) by the exchange
of control and status between CIP and SIP Watch Dog
and SIP and SIP Watch Dogs, respectively.
A similar handshaking mechanism is used between CIP
and SIP Protocol Machines and SIP and SIP Protocol
Machines to form the "Narrative Protocol Machine" (see
Figure 3.3-1
L̲e̲g̲e̲n̲d̲:
SPM: SIP Protocol Machine
CPM: CIP Protocol Machine
SWD: SIP Watch Dog
CWD: CIP Watch Dog
Figure 3.3-1…01…Sub-Module Handshaking
A common vehicle for the exchange of status and control
between SIP and CIP submodules is maintained by ISH
and is called "Keep Alive Messages".
Briefly, "Keep Alive Messages" are a Mail Service provided
to CIP and SIP submodules, which make use of SIP and
CIP mailboxes for the interchange of status and control.
Keep Alive Messages are implemented as control messages
transmitted on the FIKS network.
An essential feature for the SCC Watch Dog as well
as the Narrative Message Protocol Machine is that they
can operate in a degraded mode with one or more sub-units
out of operation.
A more detailed description of "Keep Alive Messages",
the "SCC Watch Dog" and the "Narrative Message Protocol
Machine" is provided in Section 3.3.1-3.3.4: ISH Modules.
In figure 3.3-2 is found the ISH Visual Table of Contents.
3.3.1 I̲S̲H̲ ̲M̲o̲d̲u̲l̲e̲s̲
3.3.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The ISH detailed design is described in terms of three
functional units (modules) identified as:
o SCC Watch Dog (3.3.2)
o Narrative Message Protocol Machine (3.3.3)
o Keep Alive Messages (3.3.4)
Figure 3.3-2
ISH Visual Table of Contents
3.3.2 S̲C̲C̲ ̲W̲a̲t̲c̲h̲ ̲D̲o̲g̲ ̲(̲S̲C̲C̲W̲D̲)̲
3.3.2.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
Four distributed processes constitute the SCC Watch
Dog Module. The SCCWD consists of local Watch Dogs
at the two SCC's and the collocated N/M's, which in
common perform the supervision and control required
of the SCC Watch Dog.
A brief description of the SCC Watch Dogs functional
capabilities is provided in Section 3.3.2.2 as an introduction
to the detailed description in section 3.3.2.3
3.3.2.2 S̲C̲C̲W̲D̲ ̲S̲u̲m̲m̲a̲r̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
A. F̲u̲n̲c̲t̲i̲o̲n̲s̲:̲
The SCCWD performs the following functions:
o Maintenance of "System Control Center" integrity
o Interchange of Requests/Responses and Status
between the SCC supervisors
o Drive the ISH transport vehicle, i.e. "Keep
Alive Message" transmission
o Control of the operational mode of the local
SCC Message Service Systems.
The SCCWD configuration and environment is depicted
in Figure 3.3.2.2.-1.
Figure 3.3.2.2-1…01…SCCWD Configuration & Environment
B. S̲C̲C̲W̲D̲ ̲H̲a̲n̲d̲s̲h̲a̲k̲i̲n̲g̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
All functions are based upon the exchange of Status
Reports between neighbouring SIP Watch Dogs and
CIP Watch Dogs, i.e:
1) SIP to SIP Status Reports
2) SIP to CIP Status Reports
3) CIP to SIP Status Reports
Status Reports contain commands, requests, responses
and status that make each Watch Dog able to monitor
the current overall SCCWD State.
The handshaking protocol between SWD's and CWD's
is a Master/Slave Protocol
The SWD may issue commands to the CWD, while the
CWD only may forward requests from the local SCC
supervisor to the remote SCC supervisor or the
SCCWD.
The SWD to SWD protocol is a Master/Master Protocol
upon system start-up. The SWD's have to agree upon
authority and when achieved, the SWD granted authority
plays the master role, and the protocol is from
now on a Master/Slave-Protocol.
B1. S̲t̲a̲r̲t̲-̲u̲p̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Upon bootload, both SWD…0f…1…0e… and SWD…0f…2…0e… are in stand-by
mode (please, refer to Figure 3.3.2.2-1). Both
SWD's realize that no SCC is active and forward
an alarm request to CWD…0f…1…0e… and CWD…0f…2…0e… to go active.
The CWD provides the SCCWD interface to the
SCC supervisor and the request "Go Active"
is printed on the event log-printer. The supervisor
who first accepts to go active will be appointed
"Active SCC Supervisor".
B2. S̲C̲C̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
The active supervisor, only, may request the
other supervisor to go active. The request
is forwarded by SCCWD to the remote supervisor,
who can accept or reject the request.
If he accepts, the switchover is performed
by the SCCWD.
Notice that the protocol between the active
supervisor and the SCCWD is a Master/Slave-
Protocol, but that the played roles are interchanged,
while a request is in progress.
B3. S̲C̲C̲ ̲F̲a̲i̲l̲u̲r̲e̲/̲E̲m̲e̲r̲g̲e̲n̲c̲y̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
In case of stand-by SCC failure or the stand-by
SCC Supervisor goes off-line, the SCCWD forwards
a Status Report to the active supervisor which
tells him that switchover is disabled.
When an active SCC failure is encountered by
SCCWD (several Status Reports have failed to
appear, either CWD…0f…A…0e… to SWD…0f…A…0e… - or SWD…0f…A…0e… to SWD…0f…S…0e…
Status Reports), an alarm request is sent to
the stand-by SCC, to go active. The request
will stay until one SCC again is active and
the "System Control Center" reestablished.
B4. S̲p̲e̲c̲i̲a̲l̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲s̲
In case of active SCC collision (two half FIKS
networks have existed, each with its active
SCC before a connection is re-established)
encountered by either SWD, the SWD commands
the collocated SCC to go stand-by and restart.
A restart of the FIKS network will require
that new routing tables are distributed.
C. S̲C̲C̲W̲D̲ ̲H̲i̲g̲h̲l̲i̲g̲h̲t̲s̲
o A broadcasting sceme is used by the SCCWD for
"System Control Center" monitoring.
o Command & Control Signals between SIP Watch
Dogs & CIP Watch Dogs are constantly repeated,
allowing that several are lost, without damage
of the SCC Watch Dog.
o The SCC Watch Dog may operate in a degraded
mode, i.e. with one CIP and one or two SIP
Watch Dogs, and still perform Supervision &
Control of the "System Control Center".
3.3.2.3 S̲C̲C̲W̲D̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲s̲ ̲S̲W̲D̲ ̲a̲n̲d̲ ̲C̲W̲D̲
3.3.2.3.1 S̲I̲P̲ ̲W̲a̲t̲c̲h̲ ̲D̲o̲g̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲S̲W̲D̲)̲
3.3.2.3.1.1. S̲W̲D̲ ̲S̲u̲m̲m̲a̲r̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The SWD submodule performs the following functions:
1) Receive and process status reports from remote
SWD and collocated CWD.
2) Generate and forward status reports to remote
SWD and collocated CWD.
3) Issue commands to collocated CWD if required
to maintain SCC system integrity.
4) Validate and handle the interchange of requests
and responses from/to SCC supervisors, enclosed
in CWD status reports.
5) Run the SIP to remote SIP-, and SIP to collocated
CIP control links (Keep Alive Messages).
6) Maintain SIP Operational Mode.
7) Handle the interchange of Operational Status
between the SCC's.
The SWD is invoked when:
1) An AMOS message is received from the SIP Message
Processing Submole (SPM)
2) Timer interrupt is received
3) Signal is received from SPM.
An overview of the SWD environment is depicted in Figure
3.3.2.3.1.1-1.
The SWD is implemented as one CR80 process, and a program
module, which consists of the following procedures:
1) SWD Event Distribution (SWDED)
2) SWD…0f…R…0e… and CWD…0f…C…0e… Status Processing (S&CSP)
3) SWD Timer (SWDTIM)
4) Send SIP/CIP…0f…C…0e… Keep Alive Message (SSCKAM)
5) Send SIP/SIP…0f…R…0e… Keep Alive Message (SSSKAM)
The flow of control between the SWD procedures is depicted
in figure 3.3.2.3.1.1-2.
1) AMOS message from SPM of the following types:
a) CWD and SCC…0f…C…0e… status reports, retrieved from
CIP Keep Alive Message
b) SWD and SCC…0f…R…0e… status reports, retrieved from
SIP Keep Alive Message.
2) AMOS message for SIP Operational Mode update
3) Enqueue Keep Alive Messages to SIP…0f…R…0e… and CIP…0f…C…0e…
4) Retrieve SIP and CIP control data to be piggy bagged
in Keep Alive Message
5) Timer interrupt
6) Request to send Keep Alive Message to SIP…0f…R…0e… & CIP…0f…C…0e…
(signal).
Figure 3.3.2.3.1.1-1…01…SWD Interface Overview
Figure 3.3.2.3.1.1-2…01…SWD Procedure Calls
Figure 3.3.2.3.1.1-3…01…SWD Visual Table of Contents
3.3.2.3.1.2 S̲W̲D̲ ̲D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
3.3.2.3.1.2.1
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲W̲D̲-̲E̲v̲e̲n̲t̲-̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲(̲S̲W̲D̲E̲D̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
SWD Event Distribution is invoked, when an external
event is received by the SWD process, i.e. AMOS
̲messages, Timer Interrrupts, or AMOS signals.
The event is decoded and validated, and if not
recognized an error is reported. Events recognized
by SWDED are:
o Timer Interrupts, to run the SWD Timer
o CWD…0f…C…0e… Status Reports
o SWD…0f…R…0e… Status Reports
o Delivery Request from submodule SPM.
The latter will happen if SPM has received an ACK
from CPM…0f…C…0e… or received a converted message from
the collocated SCC; this will cause an immediate
mailing (by means of a Keep Alive Message, ref.
sec. 3.3.4).
In accordance with event type, SWD makes a call to:
o SWD…0f…R…0e… & CWD…0f…C…0e… Status Processing or
o Send SIP/SIP…0f…R…0e… Keep Alive Message or
o SWD Timer
and the onward processing of the event is performed
by the procedure.
B. P̲r̲o̲g̲r̲a̲m̲:̲
REPEAT (while event pending)
"GET EVENT" (Event)
IF
(Event = SIGNAL)
THEN
'SPM Delivery Request'
Call "SSSKAM" (Event)
Call "SSCKAM" (Event)
ELSE
IF (Event = Timer Interrupt)
THEN
Call "SWDTIM"
"Reserve Timer" (Time Unit)
ELSE
(Event = AMOS message)
CASE OF LETTERTYPE (1,2,3)
1. 'CWD…0f…R…0e… Status Report'
Call "S&CSP" (Event)
2. "SWD…0f…R…0e…Status Report'
Call "S&CSP" (Event)
3. "Invalid Type"
"ERROR" (Error Code)
END CASE
"Send Answer" (Event)
END IF
END IF
END REPEAT
3.3.2.3.1.2.2
Procedure SWD…0f…R…0e…&CWD…0f…C…0e… Status Processing (S&CSP)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure S&CSP is invoked when a SWD…0f…R…0e… or CWD…0f…C…0e… Status
Report is received from submodule SPM, or a Pseudo
Status Report is generated by the SWD Timer, upon absence
of CIP…0f…C…0e… or SIP…0f…R…0e… Keep Alive Messages (ref. to Sec. 3.3.2.3.1.2.3).
The SWD…0f…R…0e… and CWD…0f…C…0e… Status Report contains the status
of the remote and collocated NICS-TARE link status,
respectively, to be interchanged between the collocated
and remote SCC.
Besides, the SWD…0f…R…0e…/CWD…0f…C…0e… Status Report contains a SWD…0f…R…0e…/CWD…0f…C…0e…
State Message, which enables the SWD to monitor the
status of "The System Control Center",and to perform
the adequate control, to maintain "System Control Center"
integrity.
Vice versa the control output from SWD is contained
in a SWD…0f…C…0e… State Message to CWD…0f…C…0e… and SWD…0f…R…0e… piggybacked
in a SIP/SIP…0f…R…0e… or SIP/CIP…0f…C…0e… Keep Alive Message, respectively.
The SWD State Messages to CWD…0f…C…0e… and SWD…0f…R…0e… are generated
from the "SWD State Parameter" (SWDSP), which in turn
is maintained in accordance to the SWDSM and CWDSM
received.
The SWD STATE Parameter is described in section A1.
The main part of the S&CSP program is designed around
two state event tables with assigned action procedures
for processing of SWD…0f…R…0e… and CWD…0f…C…0e… Status Reports, respectively.
i) S̲W̲D̲S̲P̲/̲S̲W̲D̲S̲M̲ ̲S̲t̲a̲t̲e̲/̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲l̲e̲ ̲(̲S̲S̲S̲E̲T̲)̲
The calculation of the new SWD State Parameter,
and selection of the actions to be performed is
based on:
Current State = SWDSP
and
Current Event = SWDSM
ii) S̲W̲D̲S̲P̲/̲C̲W̲D̲S̲M̲ ̲S̲t̲a̲t̲e̲/̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲l̲e̲ ̲(̲S̲C̲S̲E̲T̲)̲
The actions to be performed and the new SWD State
Parameter is determined by:
Current State = SWDSP
and
Current Event = CWDSM
The specific definition of SSSET and SCSET are provided
in Sections B1 and B2, and SWDSM and CWDSM are defined
in Sections A2 and A3.
A summary description of the processing of CWD…0f…C…0e…- and
SWD…0f…R…0e…-Status Reports, is as follows:
Upon receipt of a Status Report, the corresponding
"Absence Timer" SKATIM or CKATIM (ref. to Section 3.3.2.3.1.2.3)
is reset, as acknowledgement of the receipt of a SIP…0f…R…0e…-
or CIP…0f…C…0e…-Keep Alive Message.
The SWD State Parameter is updated in accordance to
the Status Report received, and the appropriate actions
are performed.
Events that require immediate/emergency actions are:
i) SIP's Operational Mode has changed, which has to
be signalled to the SPM submodule.
(SIP Operational Mode, please ref. to Section A1).
ii) SCC…0f…C…0e… Operational Mode has changed from Active to
Stand-by, off-line or unknown, while SIP…0f…R…0e… Operational
Mode is stand-by. Remote SCC supervisor must be
alarmed.
iii)SCC…0f…R…0e… Operational Mode has changed from Active to Stand-by
or
unknown,
while
SIP…0f…C…0e…
Operational
Mode
is
stand-by.
Collocated
SCC
supervisor
must
be
alarmed.
In case i) an AMOS message defining SIP Operational
Mode is sent to SPM.
Case ii) and iii) require that a Keep Alive Message
is immediately sent to either SIP…0f…R…0e… or CIP…0f…C…0e…. This is
performed by a call of the procedure "SSSKAM" or "SSCKAM"
(ref. to Section 3.3.2.3.1.2.4/5).
A1. S̲I̲P̲-̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲-̲M̲o̲d̲e̲ ̲(̲S̲I̲P̲O̲P̲M̲)̲
"SIP Operational Mode" is a parameter, which specify
whether the collocated N/M currently interfaces to
an Active or Stand-by SCC.
SIPOPM can be assigned three values:
O: Off-line
S: Stand-by
A: Active.
The transitions between these states are controlled
by the SCC Watch Dog as a whole (i.e. handshaking between
SWD…0f…C…0e… and SWD…0f…R…0e…); this may occur as depicted in Figure
3.3.2.3.1.2.2-1.
SIPOPM is locally maintained by S&CSP, and updates
forwarded to the SIP Message Processing Submodule (SMP),
when any transition has taken place.
1) The N/M is bootloaded
2) An unrecoverable error has occured while the collocated SCC is stand-by
3) The collocated SCC goes active on request from SCC Watch Dog on either of two conditions:
a) Initial "System Control Center" start-up
b) Emergency action upon active SCC failure
4) On request from collocated SCC supervisor or upon collocated SCC failure.
5) Unrecoverable error occured while collocated SCC is active
Figure 3.3.2.3.1.2.2-1…01…SIPOPM State Transition
A2. S̲W̲D̲-̲S̲t̲a̲t̲e̲-̲P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲(̲S̲W̲D̲S̲P̲)̲
The "SWD State Parameter" is actually an extension
of the SIP Operational Mode, to cope with the transitions
from stand-by to active or vice versa, and the
interchange of requests and responses between the
two SCC supervisors. In other words, a SWD State
is an encoding of:
o SIP Operational Mode
o SWD Commands and Responses
o Supervisor Requests and Responses.
The various SWD States are summarized in table
3.3.2.3.1.2.2-1.
SWD States are grouped into "State Groups" in accordance
to SIP Operational Mode, i.e:
O: Off-line State Group
S: Stand-by State Group
A: Active State Group
In addition, a classification of SWD States as
being a "Stationary State" (ST) or a "Transition
State" (TR) is made.
A state is classified as "ST" if a State-Group
Transition is autonomously controlled by the local
watch dog SWD…0f…C…0e…. Otherwise it requires autorization
by the remote watch dog SWD…0f…R…0e…, and is classified
as "TR".
SWD State Mnemonic State State
Group Class
-------------------------------------------------------
Undefined U O ST
Off-line Acknowledge OA S ST
Stand-by S S ST
Transition Stand-by to Active TSA S ST
Stand-by Steady ST S ST
Active Attempt AT S TR
Active A A ST
Transition Active To Stand-by TAS A ST
Active Declined AD A ST
Table 3.3.2.3.1.2.2-1…01…SWD-States
A detailed definition of the purpose and function of
each state is provided in Table 3.3.2.3.1.2.2-2 in
connection with Figure 3.3.2.3.1.2.2-2, which shows
each SWD State Transition that may take place.
Figure 3.3.2.3.1.2.2-2
SWD State Transitions
SWD Description
State
---------------------------------------------------------
U State "U" is the only off-line state, and the
non-operational SWD state. It is entered
when:
TE: An unrecoverable error has occured (either
S/W or H/W error).
--------------------------------------------------------
OA This is an element in the stand-by State Group;
it is an acknowledgement of a "Transition to
Off-line" message received from the SCC.
State "O" is entered when:
T1: An "Off-line Transition Notice" is received
from the local SCC.
------------------------------------------------------
S State "S" is the only stable state in the stand-by
State Group. No commands/responses are in progress/pending
to/from the local SCC/the remote Watch Dog.
State "S" is entered when:
TO: The N/M is bootloaded
T2: SCC has returned to stand-by
T5: A transition to active (original requested
by remote SCC or Watch Dog) is disapproved
by remote Watch Dog.
Table 3.3.2.3.1.2.2-2 (cont.'d)…01…SWD State Definitions
SWD Description
State
---------------------------------------------------------
S T8: A transition to stand-by has been approved
by remote SIP Watch Dog (SWD…0f…R…0e…)
T12:A refusal to go active has been taken into
account by the remote SWD…0f…R…0e…
TS: Resynchronization with local SCC is required
--------------------------------------------------------
TSA This is an element in the stand-by State Group,
a signal to request the local SCC to go active.
State "TSA" is entered when:
T3: a) No SCC is active (emergency switchover
initiated by the Watch Dog)
b) A "Go Active" request is forwarded
from
the remote SCC supervisor
--------------------------------------------------------
ST State "ST" is an element in the Stand-by State
̲Group and signals a refusal or inability from
the local SCC to go active.
It is entered when:
T11: The local SCC supervisor has rejected
to
go active
TF: Local SCC failure has occured
--------------------------------------------------------
Table 3.3.2.3.1.2.2-2 (cont. 'd)
SWD Description
State
---------------------------------------------------------
AT "AT" is the gate to the active from the stand-by
State Group. It signals that the local SCC
is ready to go active.
State "AT" is entered when:
T4: The local supervisor has accepted to go
active (which requires authorization by
the remote Watch Dog)
--------------------------------------------------------
A State "A" is the stable state in the active
State Group.
No commands/responses are in progress/pending
to/from local SCC/remote Watch Dog.
State "A" is entered when:
T6: A request to go active is authorized by
remote Watch Dog.
T10:A refusal from the remote SCC to go active
has been taken into account by local SCC
-------------------------------------------------------
TAS State "TAS" is an element in the active State
Group, and is a request to the remote SCC to
go active. It is a SWD…0f…C…0e… response, to a request
from the collocated SCC supervisor, to go stand-by.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-2 (cont. 'd)
SWD Description
State
--------------------------------------------------------
TAS State "TAS" is entered when:
T7: The active SCC supervisor enters the
command "Go Stand-by"
--------------------------------------------------------
AD State "AD" is an element in the active STATE
̲Group, and signals to the local SCC supervisor
that the remote (stand-by) SCC supervisor has
refused or is unable to go active.
State "AD" is entered when:
T9: A "Stand-by Steady" response has been received
in a SWD State Message.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-2 (cont.'d)
A3. Inbound CWD…0f…C…0e…-Status-Report Decoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The CWD…0f…C…0e… Status Report consists of two parameters:
o The collocated SCC NICS-TARE Link Status (N/T…0f…C…0e…)
o CWD (CWDSM)
The NICS-TARE Link Status is intended for the remote
SCC supervisor, and is not processed by the SWD,
but placed in the SIP…0f…R…0e… Mailbox, to be forwarded
to the remote SCC in the next transmitted SSKAM.
The CWD…0f…C…0e… State Message, on the other hand, contains
all information required by the SWD to monitor
and control the operational mode of the collocated
SCC.
CWDSM is an encoding of:
o SCC…0f…C …0e…Operational Mode
o Active SCC…0f…C…0e… Supervisor Requests
o Stand-by SCC…0f…C…0e… Supervisor Responses.
CWDSM is a transformation of the CWD State Parameter
(CWDSP), which is described in details in Section
3.3.2.3.2.2.2-A2.
The decoding of the CWD…0f…R…0e… State Message into the
above mentioned three classes is defined by Table
3.3.2.3.1.2.2-3.
-----------------------------------^
CWD…0f…C…0e… State Message Mnemonic
-----------------------------------^
^ O ^ S ^ ST ^ AT* ^ A ^
TAS ^
---------------------------------------------------------^
SCC…0f…C…0e… Operational Mode O S S S/A A
A
---------------------------------------------------------^
Active SCC…0f…C…0e… Supervisor - - - -/RQ2 -
RQ1
Request
---------------------------------------------------------^
Stand-by SCC…0f…C…0e…Supervisor - - RP1 RP2/- -
-
Response
---------------------------------------------------------^
*) This message is used by the stand-by as well as
the
active CWD.
SCC…0f…C…0e… Operational Mode may be:
O: Off-line
S: Stand-by
A: Active
Active SCC Supervisor Requests are:
RQ1: Request Remote SCC to go active
RQ2: Cancel 'RQ1'.
Stand-by SCC Supervisor Responses to RQ1 may be:
RP1: Reject to go active
RP2: Accept to go active
Table 3.3.2.3.1.2.2-3…01…CWDSM Decoding
A4. Inbound SWD…0f…R…0e…-Status-Report Decoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The SWD…0f…R…0e… Status Report consists of two parameters:
o The remote SCC NICS-TARE Link Status (N/T…0f…R…0e…)
o SWD…0f…R…0e… State Message (SWDSM).
The NICS-TARE Link Status is intended for the collocated
SCC supervisor, and is not processed by the SWD.
N/T…0f…R…0e… is mailed in the CIP…0f…R…0e… Mailbox and is transmitted
to the collocated SCC in the next SIP/CIP…0f…C…0e… Keep Alive
Message to the collocated SCC.
The SWD…0f…R…0e… State Message, on the other hand, contains
all information required by SWD to monitor the operational
mode of the remote SCC.
The SWD…0f…R…0e… State Message is an encoding of:
o SIP…0f…R…0e… Operational Mode (SIPOPM)
o Active SCC…0f…R…0e… Supervisor Requests
o Stand-by SCC…0f…R…0e… Supervisor Responses.
The SWD…0f…R…0e… State Message to the remote SWD, is a transformation
of the SWD State Parameters for the remote SIP, as
defined in Sec. 3.3.2.3.1.2.2-A6.
The decoding of the SWD…0f…R…0e… State Message into the above
mentioned three classes is defined by Table 3.3.2.3.1.2.2-4.
-----------------------------------^
SWD…0f…R…0e… State Message Mnemonic
-----------------------------------^
^ S ^ ST ^ AT ^ A
^ TAS
---------------------------------------------------------^
SIP…0f…R…0e… Operational Mode S S S A
A
---------------------------------------------------------^
Active SCC…0f…R…0e… Supervisor - - - -
RQ1
Request
---------------------------------------------------------^
Stand-by SCC…0f…R…0e… Supervisor - RP1 RP2 -
-
Response
---------------------------------------------------------^
SIP…0f…R…0e… Operational Mode:
S: Stand-by
A: Active
Active SCC…0f…R…0e… Supervisor Request:
RQ1: Request to local SCC to go active
Stand-by SCC…0f…R…0e… Supervisor Responses:
RP1: Transition to active rejected/impossible
RP2: Transition to active accepted
Table 3.3.2.3.1.2.2-4…01…SWDSM Decoding
A5. Outbound CWD…0f…C…0e…-Status-Report Encoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The Status Report sent from SWD to the collocated CIP
Watch Dog (CWD…0f…C…0e…) contains three parameters:
o Remote SCC NICS-TARE Link Status (N/T…0f…R…0e…)
o Remote SIP Operational Mode
o SWD to CWD State Message
The N/T…0f…R…0e… and remote SIP Operational Mode are retrieved
from the inbound SWD…0f…R…0e… Status Message and forwarded
to the collocated SCC.
The SWD to CWD State Message is generated from the
SWD State Parameters, and is an extract of status,
commands and responses required, to control and service
the collocated CWD (SCC).
The conversion from SWD State Parameters to Outbound
̲CWD State Message is defined in Table 3.3.2.3.1.2.2-5.
Outbound CWDSM
OA S TSA A
AD
S OA X
W S X
D TSA X
S ST X
P AT X
A X
TAS X
AD
X
Table 3.3.2.3.1.2.2-5…01…SWDSP to CWDSM conversion
A6. Outbound SWD…0f…R…0e…-Status-Report Encoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The status report sent from SWD to the remote SIP ̲Watch
Dog (SWD…0f…R…0e…) is similar to the inbound SWD…0f…R…0e… Status Report
and holds:
o Collocated NICS-TARE Link Status (N/T…0f…C…0e…)
o SWD State Messge (SWDSM).
The N/T…0f…C…0e… is retrieved from the inbound CWD…0f…C…0e… Status
Report and forwarded to the remote SCC.
The SWD State Message is an extract of SWD State ̲Parameters
Information, and is generated as defined by Table 3.3.2.3.1.2.2-6
shown below:
Outbound SWDSM
S ST AT A TAS
S OA X
W S X
D TSA X
S ST X
P AT X
A X
TAS X
AD X
Table 3.3.2.3.1.2.2-6…01…SWDSP to SWDSM Conversion
B. P̲r̲o̲g̲r̲a̲m̲ ̲S̲&̲C̲S̲P̲
BEGIN
IF (event = CWD…0f…C…0e… Status Report)
THEN
Retrieve "Collocated NICS TARE Link Status"(N/T…0f…C…0e…)
Load N/T…0f…C…0e… to SSKAM
Retrieve "CWD…0f…C…0e… State Message" (CWDSM)
'Calculate new state'
SWDSP:= SCSET ̲STATEC (SWDSP, CWDSM)
'Get Action'
Action Procedure: = SCSET ACTION (SWDSP,
CWDSM)
ELSE (Event= SWD…0f…R…0e… Status Report)
Retrieve "Remote NICS TARE Link Status"
(N/T…0f…R…0e…)
Load N/T…0f…R…0e… to SCKAM
Retrieve "SWD…0f…R…0e… ̲State ̲Message" (SWDSM)
'Calculate new state'
SWDSP: = SSSET State (SWDSP, SWDSM)
'Get Action'
Action Procedure:= SSSET Action (SWDSP,
SWDSM)
END IF
SIP Operational Mode:= State Group (SWDSP)
"Generate" (Outbound SWDSM, SWDSP)
Load Outbound SWDSM to SSKAM
"Generate" (Outbound CWDSM, SWDSP)
Load Outbound CWDSM to SCKAM
'Execute Action Retreived from State event
table'
Call "Action Procedure
END
B1. S̲t̲a̲t̲e̲-̲E̲v̲e̲n̲t̲-̲T̲a̲b̲l̲e̲s̲
B1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The SCSET and SSSET State Event Tables, defined
in table 3.3.2.3.1.2.2-A and Table 3.3.2.3.1.2.2-A,
are encoded as follows:
Entry
No.
(*)
New Action
State No.
o "Entry No." is referenced in the State Event
comments table, appended to each State Event
Table
o "New State" is the mnemonic for the SWD State
Values, and the SWD State Parameters updated
in accordance to that. If the contents is (-)
then no SWD State change is required.
o "Action No." is a reference to one of the Action
Procedures, defined in B1.2; this is executed
each time an entry applies. If the contents
is (-) then no action is required.
o An asterix (*) in the center field indicates
that a SIP Operational Mode change takes place.
B1.2 A̲c̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
A1: BEGIN
"Send SIP/SIP…0f…R…0e… Keep Alive Message"
END
A2: BEGIN
"Send SIP/CIP…0f…C…0e… Keep Alive Message"
END
A3: BEGIN
"Send SIP/SIP…0f…R…0e… Keep Alive Message"
"Send SIP/CIP…0f…C…0e… Keep Alive Message"
END
A4: BEGIN
"Send SIP/SIP…0f…R…0e… Keep Alive Message"
"Send SIP/CIP…0f…C…0e… Keep Alive Message"
"Send AMOS Message to SPM with SIP
Operational Mode Update"
END
B1.3 S̲W̲D̲S̲P̲/̲C̲W̲D̲S̲M̲ ̲S̲t̲a̲t̲e̲/̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲e̲l̲ ̲ ̲(̲S̲C̲S̲E̲T̲)̲
The SCSET State Event Table is a two dimensional
array, where each element holds a State- and Action
designator.
State is retrieved by a call:
STATE:= SCSET ̲STATE (STATE, EVENT)
Action is retrieved by a call:
ACTION:= SCSET ACTION (STATE,EVENT)
SCSET is defined by Table 3.3.2.3.1.2.2-7A.
Narratives to each entry are provided in Table
3.3.2.3.1.2.2-7B, which describes the purpose and
function of the specific entry.
+) The first column applies to the Pseudo Status Reports
generated upon CIP Keep Alive Message Timeout.
Table 3.3.2.3.1.2.2-7A…01…SWDSP/CWDSM State Event Table
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
1 SCC…0f…C…0e… supervisor has intentionally gone off-line.
2 Off-line acknowledgement has not yet been received
by CWD…0f…C…0e….
3 SCC…0f…C…0e… has switched from off-line to stand-by.
Synchronize SWD state with CWD…0f…C…0e… state.
4-7 These are invalid state combinations. Wait
for CWD…0f…C…0e… to resynchronize.
8 SCC…0f…C…0e… failure; announce to SCC…0f…R…0e… that switchover
is impossible.
9 SCC…0f…C…0e… goes off-line; acknowledge this notice.
10-14 The N/M has failed, which has not yet been
realized by CWD…0f…C…0e…. Await that CWD…0f…C…0e… resynchronizes.
15 SCC…0f…C…0e… failure not resolved.
16 Please ref. to 9.
17 SCC…0f…C…0e… has returned to stand-by. Enable requests
to "go active" from remote SCC.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-7B…01…SCSET Narratives
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
18 SWD…0f…R…0e… has not yet realized that SCC…0f…C…0e… supervisor
refuses/or is unable to go active.
19-21 Invalid state combination. Wait for CWD…0f…C…0e… to
resynchronize.
22 SCC…0f…C…0e… failure while SWD has requested SWD…0f…R…0e… authorization
to go active. Since SWD goes stand-by, SWD…0f…R…0e…
must be alarmed. Also refer to 8.
23 Identical to 22 besides that the off-line transition
notice is acknowledged.
24 The SCC…0f…C…0e… has failed, but has returned to stand-by.
25 Invalid state. The CWD…0f…C…0e… has cancelled a request
to go active immediately after accepting it.
SWD goes stand-by and waits for CWP to synchronize.
26 An acceptance of to go active has not yet been
received by SWD…0f…R…0e…. Keep on announcing it.
27-28 Invalid state. CWD…0f…C…0e… has gone active on its
own account. SWD goes stand-by and waits for
CWD…0f…C…0e… to synchronize..
29 Please refer to 8.
30 Please refer to 9.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-7B (cont.'d)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
31 A request to go active from SWD or SCC…0f…R…0e… supervisor
has not yet been handled by SCC…0f…C…0e… supervisor
(continue to request take over).
32 SCC…0f…C…0e… supervisor has rejected to go active.
Announce this to SCC…0f…R…0e… supervisor or SWD, whoever
may have requested it.
33 SCC…0f…C…0e… supervisor has accepted to go active.
Request authorization to go active from SWD…0f…R…0e….
34-35 Please refer to 10-14.
36 SCC…0f…C…0e… has failed while active. No active SCC,
so SWD…0f…R…0e… must be alarmed.
37 SCC…0f…C…0e… has failed and supervisor switches the
SCC…0f…C…0e… to off-line. The off-line transition is
acknowledged, and SWD…0f…R…0e… is alarmed.
38 SCC…0f…C…0e… has failed, but has recovered and is returned
to stand-by. No active SCC, send alarm to SWD…0f…R…0e…
and resynchronize with CWD…0f…C…0e….
39 Invalid state combination. SWD goes stand-by
and waits for CWD…0f…C…0e… to synchronize.
40 Permission to go active has been granted, but
has not yet been realized by CWD…0f…C…0e….
--------------------------------------------------------
Table 3.3.2.3.1.2.2-7B ( cont 'd)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
41 Equilibrium state active. No transition in
progress.
42 SCC…0f…C…0e… supervisor requests the SCC…0f…R…0e… supervisor
to go active.
Forward the request to SWD…0f…R…0e….
43 Please refer to 36.
44 Please refer to 37.
45 Please refer to 38.
46 Please refer to 39.
47 SCC…0f…C…0e… supervisor has cancelled a request to
go stand-by.
Make SWD…0f…R…0e… aware of that.
48 Invalid state combination.
SWD goes stand-by, waits for CWD…0f…C…0e… to synchronize.
49 SCC…0f…C…0e… supervisor still awaits response to switchover
request.
50 Please refer to 36.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-7B (cont.'d)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
51 Please refer to 37.
52 Please refer to 38.
53 Please refer to 39.
54 The SCC…0f…C…0e… supervisor has issued a request to
switchover.
This has been rejected by the remote SCC supervisor
(or SWD…0f…R…0e…) at the same time as the SCC…0f…C…0e… supervisor
cancels the request. Permit SCC…0f…C…0e… supervisor
to return to active.
55 The remote SCC has refused to go active; this
has been taken into account by CWD…0f…C…0e…, and needs
no more be announced.
56 The SCC…0f…C…0e… supervisor has not yet realized that
the remote SCC…0f…C…0e… supervisor refuses to go active.
Go on announcing it.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-7B (cont.'d)
B1.4 S̲W̲D̲S̲P̲/̲S̲W̲D̲S̲M̲ ̲S̲t̲a̲t̲e̲/̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲l̲e̲ ̲ ̲(̲S̲S̲S̲E̲T̲)̲
The SSSET State Event Table is a two dimensional
array, with each entry holding a State- and Action
designator.
State is retrieved by a call:
STATE:= SSET ̲STATE (STATE, EVENT)
Action is retrieved by a call:
ACTION:= SSET ̲ACTION (STATE, EVENT)
The SSSET is defined by Table 3.3.2.3.1.2.2-8A,
and a narrative to each entry is provided in Table
3.3.2.3.1.2.2-8B, describing the purpose and function
of each entry.
+) The first column applies to the Pseudo Status Reports
generated upon SIP Keep Alive Message Timeout.
Table 3.3.2.3.1.2.2-8A…01…SWDSP/SWDSM State/Event Table
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
1-6 The collocated SCC is off-line. Go on announcing
to SWD…0f…R…0e… that switchover is disabled.
7-9 No SCC is active. Forward an emergency request
to CWD…0f…C…0e… to go active.
10 The remote SCC is ready to go active. SWD yields
by remaining stand-by.
11 The other SCC is active. Equilibrium state
where no transition is in progress.
12 Remote SCC supervisor requests a switchover.
SWD forwards this request to collocated SCC
supervisor.
13-16 The collocated SCC is not able to take over;
announce this.
17 SWD…0f…R…0e… has realized SWD's objection to go active.
18 SWD…0f…R…0e… has not yet been told that SWD has refused
to go active. Go on announcing this.
19-21 Permission for SWD to go active is granted.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-8B…01…SSSET Narratives
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
22 Both SWD's ask for permission to go active.
This may occur during initial start-up or restart
of the "System Control Center". SWD yields
for SWD…0f…R…0e…. If, by accident, SWD…0f…R…0e… also yields
for SWD, i.e. no SCC goes active, then a "collision"
has occured, and the SCC's competion to go
active will continue.
If, on the other hand, one of the SWD's is
sufficient ahead of the others in the "go active
cycle" (10), it will be granted permission
to go active.
23 SWD…0f…R…0e… was sufficient ahead of SWD to go active
(ref. to 22).
24 SWD…0f…R…0e… has a request to SWD to go active. This
has been accepted by SWD but not yet realized
by SWD…0f…R…0e…. Go on announcing it.
25-27 Still no SCC active. SWD shall continue to
request the CWD…0f…C…0e… to go active.
28 SWD yields for SWD…0f…R…0e… going active, by going
stand-by.
29 Please refer to 28
--------------------------------------------------------
Table 3.3.2.3.1.2.2-8B (cont.'d)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
30 SWD…0f…R…0e… has a pending request to SCC…0f…C…0e… supervisor.
SWD continues to forward that request to CWD…0f…C…0e….
31-34 SWD is active, and has authority to ignore
all requests from SWD…0f…R…0e… and to remain active.
35-36 Both SCC's are active.
The FIKS network and the SCC Watch Dog has
been operating in a degraded mode, as two independent
networks, each with its own "System Control
Center".
That is possible, if all trunks between these
two "Half Networks" are down, and both SWD's
have interpreted that as if the other SWD (SCC)
has failed. (Keep Alive Message Timeout).
When a link between the "Half Networks" is
restablished this "Active Collision" will occur.
To recover from that the SWD which first detects
this integrity violation (if not both SWD's
detect it) shall yield.
An alarm is forwarded to as well SWD…0f…R…0e… as CWD…0f…C…0e…
to initiate a "go active cycle" to establish
o̲n̲e̲ "System Control Center".
--------------------------------------------------------
Table 3.3.2.3.1.2.2-8B (cont.'d)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
37 The SCC…0f…C…0e… supervisor has requested the SCC…0f…R…0e…
supervisor to go active. SWD realizes that
it is impossible, and announces this to CWD…0f…C…0e….
38 The remote SCC…0f…C…0e… supervisor has not yet responded
to a request to go active.
39 The remote SCC supervisor has rejected to go
active, which is told to CWD…0f…C…0e….
40 The remote SCC supervisor has accepted to go
active, and the swithchover is performed by
SWD.
41-42 Please refer to 35-36.
43 SWD must continue to tell CWD…0f…C…0e… that switchover
is impossible.
44-45 CWD…0f…C…0e… may still forward a request to SCC…0f…R…0e… to
go active, which once has been rejected. This
has not yet been realized by CWD…0f…C…0e….
46 SWD…0f…R…0e… must have detected SWD failure, and has
started to go active, on its own account.
47-48 Please refer to 35-36.
--------------------------------------------------------
Table 3.3.2.3.1.2.2-8B (cont.'d)
3.3.2.3.1.2.3 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲W̲D̲-̲T̲i̲m̲e̲r̲ ̲ ̲(̲S̲W̲D̲T̲I̲M̲ ̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
The SWD Timer constitutes four different timers,
identified as:
1) SIP…0f…R…0e… Kam Absence Timer (SKATIM)
2) CIP…0f…C…0e… KAM Absence Timer (CKATIM)
3) SIP/SIP…0f…R…0e… KAM Release Timer (SSKRTIM)
4) SIP/CIP…0f…C…0e… KAM Release Timer (SCKRTIM)
SWDTIM is invoked by SWDED, when a Timer Interrupt
is received by the SWD-Process, used to run these
timer, which are all synchronously driven by one
and the same Timer Interrupt.
SWDTIM maintains these timers as commanded by the
procedures S&CSP, SSSKAM and SSCKAM; when a timer
expires a predefined action is performed. The maintenance
and purpose of each timer is as follows:
A1. S̲K̲A̲T̲I̲M̲ ̲a̲n̲d̲ ̲C̲K̲A̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲s̲
The purpose of SKATIM/CKATIM is to detect when
a SIP…0f…R…0e…/CIP…0f…C…0e… KAM has failed to appear within a predefined
time interval (SKATIM/CKATIM preset values SKATIM0/CKATIM0),
which is interpreted as a failure of SIP…0f…R…0e…/CIP…0f…C…0e….
If the SKATIM/CKATIM expires a call is made to
procedure S&CSP to simulate the receipt of a SWD…0f…R…0e…/CWD…0f…C…0e…
status report, with "Undefined" SWD…0f…R…0e…/CWD…0f…C…0e… status.
SKATIM/CKATIM is commanded preset by S&CSP each
time a SWD…0f…R…0e…/CWD…0f…C…0e… status report is received.
A2. S̲S̲K̲R̲T̲I̲M̲/̲S̲C̲K̲R̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲s̲
The purpose of SSKRTIM/SCKRTIM is to trigger the
release of SSKAM/SCKAM with regular intervals (SSKRTIM/SCKRTIM
preset values SSKRTIM0/SCKRTIM0).
When SSKRTIM/SCKRTIM expires, a call is made to
procedure SSSKAM/SSCKAM, to provide for the transmission
of a SIP to SIP…0f…R…0e…/SIP to CIP…0f…C…0e… Keep Alive Message.
SSKRTIM/SCKRTIM is preset by SSSKAM/SSCKAM when
a SSKAM/SCKAM has been transmitted (enqueued in
TQ).
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
CASE OF EVENT/COMMAND (1,2,3,4,5)
1. "EVENT = Timer Interrupt'
'Begin Run Timers'
CKATIM:= CKATIM-1
SKATIM:= SKATIM-1
SSKRTIM:= SSKRTIM-1
SCKRTIM:= SCKRTIM-1
"End Timer Update'
IF
SKATIM = 0 'SKATIM expired')
THEN
SWD…0f…R…0e… ̲Status:= Undefined
N/T…0f…R…0e… ̲Status:= Undefined
Call "S&CSP" SWD…0f…R…0e…-Status ̲Report)
END IF
IF
(CKATIM = 0 'CKATIM expired')
THEN
CWD…0f…C…0e… ̲Status:= Undefined
N/T…0f…C…0e… ̲Status:= Undefined
Call "S&CSP" (CWD…0f…C…0e… ̲Status ̲Report)
END IF
IF
(SSKRTIM 0 'SSKRTIM expired')
THEN
Call "SSSKAM"
END IF
IF
(SCKRTIM =0 'SCKRTIM expired')
THEN
Call "SSCKAM"
END IF
2. 'COMMAND = Preset SKATIM Timer'
SKATIM:= SKATIM0
3. 'COMMAND = Preset CKATIM Timer'
CKATIM:= CKATIM0
4. 'COMMAND = Preset SSKRTIM Timer'
SSKRTIM:= SSKRTIM0
5. 'COMMAND = Preset SCKRTIM Timer'
SCKRTIM:= SCKRTIM0
END CASE
END
3.3.2.3.1.2.4 Procedure Send SIP/CIP…0f…C…0e… Keep-Alive-Message
(SSCKAM)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
A: N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure SSCKAM is invoked when a CIP…0f…C…0e… Keep
Alive Message has to be transmitted. A CIP…0f…C…0e…
Keep Alive Message is sent with a regular frequency
(controlled by SWDTIM, section 3.3.2.3.1.2.3)
or when an emergency situation has occured
that requires an immediate exchange of status
between the collocated Watch Dog CWD and SWD.
In the latter case, "SSCKAM" is called by "S&CSP".
The status and data to be piggybacked in the
CIP Keep Alive Message are retrieved from the
CIP Mailbox.
B: P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
"Reserve Critical Region" (CIP Mailbox)
Retrieve CIP ̲Mailbox Data
"Release ̲Critical Region" (CIP Mailbox)
Write Control Message" (CIP Keep Alive
Message)
"Enqueue" (CIP Keep Alive Message, TQ)
END
3.3.2.3.1.2.5 Procedure Send SIP/SIP…0f…R…0e… Keep-Alive-Message
(SSSKAM)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure SSSKAM is called whenever a SIP…0f…R…0e…
Keep Alive Message has to be transmitted.
A SIP…0f…R…0e… Keep Alive Message is normally sent
with a regular frequency, controlled by "SWDTIM"
(Section 3.3.2.3.1.2.3), but when the SIP ̲Mailbox
overflows, or an emergency situation has occured,
it is immediately transmitted. SIP ̲Mailbox
overflow is encountered by the SIP ̲Message
Processing Module.
The data and status to be piggybacked in the
SIP Keep Alive Message are retrieved from the
SIP Mailbox, before the message is released
for transmission.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
"Reserve Critical Region" (SIP Mailbox)
Retrieve SIP Mailbox Data
"Release Critical Region" (SIP Mailbox)
"Write Control Message" (SIP Keep Alive
Message)
"Enqueue" (SIP Keep Alive Message, TQ)
END
3.3.2.3.2 C̲I̲P̲ ̲W̲a̲t̲c̲h̲ ̲D̲o̲g̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲ ̲(̲C̲W̲D̲)̲
3.3.2.3.2.1
C̲W̲D̲ ̲S̲u̲m̲m̲a̲r̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The CWD submodule performs the following functions:
1) Receive and process SWD…0f…C…0e… Status Report from collocated
N/M Watch Dog (SWD…0f…C…0e…).
2) Generate and forward CWD Status ̲Reports to collocated
SWD…0f…C…0e….
3) Forward command & responses to local SCC supervisor,
if so commanded by SWD…0f…C…0e….
4) Maintain the local SCC Operational Mode (CIP Operational
Mode).
5) Provide the remote SCC and NICS TARE Link Status
to the SCC supervisor.
6) Validate and handle commands and responses from
the SCC supervisor to control SCC Operational Mode.
7) Run the CIP to collocated SIP control link (Keep
Alive Messages).
An overview of the CWD environment is depicted in Figure
3.3.2.3.2.1-1.
The CWD is invoked when:
1) An AMOS message is received from the CIP Protocol
Machine (CPM)
2) A message is enqueued in the IC queue by NSC
3) A Timer Interrupt is received (AMOS answer).
1) AMOS message containing SWD…0f…C…0e… Status Report
2) AMOS message with CIP Opertional Mode change command
3) Storage and retrieval of CIP control data to be
piggybacked in Keep Alive Message
4) SCC Supervisor commands/responses
5) CWD Responses/Command to 4) above and remote SCC
status updates
6) Enqueue Keep Alive Message for transmission
7) Timer Interrupt (AMOS answer)
Figure 3.3.2.3.2.1-1…01…CWD Interface Overview
The CWD is implemented as one CR80 process and a program
module, which consists of the following procedures:
1) CWD Event Distribution (CWDED)
2) CWD Command & Status Processing (CWDC&SP)
3) CWD Timer (CWDTIM)
4) Send CIP/SIP…0f…C…0e… Keep Alive Message (SCSKAM)
5) Transmit NSC-report (XNSCREP)
The flow of control between these CWD procedures is
illustrated in Figure 3.3.2.3.2.1-2 overleaf.
A visual table of contents is provided in Figure 3.3.2.3.2.1-3.
Figure 3.3.2.3.2.1-2
CWD Procedure Calls
Figure 3.3.2.3.2.1-3…01…CWD Visual Table of Contents
3.3.2.3.2.2 C̲W̲D̲ ̲D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
3.3.2.3.2.2.1 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲W̲D̲ ̲E̲v̲e̲n̲t̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲ ̲(̲C̲W̲D̲E̲D̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
CWD Event Distribution is invoked, when an
external event is encountered by the CWD process,
i.e.:
o AMOS message
o AMOS Signal when an element is enqueued
in IC or CPM indicates change in N/T…0f…C…0e… status
change
o Timer Interrupt (AMOS answer).
The event is decoded and validated and if not
recognized by "CWDED" an error is reported.
Events recognized by CWDED are:
i) SWD…0f…C…0e… Status Report delivered by CMP
ii) NICS-TARE Link Status Reports
iii)SCC Supervisor Mode Control
Commands/Responses
iv) Timer Interrupt to run the CWD Timer.
SWD…0f…C…0e… Status Reports and SCC Supervisor Mode
Control commands/responses are for inbound
CWD processing, while NICS-TARE Link Control
Commands are forwarded to the CIP Protocol
Machine.
NICS TARE Link Status Reports are intended
for both internal and external use. The N/T…0f…C…0e…
status is retrieved from the report and mailed
in the "SIP…0f…C…0e… Mailbox" to be forwarded to the
SIP…0f…C…0e… Watch Dog in the next SIP…0f…C…0e… Keep Alive
Message. After that the report is delivered
to the NSC subsystem in the CMQ.
1) Timer Interrupt
2) a) SWD…0f…C…0e… Status Reports
b) SCC Supervisor Mode Control Commands/Responses
3) NICS-TARE Link Control Commands
4) NICS-TARE Link Status Report
Figure 3.3.2.3.2.2.1-1…01…CWD Event Distribution
B. P̲r̲o̲g̲r̲a̲m̲ ̲C̲W̲D̲E̲D̲:̲
REPEAT
"WAIT EVENT (EVENT)
CASE OF EVENT (1,2,3,4)
1. 'AMOS Signal'
REPEAT UNTIL IC Queue Empty
"DEQUEUE" (NSC CMD, IC Queue)
IF (SCC Mode Control CMD)
THEN
CALL "CWDC&SP" (NSC CMD)
ELSE
REPORT-ERROR (Unknown signal)
END IF
END REPEAT
CALL "XNSCREP" (NK report)
CALL "SCSKAM"
2. 'AMOS Message
IF (SWD…0f…C…0e… Status Report)
THEN
CALL "CWDC&SP" (SWD…0f…C…0e… Status Report
ELSE
REPORT-ERROR (unknown message)
END IF
3. 'Timer Interrupt'
CALL "CWDTIM"
4. 'ELSE'
REPORT ERROR (Unknown Event)
END CASE
END REPEAT
3.3.2.3.2.2.2
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲W̲D̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲&̲ ̲S̲t̲a̲t̲u̲s̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲C̲W̲D̲C̲&̲S̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure CWDC&SP is invoked when:
o CWDED has encountered a supervisor mode control
command
o CWD Timer has detected Remote Supervisor Response
Timeout
o A SWD…0f…C…0e… Status Report is received from CPM
o A Pseudo SWD…0f…C…0e… State Report is generated by CWD
Timer upon SIP…0f…C…0e… Keep Alive Message Timeout (ref.3.3.2.3.2.2.3).
Mode control commands are validated by the CWD and
may result in the fact that a request or response has
to be forwarded to the SCC Watch Dog or Remote Supervisor.
This will be enclosed in a CWD…0f…C…0e… State Message piggybacked
in a Keep Alive Message to the collocated SWD…0f…C…0e….
Response timeouts, on the other hand, will require
that a pending request to the remote supervisor is
cancelled.
SWD…0f…C…0e… State Reports (real and pseudo) contain Remote
SCC…0f…R…0e… and NICS-TARE ̲Link Status, which must be provided
to the local supervisor, if any changes have occured.
SWD…0f…C…0e… State Reports may in addition hold commands, requests
and responses from the SCC Watch Dog on the remote
supervisor, and may imply that the SCC Operational
Mode is changed. The supervisor must be aware of that.
The main part of the CWDC&SP procedure design is based
on two state event tables with assigned action procedures
for processing of external events (SWD…0f…C…0e… Status Reports)
and internal events (Operator Commmands),
respectively.
i) CWDSP/SWDSM ̲State/Event Table (CSSET):
Where the calculation of the new CWD State Parameter
(ref. A2) and selection of the processing to be
performed are determined by:
Current State = CWDSP
and
Current Event = SWDSM
ii) SWDSP/OPCMD State/Event Table (COSET):
The action to be executed and the new CWD State
Parameters are determined by:
Current State = CWDSP
and
Current Event = Operator Command
or
Response Timeout
The specific definitions of COSET and CSSET are provided
in Section B.1.3 and 1.4, respectively.
SWDSM and OPCMD's are defined in A3 and A4.
A1. C̲I̲P̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲M̲o̲d̲e̲ ̲ ̲(̲C̲I̲P̲O̲P̲M̲)̲
"CIP Operational Mode" is a parameter maintained by
the CIP Watch Dog, and defining the current operational
mode of the local SCC, i.e:
O: Off-line,
S: Stand-by,
A: Active.
The CIPOPM state transitions are controlled by either
the SCC Watch Dog as a whole, the local SCC supervisor,
or as mutually agreed.
A summary description of CIPOPM state transitions are
provided in Figure 3.3.2.3.2.2.2-1.
CIPOPM controls the SCC fuctions served/enabled by
CWD & CPM and shown in Table 3.3.2.3.2.2.2-1.
--------------------------------------------------------
SCC Functions Enabled ̲ ̲ ̲ ̲ ̲ ̲S̲C̲C̲ ̲M̲o̲d̲e̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
by CWD/CPM O S A
----------------------------------------------------
Network Supervision No Yes Yes
Network Control No No Yes
Message Service No No Yes
--------------------------------------------------------
Table 3.3.2.3.2.2.2-1…01…Service/SCC Mode
1) The SCC is bootloaded
2) The SCC supervisor goes stand-by
3) SCC Watch Dog has forwarded a request to go active
that is accepted by the SCC supervisor
4) A SCC supervisor requests to go stand-by has been
approved, or "System Control Center" failure forces
the SCC to go stand-by.
5) The SCC supervisor goes off-line
6&7) Unrecoverable error has occurred.
Figure 3.3.2.3.2.2.2-1…01…CIPOPM State Transitions
A2. C̲W̲D̲ ̲S̲t̲a̲t̲e̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲(̲C̲W̲D̲S̲P̲)̲
The "CWD State Parameter" is an extension of the CIP
Operational Mode parameter to include the intermediate
state in a transition from one stationary state to
another.
State transitions from stand-by to active and vice
versa has to be authorized by the SCC Watch Dog and/or
the SCC supervisor and cannot be immediately granted.
The CWD State Parameter is the vehicle for handshaking
between the SCC supervisor and the SCC Watch Dog, i.e.
a CWD State is an encoding of:
o CIP Operational Mode,
o SCC Watch Dog Commands & Responses,
o SCC Supervisor Requests & Responses.
The CWD States are defined in Table 3.3.2.3.2.2.2-2,
and are grouped into " State Group" in accordance to
CIP Operational mode, i.e.:
O: Off-line State Group
S: Stand-by State Group
A: Active State Group.
In addition, a classification of CWD States as being
"Stationary" (ST) or "Transition" (TR)
states is made.
A state is "ST" if a State Group Transition can be
autonomously controlled by the local SCC supervisor
(or local Watch Dog CWD).
In "TR" states, a State Group Transition may be forced
by the SCC Watch Dog.
------------------------------------------------------
CWD STATE Mnemonic State State
Group Class
------------------------------------------------------
Undefined U O ST
Off-line O O ST
Off-line Transmission Notice OT S ST
Stand-by S S ST
Stand-by Steady ST S ST
Transition Stand-by to Active TSA S ST
Active Attempt AT S TR
Active A A ST
Transition Active to Stand-by TAS A TR
Active Return AS A TR
Response Timeout RT A TR
--------------------------------------------------------
Table 3.3.2.3.2.2.2-2…01…CWD States
A detailed description of each CWD state is provided
in Table 3.3.2.3.2.2.2-3 and is related to all CWD
State Transitions that may take place as shown in Figure
3.3.2.3.2.2.2-2.
Figure 3.3.2.3.2.2.2-2…01…CWD State Transition
--------------------------------------------------------
CWD Description
State
--------------------------------------------------------
U State "U" is an element in the off-line State-Group
and is the non-operational state.
TE: State "U" is entered when an unrecoverable
errror is detected (H/W or S/W) and the
SCC stops operation.
--------------------------------------------------------
O This is the operational state in the off-line
State Group and the entry to the off-line State
̲Group, controlled by the supervisor.
State "O" is entered when:
T3: The transition to off-line has been taken
into account by SWD or the SWD acknowledgement
has timed out.
--------------------------------------------------------
OT State "OT" is an element in the stand-by State
Group and is the gate to the off-line State
Group. It signals to SWD…0f…C…0e… (or rather the remote
SCC) that the supervisor intends to switch
the SCC off-line.
State "OT" is entered when:
T2: The supervisor enters the command "Go off-line"
--------------------------------------------------------
Table 3.3.2.3.2.2.2-3…01…CWD State Description
--------------------------------------------------------
CWD Description
State
--------------------------------------------------------
S This is the only stationary state in the stand-by
State Group. No commands/responses are in progress/pending
to/from SWD…0f…C…0e… Supervisor.
State "S" is entered when:
T0: The SCC is bootloaded.
T1: The supervisor enters the command "Go
Stand-by" while CIP is off-line.
T6: A refusal to go active has been taken
into account by SWD…0f…C…0e….
T9: An acceptance to go active has been cancelled
by SWD…0f…C…0e….
T15: A request to return to active has been
refused by SWD…0f…C…0e….
T16: Request to go stand-by has been approvedby
SWD…0f…C…0e….
T17: Ref. to T15.
TU: SWD…0f…C…0e… has failed to answer, before timing-out.
--------------------------------------------------------
Table 3.3.2.3.2.2.2-3 (cont.'d)
--------------------------------------------------------
CWD Description
State
--------------------------------------------------------
ST This is a state in the stand-by State Group
and signals a refusal of request from SWD…0f…C…0e…
to go active.
State "ST" is entered when:
T5: The supervisor responds to a "Go Active"
request with a "Go Stand by" command.
--------------------------------------------------------
TSA This is a state in the stand-by State Group
and signifies that a request to "Go Active"
is in progress.
State "TSA" is entered when:
T4: A "Go Active" request from SWD…0f…C…0e… is encountered.
--------------------------------------------------------
AT This is a state in the stand-by as well as
the NS Transition State Group and signals to
SWD…0f…C…0e… that the operator has accepted a "Go Active"
request. State "AT" is the gate from the stand-by
State Group to the Active State Group.
State "AT" is entered when:
T7: A pending "Go Active" request is accepted
by the supervisor by means of a"Go Active"
command.
--------------------------------------------------------
A State "A" is the only stationary state in the
Active State Group. No commands/responses are
in progress/pending to/from SWD…0f…C…0e… Supervisor.
State "A" is entered when:
T8: An attempt to go from stand-by to active
operational mode has been approved by
SWD…0f…C…0e…
T12: A return to active, upon timeout of an
outstanding request, is requested by SWD…0f…C…0e….
--------------------------------------------------------
Table 3.3.2.3.2.2.2-3 (cont.'d)
--------------------------------------------------------
CWD Description
State
--------------------------------------------------------
A T14: A request to remain active, even though
a transition to stand-by has been intiated,
is accepted by SWD…0f…C…0e….
--------------------------------------------------------
TAS This state is a state in the active State
Group. It is the only "smooth" gate to
the stand-by State Group and signals a
request to the remote SCC to go active.
State "TAS" is entered when:
T10: The active SCC supervisor requests to
"Go Stand-by" by means of the command
"Go stand-by".
--------------------------------------------------------
AR State "AR" is a state in the active State
Group. It signals that the supervisor
has regretted to go stand-by and is an
attempt to return to state "A", which
requires approval by SWD…0f…C…0e….
State "AR" is entered when:
T13: The supervisor enters the command "Go
Active" in an attempt to cancel a prior
"Go Stand-by" command.
RT This state is an element in the active
State Group and signals a response timeout
from the remote SCC supervisor, who was
requested to go active.
--------------------------------------------------------
RT Whether the active SCC can remain state
"A" has to be approved by SWD…0f…C…0e….
State "RT" is entered when:
T11: Responce Timeout is encountered to a "Go
Stand-by" command entered by the supervisor.
--------------------------------------------------------
Table 3.3.2.3.2.2.2-3 (cont.'d)
A3. Inbound SWD…0f…C…0e…-Status-Report-Decoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The SWD…0f…C…0e… Status Report consists of three parameters:
o Remote SCC Operational Status (SCCOPS…0f…R…0e…)
o Remote NICS-TARE Link Status (N/T…0f…R…0e…)
o SWD…0f…C…0e… State Message (SWDSM).
The SCCOPS…0f…R…0e… and N/T…0f…R…0e… are forwarded to the local supervisor
(NSC), if a status change is observed, but is only
of informatory nature.
The SWD…0f…C…0e… State Message, on the other hand, contains
all commands and responses from the SCC Watch Dog or
Remote Supervisor.
SWDSM is an encoding of :
o SIP…0f…C…0e… Operational Mode
o Remote SCC…0f…C…0e… Supervisor Requests & Responses
o SCC Watch Dog Commands & Responses & Requests.
SWDSM is actually a transformation of the SWD State
Parameter as defined in section 3.3.2.3.1.2.2-A6.
The decoding of the SWD…0f…C…0e… State Message is defined in
table 3.3.2.3.2.2.2-4.
-------------------------
SWD…0f…C…0e… State Message Mnemonic
-------------------------
OA S TSA A
AD
--------------------------------------------------------
SIP…0f…C…0e… Operational Mode S S S A
A
--------------------------------------------------------
SCC…0f…R…0e… Supervisor Request
& Responses - - RQ1 -
RP1
--------------------------------------------------------
SCC Watch Dog Requests &
Commands & Responses RP3 CMD1 RQ1 -
RP2
--------------------------------------------------------
Active SCC…0f…R…0e… supervisor or SCC Watch Dog Request:
RQ1: Request to local supervisor to go active
Stand-by SCC…0f…R…0e… Supervisor Response:
RP1: Go active declined
SCC Watch Dog Commands & Responses:
CMD1: Go stand-by Command (mandatory)
RP2: Switchover impossible
RP3: Off-line authorized
Table 3.3.2.3.2.2.2-4…01…SWDSM Decoding
A4. S̲C̲C̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The SCC supervisor is provided with three commands
to "control" the operational mode of the SCC:
M̲n̲e̲m̲o̲n̲i̲c̲ C̲o̲m̲m̲a̲n̲d̲
GO Go Off-line
GS Go Stand-by
GA Go Active
For the active supervisor it is rather a "request"
than a command that he may issue, since an active supervisor
can n̲e̲v̲e̲r̲ issue commands to the SCC Watch Dog.
All issued commands have to be approved by the SCC
Watch Dog before they are executed.
The use of these commands are resticted by the current
SCC Operational Mode, as well as the functions performed
are SCC Mode dependant.
The CIP Watch Dog Interpretation & Validation of these
commands are defined in Table 3.3.2.3.2-2.2-5.
When the CWD…0f…C…0e… has validated and forwarded a request
from an active SCC supervisor, in some cases a timer
is started. If no response is encountered within a
predefined time limit (response timeout), the request
is cancelled and the supervisor notified (ref. 3.3.2.3.2.2.3).
Table 3.3.2.3.2.2.2-5…01…Command Validation & Interpretation
A5. Outbound CWD…0f…C…0e…-Status-Report Encoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The Status Report sent from CWD to the collocated SIP
Watch Dog (SWD…0f…C…0e…) contains two parameters:
o Local NICS-TARE Link Status (N/T…0f…C…0e…),
o CWD to SWD…0f…C…0e… State Message.
The N/T…0f…C…0e… as retrieved from NICS-TARE Status Reports
received via the CIP Protocol Machine, and as intended
for the remote SCC supervisor.
The CWD to SWD…0f…C…0e… State Message is generated from the
CWD State Parameter and contains CIP Operational Status
and the SCC Supervisor Requests and Responses to the
SCC Watch Dog/Remote SCC Supervisor.
The CWD State Parameters to CWD to SWD…0f…C…0e… State Message
conversion is defined in Table 3.3.2.3.2.2.2-6.
