top - download
⟦9c3ba4884⟧ Wang Wps File
Length: 22113 (0x5661)
Types: Wang Wps File
Notes: P.O. CRA + CR CORP
Names: »0711A «
Derivation
└─⟦ecb9329a3⟧ Bits:30006006 8" Wang WCS floppy, CR 0041A
└─ ⟦this⟧ »0711A «
WangText
)…06…(…86…1
…02… …02…
…02… …02…
- # -
C̲O̲N̲T̲E̲N̲T̲S̲ ̲O̲F̲ ̲C̲O̲N̲T̲R̲A̲C̲T̲
S̲p̲e̲c̲i̲a̲l̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲
Clause 1 Scope of Contract
Clause 2 Price
Clause 3 Payments
Clause 4 Schedule
Clause 5 Development Plan
Clause 6 Documentation
Clause 7 Technical Baseline Documents
Clause 8 Work Package Description
Clause 9 Contract Deliverable Items
Clause 10 CR A/S Supplied Equipment/Products
Clause 11 Reviews
Clause 12 Approval of Design Documents
Clause 13 Acceptance
Appendix A: General provisions
Appendix B: Schedule
Appendix C: Deliverable Items Description
Appendix D: Detailed Work Package Description
ORDER AGREEMENT…01…FOR CAMPS…01…BETWEEN CR A/S AND CR CORP.
1. S̲C̲O̲P̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲R̲A̲C̲T̲
This order agreement defines the equipment services
and associated terms and conditions for CR CORP. development
and delivery of LTU-firmware related to the LITSYNC
protocol.
2. P̲R̲I̲C̲E̲
The development/delivery items listed under clause
8 and 9 are delivered at a fixed price of:
U̲S̲ ̲#̲ ̲1̲2̲9̲.̲6̲0̲0̲
3. P̲A̲Y̲M̲E̲N̲T̲S̲
Payments will be released upon receipt/approval of
the deliverables listed under clause 9.
A down payment of 30% of the price is released at the
time of contract signature.
10% is released at delivery and approval of package
A (refer clause 9).
10% is released at delivery and approval of package
B.
25% is released at delivery and approval of package
C (refer clause 9).
25% is released at delivery and approval of package
D (refer clause 9).
4. S̲C̲H̲E̲D̲U̲L̲E̲
The development effort shall be divided into four phases
which are:
- preliminary design
- detailed design
- implementation
- acceptance
The development schedule is presented in Appendix B.
5. D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲
C. Rovsing Corp. shall no later than two weeks after
contract signature produce a "Development Plan" which
complies with the Sub-contract Management Plan and
Procedures CPS/PLN/001 and addresses the following
subjects:
- development schedule
- WBS (Work Break-down Structure)
- WP (Work Package) Description
- Organization and responsibilities
- Milestones
- Dependencies to CR A/S
- Plan for acceptance test
6. D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
The design documentation i.e. preliminary, detailed
and as-built-design specifications shall be in accordance
with CAMPS Design Standards CPS/STD/001.
Test planning documentation shall be in accordance
with CAMPS Software Test Plan CPS/TSP/001 and the UDF-standard
contained in CPS/STD/001.
7. T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲B̲A̲S̲E̲L̲I̲N̲E̲
This clause defines the technical baseline by referencing
the specifications which are applicable and the scope
of the applicability.
Reference Documents:
I CAMPS REQUIREMENTS SPECIFICATION
CPS/210/SYS/0001, Issue 3
II CAMPS SYSTEM DESIGN SPECIFICATION
CPS/SDS/001, Preliminary 1981-01-15
III ACP127 NATO SUPP. 3 PROCEDURES
CPS/230/ICD/0003, Issue 2
IV NICS TARE INTERFACE
CPS/ICD/004, Issue 1
V Subset of (as defined in ref. IV):
SUBSYSTEM SPECIFICATION FOR THE TARE FOR THE
NICS (VOL. IV) APP. 30 AND 40. DOC 177000-600F
OF 29 JUNE 1979 with DCN G2 of 15 FEB 1980.
VI DAMOS SYSTEM REQUIREMENT SPECIFICATION
CSS/006/SPG/0001
VII CAMPS ADDITIONAL REQUIREMENTS TO DAMOS STANDARD
SOFTWARE, Issue 2 1980-10-10.
VIII CR80 LTU I/F DEVELOPMENT SPECIFICATION
CSD-MIL/430/DSP/0002, Preliminary
IX LTU OPERATING SYSTEM AND SUPPORT SOFTWARE
The technical baseline is defined by ref. II section
4.7 IO Control Software, the NICS-TARE interface requirements
(ref IV and V) and LTU operating system and support
software specifications (ref. IX).
The implementation shall be in accordance with general
design requirements as defined in Ref. I, II, VI, and
VII including special security measures.
8. W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
This clause identities the major components and associated
capabilities to be developed by CR CORP as part of
this order of agreement.
The task is to develop the LTU Protocol Software and
the V24/Crypto control line drivers (here called V24
drivers) in accordance with the technical baseline
(Clause 7) expanded with the specification in Appendix
D.
Main functions of the LTU Protocol SW are:
To implement the EDC protocol from the level of a segment
interface down to the software interface for V24 drivers.
Main function of the V24 drivers are to control the
synchronous communication on the V24 lines to control
the BIO 1000 Crypto.
9. C̲O̲N̲T̲R̲A̲C̲T̲ ̲D̲E̲L̲I̲V̲E̲R̲A̲B̲L̲E̲ ̲I̲T̲E̲M̲S̲
The deliverable items have been grouped into four delivery
packages A,B,C, and D.
The schedule for deliviries are presented in Appendix
B.
Below the delivery packages are defined by the associated
deliverable items. A more detailed description of
the deliverable items is contained in Appendix C.
P̲a̲c̲k̲a̲g̲e̲ ̲A̲
LITSYNC Protocol Development Plan (refer clause 5)
CPS/PLN/XXX
P̲a̲c̲k̲a̲g̲e̲ ̲B̲
LITSYNC Protocol Preliminary Design Specification
CPS/SDS/XXX
P̲a̲c̲k̲a̲g̲e̲ ̲C̲
LITSYNC Protocol Detailed Design Specification
CPS/UDF/XXX
P̲a̲c̲k̲a̲g̲e̲ ̲D̲
1 - LITSYNC Protocol Product Specification
(As-built) CPS/UDF/XXX
2 - Source Code and Listings
3 - Acceptance test drivers, test specification, test
procedures and test results.
10 P̲U̲R̲C̲H̲A̲S̲E̲R̲ ̲S̲U̲P̲P̲L̲I̲E̲D̲ ̲E̲Q̲U̲I̲P̲M̲E̲N̲T̲ ̲A̲N̲D̲ ̲P̲R̲O̲D̲U̲C̲T̲S̲
CR A/S shall supply CR CORP with the following equipment
and products:
1. 1 LTU, type CR8066 (16 + 16K, 4 channels)
2. LTU Operating System
3. LTU Queue/Buffer Handler
4. LTU/CR80 I/F Software
5. Documentation of the above products 1-4.
Equipment and Products (1-4) shall be delivered at
completion of detailed design (Refer Appendix B).
Documentation (5) shall be delivered to CR CORP. no
later than one month after contract signature.
11 R̲E̲V̲I̲E̲W̲S̲
Reviews of preliminary and detailed design specifications
shall be held at CR A/S with one or more participants
from CR CORP.
The period scheduled for each review is one week elapsed
time.
12 A̲P̲P̲R̲O̲V̲A̲L̲ ̲O̲F̲ ̲D̲E̲S̲I̲G̲N̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
The preliminary and detailed design specifications
shall be approved by CR A/S.
13 A̲C̲C̲E̲P̲T̲A̲N̲C̲E̲
CR CORP shall establish an acceptance test to be performed
at CR A/S when the product is delivered.
Acceptance criterias are established as part of the
detailed design package and shall be approved by CR
A/S.
The acceptance test shall be performed on a configuration,
where the LTU is connected to an CR80D (mapped version).
CR CORP shall stay on-site until the acceptance test
has been completed successfully.
A̲P̲P̲E̲N̲D̲I̲X̲ ̲B̲
D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲c̲h̲e̲d̲u̲l̲e̲
This appendix presents the master schedule, which shall
be expanded in the development plan to be produced
by CR CORP (refer clause 5).
The schedule presents furthermore the events at which
the deliverables shall be delivered by CR CORP to CR
A/S.
Time Schedule
A̲P̲P̲E̲N̲D̲I̲X̲ ̲C̲
D̲E̲L̲I̲V̲E̲R̲A̲B̲L̲E̲ ̲I̲T̲E̲M̲S̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The purpose of this appendix is to define contents
and scope of each of the deliverable items.
1. D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲
Requirements to the development plan are as defined
in the CAMPS Subcontract Management Plan CPS/PLN/001.
2. P̲R̲E̲L̲I̲M̲I̲N̲A̲R̲Y̲ ̲D̲E̲S̲I̲G̲N̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The purpose and the scope of the preliminary design
shall be to define the complete software architecture/structure
of the software package.
All modules to be developed shall be defined, as well
as their functional capabilities.
A complete functional breakdown shall be performed
and the functions shall be allocated to the software
modules.
The preliminary design shall contain data flow and
control logic between the software modules.
All common data, files, and tables shall be defined
during preliminary design.
Interfaces to other software packages as well as internal
(i.e. between software components such as modules,
tasks and/or processes) shall be defined during the
preliminary design.
The documentation standard to be followed during preliminary
design is the Subsystem Design Specification Standard
contained in CPS/STD/001.
To obtain a consistent software design documentation,
all preliminary software design packages shall comply
with the table of contents presented overleaf.
C̲A̲M̲P̲S̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
T̲a̲b̲l̲e̲ ̲O̲f̲ ̲C̲o̲n̲t̲e̲n̲t̲s̲
1 GENERAL
…02……02…1.1 PURPOSE AND SCOPE
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
1.3 TERMS AND ABBREVIATIONS
2 SUMMARY OF REQUIREMENTS
2.1 PACKAGE DESCRIPTIONS
2.2 PACKAGE FUNCTIONS
2.3 CHARACTERISTICS
3 ENVIRONMENTS
3.1 EQUIPMENT
3.2 SUPPORT SOFTWARE
3.3 INTERFACES
3.3.1 System Interfaces
3.3.2 Package Interfaces
3.4 Security
4 PACKAGE DESIGN
4.1 PACKAGE OVERVIEW
4.1.1 Functional Specification
4.1.1.1 Functional Breakdown
4.1.1.2 Functional Flow
4.1.2 Software Structure
4.1.3 Functional Allocation
4.1.4 Data Flow and Control Logic
4.2 MODULE SPECIFICATION
4.2.x Module x
4.2.x.1 Functional Capabilities
4.2.x.2 Software Structure
4.2.x.3 Processing
4.2.x.4 Interfaces
4.2.x.5 Module Data
4.3 Memory Lay-Out
4.4 Common Data
3. D̲E̲T̲A̲I̲L̲E̲D̲ ̲D̲E̲S̲I̲G̲N̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
The detailed design package shall contain module design.
The modules defined during preliminary design shall
be designed to "code-to" level.
The detailed design package shall furthermore contain
test specifications as described in the CAMPS Software
Test Plan CPS/TSP/001.
The detailed design package shall be documented in
accordance with the UDF standard and the module design
standard contained in CAMPS Design Standards CPS/STD/001.
The detailed design shall furthermore comply with the
software design guidelines and engineering requirements
defined in CPS/STD/001.
4. A̲C̲C̲E̲P̲T̲A̲N̲C̲E̲ ̲P̲A̲C̲K̲A̲G̲E̲
The elements making up the acceptance package are those
defined according the UDF standard which are:
- requirements
- functional capabilities
- "as-built" design
- source listings (floppy disc + printout)
- test specifications/procedures
- test drivers
- test results
- test bed
The deliverable items related to test shall comply
with the CAMPS Software Test Plan CPS/TSP/001.
A̲P̲P̲E̲N̲D̲I̲X̲ ̲D̲
Detailed Work Package Description.
The description below shall be seen as a detailed description
of the NICS TARE control section in Clause 7, the technical
baseline ref. II, section 5.7. It is an addition of
a level of detail, in order to define the functions
of the NICS TARE Handler and the functions of the LTU
Protocol Software (TARE LTU) and the interface between
the two.
The sections D.1.2, and D.2 are fully applicable to
the work package description, where the sections D.1
(up to D.1.1) and D.1.1 are only included for completeness.
D.1 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲C̲O̲N̲T̲R̲O̲L̲
The NICS TARE Control implements the NICS TARE Specification
interface between CAMPS application software and the
electrical interface lines for Local or Remote NICS
TARES.
The function of NICS TARE Control are implemented in
the NICS TARE Handler and in the LTU Protocol Software.
Fig. D.1 presents an overview.
In this context there is one incarnation of the NICS
TARE Handler and one incarnation of the LTU Protocol
Software per channel. The Handler executes in the
CR80D processor unit and the LTU Protocol Software
executes in the CR8066D LTU.
Fig. D.1
D.1.1 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲H̲A̲N̲D̲L̲E̲R̲
The NICS TARE Handler implements the interface between
application and system software data transfer requests
and the queue interface of the LTU. It includes for
the application:
- Conversion from the CAMPS internal message record
format to the sequential character string format
required by NICS TARE and build of segments as
required by the EDC protocol.
- Conversion from the sequential character string
format delivered by the EDC protocol to the internal
message record format.
- Generation of responses to application.
- Transfer of preempt and cancel requests to the
LTU Protocol SW.
- Transfer of responses from LTU Protocol SW to application.
and for the system control software:
- Transfer of channel and protocol control commands
to and from the LTU Protocol SW.
D.1.2 L̲T̲U̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
1. D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The LTU protocol software implements the EDC protocol
as specified in clause 7, the technical baseline
ref. IV and V from the level of error free segments
down to the level 1. It receives segments of message/LCB
data from the Handler for transmission and it returns
acknowledge of error free transmission of the segment
to the Handler, or notification of irrecoverable
errors.
It delivers error free segments to the Handler
and withholds segment acknowledge transmission
until the Handler has acknowledged the delivery.
In order to perform the above LTU Protocol Software
handles generation, transmission, retransmission,
and reception of all block types, i.e. D, LCB,
EOM, EOS, ACK, ACKC, NAK, NAK2, NAKF, SETB, RR
and handles all error checking, counters and timeouts
as required to perform the error free transmission.
The LTU Protocol Software fits into the CAMPS system
environment as described in clause 7, the technical
baseline Ref. II and further detailed below in
the interface description.
This means:
Implementation of Channel and protocol control
commands received from the Handler.
Collection of status of protocol errors and delivery
to Handler upon request.
Delivery of error reports on irrecoverable errors.
Implementation of Cancel and Preempt command.
Implementation of Crypto (BIO 1000) control.
Interface to and by the LTU standard software as
described in:
ref. II section 5.7 for general
ref. VIII for CR80D - LTU interface
ref. IX LTU operating system and support Sw
Interface to V24 drivers (part of this work package)
The LTU Protocol Software resident in one LTU handles
two NICS TARE channels of possible different speed,
security classification and different channel and
protocol control parameters. The resources available
must be so administered, that overload or error
conditions on one channel does not influence the
capability to support the other channel.
2. P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
The LTU Protocol software shall per LTU be able
to support two full duplex 2400 baud EDC controlled
channels at full speed running in the standard
LTU software environment.
The LTU Protocol Software together with the V24
drivers shall in program size not exceed 7 Kbytes.
The LTU Protocol Software and the V24 driver Software
data space required for operation of two channels
as outlined above shall including buffers required
for the proper function of the EDC protocol and
required for the proper function of the interface
to the Handler shall not exceed 8 Kbytes.
Data areas used for handling each of the two NICS
TARE channels shall except for queue and buffer
pools be completely separated and so structured,
that by adding memory and processing power, the
number of NICS TARE Channels handled can be expanded.
D.2 H̲A̲N̲D̲L̲E̲R̲ ̲-̲ ̲L̲T̲U̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
The interface is via queues as described in Clause
7 technical baseline ref. VIII.
Per NICS TARE channel two LTU-CR80D channels are used.
With the definition in Clause 7, technical baseline
ref. VIII para 3.1, it could for example be channel
2+3 for one and channel 4+5 for the other NICS TARE
Channel with 6+7 and 8+9 as spares for extensions.
The two channels are configured as Data Channel and
as Control Channel and combined with the direction,
they are defined as:
DATA OUT
Direction: Handler - LTU
CONTROL OUT
DATA IN
Direction: LTU - Handler
CONTROL IN
Queue elements refer to interface buffers.
The interface buffers are laid out as follows:
1. byte: Spare = 0
2. byte: Type
3. + 4. byte: Identifier
5. + 6. byte: Length of interface data = N-6
7. - N: Interface data (N - 518)
T̲h̲e̲ ̲T̲y̲p̲e̲ is a system generation parameter defining
the segment type.
T̲h̲e̲ ̲i̲d̲e̲n̲t̲i̲f̲i̲e̲r̲ is a reference defined by the generating
part (either Handler or LTU-Protocol SW). It is used
as a reference of acknowledge, cancel etc. as follows:
The HANDLER defines for outgoing segments the identifier.
When the segment is correctly transmitted, the acknowledge
control function (see below) returns this identifier,
which will make it possible for the handler to react
accordingly. The Protocol SW sends with an incoming
segment an identifier. When the Handler acknowledges
the acceptance (e.g. storage on disk), it returns the
identifier.
T̲h̲e̲ ̲L̲e̲n̲g̲t̲h̲ is the 16 bit integer defining the number
of bytes of Interface data. For DATA IN + OUT, the
length is up to 512 bytes., for CONTROL IN, CONTROL
OUT, it is never more than 32 bytes. (To be revised
when all control interfaces are defined).
D̲A̲T̲A̲ ̲I̲N̲,̲ ̲D̲A̲T̲A̲ ̲O̲U̲T̲
Type*): First Segment of Message
Intermediate Segment of Message
Last Segment of Message
One Segment Message
LCB Segment
Idenfier: For DATA OUT, the identifier is generated
by the Handler, which will use this for
future identification of the same segment.
For DATA IN, the Handler will in the acknowledge
use the identifier supplied by the Protocol
SW.
Length: For DATA OUT, the Handler will in most
cases of type First and Intermediate generate
segments of 512 bytes. (For performance
estimates, it can be assumed, that the
average length of these types is at least
450. It is TBD if 512 is always generated).
For DATA IN, the Handler will accept any
length, but will assume an average as above
of at least 450.
Interface
Data: Transmitted or received data.
Queue
Length: The DATA-IN queue shall never exceed 2
segments, the DATA-OUT never 2 segments.
By queue length is here meant for DATA-IN
the number of segments ready for Handler
processing, but not acknowledged, and for
DATA-OUT the number of segments queued
for Protocol SW, but not accepted for transmission.
The max. number of acknowledge segments
should not exceed, i.e. one on either side
and one in transmission.
*) Note: for DATA IN, the types First segment and
One Segment Message are defined as the
first DATA segment/EOM segment following
an EOM segment.
C̲O̲N̲T̲R̲O̲L̲ ̲O̲U̲T̲
Type: Level 1 Control (TBD)
Open
Close (including ordered close down TBD)
Setup (including definition of control
parameters)
Reset
Set control parameters (retransmission
count, timecount for message and LCBs timeout
for RRs, blocksize)
Acknowledge segment
Cancel
Preempt
Get status
Identifier: For Level 1, Open, Close, Setup, Reset,
Set Control and Get Status:
defined by Handler.
For Acknowledge segment the value given
by
the Protocol SW when segment delivered.
For Cancel the value earlier supplied
by
the handler in DATA-OUT.
For Preempt TBD.
Length: TBD when exact layout of commands defined.
Interface
Date: Level 1 TBD (Speed, Crypto control)
Open none
Close Definition ordered close
down or immediate.
Setup Retransmission Count
Message & LCB timeout
RR timeout
Blocksize
Reset None
Set Control
Parameter As setup
Acknowledge
Segment None
Cancel*) None
Preempt*) Number of characters from
first block of message,
where preemption is not
allowed. Number of
characters from message
start after which
preemption should not be
performed.
Get Status None.
*) For function see below.
F̲U̲N̲C̲T̲I̲O̲N̲ ̲O̲F̲ ̲C̲A̲N̲C̲E̲L̲ ̲A̲N̲D̲ ̲P̲R̲E̲E̲M̲P̲T̲
The Cancel cancels the identified segment and all following
segments in DATA-OUT.
The Preempt preempts the identified message. If this
message is not in transmission (either not initiated
or completed), the Preemption shall be refused.
C̲O̲N̲T̲R̲O̲L̲ ̲I̲N̲
Type: Level 1 control response TBD
Level 1 reports TBD
Open Response
Close Response
Setup Response
Reset Response
Set Control parameter response
Acknowledge segment response (unknown segment)
Cancel Response
Preemption Response
Status Response
Segment Acknowledge (of correct transmission)
Irrecoverable error reports
Identifier: Responses: the ident. of the request
Reports: none
Segment ACK: The identifier at DATA-OUT
Lenght: TBD.
I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲A̲T̲A̲
Details TBD. The Cancel and Preempt must supply at
least the identifiers of cancelled/preempted segments.
Status must supply statistics on errors of various
types since last request.
