top - download
⟦5f9c792f7⟧ Wang Wps File
Length: 21264 (0x5310)
Types: Wang Wps File
Notes: FIKS SYSTEM EXT: PROP
Names: »5699A «
Derivation
└─⟦b3c9a9699⟧ Bits:30006142 8" Wang WCS floppy, CR 0015A
└─ ⟦this⟧ »5699A «
WangText
…0c… …86…1
…02…
…02…
…02…
…02…
FIKS SYSTEM
EXTENSION
SYS/85-02-01
TECHNICAL
AND COST
PROPOSAL
Page
#
PROPOSAL FOR
FIKS-NICS TARE INTERFACE
BASE LINE UPDATE
TABLE OF CONTENTS
1 SCOPE ............................................
3
2 DOCUMENTATION ....................................
4
3 PROPOSAL SOLUTION CONCEPT ........................
5
4 PROPOSED SOLUTIONS ...............................
6
4.1 ASM-HANDLING .................................
6
4.2 ASM-RELATED UPDATE ...........................
11
4.3 SIGNALS FOR INTERCEPT ........................
12
4.4 ADDITIONAL CR80-MEMORY .......................
13
4.5 FINAL TESTING OPTION .........................
13
5 HARDWARE SPECIFICATION ...........................
14
6 SOFTWARE SPECIFICATION ...........................
15
7 DEVELOPMENT, TEST, DOCUMENTATION .................
16
8 PRICE SUMMARY, PRICE BREAKDOWN ...................
17
8.1 DEVELOPMENT COSTS ............................
17
8.2 HARDWARE COSTS ...............................
18
8.3 OPTION COSTS .................................
18
9 BIDDING PROVISIONS ...............................
19
9.1 VALIDITY .....................................
19
9.2 DELIVERY .....................................
19
9.3 PAYMENT PLAN .................................
19
1 S̲C̲O̲P̲E̲
This document provides an unsolicited proposal for
modification of the FIKS System concerned the FIKS-NICS
TARE Interface.
Refer to AMC letter: AHK. 601.1768-102,
dated 24 January, 1985.
The modification shall include changes and updatings
of the existing FIKS System to get the present FIKS-NICS
TARE Interface to function as intended. The proposal
covers the following main items:
1. At the time when the interface was delivered, the
NICS TARE side of the interface was not ready.
Since then changes in the interface specifications
has occured. This concerns mainly "Abreviated Service
Messages" (ASM's) and the open-/close-link procedure.
This shall be incorporated in the interface.
2. Whereas the FIKS-system has been used, different
errors and inconveniences related to the FIKS-NICS
TARE link has been discovered. The correction of
that will be included in this proposal.
3. The FIKS-NICS TARE link has to be tested in real
environment, when the NICS TARE side gets ready.
The testing may lead to discovering of errors,
which must be corrected. This porposal contains
therefore an option, by which AMC after request
will get qualified personnel from CR to participate
in these activities.
2 D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
The following documents are required to establish a
firm base line for the modifications.
1) FIKS SYSTEM SPECIFICATION
FIX/1000/PSP/0038
2) FIKS DATA I/F REFERENCE
FIX/0100/MAN/0004
3) FIKS ISH PROCESSES PSP
FIX/1160/PSP/0091
4) NICS TARE Communication Subsystem
FIX/1162/DSP/0012
5) NICS Telegraph Automatic Relay Equipment (TARE)
Technical Interface Criteria, Issue 4,
dated March, 1983
6) FIKS REQUIREMENT SPECIFICATION
FIX/0000/SPC/0002, issue 5, p. 249-274 (sec. 3.1.1.3.2.4.3)
7) PROPOSAL FOR FIKS SYSTEM EXTENSION,
SCC CONVERSION LOG & RETRANSMISSION PROCEDURE,
dated 84-12-14
8) AMC letter: TST.604.8228/312.1-635, dated
2 November 1984.
9) AMC letter: AHK.601.1768-102, dated 24 January,
1985
3 P̲R̲O̲P̲O̲S̲A̲L̲ ̲S̲O̲L̲U̲T̲I̲O̲N̲ ̲C̲O̲N̲C̲E̲P̲T̲
The modifications will be implemented with as few as
possible changes in the existing FIKS S/W and H/W to
reduce the amount of effort involved.
The proposed solution assumes that the activities concerned
other FIKS System modifications are carried out. Refer
to ref. 7 + 8.
To overcome the problem concerned the limited amount
of spare CR80 - program memory, implementation using
"background processing" will be used. In case the the
CR80- computers at a latter point of time will be equipped
with the XAMOS System, the background processing can
be transferred to ordinary processing and thereby improving
the performance.
Test configurations used at the development will be
implemented in a way, that they, by slight modification,
can be used at related development/testing.
4 P̲R̲O̲P̲O̲S̲E̲D̲ ̲S̲O̲L̲U̲T̲I̲O̲N̲S̲
4.1 A̲S̲M̲-̲H̲A̲N̲D̲L̲I̲N̲G̲
An outline is shown in figure 4.1.
The following ASM's shall be known and processed by
the FIKS-System.
ASM's transmitted from FIKS to NICS TARE:
- Open Channel (QRV), ref. 5, sec. 10.6.2.1.
The ASM is despatched when the SCC-supervisor issues
an "Open Channel"- command. The incoming channel
is hereby opened for narrative messages. The event
is logged in the "Conversion Log".
- Close Channel (QRT), ref 5, sec. 10.6.2.2.
The ASM is despatched when the SCC-supervisor issues
a "Close Channel"- command. The incoming channel
is hereby closed for narrative messages. The event
is logged in the "Conversion Log".
- Flash Receipt (R Z), ref. 5, sec. 10.6.2.5.
FIKS will after reception of a flash-precedence
message despatch this ASM.
- Channel Account/Final Numbers (ZID), ref. 5, sec.
10.6.3.2.3.
FIKS will after reception of a message with a TI
(Transmission Identification) equal to 1 or when
the SCC-supervisor issues a "Reset TI's"- command,
reset its own TI's (incoming and outgoing) and
despatch the ASM. The event (including last received
TI) is logged in the "Conversion Log".
- Channel Check, ref. 5, sec. 10.6.2.6.
The SCC-supervisor can by issueing the "Check Channel"
- command initiate despatch of this ASM. The ASM
will automatically be despatch after the "Open
Channel"- ASM (test of channel). The return of
the ASM is expected within 15 minutes. Return/timeout
will be logged in the "SCC-Event Log".
FIGURE 4.1
ASM HANDLING OUTLINE
- Channel Continuity, ref. 5, sec. 10.6.2.7.
If the outgoing channel is open and no outgoing
traffic has taken place in a period of 5 minutes,
then FIKS will despatch this ASM.
ASM's received from NICS TARE by FIKS:
- Open Channel (QRV), ref. 5, sec. 10.6.3.1.1.
FIKS will not despatch any narrative messages before
this ASM has been received. The event is logged
in the "Conversion Log".
- Close Channel (QRT), ref. 5, sec. 10.6.3.1.2.
FIKS will not despatch any narrative messages after
this ASM has been received. The event is logged
in the "Conversion Log".
- Flash Receipt (R Z), ref. 5, sec. 10.6.3.2.5.
FIKS expects to receive this ASM within 5 mnutes
after despatch of a flash procedence message. When
it is received or timeout occurs, this is logged
in the "Conversion Log".
- Channel Account/Final Numbers (ZID), ref. 5, sec.
10.6.2.2.3.
FIKS will check that the TI, contained in the ASM,
confirms with that of FIKS. The event (including
the last TI received by NICS TARE) is logged in
the "Conversion Log". If the TI-checking fails,
then the logging will be marked with "Outgoing
TI-missing".
- Channel Check, ref. 5, sec. 10.6.3.1.5.
The incident will be logged in the "SCC Event Log".
- Channel Continuity, ref 5, sec. 10.6.1.6.
FIKS expects to receive this ASM if the incoming
channel is open and nothing else has been received
within 6 minutes. If not then "Missing Channel
Continuity" will be logged in the "SCC-Event Log".
- Other ASM's received.
The event will be logged in the "SCC Event Log"
including at least the first 32 characters of format
line 12. (Unknown ASM).
An ASM will by FIKS be identified as such if the general
ACP127- format specified in ref. 6 is observed and
the routing indicators (RI's) in format line 2 + 3
contains one and only one of two unique RI's - a "FIKS"-
RI or a "NICS TARE"- RI.
The implementation of the abovementioned is outlines
as follows: (ref. figure 4.1):
- A new ASM-process is introduced. This process generates
upon request (contained in an AMOS-message) the
required ASM and enqueues it to the CPM-process.
A new logical "ISH-channel" (ref.3) will be associated
to the AMS's. This channel is used to separate
ASM- and narrative message traffic.
- The CPM-process will enqueue the ASM directly into
the NICS TARE-queue. CPM will receive the acknowledge
from NICS TARE and is in this way capable to control
the ASM-flow to NICS TARE.
- Incoming ASM's will be routed to the MAS-process
together with the narrative messages. …02…MAS shall
be updated such that it is able to extracxt ASM's
from the message flow and enqueue them directly
to the ASM-process.
- The ASM-process, shall analyse the received ASM's,
perform the necessary updating (channel status
changes), initiate the required logging and inform
the other processes if needed.
- The ASM-process shall be the controller of timeout
of "Check Channel"- answers, "Missing Channel Continuity"
and "Flash Receipt". To do this the TIMER- process
is used. The TIMER-process will have to be updated.
In case timeout occurs, then the ASM shall initiate
the required loggings.
- The IOMP-process in the NICS TARE Subsystem (ref.4)
shall supervise "outgoing channel continuity",
i.e. initiate despatch of "Channel Continuity"
- ASM if required.
- The MAS-process will supervise "incoming channel
continuity" and report in case of "Missing Channel
Continuity".
- The TEPTNT-process shall be updated so that the
range of SCC-supervisor commands is expanded with
"Open Channel", "Close Channel", "Check Channel"
and "Reset TI's. The execution of the commands
is handed over to the ASM-process via an AMOS-message.
- The CPM-process shall initiate despatch of "Flash
Receipt" when the event is sensed, and inform the
ASM-process to start timeout-test, in case a flash
message is despatched.
4.2 A̲S̲M̲-̲R̲E̲L̲A̲T̲E̲D̲ ̲U̲P̲D̲A̲T̲E̲
Certain features has, caused by the introduction of
ASM's into the FIKS System, been actualised. This concerns:
- Incoming TI-checking.
The TI-sequence of incoming messages will be checked
continuously. If the checking indicates missing
messages, this will be logged as "Incoming TI missing"
in the "Conversion Log". If the incoming TI equals
1 an "Final Numbers" -ASM shall be despatched to
NICS TARE. The MAS-process will perform the abovementioned.
- TI-checkpointing.
The TI's (incoming and outgoing) will be checkpointed,
so that the FIKS System after start/restart is
able to continue the TI-sequence and perform correct
TI-accounting with NICS TARE. The MSA-, ASM-processes
will checkpoint outgoing TI's, the MAS-process
the incoming TI's.
- Reset TI-command
After start/restart or switch off
NICS TARE-connection (to another site) the TI-sequences
may be undefined. This problem can be overcome
by the SCC-supervisor by issueing a "Reset TI"-command.
The outgoing TI will be reset (=1) and a "Final
Numbers" - ASM will be despatched to the NICS TARE.
The FIKS expects next incoming TI to be 1.
- Switch between manual/real NICS TARE Interface.
When the NICS TARE interface is going to be used,
a transition period can be foreseen. In this period
need for switching between the present "Manual
NICS TARE"-interface and the becoming "Real NICS
TARE"-interface in an easy way is required. This
is complied with implementation of the SCC-supervisor
commands - "Use Manual NICS" and "Use Real NICS".
The events will be reflected in the "SCC Event
Log". The difference of the cases appears on the
MSA- and ASM-processing. The affected processes
shall be adapted to distinguish between the two
cases.
4.3 S̲I̲G̲N̲A̲L̲S̲ ̲F̲O̲R̲ ̲I̲N̲T̲E̲R̲C̲E̲P̲T̲
When messages from NICS TARE are sent for intercept,
they are halted in the SCC waiting to be handled by
an operator. If the SCC goes STANDBY or the SCC-fails
(drops out of the FIKS network), then the intercepted
messages are stuck in the SCC, i.e. lost for the FIKS-network.
The situation is similar to that of messages sent to
internal conversion or to the NICS TARE (refer to ref.
8). To overcome this the following is proposed:
- Every message sent for intercept at the SCC shall
have a copy of it placed in the SIP-queues at the
collocated Node/MEDE. This implies that a copy
of an incoming intercepted NICS TARE-message must
be transferred to the SIP-queues. The CPM-process
shall, when it becomes aware of that an incoming
NICS TARE has been intercepted, see to that a copy
is distributed to the collocated Node/MEDE.
- The intercepted messages in the SIP-queues shall
be placed there until they are successful intercepted
and converted. (At present they are acknowledged
by the ISH-system, i.e. deleted from the SIP-queues,
at the moment they are sent for intercept). In
this way intercepted messages will be covered by
the reliability, that characterises the dual Node/MEDE-design.
The pseudo-acknowledge performed by the CPM-process
at intercept of messages must be exchanged with
an "Intercept Notice". The SIP-queues must be reorganized
and expanded.
- The checkpointing concerned message-traffic at
the SCC-installation can be eliminated. Instead
all the mesages in the SIP-queues shall be transferred
to the SCC for renewed conversion/intercept each
time the SCC goes ACTIVE. The SCC shall, when it
becomes STANDBY, clear all message queues. (to
avoid duplicate messages). SCC-restart/switchover
will not be needed. This will elinimate several
error cases raised, at SCC-restart. Implementation
of "Intercept Logging" (ref.8) will be mush easier
too.
- A procedure, which assures that the intercepted
messages are re-intercepted whatever happens, has
to be worked out.
A "real SIP-timout" is proposed. In the existing
FIKS system, messages in the SIP-queues are sent
for distribution on the collocated Node/MEDE with
reason "SIP-timeout" when a certain number of conversions
has taken place. Instead the messages shall be
sent for distribution after a certain time limit
(shall be different with cases not-intercepted/intercepted
message). The "SIP-timeout" - message can be reentered
into the ISH-system either by the "DT-reenter"-procedure
(to the collocated SCC) or by "Retransmission-
procedure as proposed in ref. 7 ( to the opposite
SCC). No messages can be stuck or lost. The SPM-process
shall be updated to handle real SIP-timeout".
As a by-product of the proposed solutions the following
is obtained too. When identical messages (same message
ID's) are processed in the SCC, severe errors can occur
(MAC #42-error). This can be avoided by not letting
identical messages pass from the SIP-queues to the
SCC. This can now easily be performed. When a message
arrives to the SIP-queues, it is checked, if it exists
already- if so it is just deleted.
4.4 A̲D̲D̲I̲T̲I̲O̲N̲A̲L̲ ̲C̲R̲8̲0̲-̲M̲E̲M̲O̲R̲Y̲
The solutions proposed in the preceedings will demand
extra CR80-memory. It is therefore proposed that each
SCC in the FIKS System gets equipped with more memory.
2 x 32 K RAM- modules is proposed.
4.5 F̲I̲N̲A̲L̲ ̲T̲E̲S̲T̲I̲N̲G̲ ̲O̲P̲T̲I̲O̲N̲
As the FIKS-NICS TARE link has never been tested in
real environment, the existing FIKS-NICS TARE Interface
may contain some concealed errors not convered by any
contractors guarantee. These error, whenever they are
detected, has to be corrected. A test of the FIKS-NICS
TARE interface in full scale must be performed when
the NICS TARE is ready. Test-procedures must be specified,
scheduled and performed. The result of the testing
shall be analysed and possible discovered errors corrected.
An option which includes the abovementioned activities
is therefore proposed. CR shall after request from
AMC within 2 months place qualified personnel at desposal
for participating in the activities. The option will
cover a maximum of 4 man month in a period of 12 month
from contract signature.
5 H̲A̲R̲D̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The only hardware involved in this proposal is the
additional CR80-memory mentioned in sec. 4.4. I.e.
2 x 32K RAM, one in each SCC-computer.
6 S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The propsed solutions are implemented by adding/updating
of the following software modules of the FIKS-system.
- New ASM-process
Generation and control of ASM's
- CPM-process update.
ASM-distribution, Flash Receipt-supervision.
- IOMP-process update
Outgoing Channel Continuity supervision.
- MAS-process updated
Adaption for AMS's, NT-intercept message transfer
to SIP-queues. Incoming Channel Contintuity supervision,
TI-checkpointing.
- MSA-process update
Real/Manual NICS switching, TI-checkpointing.
- SPM-process update
New SIP-queue structure, Real SIP-timeout.
- TEPINT-process update.
New SCC-supervisor commands.
- HSP-process udate.
New SCC-event loggings.
- SMAILB-critical region update
New "ASM-ISH logical channel", extra "Conversion
Log"- entries.
- Miscellaneous FIKS-update.
New queues, TIMER-process updated,
Checkpointing updates, etc.
7 D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲,̲ ̲T̲E̲S̲T̲,̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
Development (design and coding) and low level module
testing will take place at CRAS, Ballerup. High level
module tests, integration tests and acceptance test
shall take place at the FIKS Test System at Vedb`k.
Occasionally employment of the operational SCC at Vedb`k
may occur. AMC must arrange for the abovementioned.
The acceptance test procedure shall be approved by
AMC before the test is carried out.
A document containing the product specification for
the solutions and test procedures, will be issued and
delivered to AMC before integration test is started.
The needed update of system software interface documents
will be specified as DCN's to the existing documents.
8 P̲R̲I̲C̲E̲ ̲S̲U̲M̲M̲A̲R̲Y̲,̲ ̲P̲R̲I̲C̲E̲ ̲B̲R̲E̲A̲K̲D̲O̲W̲N̲
The total cost of the proposals will be:
1̲,̲3̲7̲5̲,̲4̲9̲1̲.̲0̲0̲ ̲K̲r̲.
8.1 D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲C̲O̲S̲T̲S̲
Manpower consumption in weeks of 38.75 hours
Task Manpower Duration/Weeks
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Management E1 6
Design/Documentation E1 25
S/W coding/Module test E2 23
Integration/Acceptance Test E2 6
Secretariate S1 4
Technical Support T1 1
MANPOWER COSTS
Manpower Weeks Price/hour Price
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
E1 31 574 689,517,50
Kr.
E2 29 437 491,078,75
Kr.
T1 1 373 14,453,75
Kr.
S1 4 324 50,220,00
Kr.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Total 1,245,270,00
Kr.
E1: Senior Engineer T1: Technician
E2: Junior Engineer S1: Secretary
8.2 H̲A̲R̲D̲W̲A̲R̲E̲ ̲C̲O̲S̲T̲S̲
Module Name QTC Unit Price Price
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
RAM 32K 2 65,111.00 kr. 130,222.00
kr
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Total 130,222.00
kr
8.3 O̲P̲T̲I̲O̲N̲ ̲C̲O̲S̲T̲S̲
"Time and Material" - accounting at rates valid at
the time of invoicing.
Note: Option Costs is not included in Total Price.
(ref.8.1)
9 B̲I̲D̲D̲I̲N̲G̲ ̲P̲R̲O̲V̲I̲S̲I̲O̲N̲S̲
9.1 V̲A̲L̲I̲D̲I̲T̲Y̲
The aforementioned costs are under assumption that:
1. Sufficient spare CR80-memory is available to contain
the extended software modules.
2. The FIKS test system and the SCC-installation at
Vedb`k will available for testing of the proposed
solution at the needed scope.
3. The proposal in ref. 7 is accepted.
4. Acceptance of this proposal is performed before
30 APR. 1985.
All prices are quoted at price level February, 1985.
These prices are subject to price variation in accordance
with labour/material indices.
9.2 D̲E̲L̲I̲V̲E̲R̲Y̲
The proposal solution (H/W and S/W) can be delivered
for installation 10 months after signature of contract.
9.3 P̲A̲Y̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲
30% at Contract Signature
20% at Design Completion
20% at Code Completion
20% at Acceptance
