top - download
⟦8360e721d⟧ Wang Wps File
Length: 75109 (0x12565)
Types: Wang Wps File
Notes: UKAIR CCIS, TECHNICAL
Names: »4779A «
Derivation
└─⟦a4c489747⟧ Bits:30006015 8" Wang WCS floppy, CR 0466A
└─ ⟦this⟧ »4779A «
WangText
…00……00……00……00……00……19……02……00……00……19…
…19……07……18……0e……18……02……17……08……17……0e……17……05……16……0c……16…
…15……09……15……00……15……07……14……0d……14……02……14… …13……0d……13… …12……0b……12……02……11……08……11……09……11……00……11……06……10……0c……10……0e……10…
…10……86…1 …02… …02… …02… …02… …02…
UKAIR CCIS ADPE - PART II SYS/84-04-15
TECHNICAL PROPOSAL Page
4̲ ̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲
4.1 P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
The performance characteristics of two UKAIR CCIS sites
are given in the table below.
P̲S̲W̲H̲Q̲ ̲A̲W̲H̲Q̲ ̲
Memory Utilisation 50%/Processor 50%/Processor
Device Utilisation 40%/Device 40%/Device
Expansion Capability 100% 100%
Response Time
- Root menu 0.3 secs 0.3 secs
- Other 4 secs 4 secs
- Special Various Various
Applications (30 secs-2mins) (30 secs-2mins)
Standard Deviation
- Root menu 0.1 secs 0.1 secs
- Other 1.5 secs 1.5 secs
Data Storage 2600MB 2300MB
Table 4.1-1
Performance Characteristics
These characteristics are assumed to be the baseline
requirement for the configurations of PSWHQ and AWHQ
sites. The performance figures given above are achieved
by CR90 host due to the modular construction where
each host consists of several processor sections (PS).
Each PS is in itself a high performance, modular computer
system. The sites are configured to achieve the baseline
performance characteristics given the workload described
in section 4.2 during the peak hour. The peak hour
work load is assumed to be 12.5% of the total daily
work load.
4.2 P̲E̲A̲K̲ ̲H̲O̲U̲R̲ ̲W̲O̲R̲K̲ ̲L̲O̲A̲D̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
An estimate of the work load on the proposed UKAIR
PSWHQ system is presented in this sections. The transaction
volume figures and the transaction characteristics
are based on the volume figures in the RFP, with some
changes as indicated in the following text.
The transaction volume figure for the AWHQ system is
assumed to be 70% of the transactions volume figures
for the PSWHQ system.
The UKAIR PSWHQ and AWHQ systems have been configured
to effectively and efficiently handle the peak hour
load on the systems.
4.2.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲W̲o̲r̲k̲ ̲L̲o̲a̲d̲
The main part of the work load on the host system is
a result of UKAIR CCIS operator initiated terminal
transactions. These transactions can be initiated at
local or remote terminals.
The host system performs other transactions as well,
e.g. data exchange with other systems, etc.
The total work load on the UKAIR CCIS host system is
a result of the following types of transactions:
T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲T̲y̲p̲e̲ D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
I Common terminal log-on, log-off, operational
transactions database transactions, message
handling, menu or format
requests, hardcopy requests
II Prompts result in unsolicited output
to the terminals
III System processes timer triggered on system
controll staff initiated
trans-
actions like central hardcopy
or database archive
IV Data exchange data reception a transmission
from/to CAMPS or ACENET
V Special event trig- message queue updates, tote
gered processes updates
VI Special applications event triggered or operator
initiated, infrequently used,
time consuming applications.
Table 4.2.1-1
Transaction Types
The common terminal transactions can be further classified
into the following categories:
C̲o̲m̲m̲o̲n̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲T̲y̲p̲e̲ D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
IA Session control log-on, log-off
IB Operational database data retrieval, amendment,
transactions insertion
IC Message handling storage and retrieval of
operational and service messages
ID Menu/format support display of menu or format
IE Scratchpad handling text and graphic scratchpad
update and display
IF Hardcopy requests hardcopy of a specified text
or graphic image
IG Graphic transactions
Table 4.2.1-2
Common Terminal Transactions
The terminal workstations (WS) are assumed to be able
to perform local processing and to be equipped with
a non-volatile memory (floppy-disk or disk).
The assumptions used for host work load calculations
are:
- WS can store several pages of text and perform
paging and scrolling
- most frequently used formats (e.g. formats used
for message preparation) are stored permanently
in WS
- the background geographical data - coastlines,
rivers, boundaries, topology - are stored permanently
in WS. WS can however request an update of these
data. This operation is assumed to be performed
very seldom.
The host transaction processing work load is calculated
subject to the following factors:
- operational data base retrievals, 90% require a
single tote which is kept in the processor memory,
10% require an actual data base retrieval
- message preparation, the messages are stored in
the data base and on average 6 queues will be updated
for each message, 15% of messages will be transmitted
to CAMPS
- reception of NATO messages, on average each message
received will have 10 addressees requiring queue
updates
- retrieval of queued message, the number of retrievals
of queued messages is 6 times the number of message
preparations
- display of graphics picture requires foreground
data only
- database archive is performed during quiet hours
and is not included in the peak hour calculations
- transactions performed every second hour contribute
as "half transaction" to the total load during
peak hour
- all formats menus and majority of totes used for
retrieval are memory resident and does not require
disk database access. The totes are automatically
updated after database amendment or insertion.
The following table contains mnemonics and descriptions
of all transactions.
Table 4.2.1-3
Transaction Description
I C̲O̲M̲M̲O̲N̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲S̲
A. SESSION CONTROL:
S̲A̲0̲1̲ ̲L̲O̲G̲-̲O̲N̲: Operational users will gain access
to the system by using this transaction.
S̲A̲0̲2̲ ̲L̲O̲G̲-̲O̲F̲F̲: Operational users will be able to
temporarily terminate access of the system with
this transaction, leaving the terminal in a secure
state.
B. OPERATIONAL DATA BASE TRANSACTIONS:
D̲R̲0̲1̲ ̲D̲A̲T̲A̲ ̲R̲E̲T̲R̲I̲E̲V̲A̲L̲: This transaction will be
used by operators to access the database and produce
formatted displays on their terminals. 75% of transactions
will result in a multi-page output being generated,
with the mean number of pages being 4. The remaining
25% of transactions will be single page. 90% of
transactions require a memory resident tote, 10%
require database retrieval.
D̲U̲0̲1̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲ ̲A̲M̲E̲N̲D̲M̲E̲N̲T̲: Data input via an operator
terminal will be used by this transaction to update
the existing database. 20% of transactions trigger
a tote update.
D̲U̲0̲2̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲ ̲I̲N̲S̲E̲R̲T̲I̲O̲N̲: Data input via an operator
terminal will be inserted into the database. 20%
of transactions trigger a tote update.
C. MESSAGE HANDLING:
M̲H̲0̲1̲ ̲P̲R̲E̲P̲A̲R̲E̲ ̲M̲E̲S̲S̲A̲G̲E̲: This transaction will be
used to prepare message text and message header(s),
and initiate the distribution of the messages.
15% of messages will have two headers; one for
UKAIR addressees and one for NATO addressees. The
remaining 85% will have only one header for UKAIR
addressees. For UKAIR messages on average 6 queues
will be updated by MHO1Q. For NATO messages the
distribution will entail passing the message to
CAMPS.
M̲H̲0̲2̲ ̲R̲E̲C̲I̲E̲V̲E̲ ̲N̲A̲T̲O̲ ̲M̲E̲S̲S̲A̲G̲E̲: NATO messages are received
from CAMPS and stored in the database. On average
each message received will have ten addressees.
M̲H̲0̲3̲ ̲R̲E̲T̲R̲I̲E̲V̲A̲L̲ ̲O̲F̲ ̲Q̲U̲E̲U̲E̲D̲ ̲M̲E̲S̲S̲A̲G̲E̲: This transaction
accesses the message from the top of the nominated
queue and outputs the message to the requesting
operator's terminal.
M̲H̲0̲4̲ ̲O̲P̲E̲R̲A̲T̲O̲R̲ ̲R̲E̲T̲R̲I̲E̲V̲A̲L̲ ̲F̲R̲O̲M̲ ̲T̲H̲E̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲:
Messages are retrieved from the database according
to operator defined parameters input via a terminal.
On average five messages will be retrieved for
each transaction.
D. MENU/FORMAT SUPPORT:
D̲S̲0̲1̲ ̲M̲E̲N̲U̲ ̲S̲U̲P̲P̲O̲R̲T̲: This transaction will allow
the operational user to obtain a menu or list of
options from which the user may select further
menus or lists, or select a transaction.
D̲S̲0̲2̲ ̲F̲O̲R̲M̲A̲T̲ ̲S̲U̲P̲P̲O̲R̲T̲: This transaction will allow
the operational user to obtain a format display
on the terminal.
E. SCRATCHPAD HANDLING:
S̲U̲0̲1̲ ̲U̲P̲D̲A̲T̲E̲ ̲S̲C̲R̲A̲T̲C̲H̲P̲A̲D̲ ̲P̲A̲G̲E̲: Operational users
will update their scratchpad file pages using this
transaction. They will be able to update existing
data and insert additional data.
S̲D̲0̲1̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲S̲C̲R̲A̲T̲C̲H̲P̲A̲D̲ ̲P̲A̲G̲E̲: This transaction
will be used to display a scratchpad file page
on an operational user's terminal.
G̲D̲0̲3̲ ̲S̲T̲O̲R̲A̲G̲E̲ ̲O̲F̲ ̲S̲K̲E̲T̲C̲H̲P̲A̲D̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲P̲I̲C̲T̲U̲R̲E̲: This
transaction is similar to SU01 except that the
data stored in the sketchpad file is used to display
a graphic picture on the operator's terminal.
G̲D̲0̲4̲ ̲R̲E̲T̲R̲I̲E̲V̲A̲L̲ ̲O̲F̲ ̲S̲K̲E̲T̲C̲H̲P̲A̲D̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲P̲I̲C̲T̲U̲R̲E̲: A
previously stored sketchpad graphic picture is
accessed from the database and displayed on the
requesting operator's terminal.
F. HARD COPY:
H̲C̲0̲1̲ ̲H̲A̲R̲D̲ ̲C̲O̲P̲Y̲ ̲O̲F̲ ̲T̲E̲X̲T̲: This transaction is used
by an operational user to obtain a hard copy of
the contents of his current text display.
H̲C̲0̲2̲ ̲H̲A̲R̲D̲ ̲C̲O̲P̲Y̲ ̲O̲F̲ ̲G̲R̲A̲P̲H̲I̲C̲S̲: The current contents
of a graphics display are output to a graphic hard
copy terminal.
G. GRAPHIC TRANSACTIONS:
G̲D̲0̲1̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲G̲R̲A̲P̲H̲I̲C̲S̲ ̲P̲I̲C̲T̲U̲R̲E̲: This transaction
is used to access GASS data and display the data
on the requesting operational user's terminal as
a graphic picture.
II P̲R̲O̲M̲P̲T̲S̲
P̲D̲0̲1̲ ̲C̲A̲U̲S̲E̲ ̲P̲R̲O̲M̲P̲T̲: This process is used by the prompt
mechanism to output a prompt message to an operator's
terminal when an event or time trigger has occurred.
D̲U̲0̲3̲ ̲T̲H̲R̲E̲S̲H̲O̲L̲D̲ ̲M̲O̲N̲I̲T̲O̲R̲I̲N̲G̲: This process is used to
identify when specific data items satisfy pre-determined
threshold conditions. Each time the data items are
updated the new values are tested against the threshold
value and if the conditions are satisfied a prompt
message is output to an operator's terminal. 10% of
DU01 transactions will cause threshold prompts to be
output.
D̲U̲0̲4̲ ̲R̲E̲F̲R̲E̲S̲H̲ ̲D̲I̲S̲P̲L̲A̲Y̲S̲: Each time a data item is updated
the process identifies the terminals, if any, currently
displaying the data item. For the identified set of
terminals their displays will be refreshed showing
the updated data. For each DU01 transaction 12 terminals
will require an updated display.
G̲D̲0̲2̲ ̲R̲E̲F̲R̲E̲S̲H̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲D̲I̲S̲P̲L̲A̲Y̲: This process causes
graphic displays to be updated when the underlying
database data is updated. This process will be performed
twice each hour and on each occasion 75 terminals will
receive an updated display.
III S̲Y̲S̲T̲E̲M̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
S̲P̲0̲1̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲ ̲A̲R̲C̲H̲I̲V̲E̲: This process performs the archiving
of all the databases within the system. Each database
will be archived once every 24 hours. This process
may be ignored when calculating peak hour rates.
S̲P̲0̲2̲ ̲C̲E̲N̲T̲R̲A̲L̲ ̲H̲A̲R̲D̲ ̲C̲O̲P̲Y̲: This process produces formatted
hard copy of a sub-set of the database. The process
runs once every 2 hours.
S̲P̲0̲3̲ ̲F̲A̲L̲L̲-̲B̲A̲C̲K̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲: This process is used to
output to operator workstations the data required in
the event of fall-back being necessary. The process
will be performed every 2 hours for up to 70 workstations.
IV D̲A̲T̲A̲ ̲E̲X̲C̲H̲A̲N̲G̲E̲:
S̲E̲0̲1̲ ̲R̲E̲C̲E̲I̲V̲E̲ ̲D̲A̲T̲A̲: This transaction receives data
from another computer system and updates the CCIS database
using the received data.
SE01 will be performed once each hour for the receipt
of data from system 1; this data will consist of 38500
characters. In addition, 25000 characters of data will
be received twice each hour from system 2 and 12000
characters will be received once each hour from system
3.
S̲E̲0̲2̲ ̲T̲R̲A̲N̲S̲M̲I̲T̲ ̲D̲A̲T̲A̲: This transaction transmits data
from the CCIS to another computer system.
SE02 will be performed twice each hour to transmit
38500 characters of data to system 1. The AWHQ system
will receive a transmission each time the CCIS database
is updated; there will be 47650 such updates every
24 hours.
V S̲P̲E̲C̲I̲A̲L̲ ̲E̲V̲E̲N̲T̲ ̲T̲R̲I̲G̲G̲E̲R̲E̲D̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
M̲H̲0̲1̲Q̲ ̲U̲P̲D̲A̲T̲E̲ ̲Q̲U̲E̲U̲E̲: Each time a new message is received
on average 6 terminal queues will be updated.
M̲H̲0̲2̲Q̲ ̲U̲P̲D̲A̲T̲E̲ ̲Q̲U̲E̲U̲E̲: As above except that this transaction
is used in connection with messages coming from NATO.
T̲O̲0̲1̲ ̲U̲P̲D̲A̲T̲E̲ ̲T̲O̲T̲E̲: 20% of DU01 and DU02 transactions
will trigger TU01 which will update a memory resident
tote.
VI S̲P̲E̲C̲I̲A̲L̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲S̲
R̲O̲U̲T̲E̲ ̲P̲L̲ ̲ ̲ ̲R̲O̲U̲T̲E̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲: Calculation of turning
circles great circle distances, air speed and ground
speed, for route.
C̲A̲P̲ ̲P̲L̲A̲N̲ ̲ ̲ ̲C̲A̲P̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲: Calculation of ETD (estimated
time of departure) of fighters and tankers the time
for refuelling and the amount of fuel available for
refuelling.
R̲O̲L̲E̲ ̲S̲U̲M̲ ̲ ̲ ̲R̲O̲L̲E̲ ̲S̲U̲M̲M̲A̲R̲I̲E̲S̲: The database records for
mission details will be inspected, those falling within
the date/time input parameters will be used to accumulate
statistics of aircraft missions and losses.
M̲E̲S̲G̲E̲N̲ ̲ ̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲: A message will be formatted
and generated from data from the database, additional
free format text will be adding from terminal input
(100 characters) message is added to the database and
queues updated.
D̲B̲M̲S̲G̲U̲P̲D̲ ̲ ̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲ ̲U̲P̲D̲A̲T̲E̲S̲ ̲F̲R̲O̲M̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲: Status
and report messages will be used to directly update
the database. Messages will be displayed on terminal
and the operator will authorise the update.
S̲U̲M̲R̲E̲P̲ ̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲R̲E̲P̲O̲R̲T̲S̲: Display current summary
record delete previous summary record and create new
summary record.
S̲Y̲N̲O̲P̲O̲V̲W̲ ̲ ̲ ̲S̲Y̲N̲O̲P̲T̲I̲C̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲: Retrieval display of
database records associated with the communication
system identified by the input parameter.
R̲A̲D̲I̲O̲ ̲F̲R̲ ̲ ̲ ̲R̲A̲D̲I̲O̲ ̲F̲R̲E̲Q̲U̲E̲N̲C̲Y̲ ̲P̲R̲O̲P̲A̲G̲A̲T̲I̲O̲N̲: A range of
optimum ratio frequencies will be calculated given
the propagation conditions retrieved from the databases.
S̲O̲R̲T̲G̲E̲N̲ ̲ ̲ ̲S̲O̲R̲T̲I̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲: Calculation of the number
of sorties possible over a specified period.
S̲T̲A̲F̲F̲T̲A̲B̲ ̲ ̲ ̲S̲T̲A̲F̲F̲ ̲T̲A̲B̲L̲E̲ ̲M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲: Produce display
of specified UAST in the format required.
A̲I̲R̲L̲I̲F̲T̲ ̲ ̲ ̲A̲I̲R̲L̲I̲F̲T̲ ̲F̲L̲O̲W̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲: Production of a graphical
plan for each airfield within the airlift showing timetable
for individual aircraft and take-off times, loads,
fuel.
R̲O̲U̲T̲E̲P̲L̲N̲/̲S̲T̲A̲G̲E̲M̲E̲S̲ ̲ ̲ ̲R̲O̲U̲T̲E̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲/̲S̲T̲A̲G̲E̲ ̲M̲E̲A̲S̲U̲R̲E̲M̲E̲N̲T̲:
Maintenance of stage fuel payloads calculation of
stage measurement and route planning processing.
A̲C̲P̲E̲R̲F̲ ̲ ̲ ̲A̲I̲R̲C̲R̲A̲F̲T̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲: Production of graphs
and tables detailing aircraft landing and take-off
characteristics.
A̲C̲L̲D̲P̲L̲A̲N̲ ̲ ̲ ̲A̲I̲R̲C̲R̲A̲F̲T̲ ̲L̲O̲A̲D̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲: Dividing the local
details between individual aircraft.
D̲E̲T̲P̲L̲A̲N̲ ̲ ̲ ̲D̲E̲T̲A̲C̲H̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲: Creation, amendment
or deletion of the detachment plan identified by the
input.
D̲E̲P̲P̲L̲A̲N̲ ̲ ̲ ̲D̲E̲P̲L̲O̲Y̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲: Calculation of changes
to deployment progress.
A̲L̲T̲P̲R̲C̲ ̲ ̲ ̲A̲L̲E̲R̲T̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲: Retrieval of alert measure
details and format into graphical display.
The following table describes for each transaction
number of logical data accesses ("reads" and "writes")
and stimuli. The stimuli are typically terminal input
or events. The logical data accesses is an indication
of prime data records to be accessed.
(t.i. denotes terminal input)
TRANSACTION STIMULI LOGICAL DATA ACCESSES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲E̲A̲D̲S̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲W̲R̲I̲T̲E̲S̲
̲ ̲ ̲ ̲ ̲ ̲
I C̲O̲M̲M̲O̲N̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲S̲
I.A S̲e̲s̲s̲i̲o̲n̲ ̲c̲o̲n̲t̲r̲o̲l̲
SA[1 t.i. 1 1
SA[2 badge removal 1 1
I.A O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
DR[1 t.i. 1 1
90%
t.i. 40 4
10%
DU[1 t.i. 4 2
DU[2 t.i. 1 1
I.C M̲e̲s̲s̲a̲g̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
MH[1 t.i. 6 7
MH[2 CAMPS message 10
11
MH[3 t.i. 2 1
MH[4 t.i. 5 5
I.D M̲e̲n̲u̲/̲f̲o̲r̲m̲a̲t̲ ̲s̲u̲p̲p̲o̲r̲t̲
DS[1 t.i. 1 0
DS[2 t.i. 1 0
I.E S̲c̲r̲a̲t̲c̲h̲p̲a̲d̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
SU[1 t.i. 1 1
SD[1 t.i. 1 0
GD[3 t.i. 0 1
GD[4 t.i. 1 0
I.F H̲a̲r̲d̲ ̲c̲o̲p̲y̲
HC[1 t.i. 2 0
HC[2 t.i. 0 0
I.G G̲r̲a̲p̲h̲i̲c̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
GD[1 t.i. 150 0
II P̲R̲O̲M̲P̲T̲S̲
PD[1 timer/event 1 0
DU[3 db update 1 0
DU[4 db update 12 0
GD[2 db update 75 0
III S̲Y̲S̲T̲E̲M̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
SP[2 timer 8250
750
SP[3 timer 19250
1750
t.i. denotes terminal input
TRANSACTION STIMULI LOGICAL DATA
ACCESSES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲E̲A̲D̲S̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲W̲R̲I̲T̲E̲S̲ ̲ ̲ ̲ ̲ ̲ ̲
IV D̲A̲T̲A̲ ̲E̲X̲C̲H̲A̲N̲G̲E̲
SE[1 data from system 1 150 150
" " " 2 20
20
" " " 3 300 300
SE[2 timer/event
data to system 1 700
0
data to AWHQ 1
0
V S̲P̲E̲C̲I̲A̲L̲ ̲E̲V̲E̲N̲T̲ ̲T̲R̲I̲G̲G̲E̲R̲E̲D̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
V.A MH[1Q MH[1 0 1
MH[2Q MH[2 0 1
V.B TO[1 DU[1, DU[2 2 0
VI S̲P̲E̲C̲I̲A̲L̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲S̲
ROUTEPL t.i. 20 0
CAPPLAN t.i 10 0
ROLE SUM t.i. 500 0
MESGEN t.i. 40 5
DBMSGUPD formatted msg. 40
40
SUMREP t.i. 2
2
SYNDPOVW t.i. 50 0
RADIOFR t.i. 50 0
SORTGEN t.i. 20 0
STAFFTAB t.i. 800 0
AIRLIFT t.i. 100 0
ROUTEPLN t.i. 40
20
ACPERF t.i. 10 0
ACLDPLAN t.i. 1000 100
DETPLAN t.i. 20
20
DEPPLAN t.i. 100 0
ALTPROC db update 5 0
Table 4.2.1-4
The transaction frequencies for peak 24 hour period
and for peak hour are given below.
This table contains also peak hour logical data accesses.
NO TRANS ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲E̲A̲K̲
̲H̲O̲U̲R̲ ̲ ̲ ̲ ̲ ̲ ̲
T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲2̲4̲ ̲H̲O̲U̲R̲S̲ ̲ ̲ ̲ ̲T̲R̲A̲N̲S̲.̲ ̲ ̲ ̲R̲E̲A̲D̲S̲
̲ ̲ ̲ ̲W̲R̲I̲T̲E̲S̲
I C̲O̲M̲M̲O̲N̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲S̲
I.A S̲e̲s̲s̲i̲o̲n̲ ̲c̲o̲n̲t̲r̲o̲l̲
SA[1 3200 400
400
400
S̲A̲[̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲3̲2̲0̲0̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲4̲0̲0̲ ̲ ̲ ̲ ̲ ̲ ̲4̲0̲0̲
̲ ̲ ̲ ̲ ̲ ̲4̲0̲0̲
6400 800 800
800
I.B O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
DR[1 30355 3276 3276
3276
364 14560
1456
DU[1 10529 1300 5600
2600
D̲U̲[̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲1̲7̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲4̲0̲ ̲ ̲ ̲ ̲ ̲ ̲1̲4̲0̲
̲ ̲ ̲ ̲ ̲ ̲1̲4̲0̲
42055 5080 23576
7472
I.C M̲e̲s̲s̲a̲g̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
MH[1 16000 2000 12000
14000
MH[2 2200 275 2750
3025
MH[3 96000 12000 24000
12000
M̲H̲[̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲4̲1̲4̲0̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲5̲1̲7̲ ̲ ̲ ̲ ̲ ̲2̲5̲8̲0̲
̲ ̲ ̲ ̲ ̲2̲5̲8̲0̲
118340 14692 41330
31605
I.D M̲e̲n̲u̲/̲f̲o̲r̲m̲a̲t̲ ̲s̲u̲p̲p̲o̲r̲t̲
DS[1 13830 1660 (1600
0)
*)
D̲S̲[̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲3̲3̲0̲8̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲3̲9̲7̲0̲ ̲ ̲ ̲ ̲(̲3̲9̲7̲0̲
̲ ̲ ̲ ̲0̲)̲ ̲*̲)̲
46912 5630 (5630
0)
I.E S̲c̲r̲a̲t̲c̲h̲p̲a̲d̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
SU[1 9140 1150 1150
1150
SD[1 7915 990 990
0
GD[3 360 45
0
45
G̲D̲[̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲4̲5̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲5̲7̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲5̲7̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲
17870 2242 2197
1195
I.F H̲a̲r̲d̲ ̲c̲o̲p̲y̲
HC[1 3919 490 490
490
H̲C̲[̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲6̲2̲0̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲7̲7̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲7̲7̲
̲ ̲ ̲ ̲ ̲ ̲ ̲7̲7̲
4539 576 567
567
I.G G̲r̲a̲p̲h̲i̲c̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
GD[1 2000 250 37500
0
=============================================================
238116 29261 105970
41639
II P̲R̲O̲M̲P̲T̲S̲
PD[1 1048 126 126
0
DU[3 1053 131 131
0
DU[4 10529 1300 15600
0
GD[2 48 2 150
0
=============================================================
12678 1559 16007
0
III S̲Y̲S̲T̲E̲M̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
SP[2 (12 0.5) 4140
375
SP[3 (12 0.5) 9625
375
=============================================================
13765
750
*) not included in total, memory resident
TRANSACTION NO TRANS ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲E̲A̲K̲
̲H̲O̲U̲R̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲2̲4̲ ̲H̲O̲U̲R̲S̲ ̲ ̲ ̲ ̲T̲R̲A̲N̲S̲ ̲ ̲ ̲ ̲R̲E̲A̲D̲S̲
̲ ̲ ̲ ̲W̲R̲I̲T̲E̲S̲ ̲ ̲
IV D̲A̲T̲A̲ ̲E̲X̲C̲H̲A̲N̲G̲E̲
SE[1 system 1 (24 1) 150
150
system 2 (48 2) 40
40
system 3 (24 1) 300
300
SE[2 system 1 (24 1) 700
0
AWHQ 47650 5956 5956
0
=============================================================
47650 5956 7146
490
V S̲P̲E̲C̲I̲A̲L̲ ̲E̲V̲E̲N̲T̲ ̲T̲R̲I̲G̲G̲E̲R̲E̲D̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
V.A MH[1Q 96000 12000
0
12000
MH[2Q 22000 2750
0
2750
V.B TO[1 2339 292 584
0
=============================================================
120339 15042 584
14750
VI S̲P̲E̲C̲I̲A̲L̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲S̲
ROUTEPL 76 10 200
0
CAPPLAN 15 1 10
0
ROLE SUM 4 0.5 250
0
MESGEN 55 7 280
35
DBMSGUPD 600 75 3000
3000
SUMREP 60 7 14
14
SYNDPOVW 150 19 450
0
RADIOFR 5 0.5 25
0
SORTGEN 30 4 80
0
STAFFTAB 220 27 22000
0
AIRLIFT 100 12 1200
0
ROUTEPLN 100 12 480
240
ACPERF 25 2 20
0
ACLDPLAN 60 7 7000
700
DETPLAN 3 0.5 10
10
DEPPLAN 20 2 200
0
ALTPROC 50 6 30
0
=============================================================
1573 191 35249
3999
Table 4.2.1-5
The summary of the total load in the transaction processing
subsystem is given in table 4.2.1-6
No trans/ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲E̲A̲K̲ ̲H̲O̲U̲R̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲2̲4̲ ̲h̲o̲u̲r̲ ̲ ̲ ̲ ̲ ̲N̲o̲ ̲t̲r̲a̲n̲s̲ ̲ ̲ ̲ ̲ ̲r̲e̲a̲d̲s̲ ̲ ̲ ̲ ̲
̲w̲r̲i̲t̲e̲s̲
Common 238116 29261 105970
41639
Prompts 12678 1559 16607
0
System n.a. n.a. 13765
750
Data exchange 47650 5956 7146
490
Special event 120339 15042 584
14750
S̲p̲e̲c̲i̲a̲l̲ ̲a̲p̲p̲l̲ ̲ ̲ ̲ ̲ ̲ ̲1̲5̲7̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲9̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲3̲5̲2̲4̲9̲ ̲ ̲ ̲
̲ ̲ ̲3̲9̲9̲9̲
Total 372706 46053 179321
61628
The overhead due to security is assumed to be 10% of
the total work load.
The overhead due to logging and checkprinting is assumed
to be 5% of the total work load.This overhead involves
CRDB only.
4.2.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲W̲o̲r̲k̲ ̲L̲o̲a̲d̲
The work load put on the communication subsystem is
estimated subject to the following factors:
- 1 page consists of 10 lines x 80 characters = 800
characters
- 1 full screen consists of 20 lines x 80 characters
= 1600 characters
- an average opertional message is 1500 characters
- an average rewiev message is 400 characters
- 50% of all messages are service messages
- 1 input parameter is 10-20 characters
- 1 output confirmation is 20 characters
- an average terminal queue update is 20 characters
- 60% of all terminal transactions use UNITER as a
communication medium, 40% use local communication
The characteristies of input/output messages for all
transaction types are presented in table 4.2.2-1.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲N̲P̲U̲T̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲O̲U̲T̲P̲U̲T̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MESSAGE SIZE MESSAGE
SIZE
I C̲O̲M̲M̲O̲N̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲S̲
I.A S̲e̲s̲s̲i̲o̲n̲ ̲c̲o̲n̲t̲r̲o̲l̲
SA[1 5 parameters 50 confirmation
20
SA[2 1 parameter 10 confirmation
20
I.B O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
DR[1 5 parameters 50 25% 4 x 10
lines 3200
75% 1 x 10
lines
800
DU[1 values 50 terminal
update
50
DU[2 new data 100 confirmation
20
I.C M̲e̲s̲s̲a̲g̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
MH[1 message text 1500/400 confirmation
20
MH[2 message text 1500
MH[3 queue id 20 message text
1500/400
MH[4 parameters 20 message text
1500/400
I.D M̲e̲n̲u̲/̲f̲o̲r̲m̲a̲t̲ ̲s̲u̲p̲p̲o̲r̲t̲
DS[1 menu option 10 new page
800
DS[2 format parameter 10 format page
800
I.E S̲c̲r̲a̲t̲c̲h̲p̲a̲d̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
SU[1 changer to page 100 new page
800
SD[1 page id 10 updated page
800
GD[3 parameters 20 graphics
8000
GD[4 graphics 8000 confirmation
20
I.F H̲a̲r̲d̲ ̲c̲o̲p̲y̲
HC[1 Parameters 20 confirmation
20
HC[2 parameters 20 confirmation
20
I.G G̲r̲a̲p̲h̲i̲c̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
GD[1 parameters 20 graphics
8000
II P̲R̲O̲M̲P̲T̲S̲
PD[1 prompt
20
DU[3 prompt
20
DU[4 display refresh
100
GD[2 refreshed
display
1000
III S̲Y̲S̲T̲E̲M̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
SP[2
SP[3 fall back
data 25000
Table 4.2.2-1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲N̲P̲U̲T̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲O̲U̲T̲P̲U̲T̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MESSAGE SIZE MESSAGE
SIZE
IV D̲A̲T̲A̲ ̲E̲X̲C̲H̲A̲N̲G̲E̲
SE[1 system 1 38500
system 2 25600
system 3 12000
SE[2
V S̲P̲E̲C̲I̲A̲L̲ ̲E̲V̲E̲N̲T̲ ̲T̲R̲I̲G̲G̲E̲R̲E̲D̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
MH[1Q queue update
20
MH[2Q queue update
20
TO[1
VI S̲P̲E̲C̲I̲A̲L̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲S̲
ROUTEPL 12 parameters 120 1 screen
2000
CAPPLAN 7 parameters 70 1 screen
2000
ROLE SUM 2 parameters 20 1 screen
2000
MESGEN 4 parameters 40 message text
1500
PBMSGUPD message text
1500
SUMREP 2 parameters 20 1 page
800
SYNDPOVW 1 parameter 10 1 page
800
RADIOFR 6 parameter 60 1 page
800
SORTGEN 3 parameter 30 1 page
800
STAFFTAB 2 parameter 20 15 screen
36000
AIRLIFT 4 parameters 40 4 screen
9600
ROUTEPLN 3 parameters 30 1 screen
2400
ACPERF 4 parameters 40 2 screen
4800
ACLDPLAN 5 parameters 50 1 page
800
DETPLAN 1 parameter 10 5 pages
4000
DEPPLAN 6 parameters 60 1 page
800
ALTPROC alert status
20
Table 4.2.2-1
Table 4.2.2-2 presents the message trafic due to transactions.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲E̲A̲K̲ ̲H̲O̲U̲R̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲O̲U̲T̲G̲O̲I̲N̲G̲
̲ ̲ ̲ ̲ ̲
NO MESSAGES NO CHARS NO MESSAGES
NO CHARS
I C̲O̲M̲M̲O̲N̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲S̲
I.A S̲e̲s̲s̲i̲o̲n̲ ̲c̲o̲n̲t̲r̲o̲l̲
SA[1 400
20000
400
8000
SA[2 400 4000 400
8000
I.B O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
DR[1 3640 182000 819
2.6M
2821
2.2M
DU[1 1300 65000 1300
6500
DU[2 140 14000 140
2800
I.C M̲e̲s̲s̲a̲g̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
MH[1 1000 1.5M
1000 400000
MH[2 257 412500 *)
MH[3 12000 240000 6000
9M
6000
2.4M
MH[4 517 10340 250
375000
250
100000
I.D M̲e̲n̲u̲/̲f̲o̲r̲m̲a̲t̲ ̲s̲u̲p̲p̲o̲r̲t̲
DS[1 1660 16600 1660
1.3M
DS[2 3970 39700 3970
3.2M
I.E S̲c̲r̲a̲t̲c̲h̲p̲a̲d̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
SU[1 1150 115000 1150
920000
SD[1 990 9900 990
792000
GD[3 45 360000 45
900
GD[4 57 1040 57
456000
I.F H̲a̲r̲d̲ ̲c̲o̲p̲y̲
HC[1 490 9800 490
9800
HC[2 77 1540 77
1540
I.G G̲r̲a̲p̲h̲i̲c̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
GD[1 250 5000 250
2M
II P̲R̲O̲M̲P̲T̲S̲
PD[1 131
2620
DU[3 131
2620
DU[4 15600
1.6M
GD[2 150
150000
III S̲Y̲S̲T̲E̲M̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
SP[2
SP[3 35
875000
Table 4.2.2-2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲E̲A̲K̲ ̲H̲O̲U̲R̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲O̲U̲T̲G̲O̲I̲N̲G̲ ̲ ̲ ̲ ̲ ̲
NO MESSAGES NO CHARS NO MESSAGES
NO CHARS
IV D̲A̲T̲A̲ ̲E̲X̲C̲H̲A̲N̲G̲E̲
SE[1, System 1 1 38500
, System 2 2 5000
, System 3 1 12000 **)
SE[2 2
77000
5959
4.8M ***)
V S̲P̲E̲C̲I̲A̲L̲ ̲E̲V̲E̲N̲T̲ ̲T̲R̲I̲G̲G̲E̲R̲E̲D̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲
MH[1Q 12000
240000
MH[2Q 2750
55000
TO[1
VI S̲P̲E̲C̲I̲A̲L̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲S̲
ROUTEPL 10 1200 10
20000
CAPPLAN 1 70 1
2000
ROLE SUM 0.5 10 0.5
1000
MESGEN 7 280 7
10500
PBMSGUPD 75 112500
SUMREP 7 140 7
5600
SYNDPOVW 19 190 19
15200
RADIOFR 0.5 30 0.5
400
SORTGEN 4 120 4
3200
STAFFTAB 27 540 27
1M
AIRLIFT 12 480 12 115200
ROUTEPLN 12 360 12
28800
ACPERF 2 80 2
9600
ACLDPLAN 8 400 8
6400
DETPLAN 0.5 30 0.5
2000
DEPPLAN 2 120 2
1600
ALTPROC 6
120
*) from CAMPS
**) from AFCENET
***) transmission of transactions to AWHQ
Table 4.2.2-2
Table 4.2.2-3 summarises the message traffic for peak
hour due to different transactions.
I̲N̲C̲O̲M̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲ P̲e̲a̲k̲ ̲H̲o̲u̲r̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CONNECTION: UNITER/LOCAL no. msg. chars
count
x
10000
I Common Transactions 29086
300
IV Data Exchange n.a.
9
VI Special Applications 112
1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Subtotal 29198
310
CONNECTION: CAMPS
I Common Transaction 275
41
CONNECTION: ACENET
IV Data Exchange n.a.
2
=======================================================
Total incomming 29473
350
O̲U̲T̲G̲O̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲
CONNECTION: UNITER/LOCAL
I Common Transactions 28946 2600
II Prompts 16047
250
IV Data Exchange 5959
480
V Special Event 14750
240
VI Special Applications 120
130
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Subtotal 65813 3700
CONNECTION: CAMPS
I Common Transaction 350
45
CONNECTION: ACENET n.a.
n.a.
======================================================
Total outgoing 66163 3745
Table 4.2.2-3
Message Traffic Analysis
In addition to handling incoming and outgoing messages,
the communication subsystem logs the incoming messages.
The number of input commands logs is estimated to be
29473 per peak hour.
4.3 S̲Y̲S̲T̲E̲M̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
The host systems are configured from Processing Sections
(PS). These PS's have allocated the processing on a
functional basis. Each host system can be considered
to consist of two major subsystems:
- C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ which communicates with
- remote and local operation workstations
- CAMPS through X.25 point-to-point connection
- ACENET through BB&N 1822 point-to-point connection
- MCCIS, IUKAUGE and AWHQ through X.25 UNITER
connection.
- T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ which executes the
transactions and controls the backend database
machine (CRDB).
Each of the two subsystems consists of several processor
sections. Within the transaction processing subsystem
the transactions are routed to different processor
sections depending on transaction type.
The configuration of the two host systems processor
sections in PSWHQ and AWHQ host systems is shown overleaf
in figure 4.3-1 and figure 4.3.1-2.
The external interfaces of PSWHQ and AWHQ host systems
are shown in figure 4.3-3 and figure 4.3-4 overleaf.…86…1
…02… …02… …02… …02…
Figure 4.3-1
PSWHQ ADPE System Configuration
Figure 4.3-2
AWHQ ADPE System Configuration
Figure 4.3-3
PSWHQ ADPE External Configuration and Load
Figure 4.3-4
AWHQ ADPE External Configuration
4.4 D̲A̲T̲A̲B̲A̲S̲E̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
Since different transactions access different and unrelated
dat, the data is split into several databases. These
databases are allocated to several database machines
CRDB's. The distribution of data into logical databases
is shown overleaf in table 4.4-2.
The allocation of logical databases to different CRDB's
in PSWHQ configuration is shown in table 4.4-1 below.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲C̲R̲D̲B̲ ̲#̲ ̲ ̲ ̲ ̲S̲I̲Z̲E̲ ̲i̲n̲ ̲M̲B̲ ̲L̲O̲G̲I̲C̲A̲L̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲ ̲ ̲
1 1022 MESSAGE
2 688 OPERATIONAL
3 688 FORMAT
SCRATCHPAD
SECURITY
GEOGRAPHY
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.4-1
Logical
Database Major data elements
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Message Data on own, enemy, other forces
comprising status, location, capabilities,
structure.
Plans, Intelligence
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Geography Coastlines, Rivers, Boundaries, Topology,
Locations of Cities, Harbours.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Format Formats for totes, messages, warnings,
alarms. Menu structure and menus.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Scratchpad Scratchpad for the individual users.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Security Users, IDs, Security profiles of
users, hardware, facilities, lines.
Configuration, Configuration management,
Non-trivial logs/journals
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.4-2
Logical Databases
4.5 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
The distribution of processing to the individual processor
sections is shown below.
The communication subsystem comprising processor sections
1, 2 and 3 maintains connections with UNITER, CAMPS,
ACENET and with local workstations. The transaction
subsystem is processing the individual transactions:
messages, tabular and graphic totes, special applications,
security, formats and menus, scratchpad and geographic
pictures.
The description of the processing sections in PSWHQ
configuration is given below:
Processor PROCESSING ̲ ̲ ̲ ̲ ̲ ̲H̲W̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
̲ ̲ ̲ ̲ ̲ ̲
Section RAM DISK STORAGE
CRDB
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲M̲B̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲M̲B̲ ̲
̲ ̲ ̲ ̲ ̲C̲O̲N̲N̲E̲C̲T̲I̲O̲N̲
1. Communication: UNITER
File system:
transac. input log,
storage of program 2 (2x)344
2. Communication: CAMPS,
ACENET, local transac. 2
3. Communication: UNITER,
operator consoles, line
printers, graphic hard
copy 2
4. Message processing 3 2x(2x)516 1
5. Tote processing:
operational db trans. 3 2x(2x)344 2
6. Special applications
incl. floating point
calculations, tote
processing 2
7. Menu, formats,
scratchpad, security,
geography 2 2x(2x)344 3
File system: Software (2x)80
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
(2x) denotes disk mirroring
Table 4.5-1
Functional Distribution
The distribution of processing to the individual processing
sections is also shown in figure 4.3-1 and 4.3-2.
The extra large RAM memory in PS # 4 is reserved for
memory resident messages and messages queues.
The extra large RAM memory in PS # 5 is reserved for
memory resident totes, formats and menues.
The file system in PS # 1 is used for transaction logging
and print spooling.
The file system in PS # 7 is used for storage of software.
4.6 W̲O̲R̲K̲ ̲L̲O̲A̲D̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
4.6.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲,̲ ̲"̲r̲e̲a̲d̲s̲"̲ ̲a̲n̲d̲ ̲"̲w̲r̲i̲t̲e̲s̲"̲
The transactions described in section 4.2.1 are assigned
to different processor sections and CRDB's in the following
fashion:
P̲S̲ ̲ ̲ ̲ ̲ ̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲R̲D̲B̲ ̲
4 IC message handling 1
IV data exchange
VA queue update
5 IB operational 2
ID menu/formats
II prompts
VB tote updates
6 IG graphics 2
III system processes
VI special applications
7 IE scratchpad 3
IF hard copy
IA session control
Table 4.6-1
Workload Distribution
Below the estimated workload for each processor and
for each CRDB is given. The figures include 5 % overhead
due to logging and checkpointing. The figures for PS
# 7 include security overhead due to transactions performed
in PS # 4, 5, 6 and transactions 1E and 1F. This security
overhead is assumed to be 10% of the total no. of transactions,
"reads" and "writes".
̲ ̲ ̲ ̲ ̲ ̲ ̲P̲e̲a̲k̲ ̲H̲o̲u̲r̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲e̲a̲k̲ ̲S̲e̲c̲o̲n̲d̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
PS CRDB No. reads writes No. reads
writes
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲r̲a̲n̲s̲a̲c̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲r̲a̲n̲s̲a̲c̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4 1 29442 50899 49187 8.2 14.1 13.7
5 2 12561 42175 7845 3.5 11.7 2.2
6 2 441 90839 4986 0.1 25.2 1.4
7 3 8134 22383 9564 2.2 6.2 2.6
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
50578 206296 71582 14.0 57.4 19.9
Table 4.6-2
Transaction Work Load Distribution
The estimated work load for each database backend machine
CRDB is given below.
̲ ̲ ̲ ̲P̲e̲a̲k̲ ̲H̲o̲u̲r̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲e̲a̲k̲ ̲S̲e̲c̲o̲n̲d̲ ̲ ̲
̲
CRDB reads writes reads writes
1 50899 49187 14.1 13.7
2 133000 12831 37.0 3.6
3 22383 9564 6.2 2.6
Table 4.6-2
Database Work Load Distribution
4.7 E̲Q̲U̲I̲P̲M̲E̲N̲T̲ ̲U̲T̲I̲L̲I̲Z̲A̲T̲I̲O̲N̲
The derivation of the equipment utilization figures
is based on conservative estimates of CPU power, disk
access times and transaction execution time. The utilization
rates are computed for the peak hour and are subject
to the following factors:
- the utilization rate is computed as a ratio
consumed time/available time
or consumed memory/available memory
- the CPU is capable of executing 2x10…0e…6…0f… instructions/second
- peak second figures are devived as 1/3600 of peak
hour figures
- an average disk "read" or "write" takes 50 ms
- execution of 1 File Management System (FMS) commands
requires 4x10000 instructions = 20 ms CPU time
- memory sizes for standard software components ar
as follows:
ORION Kernel 40 KB
FMS 60 KB
High level
operating system 100 KB
(used in communi-
cation subsystem)
Transaction Pro-
cessing System 200 KB.
4.7.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The file management system (PS # 7) overhead per transaction
due to disk "reads" necessary to start a worker process
is assumed to be 1 command and 1 disk "read".
The estimates of the number of instructions executed
for each major transaction type is given below:
Database
P̲S̲ ̲ ̲ ̲ ̲N̲o̲.̲ ̲I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲s̲/̲t̲r̲a̲n̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲"̲r̲e̲a̲d̲s̲"̲ ̲ ̲"̲w̲r̲i̲t̲e̲s̲"̲/̲t̲r̲a̲n̲s̲
̲ ̲ ̲ ̲ ̲ ̲
4 10x10000 = 50 ms 2 2
5 15x10000 = 75 ms 3 1
6 1000x10000 = 5000 ms 206 10
7 20x10000 = 100 ms
File management system
4x10000 = 20 ms 3 1
The total number of transactions per peak hour is estimated
to be app. 50000 transactions.
4.7.1.1 C̲P̲U̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
Given the peak hour transaction load given in table
4.6-2, the derived CPU utilization figures are as follows:
Real Time
P̲S̲ ̲ ̲ ̲ ̲W̲o̲r̲k̲ ̲L̲o̲a̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲ ̲ ̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
4 29442 transactions x 50 ms = 1472s 0.40
5 12561 transactions x 75 ms = 942s 0.26
6 441 transactions x 5000 ms = 2205s 0.61
7 8134 transactions x 100 ms = 813s
FMS:
5̲0̲0̲0̲0̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲ ̲x̲ ̲2̲0̲ ̲m̲s̲ ̲=̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲0̲0̲0̲s̲ ̲ 0.50
1813
These figures are well below the max. required utilization
figures of 50%, but they exclude the overhead due to
process communication, processor-to-
processor communication, etc.
4.7.1.2 M̲e̲m̲o̲r̲y̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
The number of concurrently executing worker processes
for each processes is based on the number of new worker
processes initiated during the peak second and the
expected mean elapsed execution time which are as follows:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲e̲a̲k̲ ̲S̲e̲c̲o̲n̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
PS Mean Elapsed No. Transactions No. Concurrent
̲ ̲ ̲ ̲ ̲T̲i̲m̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲W̲o̲r̲k̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
4 3s 8 24
5 3s 4 12
6 45s 0.1 5
7 2s 2.2 4
The mean elapsed time is a pessimistic estimate which
is based on the baseline requirement that the terminal
response time for most transactions of 4s must be met.
The memory utilization figures for the processor sections
are as follows:
PS Contribution from Memory Utilization
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ c̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
4 ORION 40 KB
Transaction processing
system 200 KB
2̲4̲ ̲p̲r̲o̲c̲e̲s̲s̲e̲s̲ ̲x̲ ̲6̲0̲ ̲K̲B̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲4̲4̲0̲ ̲K̲B̲
Total 1660 KB 0.55
5 ORION 40 KB
Transaction processing
system 200 KB
12 processes x 50 KB 600 KB
F̲o̲r̲m̲a̲t̲/̲t̲o̲t̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲8̲0̲0̲ ̲K̲B̲
Total 1640 KB 0.54
6 ORION 40 KB
Transaction processing
system 200 KB
5 processes x 80 KB 400 KB
F̲o̲r̲m̲a̲t̲/̲t̲o̲t̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲8̲0̲0̲ ̲K̲B̲
Total 1440 KB 0.48
7 ORION 40 KB
Transaction processing
system 200 KB
File management system 60 KB
4̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲ ̲x̲ ̲5̲0̲ ̲K̲B̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲2̲0̲0̲ ̲K̲B̲
Total 500 KB 0.25
4.7.1.3 D̲e̲v̲i̲c̲e̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
D̲i̲s̲k̲
The number of disk accesses to disk connected to PS#7
and managedment system is 50000 "reads".- This load
is distributed on 2 mirrored disks. If one "read" takes
50 ms than the disk utilization rate is 0.34.
Lower disk utilization rate can be achieved by increasing
number of disks.
D̲a̲t̲a̲b̲a̲s̲e̲ ̲d̲i̲s̲k̲s̲
The number of database disks utilized by CRDB's and
the number of peak second logical record accesses is
summarized as follows:
P̲e̲a̲k̲ ̲S̲e̲c̲o̲n̲d̲ P̲e̲a̲k̲ ̲S̲e̲c̲o̲n̲d̲
C̲R̲D̲B̲ N̲o̲ ̲D̲i̲s̲k̲s̲ "̲R̲e̲a̲d̲s̲"̲ "̲W̲r̲i̲t̲e̲s̲"̲ D̲i̲s̲k̲ ̲r̲e̲a̲d̲s̲ D̲i̲s̲k̲
̲w̲r̲i̲t̲e̲s̲
1 2 14 14 3 14
2 2 37 4 7
4
3 2 6 2 1
1
The number of actual physical disk reads is estimated
to be 1/5 of the logical record accesses due to disk
caching and indexing.
The maximum disk utilization rete is estimated as follows:
(3 "reads + 14 "writes") * 50ms /2 disks = 425 ms,
disk utilization rate is 425 ms/1000 ms = 0.42.
C̲R̲D̲B̲
The number of peak second transaction local or database
machines is based on the assumption that each logical
data record access requires an average 15 ms CRDB CPU
time.
The utilization of the CRDB's is as follows:
C̲R̲D̲B̲ W̲o̲r̲k̲ ̲l̲o̲a̲d̲,̲ ̲d̲u̲r̲i̲n̲g̲ ̲p̲e̲a̲k̲ ̲h̲o̲u̲r̲ U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
1 100,000 record accesses x 15 ms =
1,500 s 0.41
2 145,000 record accesses x 15 ms =
2,175 s 0.60
3 31,947 record accesses x 15 ms =
468 s 0.13
4.7.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The baseline parameteres used for communication subsystem
utilization are given below.
Communication system overhead:
1 x 10,000 instructions per message = 5 ms
1 instruction per byte = 5 ms
File Management system (FMS) overhead:
4 x 10,000 instructions per command = 20 ms
One FMS command is issued for each input transaction.
Based on table 4.2.2-3 the following figures for peak
hour load are derived:
UNITER: 60% of 95011 messages = 57007 msg
60% of 59.9 Mbytes = 35.9 Mbytes
LOCAL: 40% of 95011 messages = 38004 msg
40% of 59.9 Mbytes = 24.0 Mbytes
CAMPS: 575 msg
0.9 Mbytes
ACENET: 1 msg
0.012 Mbytes
DISK: 29198 logs
4.7.2.1 C̲P̲U̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
The load contributions are:
UNITER 57007 x 5 ms + 35.9 M x 0.5 = 302 s
LOCAL 38004 x 5 ms + 24.0 M x 0.5 = 202 s
CAMPS 575 x 5 ms + 0.9 M x 0.5 = 3 s
ACENET low
File management system 29198 x 20 ms = 584 s
Assuming that 20% of the UNITER load is on PS#1 and
80% is on PS#3 the final CPU utilization is as follows:
PS Work load Real time Utilization
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ c̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
1 File management
system 584 s
U̲N̲I̲T̲E̲R̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲6̲0̲ ̲s̲
Subtotal 644 s 0.18
2 Local
communication 202 s
C̲A̲M̲P̲S̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲3̲ ̲s̲
Subtotal 205 s 0.05
3 UNITER 241 s 0.06
The CPU utilization figures are well below the max.
utilization figure of 50%, but they exclude the overhead
of process communication, processor-to- processor communication
and the workload due to text and graphics hard copy.
4.7.2.2 M̲e̲m̲o̲r̲y̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
The number of concurrently executing subscriber processes
communicating with the operator workstation is as follows:
PS c̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲f̲r̲o̲m̲
1 20% UNITER Workstations = 50 processes
2 64 Local Workstations = 64 processes
3 80% UNITER Workstations = 200 processes
These figures apply for the situation when all of the
workstations are logged on the most system - a typical
situation for the peak hour.
It is assumed that the host resident subscriber process
executes a reentrant code.
The memory consumption of each subscriber process is
4 KB. This figure compares well with the average input
message size of 170 bytes and average output message
size of 560 bytes and leaves enough space for process'
private data and system buffers.
The final memory utilization is:
PS Contribution from Memory Utilization
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ c̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
1 ORION 40 KB
File management
system 60 KB
High level op. sys. 100 KB
Communic. buffers 200 KB
Subscriber
p̲r̲o̲c̲e̲s̲s̲e̲s̲ ̲5̲0̲ ̲x̲ ̲4̲ ̲ ̲ ̲ ̲ ̲ ̲2̲0̲0̲ ̲K̲B̲
Total 800 KB 0.40
2 ORION 40 KB
High level op. sy. 100 KB
Communic. buffers 200 KB
Subscriber
p̲r̲o̲c̲e̲s̲s̲e̲s̲ ̲6̲4̲ ̲x̲ ̲4̲ ̲ ̲ ̲ ̲ ̲2̲5̲6̲ ̲K̲B̲
Total 596 KB 0.29
3 ORION 40 KB
High level op. sy. 100 KB
Communic. buffers 400 KB
Subscriber
p̲r̲o̲c̲e̲s̲s̲e̲s̲ ̲2̲0̲0̲ ̲x̲ ̲4̲ ̲ ̲ ̲ ̲ ̲8̲0̲0̲ ̲K̲B̲
Total 1340 KB 0.67
4.7.2.3 D̲e̲v̲i̲c̲e̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
D̲I̲S̲K̲
The number of disk "writes" during peak hour is 29473,
which amounts to 8 disk "writes" during peak second.
If one "write" takes 50 ms then the disk's utilization
rate is 0.40. Lower disk utilization rate can be achieved
by increasing number of disks.
4.8 R̲E̲S̲P̲O̲N̲S̲E̲ ̲T̲I̲M̲E̲ ̲D̲E̲R̲I̲V̲A̲T̲I̲O̲N̲
The response time for execution of an average transaction
is estimated below.
An "average" transaction is transaction IB og IC executing
on PS#4, PS#5 or PS#6 and accessing CRDB#2.
T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
Input message size 160 characters
Output message size 600 characters
1 disk access, PS#1
2 disk accesses, PS#7
execution of worker process 15 x 10000 instructions
= 75ms
4 database logical record accesses = 60 ms
2 physical database disk accesses = 100 ms
R̲e̲s̲p̲o̲n̲s̲e̲ ̲t̲i̲m̲e̲ ̲d̲e̲r̲i̲v̲a̲t̲i̲o̲n̲
Input message handling 1x10000 instructions 5
ms
FMS, PS#1 1 command 4x10000 instructions 20
ms
1 disk access 50
ms
Transmission of input message to next
processor 25
ms
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
Input part 100
ms
FMS, PS#7, 1 command 4 x 10000 instructions 20 ms
1 disk accesses 50 ms
transmission of data between PS#7
and PS#5 or PS#$ 300 ms
execution of worker process 75 ms
4 logical databare disk 60 ms
2̲ ̲p̲h̲y̲s̲i̲c̲a̲l̲ ̲d̲a̲t̲a̲b̲a̲r̲e̲ ̲d̲i̲s̲k̲ ̲a̲c̲c̲e̲s̲s̲e̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲0̲0̲ ̲m̲s̲
Processing part 605 ms
Transmission of output message to a
communication processesor 75 ms
O̲u̲t̲p̲u̲t̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲5̲ ̲m̲s̲
Output part 80 ms
=================================================
Total 785 ms
5̲ ̲ ̲S̲Y̲S̲T̲E̲M̲ ̲A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲
The availability of the proposed equipment is very
high due to not only a high reliability of individual
system elements, but mainly due to the chosen CR90
computer configuration, where functionally identical
elements substitute each other automatically in case
of failure.
The availability will exceed the requirements, due
to the exceptional design of the CR90 configurations.
5.1 G̲E̲N̲E̲R̲A̲L̲ ̲C̲O̲N̲S̲I̲D̲E̲R̲A̲T̲I̲O̲N̲S̲
The high system availability will be achieved by the
use of highly reliable modules, triplicated processor
units and automatic error detection and correction
facilities. Care has been taken in the design to ensure
that single point errors do not cause total system
failure.
To ensure a very high system availability the following
three basics redundancy principle are implemented and
completely supported in hardware.
I Central processors
are triplicated,
meaning that
a failing
processor
immediately
can be detected
and isolated
without disturbing
the system
operation
and without
software
support.
II RAM memory
is implemented
with built
in Error
Detection
and Correction
facilities.
III Data buses
are duplicated
which together
with error
detection
bits ensure
that a failing
data bus
immediately
can be detected
and isolated
without impact
on the system
operation.
IV Very flexible
input/output
concept which
allow for
implementing
redundancy
to the level
required
by the specific
application.
The reliability criteria imposed on the computer systems
have been evaluated and the proposed hardware/software
operational system analysed to determine the degree
of availability and data integrity provided. In this
chapter reliability is stated in numerical terms and
the detailed predictions derived from mathematical
models presented.
The availability predictions are made in accordance
with system reliability models and block diagrams corresponding
to the proposed configuration. This procedure involves
the use of module level and processor unit level failure
rates, or MTBF, (mean time between failures) and MTTR
(meantime to repair); these factors are used in conjunction
with a realistic modeling of the configuration to arrive
at system level MTBF and availability.
Tabulated results of the analysis are presented including
the reliability factors: system MTBF and MTTR.
The basic elements of the proposed system architecture
are composed of standard CR90 units. Reliability and
maintainability engineering was a significant factor
in guiding the development of the CR90.
The CR90 architecture is designed with a capability
to achieve a highly reliable computer system in a cost-effective
way. It provides a reliable set of services to the
users of the system because it may be customized to
the actual availability requirements. The CR90 fault
tolerant computers are designed to avoid single point
errors of all critical system elements by provision
of redundancy paths, multi-processor capabilities and
dual power supplies.
The architecture reflects the fact that the reliability
of peripheral devices is lower than that of the associated
CR90 device controllers. This applies equally well
to communication lines where modems are used as part
of the transmission media. Thus, the peripheral devices,
modems, communication lines, etc., impact the system
availability much more than the corresponding device
controllers.
To assure this very highly reliable product, several
criteria was also introduced on the module level:
- An extensive use of hi-rel, mil-spec components,
ICs are tested to the requirements of MIL-STD 883
level B or similar
- All hardware is designed in accordance with the
general CR90 H/W design principles. These include
derating specification, which greatly enhance the
reliability and reduce the sensibility to parameter
variations
- Critical modules feature a Built-In Test (BIT)
capability as well as a display of the main states
of the internal process. This greatly improves
module maintainability, as it provides debugging
and trouble shooting methods, which reduce the
repair time
- A high quality production line, which includes
high quality soldering, inspection, burn-in and
an extensive automatic functional test
- Software reliability is another aspect which will
be incorporated in achieving high over all availability
- Data has been replicated in order to increase system
availability by mirroring all discs both directly
connected to the CR90 and connected to the CRDB
- Automatic and manual facilities are provided to
perform quick reconfiguration in case of errors
- Extensive M & D, maintenance and diagnostic software
can be used to minimize down times.
5.2 R̲E̲C̲O̲V̲E̲R̲Y̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
Flexible variation in the size and structure of the
CR90 system are permitted by the unusual degree of
hardware and software modularity. The hardware essentially
consists of fast transfer buses joined to each other
by adapters which allow units on one bus to access
those on another. Dualization at the internal level
and multiple redundancy at the system level provide
a CR90 hardware architecture which is exploited by
the ORION Kernel and the operating system extensions
to survive operational failure of individual components.
Reliability, which is increasingly becoming of concern
in real-time and distributed network applications,
is achieved in the CR90 computer systems by applying
unique architectural concepts. Fault tolerance and
backup are achieved through a redundance scheme without
preassignment of system functions to specific processors.
This is in marked contrast to the more common rigid
dualized configurations often encountered in dedicated
applications with on-line master/slave arrangements,
or off-line backup with switchover facility.
Performance degradation may result from the occurrence
of a failure if it happens durings peak load, because
systems resources are used to recover from errors.
As an example, consider the mirrored disc. If a head
crash occurs on one of the discs, then a fresh blank
disc must be inserted, and all information must be
moved from the non-failed disc to the fresh disc. This
requires more disc activity than normal operational
use, so it might affect performance levels during peak
load situations. Of course the operator can choose
to wait with disc restoration till after peak load,
but this must be considered unrecommendable, because
the system is not able to recover from the next failure.
Various degradation strategies can be programmed in
the system, which initiates all automatic reconfigurations.
The system operator may override this by enabling/disabling
various devices and he may also perform physical reconfiguration
by removing/replacing the various hardware modules.
This can be done without taking the power off the system.
5.3 F̲A̲L̲L̲B̲A̲C̲K̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
As described earlier, the CR90 configuration has been
designed to provide maximum availability. This means
that several fallback procedures have been implemented
at the hardware and system software level. Logical
addressing is used throughout the system, which make
it possible to access the system from an alternative
terminal or print out on an alternative hardcopy device
subject to security constraints.
In excess of the standard fall back procedures implemented
in hardware and system software, like the mirrorred
disc concept, procedural fall back procedures may be
implemented and enforced by the system.
5.4 R̲E̲C̲O̲V̲E̲R̲Y̲ ̲T̲I̲M̲E̲S̲
Recovery times are minimized throughout the system
by using automatic recovery wherever possible. This
approach eliminates all operator reaction time, which
is normally several magnitudes greater than procederal
methods. The actual recovery times depends very much
on the circumstances.
Reintroducing modules as part of restoring a failed
system under system operator control, will be dominated
by operator reaction time, but good procedural rules
and guidelines can minimize the time required.
The system operator can advise users of any planned
system facilities reduction.
5.5 M̲E̲A̲N̲-̲T̲I̲M̲E̲-̲B̲E̲T̲W̲E̲E̲N̲-̲F̲A̲I̲L̲U̲R̲E̲ ̲(̲M̲T̲B̲F̲)̲
The high reliability of the proposed equipment is achieved
through use of proven failure rate equipment similar
to that supplied for other programs.
Early in the design phase, a major objective for each
module is to achieve reliable performance. CR90 modules
make extensive use of carefully chosen components;
most of the IC…08…s are tested to the requirement of MIL-STD
883 level B.
The inverse of MTBF representing failure rate which
applies to system elements and modules is listed.
The MTBF data has been derived from reliability data
maintained on similar programs. Inherent MTBF values
are in general derived from the reliability predictions
accomplished in accordance with the U.S. MIL-HDBK-217
"Reliability Predictions of Electronic Equipment".
Failure rate data for terminal and peripheral equipment
is generally provided by the vendor in accordance with
the subcontract specifications.
The MTBF and MTTR figures are supplied in the following table
for equipment which will form a part of the UKARI CCIS
MTBF LAMBCLA MTTR
M̲o̲d̲u̲l̲e̲ ̲d̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲h̲o̲u̲r̲s̲)̲ ̲ ̲ ̲ ̲ ̲(̲f̲p̲m̲h̲)̲ ̲ ̲ ̲ ̲ ̲(̲m̲i̲n̲u̲t̲e̲s̲)̲
1 Bus Interface 36500 27 30
2 Status and control panel 200000 5 30
3 Majority Voter 14100 71 30
4 Central Processor (with 2MB Kam) 13900 72 30
5 Busswitch 14100 71 30
6 IEEE 488 I/F 45000 22 30
7 DESC CTRL (single bus 16K) 39400 25 30
8 RAM (1MB) 27800 36 30
9 LAN I/F 45000 22 30
10 LTU X25UNITER 45000 22 30
11 LTU CAMPS 45000 22 30
12 LTU ACENET/NICS 45000 22 30
13 LTU (local I/0) 45000 22 30
14 CRATE Dual PS 230000 5 60
15 Power Supply 26800 37 30
16 CRDB 8200 122 60
17 CRDB Disc CTRL 27700 36 30
18 CRDB Tape CTRL 27700 36 30
19 Add CRDB 488 I/F 117500 9 30
20
21 CDC 9710 RSD (80 MB) 8000 125 60
22 CDC 9715-340 FSD (344 MB) 11250 89 60
23 CDC 9715-500 FSD (516 MB) 11250 89 60
24 Tape drive 8000 125 60
25 RACKS - Tempest - 0 -
26 FAN UNITS 197 years 2 60
27 Internal Rack Cabling - 0 -
28 Mains Filter 625000 1.6 30
29
30
31 CR86T 5-10.000 200-100 -
32 Filterbox - 0 -
33 Power Line Filter - - -
34
35 LAN NET - - -
36 LAN I/O BOX (Dual + Filter) - - -
5.6 M̲E̲A̲N̲-̲T̲I̲M̲E̲-̲T̲O̲ ̲R̲E̲P̲A̲I̲R̲ ̲(̲M̲T̲T̲R̲)̲
The proposed system is designed for ease of maintenance.
The system is built of modules each comprising a complete
well-defined function. Replacement of modular units
result in minimum repair time. Software and firmware
diagnostic routines rapidly isolate faulty modules;
repair can then be performed by semi-skilled maintenance
personnel and usually without special tools.
The proposed system, composed of redundant elements,
meets the objective of ease of maintenance. All units
and system elements are of a modular construction so
that any defective module can be isolated and replaced
in a minimum amount of time.
In the design of the system elements, careful attention
was given to ease of maintenance without requiring
special tools, so that the maintenance could be performed
by semi-skilled maintenance personnel.
Fault detection and isolation to the system element,
in som cases module level, is inherent in the software
residing in the various processors. In peripheral devices,
the fault detection and isolation is accomplished by
a combination of on-line software, built-in test, and
operator observations.
An off-line diagnostics software package can be employed
to ease the diagnostics in case of error. Normally,
this software package is stored on disc. After initiation,
the program will test all modules forming the system
and print the name and address of the erroneous module
on the operator…08…s console. Having replaced the erroneous
module, the Processor is ready for operation again.
The operator might, if necessary, run the off-line
diagnostics program once more to verify that the system
is now working without errors.
The command interpreter module of the diagnostic package
enables the operator to initiate any or all of the
test programs for the specific subsystem off-line,
to assist in trouble shooting and to verify the repair.
The diagnostic package will also assist in fault isolation
of the peripherals. However, common and special test
equipment might have to be used to isolate the faulty
module.
The Mean-Time-To-Repair for the equipment is derived
from two sources. The first is actual experience data
on similar equipment to the proposed for the system.
The other source is from predictions generated in accordance
with MIL-HDBK-472 or similar documents. As an example,
the MTTR for the Disk Storage Unit was derived from
repair times measured by the supplier. The repair times
of other units were derived by a time-line analysis
of the tasks associated with fault detection, isolation,
repair, and verification. These repair times were weighted
by the MTBF of each module to derive the unit MTTR.
The calculation of the Mean-Time-To-Repair (MTTR) is
done by weighting the individual module repair times
by the MTBF of the individual module. The estimated
MTTRs of the major CR90 modules are presented.
The predicted MTTR values are from experience with
modules of other programs. The predicted MTTR assumes
that all tools, repair parts, manpower, etc., required
for maintenance are continuously available.
The following figure shows a typical fault isolation
and replacement sequence, when skilled people are used.
Figure 5.6-1…01…Typical Fault Isolation and…01…Replacement Sequence
5.7 O̲V̲E̲R̲A̲L̲L̲ ̲S̲Y̲S̲T̲E̲M̲ ̲A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲
The UKAIR CCIS ADP system has been designed with the
objective of providing an extremely highly available
system.
The computer system is partitioned into system elements
and the model used for reliability and availability
prediction shows how the proposed quipment provides
the high degree of reliability required.
The reliability characteristics for the system are
stated in numerical terms by a mathematical model.
The supporting detailed prediction is presented in
this chapter. Figures and tables 5.7-1 to 5.7-6 show
the model. For ease of calculations an MTTR of 1 hour
is used as standard although 30 minutes are more realistic
for nearly all modules, see preceeding tables. The
system model is partitioned into modular units and
system elements that reflect the redundancy of the
configuration; it accounts for all interconnections
and switching points. The MTBF and MTTR for the individual
elements used in the calculations were obtained from
experience with similar equipment on other programs.
Notes to indevidual models:
* Figure 5.7-1 and 5.7-2. the disc drives have not
been included since the input logging is not essential
for the normal operation of the communication.
The model is derived for the two UNITER interfaces.
The real availability for UNITER is higher, since
a second set is available at Processor Section
# 3. The model is equally valid for LAN communication,
excluding the LAN communication itself. The model
also covers the CAMPS and ACENET interfaces.
* Figure 5.7-3 and 5.7-4. The model is derived for
the message processing, but is equally valid for
the other Processor Sections dealing with Totes,
Special Applications, Formats etc.
* Figure 5.7-5 and 5.7-6. This model shows the combined
availability of the critical communication processing
and message processing. The model is equally valid
for most of the applications.
The equipment has been partitioned and functions apportioned,
so that system elements can have only two states -
operable or failed. System elements are essentially
stand-alone and free of chain failures.
Careful attention has been paid in the design to eliminate
series risk elements. Redundant units are repairable
without interruption of service. Maintenance and reconfiguration
are possible without compromising system performance.
The primary source selected for authenticated reliability
data and predictions is the MIL-HDBK-217. The failure
rate data are primarily obtained from experience from
previous programs and continuously revised as part
of the maintenance program on concurrent programs.
Figure 5.7-1…01…
Processor Section 1
Reliability model
Critical communication processing
Lambda
U…0f…S…0e…
NO ITEM M of N MTBF Lambda MTTR equiv M
of
N
DESCRIPTION Req'd (hours) (fpm) (hour) (fpm) (hours)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 FAN UNIT 2 1
2 CRATE 5 1
3 Total both
7
4 PWR Supply 37 1
5 Total 1 of 2 1 0.002
6 CPU 72 1
7 Total 2 of 3 1 0.031
8 BUS I/F 27 1
9 1 of 2 1 0.001
10 BUS SWITCH 71 1
11 X25 22 1
12 Total both 93 1
13 Total 1 of 2 1 0.017
14 Critical
path. 3,5,7,9,13 1 7.051 141800
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Availability= 0.999993
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 5.7-2
Processor Section 1
Critical communication processing
Figure 5.7-3…01…
Processor Section 4
Reliability model
Message Database Processing
Lambda
U…0f…S…0e…
NO ITEM M of N MTBF Lambda MTTR equiv M
of
N
DESCRIPTION Req'd (hours) (fpm) (hour) (fpm) (hours)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 FAN UNIT 2 1
2 CRATE 5 1
3 Total both 7 1
7
4 Power Supply 37 1
5 CPU 72 1
6 BUS I/F 27 1
7 RAM 36 1
8 Total both 63 1
9 1 of 2 0.008
10 Busswitch 71 1
11 488 22 1
12 CRDB 122 1
13 all 215 1
14 1 of 2 0.092
15 Disc (2 drives) 2 x 125 1
16 1 of 2 7.258 137800
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Availability = 0.999993
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 5.7-4
Processor Section 4…01…Reliability model…01…Message Database Processing
Figure 5.7-5…01…
System Availability Model…01…
Lambda
U…0f…S…0e…
ITEM M of N MTBF Lambda MTTR equiv M
of
N
DESCRIPTION Req'd (hours) (fpm) (hour) (fpm) (hours)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Critical Communi-
cation Processing 7.051 1 7.051
Data Highways
Total 1 of 2 0.000002
Message Database
Processing 7.258 1 7.258
TOTAL 14.309 69886
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Availability = 0.999987
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 5.7-6
System Availability
Lambda U…0f…S…0e…
M of N MTBF Lambda MTTR equiv M of N
Req'd (hours) (fpm) (hour) (fpm) (hours)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PS # 1 7.051
# 2 7.051
# 3 7.051
# 4 7.258
# 5 7.258
# 6 7.258
# 7 7.258
# 8 7.258
Total 57.443 17.410
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Availability = 0.999943
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 5.7-7
Total System Availability
The equivalent calculated overall availability, see
figure 5.7-7, will be above
.9999
=====
For safety reasons MTTR figures used for a calculations
are very conservative, typically 30 minutes, but a
much better result can be obtained when operators and
maintenance people are carefully instructed and trained.
5.8 A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲ ̲O̲B̲J̲E̲C̲T̲I̲V̲E̲S̲
The requirements to the ADP system are shown in figure
5.8-1. As the preceeding section shows these requirements
are more than met on the availability.
No downtime is expected for the system, since most
modules can be exchanged during operation. The major
source for downtime is expected to be due to external
power failures.
The communication subsystems will not require switching,
but for the standby database machines, the switching
time limit of 3.5 minutes can easily be met.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲A̲V̲A̲I̲L̲.̲ ̲ ̲ ̲ ̲ ̲ ̲M̲D̲T̲ ̲(̲h̲)̲ ̲ ̲ ̲ ̲ ̲ ̲M̲S̲T̲
̲(̲m̲i̲n̲)̲
Central Configuration PSWHQ 0.9995 2 3.5
min
AWHQ 0.9995 2 3.5
min
Data comms. Subsystem PSWHQ 0.99995 0.5 1 sec
AWHQ 0.99995 0.5 1 sec
Workstation PSWHQ 0.9994 0.5
AWHQ 0.9994 0.5
Figure 5.8-1
Availability Objectives
