top - download
⟦7fb844744⟧ Wang Wps File
Length: 83255 (0x14537)
Types: Wang Wps File
Notes: LKSAA Vol. II part 1
Names: »4240A «
Derivation
└─⟦84f7719fc⟧ Bits:30006031 8" Wang WCS floppy, CR 0385A
└─ ⟦this⟧ »4240A «
WangText
…00……00……00……00……00…I…02……00……00…I H…0b…H G…0c…G…05…F…0d…F…05…F…06…,
+…09…+…0d…+…06…*…05……16……00……16……01……16……07……15……0c……15……01……15……05……15……06……14……0a……14……0b……14……0c……14……02……14……06……13……0b……13……0d……13……0e……13……02……13… …12……0a……86…1 …02… …02… …02… …02…
Issue 1.5
LKSAA - VOLUME II SYS/84-06-15
Part 1
TECHNICAL PROPOSAL Page #a
2.3 A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲N̲E̲T̲S̲
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 CR80
computer configuration, where functional like elements
substitute each other automatically in case of failure.
The actual availability will be very close to 100%,
due to the exceptional design of the CR80 configuration
for the LKSAA.
2.3.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 has been achieved by the
use of highly reliable modules, redundant processor
units and automatic reconfiguration facilities. Care
has been taken to ensure that single point errors do
not cause total system failure.
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 repair time
MTTR.
The basic elements of the proposed system architecture
are constituted by standard CR80 units. Reliability
and maintainability engineering was a significant factor
in guiding the development of the CR80.
The CR80 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 CR80 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
CR80 device controllers. This applies equally well
to communication lines where modems are used as part
of the transmision media. Thus, the peripheral devices,
modems, communication line, etc., impact the system
availability much more than the corresponding device
controllers.
To assure this very highly reliable product, several
criteria were 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 CR80 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 by Light Emitting Diodes
on the module front plate. 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
- 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.
2.3.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
CR80 system used for the LKSAA 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 CR80 hardware architecture which
is exploited by the DAMOS software operating system
and programs 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 CR80 computer systems by applying
unique architectural concepts. The CR80 hardware/software
architecture treats all multiprocessors as equal elements
not absolutely dedicated to a specific role. 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.
All redundant equipment is under control of a watchdog
micro-computer, which constantly receives information
on all subsystems status. This strategy ensures that
all units are ready to operate if any reconfiguration
is needed.
The LKSAA has been sized to deal with the required
data volumes by use of primary hardware only.
Performance degradation may result from the occurence
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.
Similarly, when errors occur in one of the two processing
units, the system can continue operation with reduced
facilities in a graceful degradation mode, but it must
be realized than following errors might be catastrophic.
Various degradation strategies can be programmed in
the watchdog, 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.
In principle, users will be automatically recovered
from hardware errors, when they occur on a fully redundant
system, but in some instances it may be necessary to
ask the users to reenter his last input transaction.
The CR80 Operating System as well as application processes
contains a large number of error detection routines.
A detected error or inconsistency will result in a
report to the high level operating system, which will
then report the error on the operator console and call
a basic error module. If the error is fatal a termination
will occur and the watchdog will detect that keep-alive
messages from the active system are missing. This results
in automatic switchover and recovery.
2.3.3 F̲a̲l̲l̲b̲a̲c̲k̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
As described earlier, the CR80 configuration for LKSAA
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 mirrored
disc concept, procedural fall back procedures may be
implemented and enforced by the system. As an example
the parameterized distribution tables found in CAMPS
and implemented in LKSAA, can provide a copy of all
messages to be printed on a specific terminal.
2.3.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 automated
procedures. 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.
2.3.5 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 LKSAA system has been designed with the objective
of providing an extremely high 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. 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.
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 continously revised as part of
the maintenance program on concurrent programs.
The reliability model which applies to the proposed
configurations is identified in the figure shown in
the following.
The model that has been calculated covers the basic
operational system. In order to improve availability
for the minimal system and the Communication Handling
system to an even higher degree, you can ensure higher
spare part availability on important modules, which
can be easily introduced as part of a fall back procedure.
The crypto subsystem has not been reliability modelled,
because the dedicated encryption/decryption device
is not known to CHRISTIAN ROVSING A/S at this time.
However, CHRISTIAN ROVSING is proposing a dual Local
Area Network with a dual set of Network Managemnet
Hosts.
Figure 2.3.5-1
Reliability Model for LKSAA
User Terminal Position
2.3.6 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. CR80 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
"Reliable Predictions of Electroic Equipment".
Failure rate data for terminal and peripheral equipment
is generally provided by the vendor in accordance with
the subcontract specifications:
…06…1 …02… …02… …02… …02… …02… …02… …02… …02… …02… …02…
Module Item Description MTBF FPMH MTTR
N̲o̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲h̲r̲s̲)̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲m̲i̲n̲u̲t̲e̲s̲)̲
8002 CPU, SCM 36500 27.4 30
8003 CPU, CACHE 26100 38.3 30
8009 EPM
172400
5.8 30
8013 EPROM 91700 10.9 30
8016 RAM 128K/64K 17000/29600
58.8/33.8 30
8020 MAP 19400 51.6 30
8021 STI 32800 30.5 30
8037 UNIVAC I/F 33200 30.1 30
8039 IBM CH, I/F 32400 30.9 30
8044 DISC CTRL
DUAL 30200
33.1 30
8045 TAPE CTRL 16K 35700 28.0 30
8046 DUAL PAR.CTRL 35700 28.0 30
8047 ST.FD.CTRL
DUAL 59500
16.8 30
8050 POWER SUPPLY 26800 37.3 30
8055 MBT
285700
3.5 30
8059 MBE 10000000
0.1 30
8066 LTU DUAL 27600
36.9 30
8070 CSA
769000
1.3 30
8071 MIA 85500 11.7 30
8072 SBA 90100 11.1 30
8073 TIA
117600
8
5 30
8074 EPA
256000
3.9 30
8078 IBA 21600 46.2 30
8079 UIA 15600 64.0 30
8081 CIA A & B 71400 14.0 30
8082 LIA-N 10000000
0.1 30
8083 LIA-S (Switch +
Common) 534759/3571428 1.87/0.28 30
8084 DCA 46900 21.3 30
8085 TCA
128200
7.8 30
Module Item Description MTBF FPMH MTTR
N̲o̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲h̲r̲s̲)̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲m̲i̲n̲u̲t̲e̲s̲)̲
8086 PCA 185200 5.4 30
8087 SFA 10000000 0.1 30
8088 EIA A & B 113600 8.8 30
8106 MAINS FILTER
DISTRIBUTION 625000 1.6 30
8115 Minicrate 26300 38 60
8125/PC PU-CRATE 200000 5.0 60
8124/AB CU-CRATE 703630 1.4 60
Peripheral Item Description MTBF FPMH MTTR
N̲o̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲h̲r̲s̲)̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲(̲m̲i̲n̲u̲t̲e̲s̲)̲
8300/--- DISC DRIVE,
SMD, 40-300MB 4000 250.0 90
8301/--- DISC DRIVE,
CMD (16-48)+16MB 4000 250.0 90
8302/--- DISC DRIVE, MMD,
12-80MB 8000 125.0 60
8307/--- FLOPPY DRIVE,
dual/single 8000 125.0 30
sided
8320/001 TAPE STATION,
Pertec FT 8000 8000 125.0 60
8320/002 TAPE STATION,
Pertec FT 9000 2500 400.0 60
2.3.7 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.
In case the correct function of the system is extremely
critical, the Processors will have built-in, on-line,
diagnostic programs. Even though the Processors are
highly reliable, failures can occur; usage of the off-line
diagnostics minimizes the downtime for a system.
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 erronous module
on the operator…08…s console. Having replaced the erronious
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.
Examples of modules tested are LTU…08…s, CPU and RAM modules,
etc.
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 the equipment 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 MTTRs of
the major CR80 equipments 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 equivalent calculated overall availability will be above
99.999
======
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.
The following figure shows a typical fault isolation
and replacement sequence, when skilled people are used.
Figure 2.3.7-1
Typical Fault Isolation and…01…Replacement Sequence
Functions Failure Critical
Factor Value
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
1 Local Area Network 1.0 N/A
2 Host 1.0 A 99% …0e…1)…0f…
3 Disk storage 1.0 A 99% …0e…1)…0f…
Input/Output
4 Connections and
interfaces
5 Paper Tape Reader
6 Display Workstation
7 High Speed Printer
8 Paper Tape Punch
9 Log Printer
10 Document Printer
11 Krypto LAN 1.0 A 99% …0e…1)…0f…
12 OCR 1.0 N/A
13 Maintenance position 1.0 A 95% …0e…2)…0f…
14 Software 1.0 A 95%
R̲e̲l̲i̲a̲b̲i̲l̲i̲t̲y̲ ̲F̲a̲c̲t̲o̲r̲s̲
1) The configuration for the LKSAA has been designed
with particular emphasis on high availability as
shown in the earlier availability calculation.
The Central Processing Units has been dualized
and all disks are mirrored. The Local Area Network
for Krypto control has been dualized.
2) The maintenance position can use standard equipment
which can easily be replaced. Regarding the S/W
reliability the standard message switching software
has then been extensively tested in order to minimize
failures, and all software has been structured
so that individual programs that fail can be isolated
so that total system break down can be minimized.
2.4 I̲N̲S̲T̲A̲L̲L̲A̲T̲I̲O̲N̲
All equipment delivered by contractor is to be installed
in the FMZ (TELKO-NEUBAU) except for the TX and RX
sites.
2.4.1 F̲M̲Z̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲s̲
The equipment to be installed in the FMZ comprises
the below listed major assemblies and workstations.
A reference to the location specified by customer is
made by the numbers used in Anhang 13 of the I.F.B.:
10) 1. ZVA dual computer mounted in 5 standard 19"
racks, four disk drives, a high speed printer
and one system console position with a VDU
and a hardcopying printer.
2. Crypto computer and two crypto supervisor positions
with 2 VDU's, 1 paper tape reader and 1 printer.
3. Line switching facility mounted in a standard
19" rack. (Shalt platz and Handvermittlung).
16) Eight Message service operator positions with eight
VDU's.
6) Tape in/out position with four paper tape readers.
15) Four paper tape punch. Four printers
12) 1. Document printing system with two copiers.
2. Message service operator position with one
VDU.
3. Message distribution operator position with
one VDU and one printer.
4. Security log position with one printer.
9) Radio Control Center equipment as described below
in 2.4.2.1.
13) System Supervisor position with one color graphic
display and one printer.
Other positions:
1. One TELETEX station, location to be decided on
a Site Survey.
2. Four situation monitors to be located on distributed
positions. Location to be decided on a Site Survey.
Tables and chairs for above positions are not included
in this proposal.
2.4.2 R̲a̲d̲i̲o̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲y̲s̲t̲e̲m̲
2.4.2.1 R̲a̲d̲i̲o̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲e̲n̲t̲e̲r̲
The installation at the radio control center comprises
installation of the following equipment:
- 2 19" racks containing a dualized x-net incl. branching
boxes, XCP's, XTA's, modems and customer furnished
equipment (TT modem, ATS or ARQ).
- 6 workstations, each of one VDU, an interface box
and a loudspeaker.
- 1 log printer and a customer provided teletype.
2.4.2.2 T̲X̲ ̲S̲t̲a̲t̲i̲o̲n̲
At each of the two TX stations, the following equipment
shall be installed:
- 2 19" racks containing a dualized x-net incl. a
branching box, XCP's, XCT's, wall outlets, modem
and customer provided transmitters.
2.4.2.3 R̲X̲ ̲S̲t̲a̲t̲i̲o̲n̲
At each of the two RX stations the following equipment
shall be installed:
- 2 19" racks containing a dualized x-net, branching
boxes, XCP's, XCT's, XTA's, wall outlets, antenna
matrix and four customer provided recievers.
2.4.3 A̲E̲ ̲-̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲s̲ ̲(̲o̲p̲t̲i̲o̲n̲)̲
The AE-installations comprise up to 10 AE workstations
and the Interface (signal cables) with the computers.
The type of the workstations is TBD.
2.4.4 T̲y̲p̲i̲c̲a̲l̲ ̲L̲a̲y̲o̲u̲t̲
a) A typical layout of the ZVA computer area are shown
in figure 2.4-1. The equipment shown comprises:
- Pos P1-P5 dual main processor mounted in 5
standard 19" racks.
- One position (Table) with one system console.
The console comprises a visual display unit
with keyboard and hardcopy printer.
- Four 300 MB SMD disc drives, selfcontained.
ZVA Computer Area
TYPICAL LAYOUT
Figure 2.4-1
b) The layout reflects the floor space required by
cabinets and operator position. The access dimensions
for racks and terminal equipment are shown in figure
2.4-2 and 2.4-3. The racks and disc cabinets are
positioned such that sufficient clearance is maintained
for access to the front and rear of the equipment.
Otherwise, only few constraints as to the placement
of the equipment exist. The final layout will take
into account human factors, segregation of functional
activities, access for maintenance and other considerations
or preferences of the operating personnel.
One of the tasks to be performed at the site survey
is to work out the optimal layout in conjunction
with customer.
RACK ASSEMBLIES, DIMENSION AND ACCESS
FIGURE 2.4-2
TERMINAL EQUIPMENT
TYPICAL LAYOUTS AND ACCESS REQUIREMENTS
FIGURE 2.4-3
c) It is anticipated that the equipment room will
be provided with a computer floor. The heaviest
rack is well within the standard floor load limit
of 1000 Kp/m…0e…2…0f… for the computer floor as can be
seen from the following calculation:
Floor load of the heaviest rack:
W̲e̲i̲g̲h̲t̲ ̲ ̲ ̲ ̲ ̲ ̲= ̲ ̲ ̲ ̲ ̲ ̲2̲6̲0̲ ̲k̲g̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ = 413 Kg/sq.mtrs
Floor Space 0.6 x 1.05 sq.metres
Since the rack is provided with access space at
front and rear, the distributed floor load is considerable
smaller. Equipment weight and dimensions are given
in table 2.4-4.
EQUIPMENT UNIT ̲ ̲ ̲ ̲U̲N̲I̲T̲ ̲S̲I̲Z̲E̲ ̲C̲M̲ ̲ ̲ ̲ ̲ ̲ ̲A̲C̲C̲E̲S̲S̲
̲C̲M̲ ̲
WEIGHT
POS KG WIDTH DEPTH HEIGHT FRONT REAR
NO ITEM
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P1 Proc.Rack 260 60 105 180 120 100
P2 Proc.Rack 210 60 105 180 120 100
P3 Proc.Rack 260 60 105 180 120 100
P4 Proc.Rack 210 60 105 180 120 100
P5 Proc.Rack 260 60 105 180 120 100
SC Table 30 140 80 70 100
5
SC VDU 35 48 76 43 100
15
SC Printer 27 60 55 25 100
15
DISC 300 MB 252 59 92 92 100 100
DISC 300 MB 252 59 92 92 100 100
DISC 300 MB 252 59 92 92 100 100
DISC 300 MB 252 59 92 92 100 100
ZVA COMPUTER AREA
EQUIPMENT WEIGHT AND DIMENSIONS
TABLE 2.4-4
c) The equipment is cooled by fans with intake in
the front and exhaust at the top as shown in figure
2.4-5. The heat dissipation figures are given in
table 2.4-6.
d) Power to the equipment is fed from individual fuse
protected 220 VAC outlets. It is anticipated that
the power is supplied from a no break (UPS) system.
The equipment will operate within the following
AC power limits:
Voltage: 220 VAC single phase +/- 10 per cent.
Frequency: 50 HZ +/- 4 per cent
Except for the proposed CDC disc drives which will
require the following limits in order to operate
without degraded performance:
Voltage: 220 VAC single phase + 6 per cent -
10 per cent.
Frequency: 50 HZ + 1 per cent - 2 per cent.
e) E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
The CR80 Computer equipment is designed to operate/comply
with the following:
D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲s̲
o Operating: These limits apply to equipment
installed as specified and
operating in a normal office
or computer room environment.
o Storage: The limits apply to equipment
properly packed and protected
against dust, moisture, condensed
water etc.
o Transportation: These limits apply to equipment
properly packed for export.
T̲e̲m̲p̲e̲r̲a̲t̲u̲r̲e̲
o Operating: 15…0e…o…0f… C to 32…0e…o…0f…
Maximum rate of change
6…0e…o…0f… per hour
o Storage/Trans- - 40…0e…o…0f… to 70…0e…o…0f…C
portation:
H̲u̲m̲i̲d̲i̲t̲y̲
o Operating: 20 per cent to 80 per cent
RH non condensing. Maximum
rate of change 10 per cent
RH per hour.
Absolute water content in the
room air shall be limited to
22g water per cubic meter of
air.
o Storage/Trans- 10 per cent to 90 per cent
non
portation: condensing.
A̲l̲t̲i̲t̲u̲d̲e̲
o Operating: 0 to 2000 m.
o Storage/Trans- 0 to 10.000 m.
portation:
V̲i̲b̲r̲a̲t̲i̲o̲n̲
o Operating and 5 Hz to 50 Hz constant dis-
Storage: placement of 0.02 mm.
50 Hz smooth crossover
50 Hz - 350 Hz constant acceleration
0.2 g.
o Transportation: 5 Hz to 350 Hz constant acceleration
1.5 g.
S̲h̲o̲c̲k̲
o Operating and 1g, half sine wave, 10 ms duration.
Not to be repeated more often
than one per 10 seconds.
o Transportation: 25g, half sine wave, 10 ms
duration.
RACK ASSEMBLIES - AIRFLOW
FIGURE 2.4-5
E̲L̲E̲C̲T̲R̲I̲C̲A̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ A̲I̲R̲
̲C̲O̲O̲L̲I̲N̲G̲…06…1 …02… …02… …02… …02… …02… …02… …02…
…02… …02… …02… …02…
Pos. Description Qty. Volts Wires Phase Per Total Per Total
No. U̲n̲i̲t̲ ̲
̲ ̲ ̲ ̲ Unit
Kcal/
W Kw Kcal/
hour
hour
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…06…1 …02… …02… …02… …02… …02… …02… …02… …02… …02…
…02… …02…
P1 PROC RCAK 1 220 2x3 2 2900 2.9 2500 2500
P2 PROC RACK 1 220 2x3 2 2400 2.4 2060 2060
P3 PROC RACK 1 220 2x3 2 2900 2.9 2500 2500
P4 PROC RACK 1 220 2x3 2 2400 2.4 2060 2060
P5 PROC RACK 1 220 2x3 2 2900 2.9 2500 2500
DISC 300 MB 4 220 3 1 1600 6.40 1375 5500
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total 19.90
17120
CENTRAL COMPUTER, FACILITY REQUIREMENTS
TABLE 2.4-6
f) The physical characteristics including power and
environment conditions for the terminal equipment
to be installed in the FMZ area are specified in
the Terminal equipment data package appendixed
to this proposal.
The Total Power Consumption and Heat Dissipation
of the proposed equipment are specified in table
2.4.7 through 2.4.16.
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
C̲E̲N̲T̲R̲A̲L̲ ̲C̲O̲M̲P̲U̲T̲E̲R̲
CR80 + DISCS 1 19,900 19,900 17,120 17,120
S̲Y̲S̲T̲E̲M̲ ̲C̲O̲N̲S̲O̲L̲E̲
CR16 VDU 1 0,250 0,250 215 215
PT88 PRINTER 1 0,030 0,030 25 25
B-1000 1 0,600 0,600 515 515
C̲R̲Y̲P̲T̲O̲ ̲S̲Y̲S̲T̲E̲M̲
GNT28 PTR 1 0,030 0,030 25 25
PT88 PRINTER 1 0,030 0,030 25 25
CR 16 VDU 2 0,250 0,500 215 430
XTA 100 0,050 5,000 43 4,300
XAB 1 0,050 0,050 43 43
WALL OUTLET 210 0,010 2,100 8,6 1,806
GNT 28 PTR 1 0,030 0̲,̲0̲3̲0̲ 26 ̲ ̲ ̲2̲6̲
TOTAL 2̲8̲,̲5̲2̲0̲ 2̲4̲,̲5̲3̲0̲
TABLE 2.4-7
LKSAA CENTRAL COMPUTER SYSTEM
(AREA 10)
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
CR16 8 0,250 2,000 215 1720
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TOTAL 2̲,̲0̲0̲0̲ 1̲7̲2̲0̲
TABLE 2.4-8
LKSAA MESSAGE SERVICE OPERATORS
(AREA 16)
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
GNT28, PTR 4 0,030 0,120 25 100
GNT3601,PTP 4 0,060 0,240 50 200
PT88 PRINTER 4 0,030 0̲,̲1̲2̲0̲ 25 1̲0̲0̲
TOTAL 0̲,̲4̲8̲0̲ 4̲0̲0̲
TABLE 2.4-9
LKSAA TAPE IN/OUT POSITION
(AREA 6/15)
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
M̲S̲G̲E̲ ̲S̲E̲R̲V̲I̲C̲E̲ ̲O̲P̲.
CR16 1 0,250 0,250 215 215
M̲S̲G̲E̲ ̲D̲I̲S̲T̲R̲.̲O̲P̲.̲
CR16 1 0,250 0,250 215 215
PT88 PRINTER 1 0,030 0,030 25 25
S̲E̲C̲U̲R̲I̲T̲Y̲ ̲L̲O̲6̲ ̲P̲O̲S̲.
PT88 PRINTER 1 0,030 0,030 25 25
D̲O̲C̲.̲ ̲P̲R̲I̲N̲T̲G̲ ̲S̲Y̲S̲.
RX 2700 2 1,200 2̲,̲4̲0̲0̲ 1,150 2̲,̲3̲0̲0̲
TOTAL 2̲,̲9̲6̲0̲ 2̲,̲7̲8̲0̲
TABLE 2.4-10
LKSAA MESSAGE SYSTEMS
(AREA 12)
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
COLOUR GRAPHIC
8001 1 0,250 0,250 215 215
PT88 1 0,030 0̲,̲0̲3̲0̲ 25 ̲2̲5̲
TOTAL 0̲,̲2̲8̲0̲ 2̲4̲0̲
TABLE 2.4-11
LKSAA SYSTEM SUPERVISOR POS.
(AREA 13)
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
DCD1740 MONITOR 4 0,090 0,360 80 320
TELETEX 1 0,240 0̲,̲2̲4̲0̲ 205 2̲0̲5̲
TOTAL 0̲,̲6̲0̲0̲ 5̲2̲5̲
TABLE 2.4-12
LKSAA OTHER EQUIPMENT
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
CR 16 VDU 2 0,250 0,500 215 430
XTA 20 0,050 1,000 43 860
XCP 4 0,100 0,400 86 344
XCT 2 0,100 0,200 86 172
WALL OUTLET 62 0,010 0,620 8,6 533
MODEM 4 0,100 0̲,̲4̲0̲0̲ 86 ̲ ̲ ̲3̲4̲4̲
TOTAL 3̲,̲1̲2̲0̲ ̲2̲,̲6̲8̲3̲
TABLE 2.4-13
LKSAA RADIO CENTRAL STATION
(AREA 9)
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
XTA 26 0,050 1,300 43 1,118
XCP 2 0,100 0,200 86 172
XCT 2 0,100 0,200 86 172
WALL OUTLET 30 0,010 0,300 8,6 258
MODEM 2 0,100 0̲,̲2̲0̲0̲ 86 ̲ ̲ ̲1̲7̲2̲
TOTAL 2̲,̲2̲0̲0̲ ̲1̲,̲8̲9̲2̲
TABLE 2.4-14
LKSAA RADIO TX-STATION
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT QTY PER UNIT TOTAL PER UNIT TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
XTA 32 0,050 1,600 43 1,376
XCP 2 0,100 0,200 86 172
XCT 2 0,100 0,200 86 172
WALL OUTLET 36 0,010 0,360 8,6 310
MODEM 2 0,100 0̲,̲2̲0̲0̲ 86 ̲ ̲ ̲1̲7̲2̲
TOTAL 2̲,̲5̲6̲0̲ ̲2̲,̲2̲0̲2̲
TABLE 2.4-15
LKSAA RX-STATION
POWER CONSUMPTION(KW) HEAT DISSIPATION(Kcal/Hour)
EQUIPMENT TOTAL TOTAL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
CENTRAL COMPUTER (AREA 10) 28,520 24,530
MESSAGE SERVICE OP. (AREA 16) 2,000 1,720
TAPE IN/OUT POS. (AREA 6/15) 0,480 400
MESSAGE SYSTEMS (AREA 12) 2,960 2,780
SYSTEM SUPERVISOR (AREA 13) 0,280 240
OTHER EQUIPMENT 0,600 525
RADIO CENTRAL (AREA 9) ̲3̲,̲1̲2̲0̲
̲2̲,̲6̲8̲3̲
TOTAL 3̲7̲,̲9̲6̲0̲ 3̲2̲,̲8̲7̲8̲
TABLE 2.4-16
FMZ TOTAL POWER CONSUPTION AND HEAT DISSIPATION
2.4.5 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲a̲b̲l̲i̲n̲g̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲.̲
2.4.5.1 G̲e̲n̲e̲r̲a̲l̲
a) Contractor will provide and install the equipment
specified in section 2.4.1 and 2.4.2. The equipment
will be installed in accordance with the customer
approved Equipment Installation Drawings (EID).
b) The installation of the workstation cables and
the 10 AE workstations (option) are to be made
in accordance with the criterias defined in AMSG
719.
c) Customer will prepare the facilities in accordance
with the approved site preparation requirements.
This includes installation of metallic conduits
for the Local Area Network (option) according to
contractors specifications.
2.4.5.2 F̲M̲Z̲ ̲R̲o̲o̲m̲s̲:̲
a) Customer will provide the facilities specified
in the I.F.B. or "Lastenheft". The proposal is
based on that the FMZ is equipped with computer
floors and that contractors installations in this
area are not subject to AMSG 719. It is assumed
that customer provides a UPS system for at least
the ZVA and Crypto Computer.
b) Contractor will install all signal cables connected
to his equipment below the raised floors in customer
installed cable ducts.
d) Customer will provide power and signal line filtering
to and from the FMZ area if so required by AMSG
719.
e) The Line Switching facility (Schaltzplatz and Handvermittung)
is regarded as the division line between Contractor
and Customer concerning cabling. Customer will
provide and run the communication cables (Tx, Ttx,
Funk etc. ) from modems and cryptos and all other
cables from Customer furnished equipment up to
the line switch, except for the cable connections
from the telex terminals to the Handvermittlung,
which will be provided and run by the contractor.
Contractor will install the line switch and terminate
all cables at the line switch panels. Contractor
will install all cables from the line switch to
the ZVA computer and terminal equipment delivered
by Contractor.
The signal cable connections are to be performed as
follows:
1. Standard RS 232C cables between the ZVA Computer
and the "Schaltplatz". CR will provide cables and
connectors and install and terminate cables. Conduits,
if requires, will be provided and installed by
AA.
2. Standard RS 232C cables between the Schaltplatz
and the Handvermittlung. CR will provide cables
and connectors and install and terminate cables.
Conduits, if required, will be provided and installed
by AA.
3. Standard RS 232C cables between CR provided terminal
equipment and the Handvermittlung. CR will provide
cables and connectors and install and terminate
cables. Conduits, if required, will be provided
and installed by AA.
4. Standard RS 232 C cables between AA provided telex
terminals and the Handvermittlung. CR will provide
cables and connectors, install cables and terminate
cables at AA equipment and at the Handvermittlung.
Conduits, if required, will be provided and installed
by AA.
5. Communication cables to be connected to the ZVA
computer (Standard RS 232C cables from modems to
Schaltplatz). AA will provide cables and connectors,
install cables and terminate cables at the AA equipment.
CR will terminate cables at the Schaltplatz. Conduits
if requires will be provided and installed by AA.
6. Red and black RS 232C cables between crypto-units
and the Schaltplatz. AA will provide Cables and
Connectors and install and terminate cables. CR
will terminate cables at the Schaltplatz. Conduits
if required will be provided and installed by AA.
f) All cables installed by CR in the FMZ and Computer
room shall be of a halogenfree type, in accordance
with regulations from the Bundesbaudirektion.
2.4.5.3 C̲a̲b̲l̲e̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲t̲o̲ ̲A̲E̲-̲W̲o̲r̲k̲s̲t̲a̲t̲i̲o̲n̲s̲ ̲(̲O̲p̲t̲i̲o̲n̲)̲
a) Contractor will install the cables in conduits
provided and installed by customer.
b) Contractor has based his proposal on installation
often AE workstations including Standard V24 Interface
Cabling (refer to chapter 4). The cables are to
be routed from the ZVA Computer in the FMZ to the
AE workstations. The cable are assumed to be run
in conduits installed in the corridors. The cable
routing and location of AE workstations are to
be decided on a Site survey.
2.4.5.4 A̲E̲ ̲W̲o̲r̲k̲s̲t̲a̲t̲i̲o̲n̲s̲ ̲o̲r̲ ̲C̲e̲l̲l̲s̲ ̲(̲O̲p̲t̲i̲o̲n̲)̲
a) Customer will provide the facilities specified
in the I.F.B. or "Lastenheft".
b) Customer will provide power and ground in accordance
with AMSG 719 for these rooms. Customer is required
to install a power outlet with ground in the vicinity
of each terminal device.
c) Contractor will connect the terminals to the power
outlets and to the Interface Cable from the Computer.
2.4.5.5 R̲a̲d̲i̲o̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲e̲n̲t̲r̲e̲
a) Customer will provide the facilities specified
in the I.F.B or "Lastenheft". It is assumed that
the room is equipped with computerfloor.
b) Customer will provide power and ground according
to contractors specifications.
c) Contractor will provide, terminate and install
all signal cables in the radio control centre,
including the x-net for the workstations. Customer
will provide the appropriate plugs for customer
provided equipment.
R̲E̲ ̲a̲n̲d̲ ̲T̲X̲ ̲S̲t̲a̲t̲i̲o̲n̲s̲
a) Customer will provide the facilities specified
in the I.F.B or "Lastenheft".
b) Customer will provide power and ground according
to contractors specifications.
c) Contractor will provide, terminate and install
all signal cables at the RX and TX sites, except
the antenna cables for the RX and TX equipment.
Customer will provide the appropriate plugs for
customer provided equipment.
2.4.6 P̲h̲y̲s̲i̲c̲a̲l̲ ̲L̲o̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲i̲n̲ ̲t̲h̲e̲ ̲F̲M̲Z̲
In order to obtain a functional layout of the equipment
in the FMZ, CR proposes that the equipment is located
as shown on figure 2.4-17. As one can see, the only
major change to the original layout is the location
of the radio control centre and the handvermittlung.
The reason for this change is the fact that the radio
control equipment will have some high speed connections
to the central computer via the patch and cryptoes.
These lines have a length restriction according to
R5232C which would be difficult to meet with the original
location of the radio control centre. Taking into consideration
that the handvermittlung deals only with low speed
lines, CR see no technical problems in the new position
proposed.
FIGURE 2.4.-17
FMZ PHYSICAL LOCATION OF EQUIPMENT
2.5 D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
2.5.1 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
2.5.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
Contractor shall supply all necessary information for
Operation, Maintenance and Repair of the system.
Basic documentation shall be written in the German
language.
The documentation shall contain:
- Overview
o Documentation Tree
o System Overview
o Hardware Overview
o Software Overview
- System Description
- Message Flow Description
- User Manuals
- Operator Manuals including all Error Messages and
corrective procedures
- Functional Description and As Built documentation
for Hardware and Software
- Interface Control Documents
- Maintenance Manuals for Hardware and Software
2.5.1.2 P̲r̲o̲g̲r̲a̲m̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The German language shall be used for the documentation
of the Application Programs.
Each program and module shall contain:
- A short description
- Functional Flow
- Data flow (Input/Output parameters, global and
local data)
- Connection to other programs (f.ex. call of and
by a module)
- Test plan, Test Documentation
- Error handling
- Complete program listings
A typical example of program documentation shall be
supplied with the proposal, representative for the
contractors production and quality of the documentation.
2.5.1.3 W̲o̲r̲k̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
Work procedures for users and operators shall conform
to the following requirements:
- German language shall be used
- Generally understandable
- Short and unambigous
- With examples
- Maximum 1 page per work procedure
- Flexible breakdown
- Loose pages in binders
- Extensive Keyword Index
- Handy and solid document
- Short instructions to be placed at work positions
2.5.1.4 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
For operating the equipment is required:
- German language shall be used
- Generally understandable
- Short and unambigous
- Extensively illustrated
- Maximum 1 page per operational procedure
- Handy and solid document
- Short instruction/checklist for correcting failures
to be placed at the equipment
2.5.2 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲p̲o̲s̲a̲l̲
The documentation management, the contents and the
structure of the proposed documentation is described
in detail in the LKSAA Documentation Plan in Appendix
B of the technical proposal. Please refer to this Appendix.
The list below shows the proposed documentation and
the language to be used for each type of document.
"G" denotes the German Language, and "E" denotes the
English language.
L̲a̲n̲g̲u̲a̲g̲e̲ Q̲t̲y̲
1 Project Implementation Plan E 3
2 System Requirement Specification G 3
3 Interface Control Documents G 3
4 System Design Specification E 3
5 Acceptance Test Plan G 3
6 Acceptance Test Specification G 3
7 Acceptance Test Procedure G 3
8 Acceptance Test Report G 3
9 Documentation Plan E 3
10 System Users Manuals G 3
11 Network Operator Manuals G 3
12 Maintenance Manual G 3
13 Module Description Manuals E 3
14 Approved Spare Parts List E 3
15 System Description Manuals G 3
16 Peripheral Equipment Manuals E 3
17 Hardware Assembly Breakdown Manual E 3
18 Programming Development Manual E 3
19 Software As-Built Documentation E 3
20 Training Program Plan G 3
21 Site Preparation and
Installation Document G 3
22 Radio Control Operator Manual G 3
23 Radio Control Maintenance G 3
24 User Reference Card G 20
Above documents will be delivered in the quantity indicated
at no cost to AA. Before end of SRS phase AA must,
however, specify the correct quantity of documents
to be delivered. Quantities exceeding the contractual
quantity will be changed at 150 DM each document.
Optionally, documentation proposed in the English language
can be translated and delivered in the German language
at a price to be negotiated.
Work Procedures and Operational Procedures will be
delivered, supplementing User Manuals and Operator
Manuals, as described in the Requirements Analysis,
paragraph 2.5.1.3 and 2.5.1.4
Examples of program documentation are considered company
proprietary information and is therefore not supplied
with this proposal.
Examples may eventually be shown according to later
agreements.
The program documentation method is described in detail
as Guidelines for Package Design in Volume II, Part
1, Section 2.6.2. Please refer to this section for
further information.
2.6 M̲E̲T̲H̲O̲D̲S̲ ̲A̲N̲D̲ ̲T̲O̲O̲L̲S̲
2.6.1 S̲y̲s̲t̲e̲m̲ ̲D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Relevant experience is described in Volume I, section
2.2.6.1
2.6.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲,̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲
2.6.2.1 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲M̲e̲t̲h̲o̲d̲
2.6.2.1.1 S̲y̲s̲t̲e̲m̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
The following sections describe the baselines applicable
at the system level.
At lower levels than the system level a number of baselines
are defined.
The software implementation will be divided into a
number of sub-phases where each completed subphase
will establish a baseline.
The system development cycle is presented in Figure
2.6.2-1
Whenever this section specifies CR internal reviews,
AA participation is assumed.
Figure 2.6.2-1
System Development Cycle
2.6.2.1.2 S̲y̲s̲t̲e̲m̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The system requirement definition phase will be completed
by a System Requirements Review (SRR). The objective
of this review is to ensure the compliance and completeness
of the system requirements. After AA's approval of
the System Requirements Specification, and associated
Interface Control Documents, these will establish the
baseline for all subsequent development activities.
2.6.2.1.3 S̲y̲s̲t̲e̲m̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
During the system design phase, the system requirements
are broken down into subsystems and components of software
to ensure
a) that the system design specification represents
a complete and optimal synthesis of the system
requirements
b) that the system is complete and feasible, and
c) that a technical direction is provided to the implementation
An internal CHRISTIAN ROVSING A/S System Design Review
(SDR) will be scheduled.
After approval of the system design specification by
the LKSAA program management, this will establish the
design requirement baseline.
2.6.2.1.4 P̲r̲e̲l̲i̲m̲i̲n̲a̲r̲y̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The actual design of subsystems and software components
identified during the system design will be divided
into two phases; the preliminary phase, and the detailed
design phase. Due to the schedule it will be considered
to amalgamate the Preliminary Design Baseline and the
Detailed Design Baseline.
The preliminary design baseline (subsystem design)
is established prior to detailed design in order to
a) evaluate the progress and technical adequacy of
the selected design approach
b) determine its compatibility with the requirements,
and
c) establish the existence and compatibility of the
physical and functional interfaces between system
components
During the system design phase subsystems have been
defined and requirements/functions have been allocated.
The objectives related to the preliminary design are
to establish the following baseline documents:
- Specification of packages within the subsystems
- Allocation of requirements/functions to all packages
- Specification of detailed interfaces between subsystem
and packages
- Definition of data
- Specification of Data Base Design
The level of documentation applied to the subsystems
is defined in Subsystem Documentation Standard.
The subsystem/package interfaces will be documented
in a LKSAA Application Software Interface Control Document.
Each interface will be specified to the level of the
applied calling mechanism and passed parameters.
Global data and files will be documented in a LKSAA
Software Data Definition Document. Each data item will
be specified to at least the logical level.
The Data Base Design Document will define all files
and their logical contents. In addition the files will
be allocated to medias in order to obtain optimal performance.
The preliminary design baseline will be established
by a Preliminary Design Review (PDR) involving LKSAA
software team as well as the CR A/S System Engineering
Department and Quality Assurance Department.
When the CR A/S management team has approved the baseline
the detailed design will be initiated.
2.6.2.1.5 D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
Before the actual implementation is initiated, a Detailed
Design Review (DDR) internal Christian Rovsing A/S
will be conducted to
a) determine that the detailed design satisfies the
design requirement baseline.
b) establish the exact interface relationship between
the system components
After approval the detailed design forms the baseline
for implementation of the actual software components.
The documents which represents the baseline for detailed
design are those produced during preliminary design
as well as those applicable to the preliminary design.
The objective with detailed design baseline is to establish
"as-to-be-coded" design documentation.
The subsystem design will be designed in further details
and will be documented in a set of package design documents.
Packages will be broken down into processes and software
modules.
The Software Interface Control Document will be expanded
to contain a detailed description of each parameter
in each of the package/subsystem interfaces.
Likewise the Software Data Definition Document will
be expanded to contain a detailed definition of each
data item.
In order to maintain a current and accurate design
specification during this and subsequent phases the
concept of Unit Development Folders (UDFs) will be
applied.
The fundamental element in the software design and
development is the Unit Development Folder (UDF), which
is an essential working tool for the program developer.
The UDF begins with the definition of requirements
to be implemented within the unit, from which preliminary
and detailed design description is derived and unit
development test plan(s) describing the development
testing activity. To this is added a list of test cases
that will demonstrate that the unit meets the requirements
and is free of errors and anomalies.
The detailed design baseline will be established by
Detailed Design Reviev (DDR) involving the LKSAA software
team as well as the CR A/S System Engineering Department
and the Quality Assurance Department.
2.6.2.1.6 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
When the Software components have been produced these
shall be tested and integrated into subsystems. The
baselines are established when the subsystems have
been approved by the CR A/S QA Department.
2.6.2.1.6.1 C̲o̲d̲e̲ ̲a̲n̲d̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The objective of this phase is to produce software
units which are tested to the extend that they are
ready for software subsystem integration and test.
The concept "unit" means an entity consisting of software
modules, which makes up a functional area.
The criteria for being ready is that they can pass
the test defined in the detailed design baseline and
the software test plan.
During the process, the design description may be revised
to make it reflect the coded unit. Thus, as the unit
evolves from its initial checkout state to a completely
tested segment of code, the UDF progresses from a "code-to"
specification to an "as-built" specification. By the
time the unit is ready for integration with other units,
the product specification for the unit is complete,
including updated flow charts or structured pseudo
code.
An overview of the contents of UDF test specifications
and procedures are presented in the following.
Unit testing involves the testing of each module using
selected inputs, executing the code, and evaluating
module outputs. The primary intent of unit testing
is to prove that the module solves the right problem.
There are standards of measurement of success of testing
which always is used to insure that sufficient detailed
unit testing has been accomplished.
The test specification and procedures shall contain
a description of each test case to be employed in testing
the unit. The description must identify any test tools
or drivers used, a listing of all required test inputs
to the unit and their values, and the expected output
and acceptance criteria, including numerical outputs
and other demonstrable results. Test cases shall address
the functional capabilities of the unit, and a matrix
shall be placed into this section which correlates
requirements and functional capabilities to test cases.
This matrix will be used to demonstrate that all requirements,
partial requirements, and functional capability list
of the unit have been tested.
Guidelines for evaluation of unit test effectiveness
is presented overleaf.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PROPERTY ASSESSMENT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Numerical and It is necessary to demonstrate that the
Mathematical mechanization of the algorithms and models
Accuracy meet the prescribed quantified accuracy requirements
delineated when preparing the acceptance criteria
earlier in development.
Logical Branches All critical logical branches and error conditions
in the object coding should have been executed
at least once successfully. The remaining
inter-module linkages will be exercised during
integration test. If a correction is made,
all critical logical branches must be checked
again.
Range of The function being performed by the module
Variables should be exercised at the expected extremes
of the range of input variables and confirmed
expected outputs need to be checked. Unusual
input data points and points or ranges
of potential failure should be verified.
Computational All special conditions in the code that
could
Integrity cause erroneous computations to occur need
to be checked. This includes such items
as dividing by zero, differencing two nearly
equal large numbers, exceeding table limits,
etc.
Resource The timing and core utilization need to be
Utilization verified to insure that they are consistent
with design constraints and overall system
requirements.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Before integration of "units" a Test Readiness Review
(TRR) will be held to ensure that the UDFs are complete,
that the "units" meet their specifications, and that
the "units" have been exhaustively tested.
Units shall be approved by the Work Package Manager,
Software Manager and Quality Assurance.
After approval of the units these make up the baseline
from which integration and test are initiated.
2.6.2.1.6.2 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The objective of this baseline is to achieve fully
integrated and tested subsystems to be delivered to
LKSAA System Engineering for system integration and
verification.
The subsystem integration is based on the software
integration plan and associated test specifications
and procedures.
Integration testing verifies the linkages between the
software modules which make up entire functions, programs,
and system. Integration testing begins when individual
units/modules start to be merged together according
to the top-down methodology described below.
Integration testing is satisfied when the entire program
responds properly and the module to module interfaces
are shown to have been defined and implemented correctly,
in addition to execution timing and core storage assessment.
It is during integration testing that it is shown that
varied inputs representative of the ranges required
for overall performance produce the expected results
and that the total software package meets the performance
and design requirements.
The sequence of integration of the modules, units,
elements or subroutines into larger and larger testable
packages or groups is simply the application of the
top-down concept to achieve a systematic verification
process.
The t̲o̲p̲-̲d̲o̲w̲n̲ approach to integration starts with the
testing of the highest level system segment once it
is coded. Since this segment will normally invoke or
include lower level segments, code must exist for the
next lower level segment. This code, called a program
stub, may be empty, may output a message for debugging
purposes each time it is executed, or may provide a
minimal subset of the functions required. These stubs
are later expanded into full functional segment, which
in turn require lower level segments. Integration is,
therefore, a continous activity throughout the development
process. During testing, the system executes the segments
that have been completed and uses the stubs where they
have not been completed. It is this characteristic
of continous integration that reduces the need for
special test data drivers. The developing system itself
can support testing because
all the code that is to be exectued before the newly
added segments has previously been integrated and tested
and can be used to feed test data to the new segments.
For this reason, most problems are localized to the
recently added code. As the new segments are tested
within the developing system, the control architectue
and system logic are also tested.
In general top-down offers the following advantages:
- simple individual tests
- simple identificaiton of suspect areas
- no need to develop special versions of any program
except for all the stubs
Below some guidelines are presented for developing
integration test cases to insure that the desired level
of confidence in the overall software product has been
obtained from the integration test phase.
Insure that:
- All components are available and that they have
been unit tested
- Module interfaces are completely defined and properly
implemented
- Modules which perform more than one function meet
applicable requirements and acceptance cirtieria
- Necessary inputs and outputs are properly handled
- The expected ranges of output are evaluated with
respect to the input range of variables between
modules
- There are no unsatisfied external references
- Program entities change only those other entities
that have been designed to be changed or that act
as communication media
- Subroutines preserve and restore all common locations
and register they use, as desired
- Shared storage is protected
- Communication is maintained between dependent loops
so that proper sequencing is maintained
- Error conditions are detected and properly identified
in messages
To establish a baseline and application software, subsystem
test report will be produced. This will be reviewed
and approved by CR A/S Quality Assurance Department.
Upon approval the system integration and test phase
will be initiated.
2.6.2.1.7 S̲y̲s̲t̲e̲m̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
At the time of completion of system integration and
verification, a System Verification Review is conducted
to verify that the system performes as required, and
that product specification, manuals, and handbooks
are accurate.
2.6.2.1.8 S̲y̲s̲t̲e̲m̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
The formal system acceptance phase has been separated
into a number of sub-phases each resulting in a baseline.
The Acceptance baselines are:
- In Plant Software Test baseline (System Factory
Acceptance Test)
- Site Provisional Acceptance baseline
- Site Acceptance Test
2.6.2.1.9 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲S̲t̲r̲a̲t̲e̲g̲o̲r̲y̲
This section will address the strategy to be applied
in order to assure that all requirements will be implemented
accordingly.
In order to assure that all requirements are identified
the LKSAA system requirements identified in the LKSAA
System Requirements Specification and subsequent ICDs
will be allocated to the pertinent software subsystems.
This is done during system design and will be contained
in a Verification Control Documents.
To assure that the requirements are implemented in
the software subsystems/packages the requirements will
be allocated to each package/module in Unit Development
Folders (UDF).
The above requirements allocation will be verified
during the preliminary/detailed design reviews. All
the unit/packages test cases shall include testing
of these requirements. During system integration and
verification the Verification Control Document will
be used to track the requirements via the test procedures
and results.
To assure that the requirments are i`mplemented in
the subsystems/items the requirements will be allocated
to each subsystem/item in the Product specifications
or the Subsystem Specifications. The detailed design
review will verify that the requirements are accounted
for. The test cases developed for the items and subsystems
will tet the allocated requirements. During the system
integration and verification the VCD will be used to
track the requirements.
2.6.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲i̲g̲n̲
The design of the application software packages will
be specified according to the following guidelines.
PACKAGE DESIGN SPECIFICATION…01……01…TABLE OF CONTENTS OUTLINE
1 GENERAL
1.1 PURPOSE AND SCOPE
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
1.2.1 APPLICABLE DOCUMENTS
1.2.2 PROJECT REFERENCES
1.3 TERMS AND ABBREVIATIONS
1.3.1 TERMS
1.3.2 ABBREVIATIONS
2 SUMMARY OF REQUIREMENT
2.1 PACKAGE DESCRIPTION
2.2 PACKAGE FUNCTIONS
2.2.1 MAIN FUNCTIONS (NORMAL OPERATION)
2.2.2 FUNCTIONAL RESPONSIBILITIES
2.2.2.1 INITIALIZATION, CLOSE DOWN, AND RESTART
2.2.2.2 CHECK POINTING AND RECOVERY
2.2.2.3 ERROR DETECTINg AND ERROR HANDLING
2.2.2.4 INTEGRITY OF OPERATION
2.2.2.5 DATA COLLECTION (LOG, STATISTICS, AND
REPORTS)
2.2.2.6 SECURITY
2.3 CHARACTERISTICS
2.3.1 TIMING
2.3.2 THROUGHPUT
2.3.3 FLEXIBILITY
2.3.4 ACCURACY
3 ENVIRONMENTS
3.1 EQUIPMENT
3.2 SOFTWARE
3.2.1 SYSTEM SOFTWARE
3.2.2 DEVELOPMENT SUPPORT SOFTWARE
3.3 INTERFACES
3.3.1 EXTERNAL INTERFACES
3.3.2 PACKAGE INTERFACE
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES
4 PACKAGE DESIGN
4.1 PACKAGE OVERVIEW
4.1.1 FUNCTIONAL SPECIFICATION
4.1.2 SOFTWARE SPECIFICAION
4.1.3 DATA FLOW AND CONTROL LOGIC
4.1.4 PACKAGE DATA
4.1.5 COMMON DATA
4.1.6 INTERFACES
4.1.6.1 EXTERNAL INTERFACES
4.1.6.2 PACKAGE INTERFACES
4.1.6.3 SUB-PACKAGE INTERFACES
4.2.x SUB-PACKAGE SPECIFICATIONS
4.2.x.1 FUNCTIONAL SPECIFICATION
4.2.x.2 SOFTWARE STRUCTURE
4.2.x.3 DATA FLOW AND CONTROL LOGIC
4.2.x.4 SUB-PACKAGE DATA
4.2.x.5 SUB-PACKAGE INTERFACE
4.3 MEMORY LAYOUT
2.6.2.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲o̲d̲u̲l̲a̲r̲i̲t̲y̲
The software packages and subpackages are described
below. The subpackages will be further divided into
modules and sub-modules. These are not specified in
the following.
L̲K̲S̲A̲A̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
2.1 SUPERVISOR VDU PACKAGE
2.1.1 Common Package Procedures
2.1.2 Supervisor VDU Control
2.1.3 Supervisor Function Control
2.1.4 Supervisor VDU Dialogue
2.1.5 Supervisor Retrieval
2.1.6 Supervisor Completion Report
2.1.7 Supervisor Process Initializ.
2.2 SUPERVISOR PRINTER
2.2.1 Supervisor Print Control
2.2.2 Delivery Control
2.2.3 Request Control
2.2.4 Initialization
2.3 MESSAGE DISTRIBUTION CONTROL OPERATOR VDU FUNCTIONS
2.3.1 Common
2.3.2 Delivery VDU Control
2.3.3 Delivery Function Control
2.3.4 Delivery VDU Dialogue
2.3.5 Delivery Retrieval
2.4 MESSAGE SERVICE OPERATOR PACKAGE
2.4.1 Common Package Procedures
2.4.2 Message Service VDU Control
2.4.3 Message Service Function Control
2.4.4 Message Service VDU Dialog
2.4.5 Message Service Retrieval
2.5 USER VDU FUNCTION
2.5.1 Common Package Procedures
2.5.2 VDU Control
2.5.3 User Function Control
2.5.4 VDU Dialogue
2.5.5 Retrieve
2.5.6 User Message Access Monitoring
2.5.7 Initialization
2.6 USER PRINTER
2.6.1 Common Procedures
2.6.2 User Print Control
2.6.3 Print Output
2.7 OCR
2.7.1 Optical Character Reader Subpackage
3 MESSAGE DISTRIBUTION
3.1 Message Distribution Subpackage
4 TRAFFIC HANDLING
4.1 AAS Analysis
4.2 ACS Conversion
4.3 TCS Transport Control
4.4 ITS Incoming Transprot
4.5 OTS Outgoing Transport
5 LOGGING
5.1 Common
5.2 Log Collect
5.3 Log Trace
6 STORAGE AND RETRIEVAL
6.1 Common Package
6.2 Online Storage
6.3 Online Retrieval
6.4 Offline Retrieval
6.5 Dump
6.6 Supervisor Commands
7 STATISTICS PACKAGE
7.1 Common Package
7.2 Collect
7.3 Main Program
7.4 Dump
7.5 Generation
7.6 Delivery
8 TABLE MANAGEMENT
8.1 Common Procedures
8.2 Search
8.3 Update
8.4 TMP Monitor
8.5 TMP Main Module
9 COMMON SYSTEM FUNCTION
9.1 Common
9.2 Utility
9.3 Queue Monitor
9.4 Timer Monitor
9.5 Message Monitor
9.6 Coroutine Monitor
9.7 System Call Monitor
10 OFFLINE MODULES
10.1 System Generation
10.2 Format Generation
10.3 Table Generation
11 MESSAGE MANAGEMENT SYSTEM
11.1 Common Procedures
11.2 Command Handling
11.3 Internal Message Format File Handling
11.4 Storage + Retrieval
11.5 Checkpoint + Recovery
11.6 Disk I/O
12 SYSTEM STATUS AND CONTROL
12.1 OLD - Online Diagnostics
12.2 CMI - Command Interpreter
12.3 WDP - Watchdog Firmware
12.4 EHD - Error Handler and Command Dispatcher
12.5 TEMCO - Terminal Monitoring and Control
12.6 DEMCO - Device Monitoring and Control
12.7 CEMCO - Channel Monitoring and Control
12.8 WAMCO - Watchdog Monitoring and Control
12.9 CFH - Configuration Handler
12.10 Common
13 I/O CONTROL
13.1 Format Handler VDU
13.2 Format Handler PRT
13.3 LTU Handler
13.4 LTU Function VDU
13.5 LTU Function, Low Speed Lines
13.6 LTU Function, OCR
13.7 STI Handler
13.8 CRYPTO Handler
13.9 Watchdog Interface
2.6.2.4 S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲P̲D̲S̲
The PDS has been divided into four chapters. The objectives
for each chapter are presented below.
Chapter 1 shall contain a presentation (purpose and
scope) of the specification, define the baseline documents
and define terms/abbreviations used within the specification.
Chapter 2 shall define the package functions and characteristics
to be implemented. The functions shall be described
at a level similar to the SRS and SDS. Chapter 2 shall
define what functions are to be implemented and not
how these are implemented.
Chapter 3 shall define what the package environments
are. How interfaces are implemented shall not be described
in chapter 3.
Chapter 4 shall contain the actual design which implements
the functional requirements described in chapter 2
and 3.
It should be noted that chapter 2 and 3 of the package
specifications will be used to replace the package
definition in the SDS (section 5.x).
At package level section 4.1 of the package specification
is equivalent to chapter 4 of the SDS at system level,
while section 4.2.x of the package specification is
equivalent to section 5.x of the SDS.
S̲e̲c̲t̲i̲o̲n̲s̲ ̲a̲t̲ ̲t̲h̲e̲ ̲P̲D̲S̲
S̲e̲c̲t̲i̲o̲n̲ ̲1̲.̲1̲
a) Purpose Statement. Describe the purpose of the
Package Specification using the following as a
guide. The Package Specification for (Project Name)
(Project Number) is written to fulfil the following
objectives:
1) To provide detailed definition of the Package
functions and software architecture.
2) To provide user operational and development
personnel details of the ongoing analysis.
3) To define in detail the interfaces with other
packages and to describe their facilities.
b) Scope Statement. Descripe the scope of the document
by using the following as a guide.
1) What level of detail does the Package Specification
contain?
2) Where can higher/lower level design specifications
be found?
3) What interfaces/data are defined within the
specification and what interface/dates are
defined elsewhere?
S̲e̲c̲t̲i̲o̲n̲ ̲1̲.̲2̲
All documents which represent a baseline shall be defined.
Other documents which do not directly represent
requirements shall be listed as reference documents.
S̲e̲c̲t̲i̲o̲n̲ ̲1̲.̲3̲
This section shall contain a list of all abbreviations
and key terms pertinent to the document.
C̲h̲a̲p̲t̲e̲r̲ ̲2̲ ̲(̲G̲e̲n̲e̲r̲a̲l̲)̲
Chapter 2 and its sections shall specify requirements
pertinent to the package level.
The documentation in chapter 2 shall be able to
answer the following questions:
a) What am I part of?
b) What am I? (What are my functions?)
c) With whom do I interact?
C̲h̲a̲p̲t̲e̲r̲ ̲2̲ ̲(̲S̲p̲e̲c̲i̲f̲i̲c̲)̲
Section 2.1 shall contain a description of the
package and its inter-relationships with other
packages and/or system interfaces. A chart showing
the package and its inter-relationships shall be
resented.
Section 2.2 shall describe the function to be performed
by the package (on package level). The functions
to be described are basically those derived from
the SRS and the SDS.
Section 2.2.1 shall describe the function performed
under normal operation, while section 2.2.2 shall
describe the functions to be performed by the package
under special circumstances such as initialization,
recovery, security, etc.
Section 2.2.2 shall be seen in relation to section
3.4. It is important to distinguish between functions
which are performed by a package itself and functions
which are pertinent to a package, but performed
by other packages. Examples are log/statistics
collection and message check pointing.
Only functions performed by the package itself
shall be contained in section 2.2.2.
Section 2.3 shall specify the characteristics of
the packages which are timing, throughput, flexibility
and accuracy.
a) Timing. Describe any requirements for timing
on the package. The following requirements
should be considered:
1) Throughout time.
2) Response time to queries and for update
of data files.
3) Response time of major sub-system functions.
4) Sequential relationship of sub-system functions.
5) Priorities imposed by inputs or changes
in modes of operation.
6) Requirements for varying traffic load.
7) Sequencing and interleaving programs and
systems (including the ability to interrupt
a program without loss of data).
b) Throughput. Describe the processing capacity
(connectivity) of the package.
c) Flexibility. Describe the requirements for
the package to deal with changing situations
e.g. operational changes, and interaction with
new or improved systems. Identify those components
and procedures which may be subject to change.
d) Accuracy and Validity. Describe the requirements
for package accuracy. These requirements must
cover the following areas of concern:
1) Accuracy of input data.
2) Accuracy of transmitted data.
C̲h̲a̲p̲t̲e̲r̲ ̲3̲
Chapter 3 shall address the following four main
issues:
- equipment environment
- software environment
- package interfaces
- functions maintained by other packages
a) E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲. Describe the equipment
required for the operation of the package,
and include a description of the equipment
presently available. Discuss the characteristics
of any additional equipment required. Related
the requirement for equipment to the requirements
stated in the SRS. The follwoing items should
be described:
1) Processor(s) (number of each on/off line
and size of internal storage).
2) Storage media (number of disk units, tape
units, etc.).
3) Input/output (I/O) devices (number of each
on/off line).
4) Communications net (line speeds).
b) The software environment has been separated
into the two categories:
1) System software
2) Development Software
The system software is defined to consist of
the following components DAMOS, IOC, CSF, and
MMS.
Other LKSAA software packages using these components
shall not specify their interfaces to these
packages (Refer below, section 3.3.2).
The development support software are defined
to include all software required to implement
and test the software package.
c) I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲. Section 3.3.1 shall reference system
interfaces e.g. ICDs.
Section 3.3.2 shall identify interfaces to
other software packages (excl. DAMOS, IOC,
CSF, and MMS). The section shall not give a
detailed specification of interfaces, as these
are contained in section 4 of the PDS and in
separate ICDs.
d) F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲b̲y̲ ̲O̲t̲h̲e̲r̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
Section 3.4 shall contain a description of
functions which fulfil the following criterias:
1: functions performed by other packages which
have a major importance for the operation
of the package.
2: functions performed by other packages for
which there is no explicit interface. (supported
behind the users back")
Examples of functions to be described are:
- security functions
- check pointing function
- recovery functions
- log, statistics and report collection
- error detection and -handling
2.6.2.5 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲i̲g̲n̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲
The following pages are an example of a normal package
design process.
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
(4.1) P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
Section 4.1 of the package specification has at package
level the same mission as chapter 4 in the SDS at system
level.
In total 4.1 gives the concurrent and sequential processing
within the package with clear definition of the role
of each sub-package which are described more detailed
in section 4.2.x.
(4.1.1) F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This should be the first step in the analysis. The
package functions desolved in section 2.2.1 and 2.2.2
should be broken down to the level functional which
justifies allocation of the subpackages described further
in section 4.2.x.
̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A B C
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Common functions
Where common functions exist within a package the functional
break-down shall be continued to the level where all
common functions can be isolated.
(4.1.2) S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This section describes the allocation of functions
onto processes, shared procedures (between two processes),
monitor procedures (only for CSF, SSC, and DAMOS) or
co-routines.
Based on the above software component types sub-packages
shall be defined.
For each of the sub-packages the following elements
shall be contained.
1) Functions allocated to the subpackage (refer 4.1.1).
2) Software structure which corresponds with the functional
break-down of section 4.1.1.
The software structure shall be presented by a chart
which shows the software break-down. (Similar to chart
presented in section 4.1.1).
(4.1.3) D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Data flow and control logic related to major transaction
within a package shall be described to the sub-package
level.
The functional flow must give the normal flow (as 2.2)
and the special flow (2.3).
The tools to document flow/logic are block diagrams
for process synchronization/communication and HIPO
for sequential processing.
(4.1.4) C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲ ̲(̲I̲n̲t̲e̲r̲n̲a̲l̲)̲
This should identify common data element (but not give
detailed layout in order to make 4.1.5 more readable).
(4.1.5) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
This should identify data shared with other packages
which are defined in Data Def. Doc.
(4.1.6) I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The section shall define external interfaces as well
as software package to package interfaces (excl. DAMOS,
IOC, CSF, and MMS). At minimum shall be references
to the appropriate ICDs shall be included.
Sub-package interfaces shall, furthermore, be identified
but not specified in details, as this shall take place
in section 4.2.x.5.
G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲m̲m̲m̲e̲n̲t̲s̲ ̲t̲o̲ ̲4̲.̲1̲.̲4̲,̲ ̲4̲.̲1̲.̲5̲,̲ ̲a̲n̲d̲ ̲4̲.̲1̲.̲6̲
In order to obtain a selfcontained and readable document
it may be necessary to include detailed information
in section 4.1.4 - 4.1.6. It shall however be emphasized
that the master source for definition of data and package
interfaces are the AMSS data definition document and
the AMSS software interface control document.
(4.2.x) S̲u̲b̲-̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
This section shall expand the subpackage design, as
described in section 4.1 to a level where all modules
(less than 250 source statements, refer SRS) are identified
and the functions defined.
(4.2.x.1) F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section shall contain a functional break-down
to such a level that all SW modules can be identified
taken all functional areas defined in section 2.2 and
4.1.1 into account.
INTENTIONALLY LEFT BLANK
Figure 7.1.3…01…LKSAA WBS
Issue 1.5
LKSAA - VOLUME II SYS/84-06-15
APPENDIX C
TECHNICAL PROPOSAL Page 149
ZVA COMPUTER RACK SPECIFICATION
DIMENSIONS:
H: 1995,5 mm (36U)
W: 597 mm (19")
D: 1040 mm
WEIGHT: 95 kg.
Issue 1.5
LKSAA - VOLUME II SYS/84-06-15
APPENDIX C
TECHNICAL PROPOSAL Page 150
INTENTIONALLY LEFT BLANK
Issue 1.5
LKSAA - VOLUME II SYS/84-06-15
APPENDIX C
TECHNICAL PROPOSAL Page 151
INTENTIONALLY LEFT BLANK
Issue 1.5
LKSAA - VOLUME II SYS/84-06-15
APPENDIX C
TECHNICAL PROPOSAL Page 152
INTENTIONALLY LEFT BLANK
