top - download
⟦8ae4e5bd2⟧ Wang Wps File
Length: 59735 (0xe957)
Types: Wang Wps File
Notes: Tilbud IWS
Names: »1325A «
Derivation
└─⟦ca05b96c2⟧ Bits:30006251 8" Wang WCS floppy, CR 0086A
└─ ⟦this⟧ »1325A «
WangText
D…08…D…00…D…06…C…09…C…0c…C…0f…C
B…0a…B…0c…B A…08…A…0c…A…01…@…0b…@
?…08…?…0c……86…1
…02…
…02…
…02…
…02…
…02…
…02…
SYSTEM
PROPOSAL
FOR
AN Page
#
"INTEGRATED
WIRE
SERVICES"
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 INTRODUCTION ..................................
2
1.1 TECHNICAL PROPOSAL OUTLINE HIGHLIGHTS .....
3
1.2 ORGANIZATION OF THE TECHNICAL PROPOSAL ....
6
2 OPERATIONAL DESCRIPTION OF PROPOSED IWS SYSTEM
7
2.1 OVERVIEW OF IWS OPERATIONAL ASPECTS .......
8
2.2 ESSENTIAL IWS FUNCTIONS ...................
9
2.3 FUNCTIONAL DESCRIPTION ....................
10
2.3.1 Message Handling ......................
11
2.3.2 Incoming Wire Communication Analysis ..
12
2.3.3 Outgoing Wire Communication Processing
13
2.3.4 Message Filing and Retrieval ..........
14
2.3.5 Supervisory Functions .................
15
2.3.6 Bank Accounting Transactions ..........
18
2.3.7 Statistics ............................
19
2.3.8 Message Accountability ................
20
2.3.9 Operational Security ..................
21
2.3.10 External Wire Interfaces ..............
22
3 PROPOSAL BREAK DOWN ...........................
23
3.1 DOCUMENTATION .............................
24
3.2 MAINTENANCE ...............................
25
3.3 IWS SOFTWARE SYSTEM .......................
26
3.3.1 CR80 System Software ..................
29
3.3.2 IWS Application Software ..............
35
3.4 HARDWARE SYSTEM PARTIONING ................
40
3.5 IMPLEMENTATION SCHEDULE ...................
49
3.6 SYSTEM FAILURE CONSIDERATION ..............
52
3.7 BUDGETTARY COSTS ..........................
53
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The technical solution to the Integrated Wire Services,
hereafter called IWS, requirements offered by Christian
Rovsing A/S applies up-to-date technology and current
communications techniques to structure an integrated
hardware/software system. The proposal system is fully
responsive to the operational needs and meets the security,
reliability and expandability aspects demanded by Canadian
Imperial Bank of Commerce (CCIB).
The Technical Proposal outline contained in Section
3.3 and 3.4 presents the hardware/software system proposed
for IWS. The offered system was configured after an
analysis of the quantitative and functional requirements.
Some system features were customized in order to be
fully compliant with CICB's needs - such as security,
redundancy, no-loss switchover, diagnostics, status,
and operability.
The technical system description presented in this
portion of Christian Rovsing A/S proposal outline supplements
and supports the Implementation Schedule contained
in Section 3.5.
Following this introductory section, a brief system
analysis and operations description are presented.
1.1 T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲P̲R̲O̲P̲O̲S̲A̲L̲ ̲O̲U̲T̲L̲I̲N̲E̲ ̲H̲I̲G̲H̲L̲I̲G̲H̲T̲S̲
An overview of the significant points and unique features
of the proposal outline are presented here by way of
general orientation.
The proposed IWS system configuration was evolved from
hardware and software experience gathered on the CAMPS,
NICS-TARE, and FIKS developments. These systems are
developed for military authorities within NATO and
within Denmark. Especially the CAMPS application includes
features which resembles IWS requirements and reconfiguration
control. The unique features of the offered system
will not only ensure successful operation, but will
also reduce cost of ownership over the useful life
of the system and prevent early obsolescence.
The list of highlights on the CR80 computer presented
here is not exhaustive, but simply meant to call attention
to a system configuration which has undergone evolutionary
improvements to make it extremely well- suited for
on-line communications applications such as IWS.
o Fully Dualized Configuration
- Redundancy provided for all essential units
and sub-systems
- Dualized Processor Units and Main Memory
- Critical paths, data highways and transfer
buses dualized throughout the configuration
- No single path, series risk elements
o Automated RECONFIGURATION Control
- Microprocessor-based System Status and Control,
SS and C
- Continuous equipment status monitored and displayed
on System Status Control Panel, SSCP
- Automated re-assignment of peripherals with
manual override
- ON-LINE or STAND-BY status reassingnable by
System Supervisor
- Routine for soft let-down and switchover, initiated
from SSCP, automatically reconfigures the system
for maintenance
- NO-LOSS message integrity performed by SS and
C, switchover and recovery software and message
accountability approach
o Modular EXPANDABILITY For Growth
- Initial installed system utilization less than
50 per cent allowing expansion
- Modular expandable memory size and number of
line terminations
- Functional program modules
o File Management System
- Accessible mass storage total 160 Megabytes
- Line block and storage access rate 25-40 accesses/second
- Dual-ported through high speed DMA channels
to the Processor Units
- Multiported to both disk drives
o Distributed Processing Throughout IWS
- Multiple CPUs in Processor Units
- High throughput parallel transfer buses throughout
the configuration
o Unique SECURITY Features
- Privileged instruction set in the CR80 Processor
coupled with MAP control and boundary register
prevent unauthorized access
- Separate SYSTEM/USER state limit data access
and process changes and cause interrupt on
attempted violations
o Predicted AVAILABILITY exceeds requirements
- Reliability analysis based on accurate model
and arithmetic calculations predicts an overall
system availability better than .9999.
o Extensive Use of LSI Technology
- High equipment density achieved by use or RAMs,
PROMs, CPUs, USARTs, FIFOs, and microporcessors
- Low power consumption 12KW
- Maximum configuration occupies only 6 standard
racks
o System WATCH-DOG (SSC) Functions Provides
- On-line diagnostics, self-checks, and status
reporting implement the WATCH-DOG functions
with software
- Microprocessor-based system controller monitors
equipment status through physical sensing
o Dualized Stand-Alone MAIN MEMORY
- Accessible concurrently from either Processor
Units
- 32 kword modularity
- MAP Conrol extends addressability to 16 million
words
1.2 O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲ ̲O̲F̲ ̲T̲H̲E̲ ̲T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲P̲R̲O̲P̲O̲S̲A̲L̲ ̲O̲U̲T̲L̲I̲N̲E̲
The technical response to the Request for Proposal
is organized such that analysis of the quantitative
and functional performance requirements of IWS precedes
and forms the logical basis for the proposed system
design, hardware description and software approach.
Christian Rovsing A/S response to the technical aspects
of the IWS performance requirements is contained in
section 2.
Section 3 is subdivided in accordance with the suggestion
made in the Request for Proposal.
2̲ ̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ ̲O̲F̲ ̲P̲R̲O̲P̲O̲S̲E̲D̲ ̲I̲W̲S̲ ̲S̲Y̲S̲T̲E̲M̲
The proposed IWS system meets the functional requirements.
This section describes the essential functions performed
by IWS.
The proposed IWS system is based on the experience
of Christian Rovsing A/S from similar systems like
the SHAPE message preparation and reception system
CAMPS, the NICS-TARE system, and the Danish defense
communication network FIKS.
This section describes all the essential functions
performed by the proposed IWS system and the interfaces
to the system.
2.1 O̲V̲E̲R̲V̲I̲E̲W̲ ̲O̲F̲ ̲I̲W̲S̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲A̲S̲P̲E̲C̲T̲S̲
The proposed IWS system has been outlined with emphasis
on security and reliability aspects.
The IWS system has been outlined to provide an efficiant
and cost effective solution for the IWS requirements.
Special attention has been paid to security and ability
to recover from faults.
The approach taken with respect to security has been
to propose a design where security provisions are embedded
as an integral part of each system component and module.
Distributed processing and redundancy at subsystem
levels greatly facilitates recovery from faults at
many levels.
Error detection and isolation has been built into each
system component to enable early detection of faults,
which provides a means to take corrective action before
a fault condition propatages to other system components.
2.2 E̲S̲S̲E̲N̲T̲I̲A̲L̲ ̲I̲W̲S̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
The essential functions performed by IWS are message
preparation, handling and retrieval, supervisory functions,
accounting and statistics. Security is an integral
part of these functions.
IWS provides functions for initial preparation of messages
and editing, coordination and release of messages.
These message preparation facilities are based on operator
terminal formats which ease the operator's tasks.
Released messages are transformed into SWIFT message
format if appropriate before being transmitted to external
recepients.
Incoming messages from the SWIFT network are analysed,
based on SWIFT format procedures.
Incoming messages with format inaccuracies which prevents
automatic processing are diverted to operators for
manual assistance.
Outgoing messages are transmitted by assigned priorities.
Messages are stored on disk volumes which allow rapid
retrieval of messages not older than 24 hours.
The IWS system maintains an accountability log of all
transactions in the system. This log enables an audit
trail to be performed and also forms the basis for
system recovery and restart.
A comprehensive set of statistics is maintained by
the system. The statitics record is used for generation
of regular statistical reports.
System performance is continuously monitored and reported
to the system supervisor. A number of supervisory functions
allow the supervisors to change system parameters and
the communication line configuration.
2.3 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The functional description demonstrates that the outlined
IWS system fulfils the functional requirements of the
Request for Proposal.
This section describes the functions performed by IWS
with respect to message handling, system supervision,
statistics recording, transaction and message accounting,
and security.
2.3.1 M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Message Handling in IWS consists of the functions related
to message origination i.e. Message Preparation, Message
Coordination and Message Release plus Incoming Message
Processing, Outgoing Message Processing, Message Distribution
and Message Accountability.
Messages in transit between IWS and other systems shall
contain essential message information as described
in SWIFT. Incoming Messages in SWIFT format shall be
converted to a distribution format for delivery to
IWS subscribers while outgoing messages are converted
from preparation format to SWIFT or similar formats
for transmission.
All message data from SWIFTS will be subjected to format
analysis to detect errors and/or omissions prior to
acceptance of the data as a valid IWS message. Incoming
messages with anomalies or coming from none SWIFT networks
are referred to a IWS Operator for service. Messages
which are prepared at operator stations shall remain
in the preparation cycle until the essential message
elements have been correctly entered.
Messages which have passed format error analysis will
be automatically distributed to local terminals if
appropriate.
As with other automated message handling systems, IWS
is required to uniquely account for all message transactions.
IWS will process messages containing abbreviated name
of correspondent or institution, e.g. CITYBANK LA.
Each addressee in IWS may be associated with more than
one Routing Indicator, each of which may be valid in
different telegraph network.
IWS will provide storage for a number of predefined
report formats/headings for message preparation.
Both incoming and outgoing messages can be distributed
to many terminals and/or sent to and from terminal
a number of times.
2.3.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲W̲i̲r̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Incoming messages are validated for format accuracy
and the supervisor is informed of errors.
Character processing internal to IWS will be in the
ASCII alphabet. Messages may be received in other telegraphic
alphabets. However, they are translated to the ASCII
alphabet prior to processing and storage.
Format analysis will be completed on SWIFT messages
prior to delivery to IWS Subscribers.
Incoming messages are decoded before distribution to
the various departments. Verification of authority
is also done by IWS or by users.
Messages received over the SWIFT network will be processed
automatically. By use of system data base, verification
of authentication, overdraft, and position control
can be performed by the system. The necessary acccounting
entries can also be made.
2.3.3 O̲u̲t̲g̲o̲i̲n̲g̲ ̲W̲i̲r̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Messages which have passed through the message processing
functions contain the elements necessary to the generation
of SWIFT or similar format message as required prior
to IWS message transmission.
Authentication of messages prior to transmisson can
be done by aid of the system. A draft version of a
message can be routed to another terminal for authentication.
This electronic mail capability reduces much of the
manual and time consuming work in the present manual
procedures.
The system assigns and maintains two unique numbers
for each message entered into the system. The first
number identifies the division within which the message
was entered. The second number is taken for a global
number series within the hole IWS system. Both numbers
are reset once a day.
The numbers are used to indicate acknowledgement of
receipt. They are also used for reference purposes.
2.3.4 M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
The File Managment System will assist the System Software
located in the Processor Unit with the storage and
retrieval of both incoming and outgoing messages. The
messages will be retained on the on-line mass storage
for a period of 1 - 3 days.
The system will maintain in the Data Base all incoming
and outgoing messages for a period of 1 - 3 days from
their time of arrival (incoming) or their time of release
(outgoing). The IWS File Managemnt System has the full
control over the mass storage and thus able to insure
the message integrity. The period covered by the Data
Base depends on the number of messages which are retained.
The retrieval of messages will be possible from supervisor
and user positions through the use of a dedicated retrieval
procedure.
Retrieval will be possible for operator transactions
as well as messages. The operators will also be able
to retrieve the following transactions:
- First and last version of a message
- Notification of release
The retrieval of the transactions will be based on
a transaction number. The data to be presented will
be obtained from the message accountability log.
2.3.5 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The IWS supervisory functions provide the required
capabilities for message assistance, system status
and alarm monitoring, supervisory control, engineering
functions, and software maintenance.
The IWS supervisory functions can be divided into two
functional groups. One group provides the messsage
assistance functions required to perform service of
messages with erroneous message formats and to perform
distribution control. The other group implements the
functions which are required to manage the IWS system.
The message intercept functions can be allocated to
any number of ordinary IWS user terminals if appropriate.
It is thus possible in the early phase of the operation
life of IWS to have many message intercept positions
in order to cope with the initial percentage of messages
requiring manual assistance for processing. At a later
stage the message intercept handling can be retained
to one supervisory position.
A message intercept position is equipped with a VDU
and a hard copy printer. The hard copy printer is used
for logging og the transactions performed at the message
intercept position.
Messages are diverted to a message intercept positon
when format errors prevent automatic processing of
the message. The diverted message will be preceded
by a short report indicating the reason for diversion.
The message intercept handling is logically divided
into message servicing and distribution control. These
functions may be performed at physically separate terminals
or at the same terminal.
The message servicing function is concerned with correcting
inaccurate or garbled messages. The message servicing
operator has at his disposal message editing procedures,
means for entering routing information and provisions
for returning messages to the system. He is also able
to request rerun of messages at delivery channels as
well as directing a corrected message to a distribution
control position.
The message distribution control function supports
the automatic distribution function. Messages which
cannot be automatically distributed are sent to a distribution
control position preceded by a diversion report.
The authorization capabilities assigned to senior officers
(supervisors) prevents fraudulent or personal use of
the system. They assure that all messages requiring
manual processing are handled accordingly. Properly
routing can also be achieved by these functions. Likewise
thorough validation and priority assignments can be
performed.
The supervisory and engineering position is equipped
with a keyboard and a printer.
The supervisory and engineering position (SEP) has
the capability to configure the system functionally.
It can assign or reassign functions to the user terminals.
It has also control of the communications lines as
it can change communication line characteristics like
speed, block length and character length.
The SEP may designate additional supervisory positions
for message intercept functions.
Control system tables can be inspected and changed
by the SEP. This includes predetermined distribution
lists, tables for command processing, e.g. specification
of protected commands.
At the supervisory position reports are received for
- Statistics
- Wire performance
- Traffic Characteristics
- Security violation attempts
- Alarms and warnings
The reports are printed at the hard copy printer at
the SEP. The SEP is able to throttle reports by specifying
restrictive conditions for reports and thereby diverting
less urgent reports to back up storage at peak load
times.
A set of engineering functions are available for on-line
diagnostic test of the IWS system.
The Supervisory and Engineering position controls the
on-line IWS equipment. The total IWS configuration
is normally controlled from the System Status and Controller
(SSC) module. The SSC has a manual override capability,
thus making the SSC the ultimate configuration control
position.
To its disposal the supervisory and engineering position
has the capability to call up a printout of the overall
IWS status.
For terminals the following information is displayed.
- User profiles and department profile
- Line identification for each terminal
- Functions allocated to terminal (message preparation,
coordination, release, or supervisory function)
- Queue lengths
- Status of terminal
For communication channels the display shows:
- Routing information
- Line identification
- Queue lengths
- Status
This display shows a gross picture of the terminal
and wire channnel status. More detailed information
may be called up from the keyboard of the terminal.
A complete printout of the status of individual IWS
system components is provided by the System Status
and Controller (SSC) module.
The Security control position is assigned to a VDU
terminal. The functions allocated to this position
are of the highest security classification. They include:
- Initial allocation of operator identity codes
- Allocation of operator capabilities
2.3.6 B̲a̲n̲k̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
As a result of all released outgoing messages and all
properly received messages, the IWS will automatically
generate the associated Bank Account Transactions.
The established computer formats for outgoing messsages
will ensure that account transactions can be generated
automatically without operator assistance.
For incoming messages, only those received over the
SWIFT network can go directly into a computerized accounting
transaction generation, whereas all other received
messages require re-entry of some information within
the free format text received.
At the end of the day, all bank accounting transaction
can be copied to a magnetic tape, to be used as input
for another CICB system.
Optionally other CICB computers can be attached to
the IWS system by use of SNA protocols or the like.
2.3.7 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The IWS System data files will contain information
necessary to the statistical reporting requirements.
The statistical data for messages will be updated by
the various message processing modules. Other related
information such as channel status will be maintained
by the device servicing modules. Statistics related
to user message formats will be recorded by the User
Interface Modules.
The generation of statistical reports will be performed
by a special module for report generation. The module
will extract and compile the statistical information
necessary to report generation. The information will
then be formatted for display or printing at a user
station.
Input and Output message statistics will be compiled
for each incoming and outgoing channel and will be
maintained on an hourly and daily basis. The data items
to be recorded will include the total number of messages
received.
Channel availability and occupancy will be recorded
on an hourly and daily basis. Channel availability
is derived from channel status information (i.e. channel
availability is the amount of time during a reporting
period that the channel has an open status). Based
on the availability, the channel occupancy with traffic
will be calculated as a percentage of the availability.
Message distribution information will be recorded for
incoming messages and copies of outgoing messages.
System message totals and totals for each delivery
terminal will be maintained. Data items to be recorded
in relation to message distribution will include the
number of messages delivered.
2.3.8 M̲e̲s̲s̲a̲g̲e̲ ̲A̲c̲c̲o̲u̲n̲t̲a̲b̲i̲l̲i̲t̲y̲
Message Accountability in the IWS system will consist
of maintaining a log of information on all transactions
including those being terminated prior to completion
as well as having the equipment controlling all accountable
transactions.
The system will account for transactions with external
stations and transactions between the user/supervisor
and the equipment. Whenever anomalies are detected
a suitable warning report will be generated to the
supervisor. Based on the log of information in the
data base the supervisor will be able to inspect the
sequence of messages and transactions.
The information retained in the accountability log
will be of an uniform structure although it also will
contain information which depends on the specific transaction
covered. Each transaction of the system will be covered
by its own record in the accountability log. The following
record formats will be used to meet the various logging
needs caused by the different transactions:
- Incoming message
- Outgoing message
- Initial entry, message preparation
- Final entry, message preparation
- Security procedures
- Release
- Distribution
Each record of the accountability log will be uniquely
identified by a code indicating the type of the record,
a time stamp, and a unique reference identifier. The
time stamp used will be the time of receipt for incoming
messages, time of release for outgoing messages, and
time of initiation for all other transactions.
Furthermore, each record will contain sufficient information
as to further identify the transaction and the action
taken.
2.3.9 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
In order to achieve a system which provides a high
operational security, the proposed IWS system includes
security checks as an integral well-embedded part of
the entire system. In the proposed system solution
both the software and hardware meet this objective.
The system will distinguish between "attended" and
"unattended" operation of the terminal equipment. All
terminal equipment, communication lines, and users
of the IWS system will have an associated user's security
profile. This profile determines the allowed functions.
The profile may only be displayed and updated by the
supervisor.
The system will not permit access to sensitive information
without authentication and authorization control. Sensitive
data will not be displayed at an unattended terminal.
A terminal is changed to be attended by use of a sign-in
procedure. Each authorized operator will be issued
a unique identification code. This code will be entered
as part of the authenfication process during sign-in.
The code may be valid for a limited time.
2.3.10 E̲x̲t̲e̲r̲n̲a̲l̲ ̲W̲i̲r̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The interfaces between IWS and SWIFT, Telex, Telenet,
and Bankwire comprise different protocols.
S̲W̲I̲F̲T̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The IWS Systems exchange SWIFT messages with SWIFT
subscribers. Communications control messages will be
composed and dispatched automatically, as part of the
message level protocol.
The communications control procedures and formats are
laid down in a number of protocol levels, identified
as a SWIFT Message user level, a Service Message level,
a virtual channel level, a link level and a signal
level, the signal level being the lowest.
O̲t̲h̲e̲r̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
For other network subscribers less detailed protocols
or procedures exist.
3̲ ̲ ̲P̲R̲O̲P̲O̲S̲A̲L̲ ̲B̲R̲E̲A̲K̲ ̲D̲O̲W̲N̲
In the following subparagraphs the proposal is described
in the order suggested in the Request for Proposal.
3.1 D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
As part of this project Christian Rovsing A/S will
deliver a full set of documentation as specified in
the Implementation Schedule. This comprises:
- User Requirements Specification
- User formats
- Supervisor formats
- System Design (High Level)
- Detailed Design (Low level)
- Test procedures
3.2 M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲
The condition for H/W and S/W maintenance support can
be negotiated between CICB and Christian Rovsing A/S.
3.3 I̲W̲S̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲
The IWS software engineering profits from the message
processing and data communications system experience
which Christian Rovsing A/S has developed in projects
like NICS-TARE, CAMPS, a message preparation and reception
system for NATO, and FIKS, a data communication network
for the Danish Armed Forces.
The work packages cover:
- Development of IWS system specifications
- Building of the IWS system software package
- Building of the IWS application software package
- The IWS software as-built Documentation Package
The IWS software is divided into System Programs and
Application programs.
The IWS software provides for the basic message processing,
statistical reporting, priority handling, and man/machine
interface functions. It is divided into two categories:
system software and application software. The systems
software provides Executive Control for the IWS processor.
In addition, the systems software provides Executive
Cotnrol for the IWS processor. The systems software
handles the real-time dependent, hardware oriented
functions. These fall into the major categories of
input/output operations: interrupt handling, hardware/
software error processing, and the scheduling and execution
control of the applications level programs. The systems
programs provide the applications programs with a well-defined
and functional software interface which shields these
base units form the complexities of the hardware functions.
This interface allows an application level program
to request an input/output operation and then continue
its required processing. The systems programs control
the actual device handling, overlapping of I/O with
processing, plus any required device status checking
and error handling.
Using the hardware oriented services of the systems
programs, the applications level programs concentrate
on the actual message handling functions. These primarily
consist of user terminal handling, message preparation,
message traffic handling, message storage and retrieval,
creation of accounting transaction, statistical recording
and reporting, supervisory functions, and functions
for initialization, restart, and recovery.
The system programs are divided into the following
major functions: input/output device control, scheduling,
resource management, and error detection and processing.
Application programs operate under control of the operating
system, which is responsible for resource management,
memory managment and file management. The input/output
device control module consist of the I/O device request
interface plus individual device handlers for each
of the IWS processor's peripherals. Interrupt processing
coordinates the response to the various interrupts
from both internal and external sources. Error processing
coordinates all hardware/software fault indications
and makes them available to the applications programs
for further action. System start-up provides the necessary
system initialization to commence processing from a
cold start.
The off-line diagnostic programs provide for fault
handling capabilities at a more detailed level independent
of the IWS processor performing is normal functions.
FIGURE 3.3-1
3.3.1 C̲R̲8̲0̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The purpose of the system software is to create an
environment for multiprogramming with a clean and secure
interface between software processes.
The system software provides the IWS software with
scheduling and execution control, interrupt handling,
and interprocess communication functions.
The system software provides functions that are sufficiently
flexible to allow the applications program designer
to build a modular, hierarchical system of concurrent,
cooperating processes in a dynamically changing environment.
In spite of the flexibility, the system software functions
form clean and easily understood interfaces between
processes.
The processes executing applications programs are all
executed in user state, and are thus protected against
each other. The applications programs may only interact
through calls upon the system software, which consequently
is able to validate the interactions.
The system software further provides a set of functions
which interface the software processes (device drivers)
with the interrupt system of the computer system. The
interrupts may be transformed to resemble interprocess
communication messages.
The system nucleus is entered by issuing monitor call
(MON) instructions. The processor consequently switches
to the system state, and as the first action checks
the access profile of the calling process against the
profile of the function.
After approval of the access, the passed parameters
(register content and references) are validated.
Any illegal call or, illegal or dangerous parameter
will lead to immediate refusal of the function, and
the error will be reported.
In the CR80 system there is a clear distinction made
between programs and their executions, called processes.
This distinction is made not just logically but also
physically by applying two differenct base registers
one for program code and one for process data. This
distinction makes re-entrant, unmodifiable code inevitable.
The basic entities controlled by the system nucleus
are processes.
A process is a fundamental concept in CR80 terminology.
A process is an execution of a program module in a
given memory area. A process is identified to the remaining
software by a unique name. Thus, other processes need
not be aware of the actual location of a process in
memory, but must refer to it by name.
A process occupies a contiguous memory area with a
fixed base address and size during its lifetime.
The system nucleus maintains descriptions of all processes
in the IWS system. These descriptions include the base
addresses and bounds, user codes, priorities, and other
vital information to the system. The descriptions are
protected against the applications processes themselves
as they are located outside the boundaries of the process.
Because of their high classification level, certain
system processes are allowed execution in system state.
All other processes execute in user state and are thus
prevented from accessing memory areas outside their
own bounds. This, among other things, prevents modification
of access profiles.
D̲e̲v̲i̲c̲e̲ ̲D̲r̲i̲v̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲s̲
A device driver module is a software process which
handles a peripheral device connected to the CR80 computer.
Each hardware device connected to the CR80 computer
is controlled by a device driver process. This process
executes a program which is part of the system software.
A device driver operates principally in user state
(non privileged). However, some parts of its processing
require privileged instructions and manipulation of
data external to the process. Thus these parts of the
driver must be executed in system state.
The device drivers take care of the device peculiarities
and seek to create an uniform interface with the system.
The device drivers are in general able to handle several
commands at a time. That is, the time the device is
busy performing one operation, is used for preparation
and postprocessing of other commands.
The device drivers check the hardware equipment and
report failures to the error processing module.
Responses are evaluated for reasonableness and missing
responses are detected by the time-out mechanism of
the interrupt handling system.
Errors which may be remedied by a retry, will cause
the operation to be repeated a number of times before
an error report is issued.
Errors which cannot be corrected will lead to an immediate
error report and refusal of all subsequent commands.
V̲i̲s̲u̲a̲l̲ ̲D̲i̲s̲p̲l̲a̲y̲ ̲U̲n̲i̲t̲ ̲D̲r̲i̲v̲e̲r̲s̲
The VDU driver software provides the highest level
of terminal oriented processing for the IWS VDUs. The
next level of control is the message preparation applications
programs (accessed through the I/O System). The lowest
level is the LTU driver system software.
The VDU driver:
- Converts the stream of incoming characters to line-oriented
blocks, assisted by control information from the
LTU
- Uses flow control on the VDU communication to ensure
no-character-loss in all load situations
- Controls the basic character and line level screen
editing functions.
D̲i̲s̲k̲ ̲D̲r̲i̲v̲e̲r̲
The CR80 disk driver is a software module capable of
handling different disk drives.
Each disk driver process (and controller) is capable
of handling 4 units (drives) in a daisy-chained configuration.
If more than one unit is connected to a controller,
the disk driver will employ overlapped seeks. That
is, the disk driver will initiate seek operations on
one or more units, before initiating read or write
operations on another unit.
T̲a̲p̲e̲ ̲U̲n̲i̲t̲ ̲D̲r̲i̲v̲e̲r̲
The CR80 Tape Unit driver is a software module capable
of handling different tape drivers.
D̲e̲v̲i̲c̲e̲ ̲D̲r̲i̲v̲e̲r̲ ̲f̲o̲r̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲i̲n̲e̲s̲
The device driver for communication lines handles I/O
for synchronous and asynchronous communication lines
connecting IWS with SWIFT, Telenet, and Telex wires.
The device driver for communication lines is a functional
entity of the LTU driver. The driver provides the interface
between the I/O system and the data flow control submodule
of the LTU driver.
D̲e̲v̲i̲c̲e̲ ̲D̲r̲i̲v̲e̲r̲ ̲f̲o̲r̲ ̲P̲r̲i̲n̲t̲e̲r̲s̲
The device driver for printing devices handles output
for the IWS printers.
The printer driver formats output data in accordance
with the print format employed by the printer it also
automatically inserts New Line Functions in excessive
lines and pages output as required.
The printer driver also monitors the physical status
of the printing device (e.g. detects out-of-paper conditions).
S̲t̲o̲r̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Storage management controls both primary (RAM) and
secondary (DISK) storage.
The storage management of the IWS system is divided
into management of primary memory and management of
file (disk) space.
The file management system contains a security kernel
which prevents unauthorized access to data.
The memory management module controls the allocation
of an access to all primary storage (RAM) of the IWS
system.
The memory area of the central processors is allocated
and deallocated for programs and processes by the system
software.
Memory is allocated to programs during system start
up and by the loader.
Memory is initially allocated to processes during system
start up and also when processes create child processes.
Allocation of memory must be done by a call upon the
system nucleus (monitor), which ensures that the allocation
is permissable before allocating the necessary memory
area for the new process.
Each process shall be allocated a consecutive memory
area which is bound by the base and bound registers
of the process. The allocation mechanism assures no
overlapping of areas. The registers of a new process
are initialized by the system before it is activated.
At the time a process is removed, its memory area is
purged by the system software before the memory area
is deallocated. This prevents a later process from
reading left over information.
E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
The online error processing module maintains the general
status for the IWS system, and builds status reports
based on it.
The general status table is a hardware and software
configuration table which to each hardware and software
module of the IWS system has a connected status record.
The configuration table is updated when the error processing
module receives messages from the supervisor function
indicating a configuration change.
The hardware status records are updated upon reception
of error notices from device drivers or from the system
monitoring module:
The software status records are updated upon reception
of reports of malfunction of any of the software modules.
The seriousness of the error is evaluated on the basis
of its classification in one of seven groups and of
the importance of the failing software module.
The error processing module is also activated by power
failure interrupts which are generated when the System
Controller and Memory hardware measures a fluctuation
in the power supply.
At regular intervals the error processing module builds
a comprehensive status report, which is sent to the
SSC driver for transmission to the SS and C processor.
3.3.2 I̲W̲S̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲P̲r̲o̲g̲r̲a̲m̲
The IWS applications programs are online operational
programs, support programs and offline diagnostic programs.
The software is based on a modular design with a hieararchical
structure.
The IWS applications programs are divided into three
main categories:
o online operational programs which together with
the systems programs accomplish the message processing
tasks
o support programs for maintenance and test of the
online system
o offline diagnostic programs for offline fault detection
and fault isolation of the IWS hardware.
The IWS online applications programs are divided into
nine functional program modules.
These modules are:
o User Terminal Handler Module
o Message Preparation Module
o Message Traffic Handling Module
o Message and Transaction Accountability Module
o Message Storage and Retrieval Module
o Bank Accounting Transaction Module
o Statistics Module
o Supervisory Functions Module
o Initialization, Recovery and Restart Module
The functions performed by the applications program
modules are summarized in the following subparagraphs.
U̲S̲E̲R̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲H̲A̲N̲D̲L̲E̲R̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲U̲T̲H̲)̲
The User Terminal Handler Module (UTH) provides high
level control and handling of user terminals.
The UTH builds upon the functions provided by the Input/Output
device control of the CR80 system programs. It implements
the high level applications oriented functions related
to user terminal.
Basic transaction supports is supported. All interactive
use of VDU terminals is based on a transaction type
of processing which employes a number of specific formats,
one for each possible transaction.
The UTH implements a basic general table driven transaction
processor, which is capable of handling all the specific
IWS formats. The table driven design makes it easy
to implement new formats and to modify existing formats.
Further access control (sign in and sign out) and security
control is allocated to this module.
M̲E̲S̲S̲A̲G̲E̲ ̲P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲M̲P̲M̲)̲
The Message Preparation Module (MPM) implements the
functions necessary for preparation of outgoing messages.
These functions are provided in the following submodules:
o Initial Message Preparation Submodule. This submodule
is used to initially entering message parameters.
o Message Editing Submodule. This submodule supports
inspection, modification, blind entry or deletion
of current message contents in messages being prepared.
o Message Coordination Submodule. This submodule
implements the communication procedures related
to coordination of message preparation, i.e. distribution
of a message being prepared to other terminal positions
or departments.
o Message Release Submodule. This submodule handles
the functions in connection with release of messages,
and is responsible for notifying the message originating
terminal of the result of a release request. When
a message is released for dispatch, it is no longer
accessible for editing by the message originator.
M̲E̲S̲S̲A̲G̲E̲ ̲T̲R̲A̲F̲F̲I̲C̲ ̲H̲A̲N̲D̲L̲E̲R̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲M̲T̲H̲)̲
The Message Traffic Handler Module (MTH) processes
messages received from communication lines and messages
to be dispatched.
The MTH consists of two major submodules:
o Incoming Message Processing Submodule, which performs
SWIFT format analysis of incoming messages, when
appropriate and alphabet translation of messages
if required to the internal ASCII representation.
o Outgoing Message Processing Submodule, which performs
translation of messages from the preparation formats
to SWIFT format or the like and alphabet translation
as applicable to the wire in question. This submodule
is also responsible for routing.
M̲E̲S̲S̲A̲G̲E̲ ̲A̲N̲D̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲ ̲A̲C̲C̲O̲U̲N̲T̲I̲N̲G̲ ̲M̲O̲D̲U̲L̲E̲
The Message and Transaction Accounting Moduel (MTA)
maintains a log record of all transactions in the system.
The log which is available for inspection by the supervisor
contains information on all incoming and outgoing messages
and all transactions between the IWS-processor and
user terminals. Also transactions undertaken by the
system during message processing are logged.
M̲E̲S̲S̲A̲G̲E̲ ̲S̲T̲O̲R̲A̲G̲E̲ ̲A̲N̲D̲ ̲R̲E̲T̲R̲I̲E̲V̲A̲L̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲M̲S̲R̲)̲
The Message Storage and Retrieval Module (MSR) maintains
an online message file of all incoming and outgoing
messages. The messages are kept in storage for 24 hours.
Messages are available for retrieval from storage by
originators, original recipient and supervisors.
B̲A̲N̲K̲ ̲A̲C̲C̲O̲U̲N̲T̲I̲N̲G̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲B̲A̲T̲)̲
The Bank Accounting Transaction Module (BAT) creates
Bank Accounting Transactions from all incoming and
outgoing messages.
An internal message format with computer recognizable
fields are utilized to automate this feature.
At the end of each day all the days Bank Accounting
Transactions are written out on a magnetic tape. This
tape can be used as input for other computers.
S̲T̲A̲T̲I̲S̲T̲I̲C̲S̲ ̲M̲O̲D̲U̲L̲E̲
The statistics module (STM) collects data and compiles
statistics in order to measure system performance and
message processing characteristics.
The statistics module consists of three submodules:
o The message statistics submodule maintains statistics
about incoming and outgoing messages.
o The terminal statistics submodule maintains statistics
on terminal use of formats, and message processiong
profiles.
o The communication line statistics submodule maintains
statistics for communication wire performance.
S̲U̲P̲E̲R̲V̲I̲S̲O̲R̲Y̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲S̲F̲M̲)̲
To this module is allocated the supervisory functions:
o assistance to message processing
o monitoring of system status (status and alarms)
o modifications of communication wire configuration
o maintenance of system tables
o monitoring of security procedures
These functions are implemented in five submodules:
o The message processing assistance submodule is
responsible for displaying to the supervisor messages
with format syntax inaccuracies, which prevents
automatic processing. It also enables the supervisor
to edit such messages.
o The system status monitoring submodule displays
system status, alarms and fault indications to
the supervisor.
o The communication wire configuration control submodule
enables the supervisor to change communication
line allocation and parameters.
o The system table maintenance submodule enables
the supervisor to inspect and change basic system
tables.
o The security monitoring submodule is responsible
for notifying the supervisor on security violation
attempts by operators and violation attempts in
connection with communication lines processing.
I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲,̲ ̲R̲E̲C̲O̲V̲E̲R̲Y̲ ̲A̲N̲D̲ ̲R̲E̲S̲T̲A̲R̲T̲ ̲M̲O̲D̲U̲L̲E̲ ̲(̲I̲R̲R̲)̲
The Initialization, Recovery and Restart Module (IRR)
receives formatted error reports from the Fault Detection
and Error Processing Programs (part of the IWS system
programs). Fault detection is performed in the Online
Error Reporting Programs, in device drivers and in
all application programs.
The error reports are collected by the Watchdog submodule
(SSC) which regularly build a system error status report.
This report form the decision basis for the System
Configuration Control Module (hardware module).
The IRR module also contains the procedures for handling
of first level error recovery, second level error recovery
and restart.
3.4 H̲A̲R̲D̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲ ̲P̲A̲R̲T̲I̲T̲I̲O̲N̲I̲N̲G̲
The hardware configuration proposed for IWS is an integral
part of a total system concept which also includes
software and operational procedures. The system functions
were allocated between hardware, software or firmware
and partitioned so as to provide the most economical
implementation of IWS.
Christian Rovsing A/S proposes to implement IWS with
an integrated system composed of hardware, software
and operating procedures. The allocation of functions
between system elements has resulted in the hardware
configuration described in this section. This configuration
has been further partitioned into well-defined sub-systems
or equipment groups.
Continuous ON-LINE operation and system availability
are ensured by duplicating essential subsystems and
critical data paths. The dualized configuration allows
unrestricted reassignment of Processor Units and peripherals
subsystems and line terminations.
Highly redundant and quickly reconfigurarable, the
dualized hardware configuration proposed for IWS was
especially designed for reliable continuous on-line
operation. Stringent system availability requirements
are met by reliable processor units and peripheral
subsystems interconnected by multiple selectable data
paths. The configuration is depicted in figure 3.4-1.
Unique hardware features result in highly distributed
processing, storage and terminal management. The major
subsystems contain multiple CPUs and numerous microprocessors
are spread throughout the configuration. The modular
system architecture results in a total message handling
throughput and line connectivity limited only by the
physical constraints of the installation. This section
will highlight the most significant system-level features.
Another unique system element highly specialized for
real-time switching applications such as IWS is the
System Status and Controller. Because it is microprocessor-based,
this unit provides rapid system reconfiguration and
continuously senses and displays system status. The
SSC operates in the manual or automatic mode. In the
manual mode it quickly executes reconfiguration commands
initiated by the system supervisor. In the automatic
mode, it monitors periodic self-diagnostic information
received from the PUs and, dependent on switchover
and recovery programs,
initiates a change of on-line/standby processor assignment.
Fig. 3.4-1 IWS Hardware Configuration
It also prevents interferences to on-line operation
by blocking faulty, standby, or inactive elements.
The SSC is fail-safe reverting back to manual operator
control upon failure, and can be manually overridden
from the system control panel.
Duplication of the critical data paths coupled with
multiple entry ports permit unrestricted assignment
of the peripheral subsystems to either Processor Units.
The critical data paths include mass storage DMA channels,
and main memory data highways.
Dualized power supplies and distributed power buses
complete the system dualization.
Thus the elements essential to continuous IWS operation
and the critical interconnecting data paths are all
dualized and selectable. The software and application
programs have complete flexibility in the use of the
redundant processors, memory systems, mass storage
and front-end LTUs.
The processor unit CPU system as shown in fig. 3.4-2
is composed of a dual set of PUs capable of independent
operation, each with multiple CPUs, memory modules,
transfer and control bus; their operation within the
system is coordinated and monitored by the System and
Status controller (SSC).
The channel unit (CU) as shown in fig. 3.4-3 is dualized
within itself. The CU contains dualize disccontrollers
and LTUs are attached to both of the two I/O buses
A and B.
The LTUs are used as front end processors for VDUs,
printers and external channels.
figure ???
figure ???
S̲Y̲S̲T̲E̲M̲ ̲S̲T̲A̲T̲U̲S̲ ̲A̲N̲D̲ ̲C̲O̲N̲T̲R̲O̲L̲L̲E̲R̲ ̲(̲S̲S̲C̲)̲
The IWS hardware configuration is continuously monitored
by the system Status and Controller. Switchover of
the Central Processors from active to stand-by can
be under automatic or manual control. Reconfiguration
commands from the ON-LINE processor or system control
console are executed by a microprocessor in the SSC.
Fig. 3.4-4.
The System Status and Controller, SSC, continuously
monitors the operational status and functioning of
the IWS configuration. When a failure is detected,
SSC sets an alarm and sends a control message to the
stand-by PU and to the system console; in most cases
this will initiate a central processor switchover.
Peripheral failure will result in partial reconfiguration,.
The current configuration status is displayed at the
system panel at all times.
The SSC operates in two modes: manual or automatic.
In the automatic mode the peripherals are claimed and
controlled by the ON-LINE processor; in the manual
mode, peripheral assignments and reconfiguration are
initiated or overriden at the Status Control Panel
or by a system control transaction through the system
control console.
This section lists and describes the functions performed
by the SSC. Other sections of the proposal discuss
the recovery and switchover programs and operating
procedures involved in the overall configuration control.
The SSC monitors and controls the status and availability
of all major subsystems through hard-wired interfaces
and data channels. The Processor Units each report
status and receive commands through a 9600-baud (V24/V28)
data channel. All ports of the Main Memory are monitored
and controlable by direct wiring.
The major subsystems which interact with the SSC are:
o Processor Units
o Main Memory Systems
o Disc Drives
o Tape Drives
o LTU Drives
tegning
S̲Y̲S̲T̲E̲M̲ ̲S̲I̲Z̲I̲N̲G̲
The use of modular hardware to configure IWS installations
accommodates the initial sizing of the system, variation
in future installation, adaptations to network differences,
changes and future expansions.
Proper sizing of the IWS hardware configuration is
made easier by the inherent modularity of the proposed
hardware. Sizing involves primarily the allocation
of storage and provisions for an adequate number of
line terminations, the quantities and sizes being adjusted
to fit the variation of the different installations.
R̲E̲Q̲U̲I̲R̲E̲D̲ ̲H̲/̲W̲ ̲M̲O̲D̲U̲L̲E̲S̲
In fig. 3.4-5 all H/W modules used for the IWS system
are listed together with the quantities needed and
the respective prices in Danish Kroner.
deliverable equipped
3.5 I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲S̲C̲H̲E̲D̲U̲L̲E̲
For planning purposes the IWS project has been broken
down into a number of work packages. In the following
a description of each package is given. In fig. 3.5-1
a schedule is depicted starting at year 0 (contract
agreement).
S̲Y̲S̲T̲E̲M̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲
This document will define the overall plan for the
development of the "Integrated Wire Services" system
- IWS.
The plan will address all tasks from system definition
and implementation of hardware and software components
to integration of these components into identified
subsystems.
S̲Y̲S̲T̲E̲M̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
This document will exhaustively specify the requirements
to the IWS system as derived from the CICB Request
for Proposal Package and from clarifications to this
made by CICB in the early stages of the IWS project.
The specification will emphasize on the external requirements
to the IWS system, i.e. all the functional capabilities
and the connectivities, the performance and the availability
requirements.
U̲S̲E̲R̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲ ̲A̲N̲D̲ ̲A̲S̲S̲O̲C̲I̲A̲T̲E̲D̲ ̲F̲O̲R̲M̲A̲T̲
This Interface Control Document will describe all those
functions and capabilities given to normal users of
the IWS system. It will depict all formats to be used
by user for message preparation and receiption.
S̲U̲P̲E̲R̲V̲I̲S̲O̲R̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲ ̲A̲N̲D̲ ̲A̲S̲S̲O̲C̲I̲A̲T̲E̲D̲ ̲F̲O̲R̲M̲A̲T̲S̲
This Interface Control Document will describe all those
functions and capabilities given to supervisor (senior)
users of the IWS system. It will depict all formats
to be used for controlling and monitoring of the system.
S̲W̲I̲F̲T̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
This interface Control Document will describe the SWIFT
related procedures and the protocols related to the
SWIFT system.
O̲T̲H̲E̲R̲ ̲W̲I̲R̲E̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
This Interface Control Documents will describe all
procedures and protocols related to none SWIFT wires.
S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲I̲G̲N̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
This document will give a specification of the internal
design-related requirements. All H/W and S/W packages
will be identified and described in general terms.
D̲E̲T̲A̲I̲L̲E̲D̲ ̲D̲E̲S̲I̲G̲N̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
This document will give a thorough description off
all modules and units to be coded. It will be used
as input for coding. The three phases will be documented
separately.
C̲O̲D̲E̲ ̲A̲N̲D̲ ̲T̲E̲S̲T̲
The three phases are coded and tested separately based
on the respective Detailed Design Specification.
3.6 S̲Y̲S̲T̲E̲M̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲C̲O̲N̲S̲I̲D̲E̲R̲A̲T̲I̲O̲N̲S̲
Throughout this IWS proposal deep considerations have
been dedicated to the reliability availability aspects
of the IWS system. It has been described how the IWS
system can overcome system failures and continue live
operation.
Only in the rare case of double errors in related subsystem,
a total system failure will occur.
In case of system failures the online error reporting
module will aid the computer operator in identifying
the faulty module. Due to the modular design of the
hardware any faulty module can be easily removed and
replaced with a spare module.
3.7 P̲R̲I̲C̲E̲ ̲B̲R̲E̲A̲K̲D̲O̲W̲N̲ ̲(̲B̲u̲d̲g̲e̲t̲t̲a̲r̲y̲ ̲c̲o̲s̲t̲s̲)̲
All prices are listed in Canadian Dollars, but they
are based on Danish Kroner. Exchange rate on time of
proposal is Kr. 6,00 per 1 Canadian Dollar.
C̲a̲n̲a̲d̲i̲a̲n̲ ̲D̲o̲l̲l̲a̲r̲s̲
Program Management 1,000,000
System Engineering 600,000
Hardware Development 200,000
Software Development 2,000,000
Documentation 50,000
Hardware Equipment ̲ ̲5̲0̲0̲,̲0̲0̲0̲
Total 4,350,000
