top - download
⟦15654d75a⟧ Wang Wps File
Length: 49696 (0xc220)
Types: Wang Wps File
Notes: CPS/SRS/004
Names: »1249A «
Derivation
└─⟦0f7ba544d⟧ Bits:30006063 8" Wang WCS floppy, CR 0095A
└─ ⟦this⟧ »1249A «
WangText
B A…0b…A…0e…A…02…A…07…@…0a…@…01…@…07…?…0a…?…0b…?…0c…?…0d…?…00…?…01…?…02…>…08…>…0e…>…86…1
…02…
…02…
…02…
…02…CPS/SRS/004
…02…SRA/811123…02……02…#
CAMPS
H/W M&D
REQUIREMENT
SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL................................... 5
1.1 INTRODUCTION.......................... 5
1.2 APPLICABLE DOCUMENTS.................. 6
1.3 LIST OF ABBREVIATIONS................. 6
2 DOCUMENT SCOPE AND OUTLINE................ 8
3 ERROR IDENTIFICATION...................... 9
3.1 MAINTENANCE STRATEGY.................. 9
3.2 THE TDX TRANSFERS..................... 14
3.3 THE CHANNEL UNIT TRANSFERS............ 20
3.4 THE ACTIVE PU, INTERNAL TRANSFERS..... 25
3.5 THE STAND-BY PU....................... 29
3.6 THE WATCHDOG PROCESSOR UNIT........... 29
4 OFF LINE M&D.............................. 31
4.1 INTRODUCTION.......................... 31
4.2 OBJECTIVE............................. 31
4.3 BUILT-IN TESTS........................ 31
4.4 GENERAL OFF LINE M&D REQUIREMENTS..... 32
4.4.1 Module level...................... 32
4.4.1.1 CPU/CACHE..................... 32
4.4.1.2 MAP/MIA....................... 33
4.4.1.3 RAM........................... 33
4.4.1.4 Disk Ctrl./DCA/Disk........... 34
4.4.1.5 Floppy disk ctrl./
SFA/Floppy Disk............... 34
4.4.1.6 LTU........................... 35
4.4.1.7 TDX........................... 36
4.4.2 System level, link test........... 37
4.4.3 Test kinds........................ 37
4.4.3.1 Module level.................. 37
4.4.3.2 System level.................. 38
4.4.4 User interface.................... 39
5 ON LINE DIAGNOSTICS....................... 40
5.1 ERROR TYPES/REPORTING................. 40
5.2 TDX DATA TRANSFER VERIFICATION........ 42
5.3 TDX ERRORSOURCE IDENTIFICATION........ 45
5.4 TDX STATISTICS........................ 47
5.5 TDX CTRL. SCAN DIAGNOSTIC............. 47
5.6 I/O DATA TRANSFER VERIFICATION........ 48
5.7 I/O ERRORSOURCE IDENTIFICATION........ 49
5.8 I/O STATISTICS........................ 51
5.9 CPU DIAGNOSTICS....................... 52
5.10 CACHE ERROR MONITORING............... 52
5.11 STAND-BY PU.......................... 53
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The overall aim of the CAMPS maintenance strategy is
to meet the system requirements regarding Error handling
as stated in the SRS para. 3.2.8.3 :
a) Error handling shall fulfil the requirements
for:
1) Equipment availability/reliability
2) Integrity of operation(ref. b below)
b) Integrity of operation:
The probability that a message or internal
transaction is:
1) lost wholly or in part, or
2) misdirected, or
3) corrupted
as a result of equipment error shall be less
than 1 in 10 exp. 7.
The requirement regarding system availability implies,
for the maintenance strategy, that a predicted MTTR
value of 1 hour can be realized for all hardware modules.
The requirement regarding integrity of operation implies
that necessary tools are available for:
a) timely detection of an error
b) corrective action(error isolation)
c) error reporting
As an approach to define the necessary tools for securing
integrity of operation an analysis of error and errordetection
mechanisms has been made. The analysis has been structured
in accordance with functionally determined paths through
the hardware.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
CAMPS SYSTEM REQUIREMENT SPECIFICATION
CPS/210/SYS/0001
INTERN MEDDELELSE NO. 107
FH/810527
TDX CTRL. PRODUCT SPECIFICATION
CSD-MIC/210/PSP/0010
CAMPS SYSTEM DESIGN SPECIFICATION
CPS/SDS/001
CR80D FIRMWARE DESCRIPTION
JH[/810504
CAMPS MAINTENANCE PLAN
CPS/PLN/006
1.3 L̲I̲S̲T̲ ̲O̲F̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
BSM-X TDX-Bus Switching & Monitoring module
CAMPS Computer Aided Message Processing System
CCA Configuration Control Adapter
CCB Configuration Control Bus
CCBA Configuration Control Bus Adapter
CPU Central Processing Unit
CU Channel Unit
DAMOS CR80D Advanced Multiprocessor Operating
System
DCA Disk Controller Adapter
LIA-N Line Interface Adapter (Non switching)
LTU Line Termination Unit
LTUX-S TDX-Line Termination Unit-Single
MAP Memory Mapping unit
MIA MAP Interface Adapter
OC Operator Console(at the Operator
position)
OMDT Optical Mux/Demux Transceiver
PU Processor Unit
RAM Random Access Memory
SFA Standard Floppy disk Adapter
STI Supra-TDX bus Interface
TDX Telecommunication Data Exchange
TIA TDX Interface Adapter
WCA Watchdog Controller Adapter
WDP Watchdog Processor Unit
2̲ ̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲ ̲S̲C̲O̲P̲E̲ ̲A̲N̲D̲ ̲O̲U̲T̲L̲I̲N̲E̲
The scope of this document is to define a set of requirements
to on-line as well as off-line diagnostic tools.
The on-line diagnostic tools will provide a supplement
to the errordetecting mechanisms implemented in the
CR80D hardware and supported by the CR80D Advanced
Multiprocessor Operating system (DAMOS).
In this context on-line diagnostics are application
programs executed in the active as well as the stand-by
PU. DAMOS is not included.
Off-line M&D are programs activated to identify errors
in an off-lined module/unit. Some off-line M&D programs
(i.e. Disk test, Floppy disk test, LTU test and TDX
test) are executed in the active PU using DAMOS device
handlers, others (i.e. CPU test, RAM test and MAP/MIA
test) are executed in an off-lined PU.
The remaining part of this document is divided into
3 chapters.
Chapter 3 deals with identification of possible errorsources:
The on-line CAMPS system is broken down into 5
scenarios. Each scenario is analyzed for potential
errorsources/possibilities. Each identified errorsource
is presented in a table and marked as either …08…detected…08…
or …08…not detected…08…. …08…Detected…08… in this context means
detected by CR80D hardware and DAMOS. Each errorsource
marked as …08…not detected…08… is given a reference to
a relevant section within chapter 5. The referenced
section describes an on-line diagnostic module
designed to detect this errortype.
Chapter 4 specifies off-line M&D requirements. These
are grouped in three levels:
1. Built-in tests, BIT-list of modules that should
have BIT.
2. Off-line M&D requirements, Module level
3. Off-line M&D requirements, System level
Finally chapter 5 specifies requirements to:
1. Errortype isolation
2. Errorreport contents
3. On-line diagnostic modules.
3̲ ̲E̲R̲R̲O̲R̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
3.1 M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲ ̲S̲T̲R̲A̲T̲E̲G̲Y̲
The objective of the corrective maintenance on-site
is to locate and isolate an error to reside within
one module. Where necessary an off-line M&D module
will be employed to verify that the error is isolated.
Then the defective module will be replaced. A new test
will be performed to verify that the error has disappeared
and then the system is brought back to normal operation.
The defective module is returned to depot for repair
Fig. 3.1-1 shows a typical repair sequence.
Fig. 3.1-2 shows a flowchart of the general troubleshooting
procedures.
In order to fulfil the overall availability requirements
it is essential immediately to detect an error in the
on-line system and provide a detailed error description
at the Operator position Console(OC). Simultaneously
the CAMPS software must be able to decide whether the
error is of a nature that requires automatic reconfiguration,
eg. switch-over, or not.
To clarify the on-line error detection described in
this chapter, the CAMPS main site equipment is broken
down into logical separate units (scenarios). This
is the first step in the error isolation process. The
scenarios are described in secs. 3.2 to 3.6.
Fig. 3.1-3 shows the CAMPS system scenario breakdown.
Through the scenarios a further separation is performed.
The scenarios will therefore contribute to the identification
of errorsources.
The purpose of the on-line error detection and subsequent
print-outs (reporting) is to establish a solid entry
point into a troubleshooting tree, which will be part
of the CAMPS maintenance documentation.
Fig. 3.1-1
T̲y̲p̲i̲c̲a̲l̲ ̲r̲e̲p̲a̲i̲r̲ ̲s̲e̲q̲u̲e̲n̲c̲e̲
Fig. 3.1-2
T̲r̲o̲u̲b̲l̲e̲s̲h̲o̲o̲t̲i̲n̲g̲ ̲f̲l̲o̲w̲c̲h̲a̲r̲t̲
Fig. 3.1-3
C̲A̲M̲P̲S̲ ̲s̲y̲s̲t̲e̲m̲ ̲s̲c̲e̲n̲a̲r̲i̲o̲ ̲b̲r̲e̲a̲k̲
̲d̲o̲w̲n̲
3.2 T̲H̲E̲ ̲T̲D̲X̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲S̲
A detailed explanation of the TDX is given in CPS/SDS/001
(sec 5.2).
To ease the understanding of errorsource identification
fig. 3.2-1 shows the lay-out of the TDX frame. The
frame is the smallest information element transferred
across the TDX bus.
Hardware elements involved in the TDX is shown in fig.
3.2-2 and identified potential errorsources are listed
in fig 3.2-3 (3 sheets).
Fig. 3.2-3 identifies three kinds of …08…Detection Status…08….
These are explained as:
A: Equivocally detected.
B: Unequivocally detected
C: Not detected.
Fig. 3.2-1
T̲D̲X̲ ̲b̲u̲s̲ ̲f̲r̲a̲m̲e̲ ̲f̲o̲r̲m̲a̲t̲
Fig. 3.2-2
T̲h̲e̲ ̲T̲D̲X̲ ̲s̲c̲e̲n̲a̲r̲i̲o̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A. T̲I̲A̲/̲T̲D̲X̲ ̲b̲u̲s̲
(TIA transmitter)
A.1 Frame not trans- x Packet Pro-
mitted tocol.
A.2 F̲r̲a̲m̲e̲ ̲e̲r̲r̲o̲r̲ Fig.
A.2.A Flag byte x Packet Pro- 3.2-1
tocol.
A.2.B Data Type x do.
A.2.C Host/Mode x do. A LTUX-S
will
reject
a fra-
me
if
the
Host
/Mode
field
differs
from
[EH
and
[FH.
A.2.D D̲e̲v̲i̲c̲e̲ ̲n̲o̲
-.1 TIA-TIA x Packet Pro-
tocol.
-.2 TIA-TDX Ctrl x do.
-.3 T̲I̲A̲-̲L̲T̲U̲X̲-̲S̲
-.3a Not exist- x do.
ing LTUX-S
-.3b Single fra- x do.
me packet
to exist-
ing LTUX-S
-3.c Multi fra- x do.
me packet
to exist-
ing LTUX-S
A.2.E Communica- x do.
tion byte
A.2.F Sequence no. x do.
A.2.G B̲y̲t̲e̲ ̲C̲o̲u̲n̲t̲ sec.
5.2
-.1 Excessive x
-
-.2 Incorrect x
-
A.2.H Data Field x
-
A.2.I CRC x Packet Pro-
tocol.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.2-3 (sheet 1 of 3)
T̲D̲X̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
B. T̲D̲X̲ ̲b̲u̲s̲/̲T̲I̲A̲
(TIA receiver)
B.1 Receive error x Packet Pro-
tocol
B.2 Transfer error x x x Detected/Not
(TIA internal) detected
sta-
tus
see
note
below.
C. T̲D̲X̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
C.1 Receive error x Packet pro-
tocol
C.2 T̲r̲a̲n̲s̲m̲i̲t̲ ̲e̲r̲r̲o̲r̲
C.2.A No trans- x do.
mission
C.2.B Frame error Identical
to
A.2
except
for
A.2.D.2
which
doesn…08…t
apply.
D. L̲T̲U̲X̲-̲S̲/̲T̲D̲X̲ ̲B̲u̲s̲
(LTUX-S transmits)
D.1 Frame not x Packet pro- Indirectly
by
transmitted tocol the
user.
D.2 F̲r̲a̲m̲e̲ ̲e̲r̲r̲o̲r̲
D.2.A Flag byte x do.
D.2.B Data type x do. If
the
LOG
li-
ne
is
not
open
nothing
hap-
pens.
D.2.C Host/Mode x do. Strategic
TIA
add.
selection
D.2.D Device no. x do.
D.2.E Communica- x do.
tion byte
D.2.F Sequence no. x do.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Note: The detected/not detected status depends upon
which of the framebytes that were erroneously transferred.
Fig. 3.2-3 (sheet 2 of 3)
T̲D̲X̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
D.2.G B̲y̲t̲e̲ ̲C̲o̲u̲n̲t̲ sec.
-.1 Excessive x 5.2
-.2 Incorrect x
-
D.2.H Data field x
-
D.2.I CRC x Packet Pro-
tocol
E. T̲D̲X̲ ̲B̲u̲s̲/̲L̲T̲U̲X̲-̲S̲
(LTUX-S receive)
E.1 Receive error x Packet Pro-
tocol
E.2 Transfer error x x x Refer
to
note
on
previous
page.
F. L̲T̲U̲X̲-̲S̲/̲T̲e̲r̲m̲i̲n̲a̲l̲
F.1 Data error x Detected by This
is
an
as-
the user sumption
F.2 Link error x sec.
5.2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.2-3 (sheet 3 of 3)
T̲D̲X̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
3.3 T̲H̲E̲ ̲C̲H̲A̲N̲N̲E̲L̲ ̲U̲N̲I̲T̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲S̲
A detailed explanation of transfers within the Channel
Unit (CU) is given in CPS/SDS/001 (secs. 5.1.3.2, 5.1.4.1.4.2
and 5.1.5.1.1).
Fig. 3.3-1 indicates hardware elements involved in
transfers between a Processor Unit (PU), the CU and
internal CU modules.
Errorsources identified within this scenario are listed
in table 3.3-2 (3 sheets).
Fig. 3.3-2 identifies three kinds of …08…Detection Status…08….
These are explained as:
A: Equivocally detected.
B: Unequivocally detected
C: Not detected.
Fig. 3.3-1
T̲h̲e̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲U̲n̲i̲t̲ ̲s̲c̲e̲n̲a̲r̲i̲o̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A. M̲A̲P̲-̲M̲I̲A̲ ̲t̲r̲a̲n̲s̲f̲e̲r̲s̲
A.1 A̲d̲d̲r̲e̲s̲s̲ ̲e̲r̲r̲o̲r̲
A.1.A Not exist- x Time-out. Errors
gene-
ing CU add. Handled by rated
in
MAP
DAMOS. prior
to
transfer.
A.1.B Not exist- x do. do.
ing I/O add.
in CU
A.1.C Not exist- x do. do.
ing memory
add. in CU
A.1.D E̲x̲i̲s̲t̲i̲n̲g̲
I̲/̲O̲ ̲a̲d̲d̲r̲e̲s̲s̲
i̲n̲ ̲C̲U̲
-.1 Add. wrong x do. I/O
addresses
Command OK. should
be
se-
lected
so
that
single
bit
er-
rors
don…08…t
cause
misadd.
-.2 Add. OK x Not
used
bits
Command in
the
com-
wrong mand
field
are
…08…don…08…t
cares…08…
A.1.E Existing x sec.
Memory 5.6
wrong loc.
A.2 D̲a̲t̲a̲ ̲e̲r̲r̲o̲r̲
A.2.A Write x Parity er-
ror detec-
ted by CIA.
Handled by
DAMOS.
A.2.B R̲e̲a̲d̲
-.1 CPU x Parity er-
ror detec-
ted by CPU.
Handled by
DAMOS.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.3-2 (sheet 1 of 3)
C̲h̲a̲n̲n̲e̲l̲ ̲U̲n̲i̲t̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A.2.B
-.2 DMA x Parity er-
ror detec-
ted by DMA
H/W. Hand-
led by DAMOS
B. M̲I̲A̲-̲C̲I̲A̲ ̲t̲r̲a̲n̲s̲f̲e̲r̲
B.1 A̲d̲d̲r̲e̲s̲s̲ ̲e̲r̲r̲o̲r̲ Errors
gene-
B.1.A Parity OK. Identical rated
in
MIA
to A.1.A-E prior
to
pa-
rity
genera-
tion
and
transfer
B.1.B Wrong pa- x Parity er-
rity ror detec-
ted by CIA.
Handled by
DAMOS.
B.2 D̲a̲t̲a̲ ̲e̲r̲r̲o̲r̲
B.2.A Write x do.
B.2.B Read x Parity er-
ror detec-
ted by MIA.
Handled by
DAMOS.
C. C̲I̲A̲-̲D̲i̲s̲k̲ ̲C̲t̲r̲l̲.̲
C.1 Address error Identical to
A.1.B-E
C.2 D̲a̲t̲a̲ ̲e̲r̲r̲o̲r̲
C.2.A Write x Parity er-
ror detec-
ted by Disk
Ctrl.
C.2.B Read x Parity er-
ror detec-
ted by CIA.
Handled by
DAMOS.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.3-2 (sheet 2 of 3)
C̲h̲a̲n̲n̲e̲l̲ ̲U̲n̲i̲t̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
D. C̲I̲A̲-̲F̲l̲o̲p̲p̲y̲ ̲C̲t̲r̲l̲.̲
D.1 Address error Identical to
A.1.B-E
D.2 D̲a̲t̲a̲ ̲e̲r̲r̲o̲r̲
D.2.A Write x Parity er-
ror detec-
ted by Flop-
py Ctrl.
D.2.B Read x Parity er-
ror detec-
ted by CIA.
Handled by
DAMOS.
E. C̲I̲A̲-̲L̲T̲U̲
E.1 Address error Identical to
A.1.B-E
E.2 D̲a̲t̲a̲ ̲e̲r̲r̲o̲r̲
E.2.A Write x Parity er-
ror detec-
ted by LTU
E.2.B Read x Parity er-
ror detec-
ted by CIA.
Handled by
DAMOS.
F. D̲i̲s̲k̲ ̲C̲t̲r̲l̲-̲D̲i̲s̲k̲ x Errorstatus
generated by
Disk Ctrl.
Handled by
DAMOS.
G. F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲k̲ ̲C̲t̲r̲l̲-̲ x Errorstatus
F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲k̲ generated by
Floppy Disk
Ctrl.Handled
by DAMOS.
H. LTU-Ext.Channels x Errorstatus This
is
an
as-
generated by sumption
LTU.Handled
by DAMOS.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.3-2 (sheet 3 of 3)
C̲h̲a̲n̲n̲e̲l̲ ̲U̲n̲i̲t̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
3.4 T̲H̲E̲ ̲A̲C̲T̲I̲V̲E̲ ̲P̲R̲O̲C̲E̲S̲S̲O̲R̲ ̲U̲N̲I̲T̲ ̲I̲N̲T̲E̲R̲N̲A̲L̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲S̲
A detailed description of internal transfers in a Processor
Unit (PU) is given in CPS/SDS/001 (sec. 5.1).
The PU hardware involved in these transfers is shown
in fig. 3.4-1, and identified errorsources are listed
in table 3.4-2 (2 sheets).
Fig. 3.4-2 identifies three kinds of …08…Detection Status…08….
These are explained as:
A: Equivocally detected.
B: Unequivocally detected
C: Not detected.
Fig. 3.4-1
T̲h̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲U̲n̲i̲t̲ ̲s̲c̲e̲n̲a̲r̲i̲o̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A. C̲P̲U̲ ̲e̲r̲r̲o̲r̲
A.1 Data processing x This
type
of sec.
error
is
only 5.9
revealed
if
an
on-line
CPU
test
is
exe-
cuted
contin-
ously.
A.2 Bus Interface x Most
errors sec.
will
halt
the 5.9
CPU
with
no
significant
bus
load.
A
few
errors
will
block
the
proces-
sor
bus
com-
pletely.
A.3 No response x Interrupts sec.
upon notifica- can
be
disab- 5.9
tion led
setting
two
bits
in
PSW.
A.4 Addressing (x) x Is only de- sec.
tected if 5.9
misadd.
leads to
access vio-
lation
A.5 CACHE errors (x) x CACHE errors Requires
an sec.
are regis- application 5.10
tered in a program
to
CACHE ERROR read
the
CA-
REGISTER. CHE
ERROR
RE-
GISTER.
B. P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲B̲u̲s̲/̲M̲B̲T̲/̲ (x) x Could be de- Off-Line
M&D sec.
C̲h̲a̲n̲n̲e̲l̲ ̲B̲u̲s̲ tected as: strategy 5.9
Parity er-
ror, Time-
out, access
violation.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.4-2 (sheet 1 of 2)
P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲U̲n̲i̲t̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
Detection
Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Detection
Errorsource A B C Mechanisms Comments Ref.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C. M̲A̲P̲ ̲e̲r̲r̲o̲r̲s̲ (x) x Could be de- Off-Line
M&D
C̲h̲a̲n̲n̲e̲l̲ ̲B̲u̲s̲ tected as: strategy
Parity er-
ror, Time-
out, access
violation.
D. R̲A̲M̲ ̲e̲r̲r̲o̲r̲s̲
D.1 Addressing (x) x (Time-out) Will
only
be sec.
detected
if 5.6
the
internally
garbled
add.
results
in
no
response.
D.2 Data error (x) x (Parity er- Some
bit
er- sec.
ror) ror
combina- 5.6
tions
will
be
detected
as
parity
errors
remaining
er-
rors
won…08…t.
E. S̲T̲I̲ ̲e̲r̲r̲o̲r̲s̲
E.1 Addressing (x) x (Access vio- sec.
lation) 5.2
E.2 Data errors (x) x (Parity er- Some
bit
er- sec.
ror) ror
combina- 5.2
tions
will
be
detected
as
parity
errors
remaining
er-
rors
won…08…t.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 3.4-2 (sheet 2 of 2)
P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲U̲n̲i̲t̲ ̲e̲r̲r̲o̲r̲s̲o̲u̲r̲c̲e̲ ̲t̲a̲b̲l̲e̲
3.5 T̲H̲E̲ ̲S̲T̲A̲N̲D̲-̲B̲Y̲ ̲P̲R̲O̲C̲E̲S̲S̲O̲R̲ ̲U̲N̲I̲T̲
Identification of errorsources within the Stand-by
PU is identical to the identification within the active
PU described in sec. 3.4.
3.6 T̲H̲E̲ ̲W̲A̲T̲C̲H̲D̲O̲G̲ ̲P̲R̲O̲C̲E̲S̲S̲O̲R̲ ̲U̲N̲I̲T̲
The Watchdog Processor Unit (WDP) function in the CAMPS
system is described in CPS/SDS/001 (sec. 5.4).
The WDP is schematically shown in fig 3.6-1 along with
Configuration Control Adapters (CCAs) and the BSM-Xs,
part of which is reserved for TDX functions and the
remaining part reserved for watchdog functions. The
CCAs and the BSM-Xs are connected to the WDP via the
Configuration Control Bus (CCB).
Three types of diagnostic tools are implemented to
supervise vital WDP functions:
1. Program execution. With regular intervals the
WDP must refresh a monostable multivibrator to
remain connected to the CCB.
2. BSM-X/CCA control set-up. Each control operation
requires 3 set-up phases to perform a command on
a CCA/BSM-X. Each set-up phase consists of a transfer
of data from the WDP to the involved CCA/BSM-X.
These data are retransferred from the CCA/BSM-X
involved to the WDP. To proceed to the next set-up
phase the WDP transferred and received data shall
match.
3. WDP - PU (active and stand-by) communication.
This communication ,performed via the Watchdog
Control Channels (WDCCs) #1 and #2, is supervised
via a protocol:
a) …08…Alive…08… messages are transmitted from both
PUs to the WDP with regular intervals.
b) The WDP transmits an …08…Alive…08… acknowledge back
to the source PU.
No additional diagnostic tools is required for the
WDP.
Fig. 3.6-1
T̲h̲e̲ ̲W̲a̲t̲c̲h̲d̲o̲g̲ ̲s̲c̲e̲n̲a̲r̲i̲o̲
4̲ ̲O̲F̲F̲-̲L̲I̲N̲E̲ ̲M̲&̲D̲
4.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
While on-line diagnostics are employed for on-line
error reporting and reconfiguration decissions, simultaneously
providing an entry point to the troubleshooting procedures,
the off-line M&D programs are employed to troubleshoot
and verify on an off-line module/system level. Even
if the on-line diagnostics provide an unequivocal status
report about a faulty module, the appropriate off-line
M&D program must be employed to verify the detected
error. Furthermore, after the module is replaced a
verification test must be performed to ensure that
the error has disappeared.
4.2 O̲B̲J̲E̲C̲T̲I̲V̲E̲
Off-line M&D will be employed when the on line diagnostics/DAMOS
has identified and reported an error.
Off-line M&D shall pin down an error to be within a
particular module.
Off-line M&D shall communicate with the operator position.
Off-line M&D shall verify that an error is removed
both after replacement of a defective module and upon
reception of new modules from a supply depot (NAMSA).
4.3 B̲U̲I̲L̲T̲-̲I̲N̲ ̲T̲E̲S̲T̲S̲ ̲(̲B̲I̲T̲)̲
The following modules must have BIT:
CPU/CACHE
MAP/MIA
STI
TIA
Disk Controller/DCA
Floppy Disk Controller
LTU
TDX Controller
LTUX-S
Watchdog Processor Unit
The efficiency of BITs must at least be so that errors
not found by the BIT must not inhibit a more extensive
off-line M&D test to be performed. Exceptions are errors
in interface drivers and receivers.
4.4 G̲E̲N̲E̲R̲A̲L̲ ̲O̲F̲F̲-̲L̲I̲N̲E̲ ̲M̲&̲D̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
4.4.1 M̲o̲d̲u̲l̲e̲ ̲l̲e̲v̲e̲l̲
An off-line M&D test program must exist for each
of the below mentioned modules/set of modules:
CPU/CACHE
MAP/MIA
RAM
Disk Controller/DCA/Disk
Floppy Disk Controller/SFA/Floppy Disk Drive
LTU
STI
TIA
TDX Controller
BSM-X
LTUX-S
The efficiency of each off-line M&D module must
be so that errors can be traced down to be within
one particular module for 90% of the errors. The
remaining errors must be identified to be within
a set of 2 modules.
4.4.1.1 C̲P̲U̲/̲C̲A̲C̲H̲E̲
The CPU/CACHE off-line M&D test program tests
proper operation of a CPU using a standard
CR80D instruction set.
Following items must be verified:
a) the CPU control logic by:
1) the special test instruction
2) verifying all possible instructions
(possibly with the exception of
a few I/O instructions).
b) mode switch by program execution in
system and user mode.
c) memory protect and page fault mechanisms.
d) single step facility.
e) the CACHE controller/memory by:
1) executing the special CACHE test
instruction.
2) checking the CACHE status registers.
3) checking performance increase (due
to CACHE) by executing programs
with low and high hitrate.
4.4.1.2 M̲A̲P̲/̲M̲I̲A̲
The MAP/MIA off-line M&D test program tests
proper operation of the MAP and MIA (MAP Interface
Adapter) modules.
Following items must be verified:
a) the MAP control logic using BIT.
b) the memory mapping function. This includes
testing the segment registers, translation
tables and memory protect/absent control.
c) the MAP DMA functions.
d) the MAP interrupt system.
e) the V24 communication part of the MAP/MIA.
4.4.1.3 R̲A̲M̲
The RAM off-line M&D test program tests proper
operation of the RAM module.
Verification must be performed by:
a) storing a checkerboard pattern in the
entire RAM area and verifying the pattern.
b) changing each bit in any location separately
keeping the remaining bits unchanged
(i.e the bit patterns #0001, #0002,
,#8000 are each stored and verified
in all locations, one location at a
time).
c) verifying the internal RAM addressing
circuitry by storing the internal address
off each RAM location in the location
followed by a verification of the presence
of all relevant address combinations.
The test is performed in blocks of
64Kwords.
d) testing the byte (upper and lower)
addressing mode by storing and reading
bytewise in all RAM locations.
e) long term stability test (refresh).
This is tested by storing a pattern
in RAM and verifying the pattern after
1 sec.
f) move multiple. The lower half of the
RAM section under test is filled with
a checker board pattern and then transferred
to the remaining portion of the RAM
using the MOVM machine instruction.
4.4.1.4 D̲i̲s̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲/̲D̲C̲A̲/̲D̲i̲s̲k̲
The Disk Controller off-line M&D test program
tests proper operation of the Disk Controller/DCA/Disk
system.
Verification must be performed as:
read, write, (format).
Handler requirements:
Transfer of on-board RAM contents to
test program.
Transfer of controller status to test
program.
Initiating controller built-in test
and returning the result to the test
program.
Disk requirements:
Some sectors on the disks must be reserved
for read and write tests
Possibly the disks should contain some
read-only sectors with testpatterns.
4.4.1.5 F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲/̲S̲F̲A̲/̲F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲k̲ ̲d̲r̲i̲v̲e̲
The Floppy Disk off-line M&D test program verifies
proper operation of the Floppy Disk Controller/SFA/Floppy
Disk drive system.
Verification must be performed as:
read, write, (format).
Handler requirements:
Transfer of on-board RAM contents to
test program.
Transfer of controller status to test
program.
Initiating controller built-in test
and returning the result to the test
program.
Disk requirements:
A special test Floppy disk must be
mounted for the test. The test disk
must contain some test patterns and
a reserved area for write tests.
4.4.1.6 L̲T̲U̲
The LTU off-line M&D test program tests proper
operation of the LTU.
Verification must be performed as:
Initiating the LTU BIT and returning the
result.
An application sending data to the LTU
which …08…loops back…08… the data for verification.
LTU requirements:
BIT
Implementation of a loop back facility
in the LTU which enables the LTU transmitter
part to …08…hand over…08… data to the receiver
part (loop back mode).
Handler requirements:
Transfer of LTU on-board RAM contents to
test program.
Transfer of LTU status registers to test
program.
Initiating LTU built-in test and returning
the result to the test program.
4.4.1.7 T̲D̲X̲
The TDX of-line M&D test program tests proper
operation of the STI, TIA, TDX bus, TDX Ctrl.,
BSM-X and LTUX-S system.
Verification shall be performed as:
a) STI, TIA, TDX Ctrl.and TDX bus are tested
by transmitting data from a CR80D application,
via the TDX system, back to it self.
b) The BSM-X and LTUX-S is tested with
the LTU-X in …08…loop back…08… mode by transmitting
data to the LTUX-S from a CR80D application
and verifying the received (looped back)
data.
Device (LTUX-S) requirements:
Implementation of a loop back facility
which enables the LTUX-S to return data
received from the CR80D application. No
data should be transferred across the V24
interface.
TDX handler requirements:
Transfer of STI on-board RAM contents to
test program.
Transfer STI and TDX Controller status
registers to test program.
Ability to start the various BITs and return
results to test program.
4.4.2 S̲y̲s̲t̲e̲m̲ ̲l̲e̲v̲e̲l̲,̲ ̲l̲i̲n̲k̲ ̲t̲e̲s̲t̲
In addition to the BIT and module level tests,
it will be necessary to employ a higher level test
to verify V24/V28 or Opto links.
The purpose of the link test is to verify proper
operation of a selectable communication link (Opto
or V24).
A text string (e.g. …08…the quick brown fox jumped
over the lazy dog…08…) is transmitted over the selected
link and proper operation is verified either by
observing the …08…print out…08… of the string on the connected
equipment (terminal/communication analyzer) or
by comparing the retransmitted string to the original
transmitted.
Retransmission shall be obtained in two ways:
a) The corresponding LTUX-S/LTU is put in
…08…loop back…08… mode (sec. 4.4.1.6 - 7).
b) The physical link is …08…broken…08… and the transmit
circuit is connected to the receive circuit
via a dummy connector or a communication
analyzer.
4.4.3 T̲e̲s̲t̲ ̲k̲i̲n̲d̲s̲
4.4.3.1 M̲o̲d̲u̲l̲e̲ ̲l̲e̲v̲e̲l̲ ̲t̲e̲s̲t̲s̲
Two selectable testmodes shall exist:
a) Standard test mode.
b) User specified test mode.
The standard tests shall perform a …08…high level…08…
test, i.e. try a group of device operations
and verify the results.
In a Disk test this could be:
c) write some testpatterns on a disk and
afterwards attempt to read and verify
the patterns.
The user specified tests shall facilitate:
d) basic device operations, e.g. reading
a single sector from a disk.
e) access to device status and mode registers.
f) memory dump from device on-board RAM.
It shall be possible to have any test, standard
as well as user specified, repeated a specified
number of times.
4.4.3.2 S̲y̲s̲t̲e̲m̲ ̲l̲e̲v̲e̲l̲ ̲t̲e̲s̲t̲
As for the module level tests 2 selectable
modes shall exist:
a) standard test mode
b) user specified test mode
When selected the standard test transmits the
text string …08…the quick brown...etc.…08… via the
selected link.
The user specified test mode enables the operator
to specify an arbitrary ASCII text string (max.
80 characters) to be transmitted across the
selected link.
Transmitted and received (looped back) text
strings shall be delivered to the selected
output media (ref. sec. 4.4.4).
It shall be possible to have any test, standard
as well as user specified, repeated a specified
number of times.
4.4.4 U̲s̲e̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
All test programs must conform to a common input command
syntax and output reporting.
Input commands shall be taken either from a terminal
(OC) or from a disk file (both possibilities must exist).
Output reporting shall be delivered either to a Disk
file or a terminal (OC) (both possibilities must exist).
If the input file or the output file is a disk file,
input commands shall be echoed to the output file,
for verification purpose.
Optionally it shall be possible to save test program
inputs and outputs in a log file.
Concerning output reporting three levels shall exist.
The difference between the levels, which are specified
prior to test activation, is only seen when the test
is performed as a repeated (n times) test:
Level 0:
No messages are output during a repeated test,
but a summary of errors which have occurred during
the repeated test, is output when it stops.
Level 1:
Error messages are output when the errors occur.
Standard test OK-messages are not output.
Level 2:
All error messages are output when the errors occur.
During the standard tests, a "TEST x.y. OK" should
be output if no error have occurred.
5̲ ̲ ̲O̲N̲ ̲L̲I̲N̲E̲ ̲D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
To fulfil the requirements to system availability and
integrity of operation, a set of on line diagnostic
modules are required as part of CAMPS system software.
The task of on line diagnostics will be to:
a) Supply adequate information about system peformance
based upon statistic information collected during
runtime.
b) Pin down error causes to be within modules or functional
groups (e.g. CPU + MAP/MIA, STI + TIA + TDX ctrl.
+ TDX bus)
On line diagnostics are divided in two types:
1) On line diagnostics executed continously (low priority
routines)
2) On line diagnostics activated only when equivocal
errortypes are identified (e.g. TDX error).
5.1 E̲r̲r̲o̲r̲ ̲t̲y̲p̲e̲s̲/̲r̲e̲p̲o̲r̲t̲i̲n̲g̲
Errors detected on line by DAMOS and/or on line diagnostics
shall be identified as one of the following types:
TYPE ERROR
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 Single terminal/channel
2 LTU
3 LTUX-S
4 BSM-X
5 TDX bus (TDX Ctrl., bus, TIA)
6 PU (incl. STI, I/O bus) implying process retire
7 PU (" " " " ) implying shut down
8 Mirrored Disk (incl. Disk Ctrl. Disk drive)
9 Mirrored Disk Volume
10 Single Disk (incl. Disk Ctrl., Disk drive)
11 Single Disk Volume
12 Floppy Disk (incl. Ctrl., Drive)
13 Stand by PU via the TDX bus checkpointing
T̲A̲B̲L̲E̲ ̲5̲.̲1̲-̲1̲
The isolation may be direct as detected by DAMOS or
indirect as a combination of DAMOS and applied on line
diagnostic reports.
Having identified an error as one of the types in table
5.1-1 DAMOS and/or the applied on line diagnostic must
prepare a detailed errorreport for CAMPS System, Status
& Control (SS & C).
The errorreport shall include the following information:
- time of day
- identification of device/program detecting the
error
- detailed device status e.g.:
- erroneous device
- detailed device status
- identification of current CPU and PU
- type of failing operation (read, write, seek)
- errortype (table 5.1-1)
- Device positionary information (head, cyl., sector)
5.2 T̲D̲X̲ ̲d̲a̲t̲a̲ ̲t̲r̲a̲n̲s̲f̲e̲r̲ ̲v̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Transfer of packets across the TDX bus (fig. 5.2-1
between TDX frontends (i.e. TIAs, LUTX-S front ends)
is verified by a HDLC protocol. But as indicated in
table 3.1-3 (3.1-3.A.2.G-H) garbling of data and/or
bytecount prior to CRC generation isn't detected.
The TDX data transfer shall be verified based on a
checksum placed as the last data in the buffer to be
transferred. The checksum is generated by the application
process creating the buffer. The receiving application
process verifies data on a checksum generate and verify
basis.
The receiving application process must return information
to the data transmitting application about buffer transfer
status.
A correct received databuffer releases a data buffer
acknowledge (DACK) while a garbled set of data releases
a negative data buffer acknowledge (NDAK).
If an application receives a NDAK upon a data transfer,
the transfer shall be retried up to three times, after
which the transmitting application "gives up" if the
response is a NDAK again.
T̲D̲X̲ ̲D̲A̲T̲A̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲
FIG. 5.2-1
If three retries have been performed without success
the SS&C module must be informed. This is done by the
involved application process in the active PU.
Error reporting causes:
1) reception of 3 successive NDAKs
2) transmission of 3 successive NDAKs
The errorreporting causes the SS&C to activate an on
line diagnostic module (ref. sec. 5.3) the task of
which will be to isolate the error source (i.e. TDX
bus, LTUX-S or stand by PU). In this context the TDX
bus means TDX bus, TIAs and TDX ctrl.
The DACK/NDAK responses could be further differentiated
for LTUX-S applications. The V24 communication driver/receiver
module could perform a V24 control signal monitor/supervision
function. Thus a DACK response would mean:
1) databuffer correct received via TDX
2) data correct transferred to connected terminal
A NDAK response would mean:
1) either databuffer checksum invalid
2) or V24 controlsignals indicate link error
Possibly a parameter to identify 1 or 2 should be attached
to the NDAK to ease error source identification (NDAK(1)
or NDAK(2)).
5.3 T̲D̲X̲ ̲E̲R̲R̲O̲R̲S̲O̲U̲R̲C̲E̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
When DAMOS or application processes in the active PU
detects errors in the TDX system, these are reported
to the SS&C module. The task of the SS&C is now to
get a more differentiated erroridentification. The
result of this could lead to either a TDX reconfiguration
or to a PU switch decided by the SS&C .
The first task of the SS&C is to verify the TDX bus
(TDX bus, TIA and TDX ctrl.) by sending one or more
frames to itself. The result of this test decides further
activity.
If the test fails then the SS&C will reconfigurate
the TDX by switching to the stand-by TDX. Before doing
so the SS&C module should transmit the test frame(s)
to itself via the stand-by TDX to verify it.
If the test was accepted further SS&C action will depend
upon which device that was involved in the erroneous
communication:
A) The stand-by PUs TIA.
Action: The SS&C reports a stand by PU TDX
fault to the OC (off line M & D applied
hereafter).
B) A LTUX-S
Action: Decide whether LTUX-S or BSM-X is faulty,
and report status to the OC.
The B action is carried out by sending a test frame
to the in crate neighbour LTUX-S (if any). The test
frame contains a "Loop back" flag which causes the
LTUX-s to echo this test frame without forwarding the
data part to the LTUX-S application (the test could
be carried out via log channel 0 or 1.) If no in crate
neighbour LTUX-S exists then further action will be
based on off line M & D. Refer to fig. 5.3-1.
T̲D̲X̲ ̲E̲R̲R̲O̲R̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲…01…Fig. 5.3-1
5.4 T̲D̲X̲ ̲S̲T̲A̲T̲I̲S̲T̲I̲C̲S̲
Statistic information about the TDX performance must
be available to provide advance indication of possible
future errors.
The statistic area must as a minimum for each LTUX-S/TIA
Keep track of
1) total number of transferred packets
2) total number of retries ending with success (NAKs
or timeouts)
3) total number of irrecoverable packet errors (NAKs
or timeouts)
Whether the statistic area is resident within the TDX
handler or part of the TDX Controller diagnostics or
both it shall be possible to access the information
from the OC. Reset of information in the statistic
area shall only be carried out due to a special reset
command.
5.5 T̲D̲X̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲S̲C̲A̲N̲ ̲D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲
As described in CSD-MIC/210/PSP/0010 sec. 3.2.7 this
scan diagnostic module initially simulates all possible
devices are off the system. Afterwards it continously
sends diagnostic requests to all devices appearing
in the Mux-table. In case the device answers within
three attempts, it is regarded as "ready", otherwise
it is "failed". All statuschanges are reported to the
Watch-Dog via a V24 communication port.
This Watchdog is not the CAMPS Watchdog.
As the V24 port is not used by the CAMPS Watchdog,
the above mentioned reporting must be performed via
the TDX to the active PU and here forwarded to the
OC (if possible the V24 port output facility should
be retained). One exception from this is the situation
where it is the active PUs TIA which goes from active
to passive. This report must be send via the TDX to
the Stand by PU and from here forwarded to the OC.
5.6 I̲/̲O̲ ̲D̲A̲T̲A̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲ ̲V̲E̲R̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
As for the TDX data transfers, databuffer transfers
between main memory and I/O controllers (i.e. Disk
Ctrls., Floppy disk ctrl. and LTUs) must be verified
by the means of an added checksum. The buffer checksum
must be generated by the "sender", i.e. either a CAMPS
application module or I/O ctrl. firmware/application.
The "receiver" verifies the databuffer by generating
the checksum and comparing it against the received
checksum.
If an I/O ctrl. rejects a databuffer due to illegal
checksum, this must be signalled to the sending application
process by setting an "invalid checksum" bit in the
ctrl. statusword. The transfer shall be retried 3 times
before the SS&C is alerted. Preferably the DAMOS handler
level should handle all status error detection and
perform retries to correct errors, when a CAMPS application
sends data to an I/O controller. If correction is impossible
the CAMPS application and SS&C must be alerted.
Accepted Data buffers meant for either a disk or a
communication line must only be subjected to further
processing when stripped for the checksum information
by the relevant control.
If a CAMPS application process detects an invalid checksum
condition when reading a data buffer from an I/O control,
it must retry the read operation max. 3 times before
giving up and alerting SS&C.
When the SS&C is alerted due to I/O ctrl. transfer
errors, on line diagnostics will be applied to identify
the I/O errorsource (ref. sec. 5.7).
5.7 I̲/̲O̲ ̲E̲R̲R̲O̲R̲S̲O̲U̲R̲C̲E̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
CAMPS application processes or DAMOS reports detected
errors in the I/O system to the SS&C. To decide whether
or not a PU-I/O bus switch is necessary some more information
must be available for the SS&C.
The SS&C shall perform a "read status" to all connected
I/O controllers when an error condition in the I/O
system (MAP, MIA, Datachannel, CIA, I/O bus, I/O ctrls.)
is reported. The response will indicate to SS&C whether
one or more controllers are erroneous (ref. fig. 5.7-1).
One defective controller will not lead to a PU-I/O
bus switch whereas more defective controllers shall
activate a PU-I/O bus switch.
If a multiple control error condition arises the SS&C
shall perform a dummy databuffer transfer to an arbitrary
I/O control. If this transfer fails during the MAP,
MIA, CIA set up transfer phase then the errorsource
is most likely within the MAP, MIA, Datachannel, CIA
string. Else the error is within the CIA, I/O bus,
I/O control string.
I̲/̲O̲ ̲E̲R̲R̲O̲R̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲…01…Fig. 5.7-1
5.8 I̲/̲O̲ ̲S̲T̲A̲T̲I̲S̲T̲I̲C̲S̲
Statistic information about I/O system performance
must be available to provide advance indication of
possible future errors.
Statistic information will reside within the different
handlers (DAMOS) and shall be accessible from the OC.
Reset of information in the statistic area of the different
handlers shall only be reset on a special reset command.
As a minimum the Disk handler, Floppy disk handler
must contain information about:
A) Total number of accesses
B) Total number of successful recovery procedures
for
read
write
seek
C) Total number of unsuccessful recovery procedures
for:
read
write
seek
As a minimum the LTU handler must contain information
about:
A) Total number of block transfers
B) Total number of successful recovery procedures
for
read
write
C) Total number of unsuccessful recovery procedures
for
read
write
5.9 C̲P̲U̲ ̲D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲S̲
To verify CPU functions, firmware and bus interface
circuitry a CPU diagnostic application program is required.
This application program shall regularily (TBD) be
executed by each CPU in a PU (active as well as stand-by)
to ensure that no data or program areas are destroyed
due to misaddressing (CPU or Processor Bus generated)
and/or data garbling. The diagnostic program should
be a data manipulating process activated by the SS&C
with the result interpreted by the SS&C. Furthermore
the diagnostic program could contain the Test CPU Instruction
(TST) which, when executed, activates a CPU firmware
test. The test result is available in one of the general
purpose registers (R0-7). This test facility requires
that the diagnostic program is a system level program.
5.10 C̲A̲C̲H̲E̲ ̲E̲R̲R̲O̲R̲ ̲M̲O̲N̲I̲T̲O̲R̲I̲N̲G̲
The CPU is equipped with a CACHE memory to enhance
performance. The CPU constantly monitors the health
of the CACHE memory, incrementing the CACHE ERROR REGISTER
upon each detected CACHE memory parity error (ref.
CPS/SDS/001). To transfer this information to SS&C,
a system level program, CACHE ERROR monitoring program,
is required. This program decides whether or not to
disable CACHE functions based upon CACHE ERROR REGISTER
contents. The program should extract the information
from each CPU with regular intervals (TBD) and the
CACHE disable strategy shall be selectable as either
total number of errors or max. relative number of errors
(in proportion to the last number of errors). If a
CACHE memory is disabled (resetting the CACHE ERROR
REGISTER) this shall be reported to the OC along with
disable strategy and associated error number.
This diagnostic program could possibly be part of the
CPU diagnostic program (se. 5.9).
Reenabling of a disabled CACHE memory shall be possible,
and shall be controlled from the OC.
5.11 S̲T̲A̲N̲D̲-̲B̲Y̲ ̲P̲U̲
As the stand-by PU at any time must be able to switch
from stand-by to active, in case the former active
PU fails, it is necessary continously to monitor the
Stand-by PU availability hence all errordetecting/reporting
S/W (DAMOS, on line diagnostics) implemented for the
active PU should also be executed by the stand-by PU.
TDX I/F (STI, TIA) errors will be detected either by
the TDX controller on line scan diagnostics (ref. sec.
5.5) or TDX protocols in connection with checkpoint
communication with the active PU (ref. sec. 5.2).
The Data Channel and the standby I/O bus is supervised
in two ways.
1: Interrupt requests from the MIA to the CIA. These
requests causes the CIA to transmit either the
CU interrupt status, a test pattern or an error
code.
2: The Floppy disk controller is accessed regularly
(intervals: TBD) and the access is monitored for
errors. This requires that the Floppy disk Controller
is allocated to the Stand-by PU.
Watchdog connection is supervised via PU "alive" communication
and associated watchdog acknowledge (Ref. 3.6).
