top - download
⟦19909b399⟧ Wang Wps File
Length: 15737 (0x3d79)
Types: Wang Wps File
Notes: FIKS System Extension
Names: »5633A «
Derivation
└─⟦b3c9a9699⟧ Bits:30006142 8" Wang WCS floppy, CR 0015A
└─ ⟦this⟧ »5633A «
WangText
FIKS SYSTEM
EXTENSION SYS/84-12-14
TECHNICAL
AND COST
PROPOSAL Page
#
PROPOSAL FOR
FIKS SYSTEM EXTENSION
CONCERNING
SCC CONVERSION LOG
AND
RETRANSMISSION PROCEDURE
TABLE OF CONTENTS
1 SCOPE ........................................
2
2 DOCUMENTATION ................................
2
3 PROPOSAL SOLUTION CONCEPT ....................
3
4 PROPOSED SOLUTIONS ...........................
4
4.1 SCC CONVERSION LOG .......................
4
4.2 RETRANSMISSION OF MESSAGES ...............
7
5 HARDWARE SPECIFICATION ....................... 10
6 SOFTWARE SPECIFICATION ....................... 11
7 DEVELOPMENT, TEST, DOCUMENTATION ............. 12
8 PRICE SUMMARY, PRICE BREAKDOWN ............... 13
8.1 DEVELOPMENT COSTS ........................ 13
8.2 HARDWARE COSTS ........................... 14
9 BIDDING PROVISIONS ........................... 15
9.1 VALIDITY ................................. 15
9.2 DELIVERY ................................. 15
9.3 PAYMENT PLAN ............................. 15
1 S̲C̲O̲P̲E̲
This document provides an unsolicited proposal for
modification of the FIKS System as described in AMC
letter: AHK.601.1728-1090 dated 23 November, 1984.
The modifications concerned are with two objects:
1. SCC Conversion Log
- All messages passing a conversion procedure
(SMF to ACP127, ACP127 to SMF) shall be logged.
2. Retransmission of Messages
- One message or messages in a DTG-range can
be object for retransmission. The modification
shall especially enable retransmission of messages
from FIKS to NATO.
This proposal covers all S/W and H/W (except additional
terminal equipment) needed to implement the modifications.
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 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) AMC letter AHK.601.728-1090
dated 23 November, 1984
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 shall 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 implementation
shall be performed, considering the limited resources,
in the shape of spare CR80-memory.
R̲e̲.̲ ̲S̲C̲C̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲L̲o̲g̲
The logging is performed when a message enters/leaves
the ISH Subsystem. A new kind of terminal "LOG PRINTER"
will be introduced in the FIKS System. This will be
a "Receive Only Printer", that uses the same hardware
printer as those connected to the existing VDU-terminals.
No input operations will be supported. To implement
this, a new kind of LTUX is introduced (LTUX-log).
This will be a modification of the existing LTUX-tele.
The solution shall be used as a model for future extension/modification
of log-functions used in the FIKS-system.
R̲e̲.̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
A retransmitted message shall, for the receiver, look
just like if it was received as an intended original.
It must be possible to specify a subset of the original
message addressees, which then will receive the message.
No other than those specified addressees, must receive
the message. To implement this a new kind of message
has been introduced. "Retransmission Message", which
will have its own identity. The existing FIKS Software
must learn to handle this.
4 P̲R̲O̲P̲O̲S̲E̲D̲ ̲S̲O̲L̲U̲T̲I̲O̲N̲S̲
4.1 S̲C̲C̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲L̲O̲G̲
An outline is shown in figure 4.1
The information concerning which message that enter/leave
the ISH Subsystem (ref.3), i.e for which conversion
is started/completed, is contained in the CIP-SIP-
and SIP-SIP keep alive control messages. They are at
the SCC-colocated Node/MEDE delivered to the SWD-process
(SIP-watchdog), which then places them in the critical
region SMAILB, where they can be inspected by other
processes. The input to the "SCC Conversion Log" will
be based upon the mentioned control messages.
The existing keep alive traffic shall be expanded to
contain information enough to format a log-record as
described in ref. 4.I.6. The number of fields has to
be increased. The control messages must also contain
information about the incoming NICS-FIKS-messages as
"Start of ACP127-SMF-conversion" and "Conversion Completed".
This implies that:
- the layout of the critical regions SMAILB, CMAILB
and the keep alive control messages must be modified.
- the processes that access SMAILB and CMAILB must
be modified so that they can perform the required
extended updating. This concerns the processes
CWD, CPM, MAS at the SCC's and SWD, SPM at the
colocated Node/MEDE's.
- "flow control" of the SIP-SIP keep alive traffic
must be introduced. No later oncoming antimessages
(used at event: leave ISH-system) must overwrite
the preceeding ones. This is to ensure the same
logging on both ACTIVE and STANDBY SCC.
A new process CVLOG (Conversion Log Printer Process)
is implemented. This shall, when notified by the SWD-process,
format the log-records based upon the SMAILB-content.
The records are written into the CVF-disk file. The
CVF-file has a structure and size like the existing
MJF-file (Message Journal File).
…86…1 …02… …02… …02… …02… …02…
FIGURE 4.1
SCC CONVERSION LOG OUTLINE
After the records have been stored they are printed
on the particular allocated Conversion Log Printer
in case the logging is of the type "leave of ISH-system",
i.e. conversion completed. Later on, all the records
(or part of them) can be printed at the request of
the supervisor. By keying in an appropriate supervisor
command, he will initiate the printout.
The printout is performed using a "LOG PRINTER". This
will be a new kind of FIKS-terminal, using a minimum
of resources, and with the special purpose of performing
log printout. An existing ordinary FIKS-terminal might
have been used, but this would imply occupation of
a valuable message terminal and thereby decrease further
extension possibilities. The hardware printer to be
used shall be of the same type as the one used together
with VDU-terminals, i.e 300 band printers with the
full ASCII-character set available, it is necessary
to introduce a new kind of corresponding LTUX-device
into the red TDX-system. This will be a modification
of the existing LTUX-tele, i.e. an LTUX-S with the
possibilitiy of connecting up to four log printers.
This can be exploited in future extension/improvement
of the FIKS system.
4.2 R̲E̲T̲R̲A̲N̲S̲M̲I̲S̲S̲I̲O̲N̲ ̲O̲F̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲
An outline is shown in figure 4.2.
A retransmitted message shall after retransmission,
for the receiver, look like it never was retransmitted,
i.e. Message id, release DTG, from/to addresses, address-marking,
etc must not be changed caused retransmission. This
indicates that at least a complete copy of the original
message has to be transmitted (incl. the ANO-.list).
Anyway the message has to be routed in a different
way (only to a subset of the original addressees).
This indicates a different ANO-list to be used. The
following is proposed:
A retransmitted message contains both the original
ANO-list (the old) and the one used at retransmission
(the new). The new ANO-list is added to the end of
the old message. The items, message length and ANO-list
offset, in the binary header is updated to confirm
with the new ANO-list. The new ANO-list will contain
the old
FIGURE 4.2
"RETRANSMISSION OF MESSAGE" - OUTLINE
ANO-list offset, so that the old ANO-list still can
be accessed as an ANO-list. The message will be marked
as a "retransmitted message" by using a spare bit position
in the binary header. This will ensures that the message
always can be processed in the correct way.
The network- and distribution routines in the FIKS
network will in this way not be affected. The retransmitted
messages will be stored as such in the HDB. The processes
that access the signal text will have to distinguish
between retransmitted/not retransmitted messages. This
concerns the following:
- the PIP-, MAS-, MSA-, TERM-processes has to be
updated so that they skip the old ANO-list as signal
text.
- the PIP-process shall use the old ANO-list for
address-marking.
- the MSA shall use the new ANO-list when the routing
indicators are set up. (building format line 2).
A new supervisor procedure as described in ref. 4-II.4
to be used in preparation of retransmitted messages
will be implemented. The steps 1-4 will be like preparation
of a readdressed message, except no new message id,
no FM ̲ -prompt. The ordinary message header preparation
will be used (AIG's, XMT's, etc.) If the ANO does not
exist in the old ANO-list, the operator is notified
and the keying is refused. The message will be automatically
released for transmission in the network, when the
preparation is finished. I.e. no editing and listing
of the message is possible.
When the DTG-range option is used a different approach
will be used. The SRR-process (the Storage Retrieve
Process) will receive the request. When SRR in the
affected DTG-range finds a message that has an ANO
pointing on a NATO-address, it will insert all such
ANO's in the new ANO-list and release the message to
the network. In this way only NATO-addressees will
receive a retransmitted message.
Retransmitted messages will be object for checkpointing,
Message Journal logging, statistics, etc. in the usual
standard FIKS manner.
5 H̲A̲R̲D̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
To implement "SCC Conversion Log" an extra LTUX-S shall
be added to the existing H/W-configuration at each
of the two SCC colocated Node/MEDE's. It is assumed
that vacant resources in the form of creates, fans,
power suppliers, etc are available.
6 S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The proposed solution is implemented by adding/updating
of the following S/W and H/W of the FIKS system baseline.
R̲e̲.̲ ̲S̲C̲C̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲L̲o̲g̲
- LTUX-tele firmware update
- New CVLOG-process is added
- ISH subsystem update, expansion of keep alive traffic,
- TERM-process update, supervisor procedure. Print
of Conversion Log.
- Miscellaneous FIKS module update, new queue structure,
LCFH-files update, etc.
R̲e̲.̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
- New supervisor procedure: "RTM", ref. 4-II
(TERM-process + SRR-process update)
- Adaption of the process PIP, MAS and MSA to handle
"Old ANO-list is not signal text".
- PIP-process updating: "Marking of Addresses".
- MSA-process updating: "Use new ANO-list to build
format line 2".
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 will take place at CR84AS's Development
System at Ballerup. Module-, Integration- and Acceptance
tests shall take place at the FIKS Test System at Vedb`k.
Integration- and acceptance procedures will be prepared.
The acceptance test procedure shall be approved by
FMK before the acceptance test is arranged.
A document containing the product specification for
the final solutions and the test procedures, will be
issued and delivered to FMK 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 proposal will be:
SCC Conversion Log : 457.802,00 Dkr.
Retransmission of Messages : 3̲2̲2̲,̲6̲7̲1̲,̲2̲5̲ ̲D̲k̲r̲.̲
Total 7̲8̲0̲.̲4̲7̲3̲,̲2̲5̲ ̲D̲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
T̲a̲s̲k̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲L̲o̲g̲ ̲ ̲ ̲^̲ ̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲^̲
̲ ̲T̲o̲t̲a̲l̲ ̲
^ ^ ^
Management (E1)^ 1 ^ 1 ^ 2
Design/Document- ^ ^ ^
ation (E2)^ 6 ^ 6 ^ 12
S/W Coding/Module ^ ^ ^
Test (E2)^ 14 ^ 10 ^ 24
Integfration/Accept ^ ^ ^
ance Test (E2)^ 1 ^ 1 ^ 2
Secretariate (S1)^ 1 ^ 1 ^ 2
Technical Support(T1)^ 1 ^ ^ 1
E1: Senior Engineer
E2: Junior Engineer
T1: Technician
S1: Secretary
M̲A̲N̲P̲O̲W̲E̲R̲ ̲C̲O̲S̲T̲S̲:̲
SCC Conversion Log:
^ ^ ^
M̲a̲n̲p̲o̲w̲e̲r̲ ̲ ̲^̲ ̲ ̲W̲e̲e̲k̲s̲ ̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲/̲h̲o̲u̲r̲ ̲ ̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲ ̲ ̲D̲k̲r̲.̲
̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
E1 ^ 1 ^ 574 ^ 22,242.50
E2 ^ 21 ^ 437 ^ 355,608.75
T1 ^ 1 ^ 373 ^ 14,453.75
S1 ^ 1 ^ 324 ^ 12,555.00
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Total 404,860.00 Dkr.
Retransmission of Messages:
^ ^ ^
M̲a̲n̲p̲o̲w̲e̲r̲ ̲ ̲^̲ ̲ ̲W̲e̲e̲k̲s̲ ̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲/̲h̲o̲u̲r̲ ̲ ̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲ ̲ ̲D̲k̲r̲.̲
̲ ̲ ̲ ̲ ̲ ̲
E1 ^ 1 ^ 574 ^ 22,242.50
E2 ^ 17 ^ 437 ^ 287,873.75
S1 ^ 1 ^ 324 ^ 12,555.00
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Total 322,671.25 Dkr
Both Proposals:
^ ^ ^
M̲a̲n̲p̲o̲w̲e̲r̲ ̲ ̲^̲ ̲ ̲W̲e̲e̲k̲s̲ ̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲/̲h̲o̲u̲r̲ ̲ ̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲ ̲ ̲D̲k̲r̲.̲
̲ ̲ ̲ ̲ ̲ ̲
E1 ^ 2 ^ 574 ^ 44,485.00
E2 ^ 38 ^ 437 ^ 643,482.50
T1 ^ 1 ^ 373 ^ 14,453.75
S1 ^ 2 ^ 324 ^ 25,110.00
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Total 727,531.25 Dkr
8.2 H̲A̲R̲D̲W̲A̲R̲E̲ ̲C̲O̲S̲T̲S̲ (only "SCC Conversion Log")
M̲o̲d̲u̲l̲e̲ ̲N̲a̲m̲e̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲Q̲T̲C̲ ̲ ̲^̲ ̲ ̲U̲n̲i̲t̲ ̲P̲r̲i̲c̲e̲ ̲^̲ ̲ ̲P̲r̲i̲c̲e̲ ̲D̲K̲r̲.̲
^ ^ ^
Standard LTUX-S ^ 2 ^ 23,855.00 ^ 47,710.00
Back Panel ^ 2 ^ 2,027.00 ^ 4,074.00
Cable (MB-BP) ^ 2 ^ 579.00 ^ 1,158.00
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
Total 52,942.00
Dkr.
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 the assumption that:
1 Vacant resources in the form of crates, fans, power
supplies, etc. are available
2 Sufficient spare CR80- memory is available to contain
the extended software modules.
3 The FIKS test system at Vedb`k shall be available
for testing of the proposed extensions.
4 Acceptance of this proposal is performed before
1 MARCH, 1985.
All prices are quoted at the price level December,
1984. These prices are subject to price variation in
accordance with labour/material indices.
9.2 D̲E̲L̲I̲V̲E̲R̲Y̲
The proposed FIKS-extensions (H/W and S/W) can be delivered
for installation 8 months after signature of contract.
9.3 P̲A̲Y̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲
40% at Contract Signature
30% at Start of Module Tests
30% at Acceptance
